I am currently in a 5-7 large development team creating a really large website with lots of pages and features.
I feel like we are in such a situation where a developer can change the style sheet to suit his own needs, but is unaware of the 1000 places where it probably change it for something else. I cannot blame him either, since I know it's hard to check everything.
It's a total mess.
I know that using one single style sheet file saves bandwidth and prevents duplicated code and maintenance, but I cant help wondering - is using style sheets a good idea for big sites, or should it be more object/element oriented.
Let's say you forget about the crazy large CSS and you define the CSS on each element instead. So each time you render a GreenBuyButton, it has the "style='bla bla bla'" on it. And this is pretty much done for all elements.
This will increase the bandwidth, but it will not create duplicated code.
Could this be a good idea or how does really large teams work on a single website do with CSS to avoid it being a mess?
Why don't you create multiple CSS sheets depending on the area of the site?
blog.css
accounts.css
shopping.css
Then you could have a serverside script (say PHP) combine all CSS into 1 sheet which will get you the same result of 1 small file (could use a minimizer as well).
Check your overall site with a CSS checker to find duplicates (css defined) and manage it that way.
Otherwise communication is key between your team, who develops what, and so people don't duplicate CSS definitions. A master CSS keeper would be best suited to manage the CSS styles, besides your team should have an agreed upon style and not go rouge creating their own unique styles.
My recommendation would be to use the CSS rules on specifity to help you. For each CSS that is not global, put an activate selector on, for example
.user-list .p {
font-size: 11pt
}
.login-screen .p {
font-size: 12pt
}
This will make it easy to identify what rules are for which pages, and which rules are global. That way developers can stick to their own set of styles, and no mess up anyone else's.
Change how you write CSS.
Instead fo treating every area of the website like a specific piece of markup that needs styling, start defining broad classes.
Enforce some rules. Like, "All <ul> have a specific look for this project." If there are multiple ways you want to style an element, start using classes. This will keep your website looking uniform throughout. Uniformity reduces broken layout.
Create building block classes like a "framework" of sorts. This has helped me so often that I never start a project without doing this first. Take a look at the jquery-ui themeroller framework to give you the idea. Here's an example:
.icon { display:block;width:16px;height:16px;}
.icon-green { background:url(/green.png);}
.icon-blue { background:url(/blue.png);}
Then on the elements:
<span class="icon icon-green"></span>
<span class="icon icon-blue"></span>
Breaking your styles up into their building blocks like this and using multiple classes on the element will keep your team members from having to change styles to suit their needs. If a particular styling quirk is not available they can define a new set of classes.
UPDATE:
Here is an example of how I used this method: Movingcost.com. Huge website, multiple different sections and pages, and only 252 lines of uncompressed css. Actually, these days I break things down further than I did on the movingcost project. I probably would have gone through those elements at the bottom of the stylesheet and figured out how to combine some of those into classes.
Multiple CSS files and combine in code
While doing development I found out that doing it the following way seems to be reasonable and well suited to development teams:
Don't put any styling into HTML. Maintainability as well as lots of head scratching why certain things don't display as expected will be really bad.
Have one (or few of them) global CSS that defines styles for global parts. Usually defines everything in template/master. Can be bound to master page or to generic controls used on majority of pages.
Have per-page/per-control CSS files when they are actually needed. Most of the pages won't need them, but developers can write them
Have these files well structured in folders
use naming and formatting guidelines so everyone will be able to write/read code
Write server side code taht will combine multiple CSS files into a single one to save bandwith.
You can as well automate some other tasks like auto adding per-page CSS files if they're named the same as pages themselves.
Doing it this way will make it easier to develop, since single CSS files will be easier to handle due to less content and you will have less code merging conflicts, because users will be working on separate functionality most of the time.
But there's not feasible way of automating CSS unit tests that would make sure that changing an existing CSS setting won't break other parts of your site.
My favorite override trick is to assign the id attribute on the <body> of each page. It's an easy way to make page specific changes without breaking out a separate stylesheet file.
You could have the following html
<body id="home">
<h1>Home</h1>
</body>
<body id="about">
<h1>About</h1>
</body>
And use the following css overrides
h1 {color: black}
#about h1 {color: green}
The home page gets the default css while the about gets overridden.
Using style sheets on large sites is an excellent idea. However, it only really works when you apply your team standards to the style. It makes sense to have a singular template controller that links your style sheet(s). It also makes sense to appoint someone on the team as "keeper of the style" who all changes to the style sheet should go through before making substantive changes.
Once the style standards are agreed upon and defined, then all of the controls in the site should implement the styles defined. This allows developers to get out of the business of coding to style and simply coding to the standard. Inputs are inputs, paragraphs are paragraphs, and floating divs are a headache.
The key is standardization within the team and compliance by all of the developers. I currently lead a team site that has upwards of 30 style sheets to control everything for layout, fonts, data display, popups, menu and custom controls. We do not have any of these issues because the developers very rarely need to edit the style sheet directly because the standards are clearly designed and published.
The answer is in the name. The reason it's called cascading style sheets is because multiple can be combined and there are decent rules defined on which one takes preference.
First of all, doing all your styling inline is a ridiculous idea. Not only will it waste bandwidth like nothing else, it will also result in inconsistency. Think about it for a while: why would changing a line of css 'break' another page? That indicates your css selectors are poorly chosen.
Here are my suggestions:
use one css file for the basic site look. This css file is written by people doing mainly design, and as a result the site has a consistent look. It defines the basic colors, layout and such.
use another css file per 'section'. For instance, a 'shopping' section will use components that are nowhere else on the site. Use that to define section-specific stuff
put page-specific styling directly in the page (in the header). If this section becomes too big, you're doing something wrong
put exceptional styling directly on the components. If you're doing the same thing three times, abstract it out and use a class instead.
choose your classes wisely and use the semantics for naming. 'selectedSalesItem' is good 'greenBold' is bad
if a developer changes a stylerule and it breaks the rest of the site, why did he need to change it? Either it's an exceptional thing for what he's working on (and should be inlined) or it was basically broken on the rest of the site as well, and should be fixed anyway.
If your css files become too big to handle, you can split them up and merge them server-side, if you want.
You don't want to define CSS for each element because if you ever need to make a change that affects many elements one day, say the looks of all the buttons or headers, you will be doing a lot of Search/Replace. And how to check if you forgot to update one rule to keep your site consistent?
Stephen touched on a very strong point in CSS. You can assign multiple classes to an element.
You should define some basic rules that "ordinary" developers can't touch. They will provide the consistency through the site.
Then developers can assign an extra class to personalize any property. I wouldn't assign more than two classes though: a global and a personalized.
Considering you already have this huge stylesheet in your hands, I'm not sure how you will pick which one of the 7 developers will have to sit down through a month and organize it. That is probably going to be hard part.
First off, you need to extract your website's default element styling and page structure into a separate stylesheet. That way people understand changing those rules affects the entire site's appearance/structure, not just the page they're working on.
Once you do that, all you really need to do is document / comment all of your code. A person is a lot less likely to write duplicate code in a well-documented stylesheet, and that is a fact.
Related
I have researched on this topic and i could not find the exact answer i needed.
For example i have so many divs that need a border. I could write a seperate css class like
.border{
border: solid;
border-color: #C6C6C6;
border-radius: 5px;
}
and use it in every div tag that needs a border. Or i could include
border: solid;
border-color: #C6C6C6;
border-radius: 5px;
properties to each and every css class i'm writing for my divs.
By writing a seperate class for border and using it reduces a huge chunk of lines in my css file. But my problem is, will it affect the performance of the web application if i include border properties to each and every css class i write for my divs.
Thanks in advance.
The answer is yes ! Best practice is to have generic class.
Some documentation about CSS methodologies : http://codetheory.in/an-overview-of-oocss-bem-smacss/.
OOCSS, BEM and SMACSS are good methodologies to organize your css.
To be fair this is quite a loaded question...
I don't know if you are aware but CSS stands for Cascading Style Sheets, it was built to 'cascade' down from sheet to html tag. So the short answer is no, with today's internet connections, probably not. However here's a few things to consider...
1) Minifying the CSS -
The best way to save on performance using CSS is 'minify' it. There are many online generators that can do this like this one https://cssminifier.com/. This will remove any characters that unnecessarily take up kb in the document, such as spaces and line breaks for example.
2) User Experience -
Users in countries like the USA or the United Kingdom now for the most part have access to high-speed broadband, but you must consider that on some very very old connections you'll find that having to re-draw that rule from each tag can take time.
3) Readability and Debugging -
If you need to come back tot hat code later and decide that you want to change the border colour, you're doing to have to do that on each and every tag to apply that change as opposed to one simple change on one style sheet. Also if you try to debug this using and kind of in-browser development tool you'll find this is also more complicated that simply looking up one value on one rule instead of however many tabs this is being applied to.
4) The Cascade Effect -
Finally, this completely defies the point of the CSS model in the first place as their styles trickle down from rule, to style declaration (in the html header), to tag, which makes both documents, not only easy to read but easy to edit too.
So in short, yes there is a performance benefit, but not noticeably so unless on an older connection, but the benefits in other areas of development are much stranger than just the loading speed alone.
By writing too many CSS code could make you CSS file size big. If you could avoid duplicate lines of code by creating a class then go for that . It's a best practice to avoid duplicate code so that if any change require with changing one line of code it will reflect every where.
So if it's possible avoid duplicate code. And aways minify your CSS for production website so that CSS file will be smaller as a result page loading time could be improved.
You're trying to solve a problem you're not yet having. Don't worry about optimisation until you need to.
On a wider scale, the amount of CSS rules you have can affect the load time of your website. When your browser encounters CSS it stops rendering the page, parses the CSS, and builds the CSSOM (CSS Object Model).
So even if you minify, compress, and merge your CSS files, an excessive amount of CSS could still slow down your website.
It sounds like you're miles away from having to worry about this, though, so don't worry until it becomes a problem (ie. when you have 100s or 1000s if kilobytes of styles).
I'm building my first website for an internship. My instructors always told me to never embed any styles on my html page.Now that I'm actually creating a site I find it annoying that, if I want to change the color of my font for a span tag - I have to I.D. it and reference it in a css file. Is there some other reason then organizational purposes for using CSS? Would embedding a single style be such a convention breaker? Thanks for reading this and I'd appreciate any feedback.
There are a couple of reasons.
Times when you want to change the style of a single element on a single page should be exceedingly rare, so it shouldn't be such a hardship. Any other time, it is going to be more efficient (from an HTTP caching perspective) and easier to maintain (from a separation of style and structure perspective) to externalize the style information.
Since there is a good chance that you'll want to style it differently for different media (e.g. screen and print), you'll need a proper stylesheet for that too.
If you embedd a style to several HTML pages, and want to change it later, you have to go file by file changing it. That is one good enough reason for me.
The key word here is maintainability. Organized code is maintainable code! It is far better to add an id to a tag and reference it in the global css file than to do it inline, because if you want to change that style later, you know where to find it, and you only have to change it in one place.
The reason you want to offload the CSS into a different file is so the browser can cache it. Otherwise, the browser has to load all the CSS as well as all the markup on every page. If you keep it in a separate file, the browser only has to load the CSS once.
The basic argument for this is that HTML's purpose is to provide structure while CSS's job is to provide styling, by embedding CSS in HTML you're breaking this basic rule. Plus, you'll have a tough time in maintaining pages.
Ideally, a design should be consistent enough that you can use generic rules for such situations. If you want to emphasize something, then <em> or <strong> is likely the way to go. After styling your <em> or <strong>, you can easily add the same emphasis to other areas of the site.
It's not simply about performance or style, it's also about consistency and ease of maintenance.
Find the similar elements in your design and mark them up similarly. It's as easy as that.
Even if it's "just 1" you should still do it because it helps you get in the habit of it.
embedded css has the following problems:-
1. It has browser compatibility problem. Example Ie has problem understanding inbuilt styling.
2. If you want to use the same css style again , it is better to have a class for it.
As someone who is beginning to make a transition from table based design to full CSS I'm wondering if using the style attribute to make adjustments to elements is considered "cheating" and if absolutely ALL presentation should be strictly in the style sheet?
See also:
A question of style - approaches to styling and stylesheets
There are cases where you know for sure that all you want to do is tweak the style of this one specific element, and nothing else.
In those cases you can happily use an inline style attribute. But then, at some point in the future, you'll realise that in fact you need to apply the same style to something else, and you'll realise you were wrong.
Been there, done that. 8-)
I feel there's an aspect that has not been touched upon here: the distinction between hand-edited HTML snippets and generated HTML snippets.
For human editing, it's probably better and easier to maintain to have the styles in a file.
However
As soon as you start generating HTML elements, with server-side scripts or with some kind of JavaScript, be sure to make all styles required for basic functionality inline!
For example, you wrote some kind of JavaScript library that generates tooltips. Now, you will inject DIVs into your page, that will need some styles. For example, position: absolute and, initially, display:none. You may be tempted to give these elements the class .popup and require that this class has the correct definitions in some CSS file. After all, styles should be specified in the CSS file, right?
You will make your JavaScript library very annoying to reuse, because you can no longer simply copy and invoke one .js file and be done with it. Instead, you will have to copy the .js file, but also have to make sure that all styles required by the script are defined in your CSS file, and you have to go hunting for those, and make sure their names don't conflict with classes you already have.
For maximum ease of use, just go ahead and set the required styles directly on the element as you create it. For styles that are purely for aesthetical purposes, such as background-color, font-size and such, you can still attach a class, to give the consumer of your script an easy way to change the appearance of your script elements, but don't require it!
You can use the style attribute, but the point of using CSS is that you make a change in a single file, and it affects the entire site. Try to avoid it as much as possible (old habits die hard)
It's not maintainable. All of us have done it. What you're best to do is put every adjustment into a style. Let me teach you something most developers do not know about CSS ... you can use N styles at a time.
For example, imagine you have a great style for colorized divs called someDIVStyle:
.someDIVStlye
{
background-color: yellow;
...
}
You want to use it, but just want to adjust the background-color to blue. Many people would copy/paste it and then make a new style with the change. However, simple create a style like this:
.blueBackground
{
background-color: blue;
}
Apply it as such:
<div class="someDIVStyle blueBackground">...
The style furthest to the right always overrides the properties of the styles preceding it. You can use a number of styles at once to meet your needs.
I agree with some other posters that it is best to keep the style information in the stylesheet. CSS tends to get complicated quickly, and it is nice to have that information in one place (rather than having to jump back and forth from HTML to stylesheet to see what styles are being used).
A little off-topic tip: Pressing F12 in IE8 brings up a great tool that lets you inspect the styles of elements in web pages you're browsing. In Firefox, FireBug does the same thing. Those kinds of tools are lifesavers if you want to know how a style change will affect an element.
It's a very "personal" question, to me the word "ALL" is a very strong word. You should do your best to have most of the styling in your css. but you can use style occetionally if it makes your life easier.
Generally it is best to have styles on the style sheet especially if it will be used multiple times, but using the style attribute is definitely not "cheating". A quick look through the stackoverflow source shows many examples of this.
Yes, it's kind of cheating, but it's up to you if you want to cheat a little. :)
The fundamental idea of having the styles in a style sheet is to separate the content from the layout. If you use the style attribute you are still mixing layout within the content.
However It's not that terrible, as you can quite easily move the style into a class. It's quite handy during development to be able to set a style on a specific element so easily without having to make up a class name and worry how the style will cascade.
I sometimes let the style attribute go through in the production code, if it's something that is specific for just one page, and if it's doubtful that it will be there for long. Occationally just because I am pressed for time, and it can be cleaned up later on...
So, even if you use a style attribute sometimes, you should still have the ambition that all the styles should be in a style sheet. In the long run it makes the code easier to maintain.
As others have said, in general, no.
However, there are cases where it makes perfect sense. For example, today I had to load an random background image into a div, from a directory with an unknown # of files. Basically, the client can drop files into that folder and they'll show up in the random background image rotation.
To me, this was a clear reason to dynamically build up the style tag on the div.
In addition, if you're using, for example, the .net framework with webforms and built-in controls then you'll see inline styles used anyway!
There can be very good reasons to put style information in a specific page.
For example, if you want to have a different header background on every page (travel agencies...), it is far easier to put that style information in that specific element (better, in the head of the document...) than to give that element a different class on every page and define all those classes in an external style-sheet.
The style attribute does have one important use: setting style programmatically. While the DOM includes methods to manipulate style sheets, support for them is still spotty and they're a bit heavyweight for many tasks, such as hiding and showing elements.
Yes, the style attribute is frowned upon in general. Since you're moving to the CSS method from table-based, I'd strongly recommend that you avoid inline styles. As a previous poster pointed out: bad habits are hard to break and getting into the habit of using inline styles for their temporary convenience is a mistake. You might as well go back to using the font tag. There's really no difference.
Having said that, there are occasions where it makes sense to use a simple inline style, but first develop the habit of using stylesheets. Only when you're comfortable with putting everything in a stylesheet should you start looking at shortcuts.
I think that's the general consensus of everyone who posted an answer
For so long, I've read and understood the following truths concerning web development:
HTML is for content
CSS is for presentation
JavaScript is for behavior.
This is normally all fine and good, and I find that when I strictly follow these guidelines and use external .css and .js files, it makes my entire site much much more manageable. However, I think I found a situation that breaks this line of thought.
I have a custom forums system that I've built for one of my sites. In addition to the usual formatting for such a system (links, images, bold italics and underline, etc) I've allowed my users to set the formatting of their text, including color, font family, and size. All of this is saved in by database of forum messages as formatting code, and then translated to the corresponding HTML when the page is viewed. (A bit inefficient, technically I should translate before saving, but this way I can work on the system live.)
Due to the nature of this and other similar systems, I end up with a lot of tags floating around the resulting HTML code, which I believe are unofficially deprecated since I'm supposed to be using CSS for formatting. This breaks rules one and two, which state that HTML should not contain formatting information, preferring that information to be located in the CSS document instead.
Is there a way to achieve dynamic formatting in CSS without including that information in the markup? Is it worth the trouble? Or, considering the implied limitations of proper code, an I to limit what my users can do in order to follow the "correct" way to format my code?
It's okay to use the style attribute for elements:
This is <span style="color: red;">red text</span>.
If users are limited to only some options, you can use classes:
This is <span class="red">red text</span>.
Be sure to use semantic HTML elements:
This is <strong>strong and <em class="blue">emphasized</em></strong>
text with a link.
Common semantic elements and their user-space terms:
<p> (paragraphs)
<strong> (bold)
<em> (italic)
<blockquote> (quotes)
<ul> and <ol> with <li> (lists)
More...?
Likely less common in forum posts, but still usable semantic elements:
<h1>, <h2>, etc. (headings; be sure to start at a value so your page makes sense)
<del>, and, to a lesser extent, <ins> (strikeout)
<sup> and <sub> (superscript and subscript, respectively)
<dl> with <dt> and <dd> (list of pairs)
<address> (contact information)
More...
This is a bit tricky. I would think about what you really want to allow visitors to do. Arbitrary colours and fonts? That seems rather useless. Emphasis, headings, links, and images? Well that you can handle easily enough by restricting to those tags / using a wikitext/forumtext markup that only provides these features.
You could dynamically build an inline style sheet in the head of the html page fed to the users. Put in the head of the page and allow it to target those elements configurable by the user.
Alternatively, there's the notion of using external stylesheets that feature the most common adjustments, but there'd be hundreds of them to account for every possible alternative. If you use this you'd need an external style sheet for a specific font size, colour and so on, and dynamically link to those in the header. As with any external stylesheet. Though this is almost unbearably complex to enable.
Option one would work okay though.
As an example:
<STYLE>
h1,h2,h3,h4 {font-family: Helvetica, Calibri;}
p {font-size: 1.2em; // Populate all this with values from the Db.
font-weight: bold;
}
a {text-decoration: underline;
color: #f00;
}
</STYLE>
Also, it just occurred to me that you could probably create a per-user stylesheet to apply the configurable aspects. Use
<link href="/css/defaultstylesheet.css" type="text/css" rel="stylesheet" media="all" />
<link href="/css/user1245configured.css" type="text/css" rel="stylesheet" media="all" />
<!-- clearly the second is a stylesheet created for 'user 1245'. -->
The bonus of this approach is that it allows caching of the stylesheet by the browser. Though it might likely clutter up the css folder, unless you have specific user-paths to the user sheet? Wow, this could get complex... :)
This is an interesting situation because you can have an infinite number of different styles, depending on your users' tastes and their own personal styles.
There are a couple of things you can be doing to manage this situation efficiently. Probably the easiest would be to just use style overrides:
<p style="color: blue; font-size: 10pt;">Lorem Ipsum</p>
This is quick and easy. And remember, this is what style overrides are there for. But as you've said, this does not fit well with this content-presentation separation paradigm. To separate them a little more, you could build some CSS information on page load and then insert it into the <head> tag of your HTML. This still keeps the HTML and the CSS somewhat distinct, even though you're not technically sepating them.
Your other option would be to build the CSS and then output that to a file. This, however, would not be efficient (in my opinion). If you were to, on every page load, build a new CSS file that accounts for your users' unique preferences, this would sort of defeat the purpose. It's the same thing as the second option, using the <head> tag, you're just making it look separated. Even if you used techniques such as caching to try to limit how often you have to build a CSS file, will the ends really justify the means?
This is a completely subjective topic and you should, in the end, choose what you're most comfortable with.
I don't know which framework or even language you are using but e.g. Django uses a certain template language to sort of represent the HTML being output. I think a nice solution would be to simply use a different "template" depending on what the user has chosen. This way you wouldn't have to care about breaking the "rules" or having a bunch of basically unused tags floating around in the DOM.
Unless I completely misunderstood...!
The easiest way to manage this is probably to emit dynamic CSS when the pages are generated, based on the user's settings. Then everything is doing the job it is supposed to be doing and the server is doing the work of converting the user's settings into the appropriate CSS.
With the CSS doing this work, you can use appropriate attributes in the HTML (id and name and class and so on) and emit CSS that will cleanly format everything the way you want.
Consider the benefits versus the costs before you do anything. What is actually wrong with your code right now? Tag soup and combined content/presentation is to be avoided not because it makes a bad website, but because it is hard to maintain. If your HTML/CSS is being generated, who cares what the output is? If what you've got now works, then stick to it.
I assume you are allowing only a limited white list of safe options, and therefore parsing the the user's HTML already.
When rendering the HTML you could convert each style declaration to a class:
<span style="font-family: SansSerif; font-size: 18px;">Hello</span>
To:
<span class="SansSerif"><span class="size_18px">Hello</span></span>
Laborious to generate (and maintain) the list. However you needn't worry about a class for each combination, which is of course your main problem.
It also has the benefit of extra security as user's CSS is less likely to slip through your filter as it's all replaced, and this should also ensure all the CSS is valid.
I've allowed my users to set the
formatting of their text, including
color, font family, and size. All of
this is saved in by database of forum
messages as formatting code, and then
translated to the corresponding HTML
when the page is viewed.
So, you've done formatting through HTML, and you know that formatting is supposed to be done through CSS, and you realise this is a problem, and you got as far as asking a 300-word SO question about it ... ?
You don't see the solution, even though you can formulate the question ... ?
Here, I'll give you a hint:
All of this is saved in by database of
forum messages as formatting code, and
then translated to the corresponding
HTML CSS when the page is viewed.
Does that help?
Is this question a joke?
Often when I'm designing a site, I have a need for a specific style to apply to a specific element on a page and I'm absolutely certain it will only ever apply to that element on that page (such as an absolutely positioned button or something). I don't want to resort to inline styles, as I tend to agree with the philosophy that styles be kept separate from markup, so I find myself debating internally where to put the style definition.
I hate to define a specific class or ID in my base css file for a one-time use scenario, and I dread the idea of making page-specific .css files. For the current site I'm working on, I'm considering just putting the style definition at the top of the page in the head element. What would you do?
Look to see if there's a combination of classes which would give you the result that you want. You might also want to consider breaking up the CSS for that one element into a few classes that could be re-used on other elements. This would help minimize the CSS required for your site as a whole.
I would try to avoid page-specific CSS at the top the HTML files since that leaves your CSS fragmented in the event that you want to change the appearance of the site.
For CSS which is really, truely, never to be used on anything else, I would still resort to putting a #id rule in the site-wide CSS.
Since the CSS is linked in from a different file it allows the browsers to cache that file, which reduces your server bandwidth (very) slightly for future loads.
There are four basic cases:
style= attribute. This is the least maintainable but easiest to code. I personally consider use of style= to be a bug.
<style> element at the top of the page. This is slightly better than style= because it keeps the markup clean, however it wastes bandwidth and makes it harder to make sweeping CSS changes, because you can't look at the stylesheet(s) and know what rules exist.
page-specifc css: This lets you have the clean HTML and clean main CSS file. However, it means your client must download lots of little CSS files, which increases bandwidth and page loading latency. It is, however, very easy to maintain.
one big site-wide CSS: The main advantage of one big file is that it's only one thing to download. This is much more efficient in terms of bandwidth and latency.
If you have any server-side programming going on, you might be able to just dynamically combine multiple sheets from #3 to get the effect of #4.
I would recommend one big file, whether you actually maintain it as one file or generate the file through a build process or dynamically on the server. You can specify your selectors using page-specific IDs (always include one, just in case).
As for the answer that was accepted when I wrote this, I disagree with finding a "combination of classes that gives you the result you want". This sounds to me like the classes are identifying a visual style instead of a logical concept. Your classes should be something like "titlebox" and not "red". Then if you need to change the text colour on the user info page, you can say
#userInfoPage .titlebox h1 { color : red; }
Don't start applying classes all over the place because a class currently has a certain appearance that you want. You should put high-level concepts into your page, represented by HTML with classes, and then style those concepts, not the other way around.
I would set an id for a page like
<body id="specific-page"> or <html id="specific-page">
and make use of css override mechanism in the sitewide css file.
I think you should definitely expand the thought process to include some doubt for "page specific css". This should be a very very rare thing to have. I'd say go for the global style sheets anyway, but refactor your css / html in a way that pages don't have to have super-specific styling. And if in the end there's a few lines of page-specific markup in the global css, who cares. It's better to have it in a consistent place anyway.
Defining the style in the consuming page or inlineing your style are two sides of the same coin - in both cases you are using page bandwidth to get the style in there. I don't think one is necessarily better than the other.
I would advocate making an #Selector for it in your site-wide main stylesheet. The pollution is minimal and if you really have that many truly unique cases, you may want to rethink they way you mark-up your sites.
I would put them in a <style /> tag at the top of the page.
It's not worth it to load a page-specific CSS file for one or two specific rules. I would place it in tags in the head of the document. What I usually do is have my site-wide CSS file and then using comments, section it up based on the pages and apply specific rules there.
As you know style-sheet files are static files and cached at client. Also they can be compressed by web server. So putting them in an external file is my choice.
For that situation, I think putting the page-specific style information in the header is probably the best solution. Polluting your site-wide style sheet seems wrong, and I agree with your take on inline styles.
In that case I typically place it at the top of the page. I have a page definition framework in PHP that I use which carries local variables for each page, one of which is page-specific CSS styles.
Put it in the place you would look if you wanted to know where the style was defined.
For me, that's exactly the same place as I would place styles that were used 2 times, 5 times, or 170 times - I see no reason to exclude styles from the main stylesheet(s) based on number of uses.