CSS question

[randomness0]

Hi,

Have just redesigned my site to utilise CSS and make the pages W3 compliant.

I have basically used the one style sheet for all pages which has meant that for most of the pages there is a fair amount of redundancy associated with the CSS code used for a given page.

Should I just have a unique page of CSS code for each page on my site or is my approach of one CSS page for the site the way to go?
Obviously the latter tends to make things easier but means that the loading time per page might be marginally slower (although as it is only text we are not talking huge file sizes here).

Thanks
Richard

[defensity]

Yes you should just have one .css file.
Then call it into everyone of your pages, via a link like this in the head area of your pages <link href="/stylel.css" rel="stylesheet" type="text/css" media="all" />

[HTMLBasicTutor]

I have basically used the one style sheet for all pages which has meant that for most of the pages there is a fair amount of redundancy associated with the CSS code used for a given page.

What do you mean by this?

[deepsand]

Yes you should just have one .css file.
Then call it into everyone of your pages, via a link like this in the head area of your pages <link href="/stylel.css" rel="stylesheet" type="text/css" media="all" />

Suppose that each page is unique, or very nearly so, with respect to its usage of CSS code.

What benefit is to be had from making each page load that which is will not use?

Is not the potential benefit dependent on the extent to which multiple pages, all needing at least some of that code, being requested?

[kgun]

Hi,
Should I just have a unique page of CSS code for each page on my site or is my approach of one CSS page for the site the way to go?

The real question.

is my approach of one CSS page for the site the way to go?

One side-wide stylesheet is of course easiest. On a popular platform like wordpress you can have multiblogs with different styling. Is something similar relevant for you?

One site-wide is easiest.

Side note:
Why is wordpress so popular? It separates

1. Content from
2. design
3. and functionality.

That implies that you can change design by activating aonther stylesheet, and it comes with plugins (functionality) http://wordpress.org/extend/plugins/wptouch/ that make the site readable / visible on mobile platforms.

If everybody used the Opera web browser this would not be a big issue, since you can change the view by a clicking the modus icon and select your preferred option or you can make the selection from the view + style menu.

Now, that is not the case. Sites that test for user agent and deliver a seamless stylesheet is my preferred option.

Skip to content | Change text size or colors (upper right corners)

http://www.w3.org/WAI/intro/accessibility.php

are nice features (Skip to content is not a CSS issue).

Changing text size and colors can be done by a seamless stylesheet. So many small seamless css style sheets or a big one is perhaps also a relevant question?

Again back to wordpress that I think set a standard. The styling of a news sites is different from the styling of a financial related site that is again different from a fashion related site ...

[weegillis]

(1) ... to utilise CSS and make the pages W3 compliant.

(2) ... one style sheet for all pages.

(3) ... one CSS page for the site.

(4) ... make things easier but means that the loading time per page might be marginally slower

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.

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.

To recap:

/theme/thispage.html

<link href="thispage.css" rel="stylesheet" type="text/css" />
<link href="/addons/plug-in.css" rel="stylesheet" type="text/css" />

/theme/thispage.css

@import "/theme/thistheme.css";

/* all page custom styles below */

/theme/thistheme.css

@import "/sitewide.css"; 

/* all theme-wide styles below */

/sitewide.css

/* all global styles here */

The Plug-in will have the highest specificity in the cascade, followed by the page, followed by the theme and lastly by the main.

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.

[weegillis]

As a stem from the above, we need also to take into account that there is a higher specificity stylesheet already present on the user's system that is loaded into the DOM at browser startup. These are referred to as User Styles and deserve to be understood and respected by any developer. This is the whole basis for document object separation. Separate content from appearance from behavior, then thread it altogether for the end user at load time. The user has the last say, and can make their own style sheet more specific, as needed to override any site styles.

It helps to consider what user settings might exist at load time that will affect the rendering of your document. What you see is not what others see. Best first assumption in my estimation, and the reason I always insert general rules in the main style sheet that 'accept' the user's own settings as my baseline for the rest of the session.

body {
 font-size: 100%;
 color: black;
 background-color: white;
}

This takes cares of three user settings, but a quick perusal of your own machine will show you all the others that may need to be considered for your particular layout. The best we can hope for is predictibility, and if we get pixel perfect rendering in some, many, most situations, kudos. Otherwise we shoot for orderly, neat, organized and usable. Succinctness is for writing, not web rendering, imho, though precise graphics are a major plus.

We should never try to wrestle control away from the user, only mould our presentation around their settings so as not to lock out their ability to make adjustments at any time. While this may apply to only a small percentage of users, over all, it is still the fundamental principle of CSS and the accessible web.

[kpmedia]

If you have page-specific CSS, then it's generally best to keep it inline, or in a per-page header (HTML head). That said, even a "large" CSS file isn't necessarily going to do much harm. Site speed is far more affect by JS, PHP, database, server quality/speed, etc. If you're running into performance issues, keep looking. This probably isn't it.

Good luck.

[weegillis]

If you have page-specific CSS, then it's generally best to keep it inline, or in a per-page header (HTML head).

While I would not disagree with this, it has one drawback: it introduces inconsistencies, and puts presentational elements in the document. This is fine on a one-off page that may be temporary, but not so when these types of pages begin accumulating, all with bits of CSS, much of it duplication, embedded in them.

There is no one right way or wrong way to style a page, just generally accepted best practices. When someone drops a site in your lap with dozens, or hundreds, or even thousands of pages, where would you rather look for the style sheet(s), a server folder or open every document? For this reason, it is not recommended we get into the habit of seasoning our pages with embedded style tags or inline style attributes. Okay for testing and sampling, but then a more permanent home for the CSS needs to be established that takes it out of the document, proper.

[weegillis]

As mentioned above, our CSS may land in someone else's lap and if we're not there to explain or point out important and subtle details, it could be several hours before that person sorts everything out. It therefore behoves us to take an organized approach, and stick with what we have adopted, at least within the scope of the project. The following article by Emily Lewis provides an excellent list of designer awareness pointers that every CSS newbie and veteran can benefit from:

scriptjunkie{}Be a CSS Team Player: CSS Best Practices for Team-Based Development