CSS Overkill?

[niche]

Why does Open Realty software ('s developer) feel the need to actually "insert" the entirety of every CSS file?

Why not just write proper <link ...> statements?

This seems very much like overkill?

Is there a reason?

[Mick]

Why does Open Realty software ('s developer) feel the need to actually "insert" the entirety of every CSS file?

Why not just write proper <link ...> statements?

This seems very much like overkill?

Is there a reason?


I think it's just the way we did it to be honest..

I'm not a CSS expert by far but I wasn't familar with external linked style sheets being the "Proper" way to include CSS. I also don't think that making a post that sounds like an attack is not the way to go about having your suggestions considered. If you think something can be done better, there is a much better way to make the suggestion about it.

Either way you do it, all of the CSS is going to be loaded by the browser so there really is no speed difference since the CSS is goign to have be loaded before the browser can render the page regardless.

Only real difference is when you view the page source you can actually see all the CSS versus the external link where you just have the reference to the external CSS file. Having CSS included as internal CSS gives developers a much easier time in troubleshooting problems and changing the layout to see changes in browser.

The main purpose of external CSS links versus the internal code is so that you can have a link to a single external CSS file in multiple webpages so you only have to edit the single CSS file to change the layout of multiple pages. In Open-Realty you get the best of both methods by having a single external CSS file that is included into Open-Realty pages. Thus you only have to edit the one single file to change the layout of multiple pages, but you have the advantage of it appearing in the source of the page in case you are troubleshooting or trying to make tweaks and see the results of your tweaks faster.

Of course.. I'm not a CSS expert so I'm sure somebody will chime in with how wrong I am. :cool:

[niche]

making a post that sounds like an attack is not the way to go

Yikes. Sorry. Didn't sound like an attack when I posted, but rather a question about whether there was some reason I was missing.


This seems very much like overkill?

Is there a reason?


But, I think you really make my point for me, in the larger sense, which is that <link>'ed style sheets can be re-used. As it is, I have to port the CSS out of OR, so that it can be used by other pages on the site, which are independent of OR. If one's site uses various styles to coordinate sections, then the developer has to cull the OR code to remove the CSS from the dynamic pages, and then move it to external style sheets.

Additionally, the CSS written in this "build a big string" method, like the repeated higher overhead PHP instances of


$display .= ...

to build the HTML from many strings, makes it very difficult to expand or extend OR to integrate with other site content.

There are very many lines of code, particularly inside OR functions, where one can see things like:



$display .= "<script ...>";
$display .= " var blah;";


and the purpose is just to write strings. This must make debugging a nightmare, for both the text (string) that is being built and for the OR php code.

The same thing can be achieved, even inside a PHP function, by just breaking the PHP, with
?>, and then placing the unescaped, straightforward HTML or script content, and then restarting PHP , with
<?php , when you want to then include some dynamic variable.

For example, here is a comparison of the way that OR does things (in a hypothetical example, but one that I partially clipped from an actual OR function) and the same thing in a very much more convenient way (easier to debug, especially since this example writes JavaScript code).

The OR way:

:mad:


<?php
function some_function()
{
$display = '';
$display .= '<script type="text/javascript">'
$display .= '<!--'
$display .= 'function ChooseState()'
$display .= '{'
$display .= ' if (document.getElementById("edit_isAgent").value == "no")'
$display .= ' {'
$display .= ' makeDisable();'
$display .= ' }'
$display .= ' else'
$display .= ' {'
$display .= ' makeEnable();'
$display .= ' }'
$display .= '}'
$display .= '//-->'
$display .= '</script>'

...


return $display;

...
}
?>



And another way to do the same thing, which has all kinds of advantages:

:)


<?php

function some_function()
{
?>
<script type="text/javascript">
<!--
function ChooseState()
{
if (document.getElementById("edit_isAgent").value == "no")
{
makeDisable();
}
else
{
makeEnable();
}
}
//-->
</script>
<?php
}
?>


These achieve the same result, in this hypothetical, yet in the second example, especially since it is, itself, code (JS) it can be edited more easily and refined, altered, extended and generally dealt with (on a human level) than the other.

Additionally, it is much less resource intensive, and so will be a benefit to OR and the site that OR is running on.


This is the same with the CSS being written out like this. It's just generally less effecient, on all fronts.

I did not mean to "attack", and I was just asking. The alternative seems just so much more usable and especially maintainable over time (it must be a nightmare to edit just a little bit of a JavaScript, for example, written in this way, than in the way I propose.)

And, yes, dynamic PHP variables and content (from a DB) can still be inserted and integrated, dynamically, into the JS code, so that's not an issue.

(Just keep breaking from HTML into PHP, <?php , to insert dynamic data, then break out of PHP back into HTML, ?> , to keep going with your markup/script/css text.)


Anyway, I didn't say so in this post, but I did in my only second other post about image uploading, that I __really dig OR__ and I very much will keep using it and develop with it.

However, it will require that I rewrite some of that $display .= stuff into the method I've shown, so that I can extend and integrate OR into other dynamic site components more easily.

(Imagine being able to easily add the same or similar JS code to OR that one uses in other site areas, just by adding a PHP function which only returned the JS code....no PHP variables would ever be needed...as in:



<?php
function my_great_OR_js()
{
?>
<script type="text/javascript">
<!--
var some_thing;
...
and so on
-->
</script>
<?php
}
?>


Much cleaner, IMO. ;)


Again, no harm (or attack) intended.

[vMike]

....
Either way you do it, all of the CSS is going to be loaded by the browser so there really is no speed difference since the CSS is goign to have be loaded before the browser can render the page regardless. Embedded CSS is loaded each time a page is rendered. External CSS files are loaded once and retrieved from their browser cache file for subsequent rendering.

[niche]

Either way you do it, all of the CSS is going to be loaded by the browser so there really is no speed difference since the CSS is goign to have be loaded before the browser can render the page regardless.

vMike pointed out what I was saying, much more clearly. Thanks, vMike, for being more clear than I.


Only real difference is when you view the page source you can actually see all the CSS versus the external link where you just have the reference to the external CSS file. Having CSS included as internal CSS gives developers a much easier time in troubleshooting problems and changing the layout to see changes in browser.

It's funny you should say this because this is exactly why I made this post...for just the opposite reason! I am finding it extremely NOT faster, or easier to examine the file for changes, precisely because I have to scroll through 3 screen pages of CSS every time I want to view source on the OR index page.

So, without attacking ;) I would humbly suggest that your premise is incorrect. It is much easier to have CSS file open in a text editor, so one can see the CSS, and then to be able to view source to see the HTML, and the point where that CSS is rendered to an HTML element, than to scroll through all these pages of (not so well written) CSS just to locate some HTML element.

