Cascading Style Sheets

CascadingStyleSheets allow Web designers to specify the presentation of Web pages. This promotes the separation of semantic markup (in a HyperTextMarkupLanguage page) and presentation markup (in a style sheet). CSS offers a simple form of inheritance which lets Web designers set a site-wide presentation style OnceAndOnlyOnce. This default style can be overridden on parts of the site (from sets of pages down to individual elements on a page) - that's the "cascading" part.

In some cases, CascadingStyleSheets can be an alternative to the FacadePattern. They can be used to support ConsistentLook and the DynamicUserInterfacePattern.

See UserStyles and WikiStyle for sample UserStyles applicable to Wiki.

Cascading Style Sheets are a WorldWideWebConsortium specification: http://www.w3.org/Style/CSS/.

InternetExplorer's CSS implementation of font size is broken

Often, I find it hard to read sites that use CSS because they tend to set the font size too small, and enlarging the text through InternetExplorer's text size menu doesn't work. -- NickBensema

This isn't CSS' fault. It happens because the people who write the CSS don't have the knowledge, experience, or courtesy to use relative font sizes [or don't realize that different OSs have different ideas about how big a 'point' is on the screen - but you're not supposed to be using points for screen sizes, anyway]. Specify font sizes in percent or ems, as in "100%" or "1em" (equivalent) and IE will scale them without any problem. Setting them as specific point sizes or pixel sizes breaks this - yet another reason to design for flow, not appearance. -- DaveCantrell

That's quite wrong. LOTS of websites set a negative relative size on the whole page, just because most browsers have a too-big default. Then if I open that website in a browser with a sane base font size default (Konqueror), everything is way too tiny to read and I have to use the browser's zoom feature. The developers probably think they're doing things right because "we're using relative sizes just as they told us." -- Nicolas

OperaBrowser, AmayaBrowser, MozillaBrowser, and NetScape allow you to work around this problem.

Basically by interpreting the user's request for a larger size as 'I don't care if it says 12pt - I want it bigger!

Unfortunately, InternetExplorers? implementation of more than just font-size is broken. So is its box model, and other important things.

Why the hell did they deviate from XML/HTML syntax for the "style sheet language"? The last thing a web developer needs to worry about is Yet Another Language.

XML wasn't as big when the CSS spec was being created as it is now. I'm also having difficulties imagining an XML replacement for CSS that would be as clean and simple.

Well, the CSS language is hardly clean and simple in my opinion, so it is hard to do worse.

You are welcome to suggest another syntax. Which would be more clear and simple, and even compatible with XML.

Re: "It happens because the people who write the CSS don't have the knowledge, experience, or courtesy to use relative font sizes..."

Often one has to design based on strict requirements from a "designer" or manager who does not want to deal with the implications of relative fonts. Making something scale is harder than making it fit a fixed set of layout requirements. Most companies really want positional (absolute) layout tools in my experience. If they want a green oval in a particular spot, they assume or expect that one can just create a green oval image and just drag it into place. See CoordinateVersusNestedGui.

You *can* do this with CSS if you want to. It's stupid, and it's a poor user experience, but that's never stopped anyone before. Designing for flow creates a superior application, especially in a web environment, but if it's really important to you to avoid doing this, you can.

YouCantAlwaysGetWhatYouWant

Why a Different Language?

I think it is dumb that CSS is a different language than HTML. Whey make Yet Another web language? We already have JavaScript, HTML, the host language, and a bunch of other webbish languages floating around in use.

But CSS is so much more versatile than HTML - they're two entirely different concepts. It's a little bit like saying why have television when we already have books - they do different things. CSS keeps my HTML and Javascript tidy. And I like tidy -- KachinaCrowe

We could have created a language for CSS that was, for all intents and purposes, an HTML Macro language. It would do the same thing and it would be unreadable, but people with a shortage of grey cells wouldn't have to learn another syntax. I suppose that could be positive. --MarcThibault

You seem to be implying that multiple languages is better than one, and that HTML is not sufficiently expressive for styles. I would like to see more justification of these implications.

Example:

 <style name="foo" width=1 cellpadding=3 color="red"\>
 ...
 <table style="foo">
 ...
 </table>

And for separate files:

 <style href="myStyles.html">
 ...
 <table style="foo">
 ...
 </table>

Embedded tags would override style sheet tags.

This takes care of attributes and basic selectors, but that's only part of CSS. How would you model more complex selectors like '.foo li p' and 'p + p'?

Related: OverhaulingStyleSheets

CSS Vs. HTML Tables

I see a lot more sites are using CSS for layout management (content placement) instead of HTML tables. HTML tables are indeed a POS to work with as a developer, but the CSS-based placement is often buggy and awkward. Panels sometimes overlap, and the scrolling is slow or jumpy. HTML tables still seem to be the smoother option, at least from the user's perspective.

A "CSS Purity" rant: http://iamelgringo.blogspot.com/2009/02/tables-vs-css-css-trolls-begone.html

I couldn't find a way to set a consistent default font for an entire web page. There used to be a BASEFONT tag that took care of that, but it's been deprecated.

But there is no decent replacement that works in all browsers. A "body" spec ignores it for tables in some browsers, H tags in others, etc. I got tired of making a big list of specs that require repetitious and error-prone changing and simply use an outer <font>...</font> tag pair. It's still not "proper", but it works on every browser I've tried. I consider it the least of two evils. I'll take a simple bastardized solution over a complex bastardized solution.

Does anybody know of a tracing tool or technique to back-track which stylesheet or style source is affecting a given element? In complex or screwed-up environments, one is often dealing with pasta-like layers such that it's difficult to tell where a given element is getting its styles from.

Modern browsers now have this built-in, typically with right-click, Inspect Element. On some, you may need to turn on a developer tools option.

We're stuck with older browsers as our target audience. We can use a newer ones for some of that, but often they don't behave the same as the old one. It's probably an unrealistic request for a tracer tool to emulate obsolete browsers and match them bug for bug.

{Top, I never fail to be amazed by the degree to which the conditions in which you work seem to be consistently crap. Does anything good ever happen?}

I keep telling ya, it's Real Live Dilbert here. (It has other perks to sort of compensate.) Most places I've worked are like that. The good times are short-lived as staff gets shuffled or the Good Guys retire. The best and newest gizmos go to the best brown-nosers. People are social animals, not Vulcans. HumansSuck.

{Curious. I guess I must be one of the brown-nosers. Earlier today, I wangled root on a "private cloud" of unused highly-connected machines. I now have 144 hyperthreaded cores (on 72 physical cores) of 2.4ghz Xeon to play with. HumansRock.}