1. So we're clear, utilizing CSS does not make a site W3C compliant. Using valid CSS AND valid (X)HTML does. There is still support for the way old, deprecated HTML of the past, so CSS is not (in the strictest sense) a requirement of compliance.
Originally Posted by randomness0
All MIME types have a set of formatting rules. What makes the object file valid is that it conforms with the rules that apply to its MIME type. W3C is the 'sober thought' side of the WWW, and really only lays down guidelines and recommendations for browser (user agent) manufacturers and web (site/application) developers. It is a totally transparent process. Nothing is hidden from anybody. If one cares to dig, the entire history of document specifications for the web can be found on the W3C site.
Of course, we're not going to find validators for every MIME type on the W3 site. The important ones are there, though. We common folk are producing largely text files, the core documents of our site--HTML and CSS (among others). Since everything stems from them, well formedness in their make up is essential (but not a strict requirement) to helping the document and all its component parts render smoothly.
2. It makes perfect sense to have one style sheet that applies to the entire site. This is not to say there must be only one. Moreso, it helps to develop uniformity throughout. I like to think of CSS as one style sheet in memory, made up of multiple parts, much like the cascade itself. The more global (site wide), the less specific.
Along these lines we can now set out a cascade for each document:
(Note: All CSS and document files are cached for at least the length of any session (typically). This permits a sort of threading as the user browses the site. The components that are missing in the cache at requrest time, are downloaded from the server and are added to the cache. Now any open (or subsequent) document can link to it without it having to download again. It is faster, not slower this way.)
A. Global CSS. This sheet downloads once, remains in the cache for the entire session and is accessible to all pages on the site during the session. All pages hook to it by direct link, or by import from within the directly linked style sheet.
B. Channel CSS. As the theme diverges into varying mini-sites within the main web, it calls up more specific CSS. These styles don't apply to the entire site, and rightly so should be kept separate. Within a given channel, it might be this style sheet that is directly linked to applicable documents, and it would it would contain as its opening declaration an import statement, hooking the main CSS to the top of the cascade, and then following under, with higher specificity.
C. Local document CSS. One I always call "thispage.css". It will usally exist in the same folder as the document, and never be called from outside of that folder. The same could be said for B., above, as well. Again, this file could be linked directly to the page, and could import B which would import A. The cascade would still be A>B>C and C would have greatest specificity.
3. More or less dealt with above... We needn't confine ourselves to limited number of style sheets, but we should place all site wide components in a low specificity position in our cascade, and allow channel and page (and further down the cascade, page plug-ins) specific declared properties to take precedence where applicable. It is in the cascade that we first establish what will be permitted to override what.
4. Actually already addressed above... One download, multiple links to that download during a given session. If the document (or any file that is linked to it) is modified during a session, the modified file will download again at the next request. Otherwise, your site's core components might site on a user's machine for days, weeks, or even months.
<link href="thispage.css" rel="stylesheet" type="text/css" />
<link href="/addons/plug-in.css" rel="stylesheet" type="text/css" />
/* all page custom styles below */
/* all theme-wide styles below */
The Plug-in will have the highest specificity in the cascade, followed by the page, followed by the theme and lastly by the main.
/* all global styles here */
What this briefly translates to is this: The main can have a declaration that applies to node type P. Say it has no margins. This will apply site wide. Now a theme can turn around and declare that all P for this theme will have margins, and override the main CSS rules for this node type. Then the page can come around and say all P will have margins of so much by so much. Again, with the greater specificity in the cascade, it wins the argument for how P should appear.
Obviously this is very general, but it goes to how little is needed to address all of one node type (element) for an entire site, right down to the plug-in. We can further specify with id and class selectors, and the plethora of relational selectors if we want to win a battle at document level. This is all part of the design of the cascade.
And we should not neglect to take into account inheritance. Any other properties that are assigned to P in the main css above, will be inherited all down the cascade, as will any other properties that get tacked on along the way down.