I really think that the time I am spending to change the files to used linked CSS and to remove all the very strange and not-very-typical dynamic writing of strings in PHP, will ultimately save me loads of time when I install my preferred copy of OR, if I do so again. Surely, as I continue to need to edit and tweak this first site, it's already starting to save me time and speed pages loads (between embedded CSS and string-by-string page writing with PHP, I have already shaved 12 seconds from the load time of OR pages.)

You really should consider this suggestion, I think, and then let the primary time of page access be devoted to MySQL calls.

You'd have a much better product that followed more generally accepted coding practice (concatenation of strings repeatedly is not an effecient practice, and it is especially not effecient for maintenance, so you would be doing yourself a big favor, too. You said you were the developer, right? These are just suggestions, based on general practice, not on personal opinion. There really are better and, uh, not better, coding practices. ;) )

I only offer things here as a means to improve the software, and that's it. (Otherwise I would never spend time typing into this very small text box, with all these ugly little 'emoticons' all around.)

:) :D :rolleyes: :mad:


But, again, I dig the software and _am_ using it with some joy.

[Mick]

vMike pointed out what I was saying, much more clearly. Thanks, vMike, for being more clear than I.

It's funny you should say this because this is exactly why I made this post...for just the opposite reason! I am finding it extremely NOT faster, or easier to examine the file for changes, precisely because I have to scroll through 3 screen pages of CSS every time I want to view source on the OR index page.

