How smelly is creating a stylesheet for each <div> and inserting each stylesheet LINK in the xhtml body just before its relevant <div> declaration?
I generate my xhtml through PHP5 classes which would be much cleaner if can place both the css and xhtml code together in the body (without using imbedded style=“…”) – as opposed to the <div> in the body and the <link … stylesheet> in the head.
My experiments show that Firefox, Explorer, Opera and Chrome render the page properly with this body-imbedded-LINKED-stylesheet approach – I just don’t know how high this strategy stinks from a design point of view.
Using that approach completely destroys the benefits of CSS, which are about efficiency and re-use. If you are generating a stylesheet for each <div> (what are you using <div>s for?), that is going to be worse than using embedded styles, because not only do you have to spell out each and every style definition every time you use it, but you’re adding in an extra file request for each element as well.
Beyond that, it means you can’t ensure consistency across the site. The way that CSS is supposed to work, you have a single file controlling the display on every page, so that related elements are always given the same style definitions. By defining the style on each the element where it’s used, you lose that guarantee of consistency.
Thanks Stevie. I defer to your knowledge on the code efficiency cost of extra files requests.
I can see where my post perhaps suggests a stylesheet for each and every <div> in the page. I agree that such an approach is, indeed, absurd.
I’m not so sure we are as diametrically opposed as it appears. I’m not looking to create a stylesheet for each <div>. But I am looking to encapsulate my main <divs> (i.e. heading, navigation, content, rightcolumn, footer). All but content div is unlikely to change, but can easily change with no ripple effect (outside that div) if encapsulated. And the content div will cascade depending primarily on whether it is a form, a list, a data display or a image display.
And, of course, most of the stylesheets are reused identically in the pages across the site (including the content cascades).
On the other hand, restricting to one-size-fits-all CSS quickly leads to a huge stylesheet where much of it may have no function within a given page. For example, if my page isn’t a form, why should my stylesheet define fieldset, label, input and submit elements? To my mind, that becomes the “spaghetti” code of CSS – which to me may be an even bigger violation of the OOP CSS intent.
All right. So it doesn’t cost much to have those extra elements. Not in network costs perhaps, but such spaghetti is disastrous for maintaining an application. In my mainframe world, we called using one-size-fits-all interfaces “stamp coupling” – something to be avoided in that a seemingly innocuous change in the interface (or stylesheet in this case) can have totally unexpected and catastrophic consequences. (e.g. the programmer who passed the telephone area code along with the zip code to the geographic validation routine caused the program crash months later because someone didn’t have a phone.)
Nevertheless, I take your comments to heart. And greatly appreciate your authoritative response.
CSS files are typically so small that it’s often faster to download one larger CSS file than a number of smaller CSS files. For each file, the browser basically has to stop and start downloads multiple times, rather than having one continuous download.
But, I generally break things up logically according to browser needs.
I have a reset.css, a style.css (and occasionally a style-form.css, only if form styling is needed on one or two specific pages, otherwise it all goes into style.css), a style-ie.css (and sometimes style-ie6.css, style-ie7.css, style-ie8.css, style-ie9.css–all for IE compatibility issues), a print.css (for styling the page for printing), a mobile.css (for styling the page for mobile browsers).
Granted, you can still end up having a small collection of CSS files there.
“embedded” ( called in line) ; this is where you use the attribute style=‘…’ in the tag itself.
<style> tag at the HEAD of the html document.
#2) is really the WORST way of using CSS and essentially defeats the purpose of CSS. I will admit that , on occasion, inline CSS is handy because code written this way has more specificity (takes precedence) over all other rules targeting THAT SAME ELEMENT than the other two methods . for everyday use this is actually quite inefficient tho.
it sound like you are saying #1 is too much trouble for you, but that you don’t want to use #3 (and you shouldn’t anyway)
I did forget to mention a fourth method which is the @import rule. you can have a link to a style sheet … which actually calls other stylesheets!! so you can override and make exceptions or add additional styles as you go along.
really the best use of PHP is to output valid HTML with the IDs and CLASSES as needed and a link and/or @ imports to specific style sheets. The other benefit of this method is caching, that is you can style your page using one or a few external style sheets… when a UA access this file , it stores it in a cache , and its ready to use when the same looks/styles are required in other pages through out your site… this is a considerable boost in speed and saving in bandwidth that you dont want to miss out on…
my personal MO is a s follows:
have a general style.css files which includes the rules generally used thought the whole site, or multiple pages of the site
if a particular page is unique add a link or /@import (eg:home.css) with the new rules/overriding rules for that specific page ( it’s also important that this link comes after the main link the the source code)… You may ask well , why not use inline css for this… the answer is simple, separation of style from content … if I want to change the look of that specific page at some time in the future… the only thing i have to do is change the rules in thats style sheet no need to mess with the HTML ( you don’t even need to ha rang with the PHP)
because we all love Bill so much we want to marry him… the occasional extra link for IE wrapped in a conditional comments helps makes your site cross browser friendly. This too is impossible to achieve if you just put your CSS directly in or by your tags.
Golly (does anyone say that anymore?) I can’t seem to get my thought across … which is actually an answer to my question (i.e. no-one seems to be doing what I propose).
Here is a code snippit:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<snip>
<head>
<snip>
<link rel="stylesheet" type="text/css" href="scheduler/root/base.css" />
</head>
<body>
<div id="PageWrapper">
<div id="banner">
<h1>Future home of Banner</h1>
</div> <!-- end banner -->
<link rel="stylesheet" type="text/css" href="scheduler/view/navigation.css" />
<div id="navigation">
<p>Future home of Navigation</p>
</div> <!-- end navigation -->
<link rel="stylesheet" type="text/css" href="scheduler/view/content.css" />
<div id="content">
<p>Future home of Page Content</p>
</div> <!-- end content -->
<link rel="stylesheet" type="text/css" href="scheduler/view/signin.css" />
<div id="signin">
<form method="post" action="scheduler/index.php?task=signin">
<snip>
</form>
</div> <!-- end signin -->
<link rel="stylesheet" type="text/css" href="scheduler/view/footer.css" />
<div id="footer">
<p>Future home of Footer</p>
</div> <!-- end footer -->
</div> <!-- end PageWrapper -->
</body>
</html>>
The idea is that I can encapsulate my code and my stylesheet lexically together rather than splitting them with the stylesheet in the <head> and the code in the <body>.
In most cases, the stylesheets are reused across all pages – this is particularly true of the navigation, heading, sidebar and footing divisions. And, for content, there are only the four I mentioned earlier (form, list, data display or image display ).
There are no stylesheets for any divisions other than these.
By lexically combining the links in the body, I pursue the OOP objectives of encapsulation, reuse and portability.
Yet as I said, the difficulty I’m having communicating my thought tells me that the proposal is probably a bad idea.
Neither the style element nor the link element is valid in the body section of the page. That takes care of that.
I would say, generally, though there may be outliers, that div by div style differences in style rules are best handled by proper use of the cascade. You may use a unique identifier, i.e. an id attribute, on each div or set an identifier on the body element and use the selector cascade.
In a well designed site, there is seldom any advantage to using multiple style sheets. You will see this done on CMSes because they are trying to be ultra generic, while avoiding stepping on plugins’ and themes’ styles.
That said, I do use multiple stylesheets for the different sections of the site. An overall global sheet is imported by the section sheet. There is a small maintenance benefit, as the unused section sheets are not seen when viewing styles.
There is a very slight bandwidth advantage if not all site sections are viewed. This may be negated by additional network latency and server overhead.
Yea I suppose I wasn’t clear enough. Thanks Gary for clarifying.
UNLIKE <script>, <LINKS> and <STYLE> must be in the head of your document. The MO I outlined was especially poignant to the code sample you provided and 1) You gain little from loading multiple files, 2) there is no difference in output from putting ALL those links inside the head of the document , and 3) even when outputting PHP… you should know which sections of the code are going to be output before the BODY code is echoed, so it’s just as easy to put the <link> in the head of the doc.
Your method is just an overkill invalid variation of what I suggested: a main site-wide style.css followed by ONE ( page specific css) OR TWO(this is usually for IE cus its “special”)
That is the most disastrously bad idea I’ve seen in coding practice in a LONG time. Above people have mentioned the extra time of each file request – this is called “handshaking”… anywhere from 200ms to a full three seconds can be tripped past the first 6-8 separate files on a page.
Putting it all in one file avoids this, and if you have stuff that’s not used on the current page, it may still load faster but more importantly, you’re PRE-CACHING the appearance of all your sub-pages! Remember, external CSS is cached across pages that use the same files just like images are! If all the HTML files are smaller since you’re not stating the embeds every couple lines, ALL of your subpages will load faster using less bandwidth.
Basically, you’re bloating out the markup!!! You might as well go for a drive with the parking brake on.
But then, you’ve got a bunch of pointless DIV in your markup too… like that DIV around the H1 or FORM for nothing… Naturally you’ll probably put the menu into that ‘navigation’ div without removing the div (since that’s par for the course on site bloat these days), etc, etc… As George Carlin said, “Not every ejaculation deserves a name” – which in Web Development means not every element needs a DIV or ID around it.
… and if you’re using a modern recommendation document spec, as mentioned you also can’t put LINK or SCRIPT in BODY… only in HEAD.
As others have said, that isn’t valid code, because the <link> elements can only go in the <head>. And while you could simply put all of them into the <head>, as DS60 says that is a whole lot of lag and bloat you’re introducing there. Common elements that are on many, most or all pages should be defined in a single stylesheet that is used across the whole site – that way, as well as saving bandwidth and handshake time, you’re also more likely to get consistency and less likely to get conflicts. Less common elements that have little styling attached can also go in the same stylesheet, because the extra byteage needed to download one line of CSS is negligible.
Where you have a page setup that is only used occasionally and requires a lot of styling that is specific to that setup, such as a form, it may make sense to extract this into a separate stylesheet and only link to it from the few pages that need it.
Don’t take it to heart it was just a matter of fact statement with no malice (or hurt intended). If you read Jason’s other posts you will see that they are pretty much in the same manner and don’t beat around the bush or sugar coat things. It’s just very straight talking and 99% of the time is right on the button.