So, without attacking ;) I would humbly suggest that your premise is incorrect. It is much easier to have CSS file open in a text editor, so one can see the CSS, and then to be able to view source to see the HTML, and the point where that CSS is rendered to an HTML element, than to scroll through all these pages of (not so well written) CSS just to locate some HTML element.

I really think that the time I am spending to change the files to used linked CSS and to remove all the very strange and not-very-typical dynamic writing of strings in PHP, will ultimately save me loads of time when I install my preferred copy of OR, if I do so again. Surely, as I continue to need to edit and tweak this first site, it's already starting to save me time and speed pages loads (between embedded CSS and string-by-string page writing with PHP, I have already shaved 12 seconds from the load time of OR pages.)

You really should consider this suggestion, I think, and then let the primary time of page access be devoted to MySQL calls.

You'd have a much better product that followed more generally accepted coding practice (concatenation of strings repeatedly is not an effecient practice, and it is especially not effecient for maintenance, so you would be doing yourself a big favor, too. You said you were the developer, right? These are just suggestions, based on general practice, not on personal opinion. There really are better and, uh, not better, coding practices. ;) )

I only offer things here as a means to improve the software, and that's it. (Otherwise I would never spend time typing into this very small text box, with all these ugly little 'emoticons' all around.)

:) :D :rolleyes: :mad:


But, again, I dig the software and _am_ using it with some joy.

See now.. this is exactly what I was referring to when I say "without attacking" The last post was helpful information that would make me consider adding a tag for external CSS link... your post.. gets me all caught up in attacks though...... and how ironic is this one?


So, without attacking ;)

And then within a sentence you let go with an attack:

.....than to scroll through all these pages of (not so well written) CSS just to locate some HTML element.

Last time I checked.. the CSS validated as valid CSS (I believe there were some warnings about things not having colors or background colors set but those are pointless in their context)

So I have a difficult time following you when you say "not so well written".

I'm amazed that you have been able to shave off 12 seconds off your page load times in Open-Realty... that really is amazing.. of course what's REALLY amazing is that your site was taking longer than 12 seconds to load in the first place. When I test my wife's site, with 6500 listings in the database and many addons running on the site doing a nice complex search it takes an average of about 5 seconds for her search results page to fully load up...

I think you have got some serious issues with your webhost or something in your coding modifications if it's taking you 12+ seconds to render any open-realty page.

There are several suggestions here that will be considered best if they are put into a feature request on the bug tracker so they're not lost or forgotten about and that way they can also be put into a little more mature wording so they don't have the hostile attitude the forum post currently does. Also the type of changes you are requesting in overall coding style is not something that would be considered for point releases but instead may be something to be brought to the head developers attention while he works on coding Open-Realty 3

Also for information I'm not THE developer... I'm an assistant dev on the project.

[niche]

I really don't consider any of these words to be a synonym for "attack":

criticism
opinion
alternative
complaint
suggestion


While I very respectfully appreciate your interaction with me on this issue, I really do not consider anything that I wrote to be "attack mode".

We all have different sensibilities, of course, and so I don't want to minimize your feelings.

For causing you to feel attacked, I offer my sincere apology.

Anyway, I don't want to say that my sensibility is the same as yours, but for me (and my re-reading), I just don't see any kind of attack.

But, I will take your feelings into account and try to be more expressive with critical comments, so as to avoid the perception of attack or anger.

I also tried to use these "smiley winks" or whatever to convey a certain "tongue-in-cheek" quality, since I suppose I thought they would help.

Further, I emphatically included my appreciation for the tool, and for its usefulness. I do believe that critical comments, while they might sting a bit, can still be useful.

I take your point, and I will make effort to integrate this exchange into any future posts. (But I won't guarantee that I won't have some grumbles.)

Thanks, and again, so sorry to offend. That was not the point. Getting a screaming fast OR is the goal, not making waves.

Cheers, and thanks, and all that.

[greengiant]

I was just skimming the forums and wanted to make a quick note. The reason Open-Realty uses the css inline and not linked is we parse the css for template tags, which we could not do in a linked file.

Also the suggestion of removing this styel of coding

$display = 'Some Text';

in favor of

?> Some Text <?php

also doe not work, as we parse all output through our template engine, and the text you just echoed direclty to output would show up prior to our parsed code..

[niche]

Okay, I see your desire (other template engines would allow that with much more flexibility, like PHPTemplate or patTemplate, both Open Source tools which will provide the same kind of tag-parsed integration.)

Additionally, and without engaging in the integration of alternative templating engines, you could consider just turning linked (<link...>) style sheets into PHP pages themselves, as in:



<?php
header("Content-Type: text/css");

# ... and so on, breaking in and out of PHP as needed

?>


The addition of that header causes a file, perhaps with the fictitious name of:

some_dynamic_styles.css.php

into an external linked style sheet of the content type shown.

This is the method which I prefer when I need to have dynamic or parsed data inside a CSS style sheet.

[pbflash]

Your method would still not allow using template tags within the css file.


This is the method which I prefer

That doesn't mean it's the best way to do it. If you don't plan on using template tags in the css, remove the {load_css_style} tag from the template and enter the links to your css files.

[Mick]

criticism
opinion
alternative
complaint
suggestion

I don't consider any of these attacking either... however.. all of them are usually done with examples, reasoning, alternatives etc... "Not so well written" is useless, baseless and hostile without providing the examples, reasoning or alternatives to show why you feel that it is "not so well written". To come onto somebody's project that they've spent countless hours coding, adding features for countless people and debugging for no compensation and to just say that it is "not so well written" is a hostile attack. i'm not a sensitive person, but that is what those sorts of comments are no matter how sensitive or not you are.

some of your criticism/opinion/alternative/complaint/suggestions were just that and I am always happy to have constructive topics on anything to do with Open-Realty... as long as they are mature and constructive. Some of this thread is constructive criticism and that's great.. it's something that will be looked at in the future when future versions are being worked on.... however some of this thread is words/phrases/sentences that have absoultely no value at all and are pointless to include unless the purpose is to illicit some sort of reaction.

[niche]

Well, this method surely allows parsing of other {...} style template tags, as in Smarty-style tags, in other applications and contexts. But maybe you mean this in the context of the way things are set up in OR at present.

Additionally, though it's "six of one, a half dozen of the other", there is no real need to force the parsing of {...} if you can also pass values to variables, at least that I can envision or that I've encountered. (I use other tools which prefer a parsed template approach, and I continue to be able to use the method I alluded to. Parsing a file for {...} tags is just that, it doesn't matter what the file contains, so long as it contains zero or more of those tags.

I do get that the current OR is locked in to this method, but I really believe that's based on architectural decisions which need not be written in stone, and would not require a full re-think of the engine.

But, again, I'm not the expert on the guts of OR, or it's mindset with respect to coding. And, of course, I'm not writing OR, I'm just re-writing some of it, for my tastes and needs.

There are, however, I still believe, some more efficient methods which could provide the same template-based functionality without slowing things down and requiring the browser to do work over and over again.

(I'm not looking at any OR css right now, but what DB values might ever need to be inserted into the CSS anyway?)

From the point of view of maintenance of the code, surely this current method must be a real bear to work through. Even trying to test a modified JavaSript, for example, becomes cumbersome when you have to break out the string concatenation and then replace it in the core.

If nothing else, to save you guys work, it seems that other methods (that might also be more browser-friendly) could be sought.

I can really find no other examples (but there may be) of PHP-based tools which adopt this character-by-character string concatenation.

(And I know this is now way off topic from CSS links versus embedded.)


My appreciation for the dialogue, but I think I'll let it be Friday (and let this thread die or re-emerge elsewhere.)

And, the more I learn about these kinds of design choices that OR has made, then the more I can know if I have anything useful to offer ... which I'd enjoy, since I've had a really straightforward experience with the software, and would recommend it wholeheartedly...with some few small caveats (but those come with any kind tool, for each of us.)

Have a great weekend, everyone, and thanks for sharing your insights into "why things are the way they are".

Over and out.

[simon132]

somebody's project What does that mean? If it means that the community doesn't get to ask questions we have problems. Some people may take exception to the way a point is made but that does not make the point any less valid.

If there are ideas that can help the *community* they need to be explored, debated and dare I say it, even argued.

I will probably get bashed for my opinion; such is life.


Cheers,

Simon
www.newenglandcedarhomes.com

[jared]

Wow this has become a favorite read.

As Ryan had said the parsing of tags is the objective and the method used is quite honestly the best of the three options available.

A side thought:
Its important to note that you do not have to keep the entire Open-Realty CSS file in the default style.css sheet. I mean, if you wanted to take advantage of open-realty tags then use it for that purpose and you can certainly provide a second CSS link for the general CSS.

Months ago I asked this very question about cache in the csscreator.com forums and I was advised by whom I believe to be well versed, that the css file gets parsed each and every time if you use IE 5.0+ regardless of where it resides. So if you embed it in OR or call it externally means very little when working with that browser.

In modern more compliant browsers the external CSS gets cached.

If it matters, without going off subject, the thing I've been doing more so than not, is use three seperate style sheets. Usually I do this. style.css for open-realtys tags, template.css that handles the layout of my design and includes a section /*=-=-[OPEN REALT MARKUP]-=-=*/ for all the open-realty general CSS.

I hope that helps.

This is a good thread none the less.

Jared

[vMike]

A side thought:
Its important to note that you do not have to keep the entire Open-Realty CSS file in the default style.css sheet. I mean, if you wanted to take advantage of open-realty tags then use it for that purpose and you can certainly provide a second CSS link for the general CSS.

I think that is the best idea, it keeps things orderly and intuitive. A major reason to use CSS is for separation of content and presentation and may be why there is no provision for tags in css files. I see no objection to using tags with CSS to accomplish a particular task and separating the task allows for a more intuitive flow.


Months ago I asked this very question about cache in the csscreator.com forums and I was advised by whom I believe to be well versed, that the css file gets parsed each and every time if you use IE 5.0+ regardless of where it resides. So if you embed it in OR or call it externally means very little when working with that browser.

I am not sure I agree with that because when a browser loads a file, whether it is jpg, gif, html, or css why wouldn't it get cached and used on subsequent loads? I am not certain but it seems logical that it is a basic browser function.

[niche]

Jared said...

This is a good thread none the less.

Agreed, Jared. Very informative and helpful. (Even if I steered it a little off-course without intending to.)

vMike said something like (1)...

...is caching just not a function of the browser...

(1) The forum shows your post on a different page than my comment addition, so I can not see it to clip it.

vMike, it _is_ a browser function, generically spekaing, but whether any particular browser -- especially one so very old and non-standards compliant as Internet Explorer -- implements CSS caching is a choice of the developer.

We do not even provide support for Internet Explorer, in any version, and we are adoping the Explorer Destroyer campaign on our site network (which is only 5 sites, but hey.) We are using the "soft notice" for 3 more weeks, and then moving to the "Sorry, you may not access this site with Internet Explorer" block message.

Too bad for IE users...it's over. ;)

<http://www.explorerdestroyer.com/> for more info.


Old folks with ancient software are not the real estate clients we serve, and we've found that over 70% of our actual lead-to-close users are using modern standards-based browsers and not Internet Explorer. Additionally, just over 85% of all agent support questions stem from IE users, and the problems they experience that are not site or OR related, but are browser related. If agents are using IE, they are just behind the times and need to get with the (our) program. By declaring that We do not provide agent site support for users of Internet Explorer we have saved money, time and resources, both on the support end and on the development end. When you can code for a standards-based browser, then you can really do much more useful (and sales-driven) things.



All good stuff, and I hope the conversation can continue (in a more appropriate thread?) about ways to improve code maintenance and speed with OR.