Cascading Style Sheets - February 7th 2007

WHAT POOR DESIGN

I have to admit that I’ve been a bit slow to get onto the Cascading Style Sheets (CSS) bandwagon. The old way of formatting text on websites using <font> tags and the like still works of course so the incentives for changing over to CSS are not immediately obvious. However, there are some clear advantages of CSS both in making it easier to change the layout and look of a website and to improve its accessibility. So I decided it was past time to embrace the (not so) new technology and get on with it.

Learning the basics of CSS isn’t difficult and the major web page editors, such as Dreamweaver which I use, provide quite a lot of help and reduce the amount of typing required. But when you get into it some more, CSS looks more and more like the horse that was designed by a committee (i.e. a camel).

Inheriting styles from one class to another is possible but is done in such an odd way that you cannot tell what something will look like just by looking at the style sheet. The inheritance depends on how the HTML is structured! This is totally at odds with all object oriented design principles and I have not yet seen a decent rationale for it.

As for laying out tabular information using CSS rather than using a <table>, words almost fail me! The CSS is tortured and impossible to understand without the HTML that uses it. Even looking at all of that isn’t particularly helpful so really you have to see the results in a browser to understand what’s going on. It is not recommended that tables are abandoned completely in favour of CSS but the main argument for using CSS instead is that the resulting pages tend to be smaller and don’t take so long to download. Well, what a weak argument. So using a table bloats a web page by 100 bytes. Big deal!

CSS could have been designed properly so that both the CSS and HTML parts could stand alone, make sense in isolation and not need a browser to understand what the result would look like. Unfortunately, of course, it’s now too late for CSS and I guess we’ll just have to wait for the next “improvement” in web page design. I suppose I could quit complaining and design and implement that next step but it doesn’t really interest me enough to go do it.

Comment by Pete on February 17th 2007

I understand what you're trying to say. While CSS has made any "template" style websites and designs a breeze at times, other times it is a plain headache.

It's wonderful if I can get CSS to work in firefox or opera or safari and so on. If I can hack around certain issues it's not always a real huge issue..

However the fact is most normal internet users still use Internet Explorer. Most computer users use windows installed on their machines..

Yeah maybe techies and geeks like I fool around with linux, unix, mac, and then Firefox and safari and so on, but at the end of the day, too many forums and tech people rarely look at real world issues. It's as if people forget that all that flashy stuff and ease of use for fellow techs is useless if more than half the world can't figure it out or don't want to..

If something doesn't work in IE, and a long winding hack is required to get around it, then in the long run, for most projects that pay my bills, it's not worth it..

Yeah pet projects are nice to fool around with and cool to use, but as you get older and you weren't lucky enough to work for a google or microsoft when the stocks skyrocketed, then the reality is, you use what works for most users, not what most techies think is cool. Plain and simple..

CSS is nice, but in the end, sometimes it creates more headaches.

Comment by Kjell Bleivik on February 20th 2007

I disagree. Some properties in HTML tags are being depricated.

Comment by Martin Fleming on March 8th 2007

Ok sure, there are some "real world" issues with CSS. Firstly, in my opinion CSS 2 is not quite complete. CSS3 looks really exciting as the much needed "column" property will soon be with us, also with a whole bunch of new psuedo classes and selectors. The advantage CSS3 will bring certainly will get even the die hard table user to switch.

Couple of important issues regarding tables though. No where in the XHTML draft does it say that tables cannot be used for layout, and they are not the most hindering issue for accessibility. However tables for layout does have a big effect on upcoming technologies such as XHTML+Voice, try to get Opera 9 to read to you a tables based layout website and the visually impaired user will make no sense of it! Sorry David, but whoever told you to use CSS instead of a table to layout tabular data is 100% wrong. This seriously breaks semantics.

The biggest issue as we all know with CSS is a rather pants product from Microsoft called IE. I still find it shocking the biggest software vendor in the world cant make a decent web browser. IE7 was a big improvement but still far behind the likes of Opera, Konqueror, Firefox and Safari. I mean MS cant even make a decent operating system, its all a bit of a joke and proves how much more important marketing is over the product.

The cascade in CSS is a lot easier to grasp if IE could actually implement this properly then we could all use CSS easier. For instance, if we have an unordered list within an unordered list, all styles we apply to the parent list will be inherited into the second list, making it confusing and time consuming to overwrite our styles for the child list if we wanted it to have a different appearence. All it would take is the parent-child selector to stop this. IE7 now supports this but what about adjacent selectors, first and last childs etc. The cascade was not designed to be as brutal as it is in real world, but for these issues and more!

Also say you have a multi page website but one page needs slightly different styling, we could include a sepearate style sheet with many of the rules duplicated, or we could @import the few lines of new css into that page, we could also cascade our new rules with higher priorities eg id wins over class or tag so this page could user the css cached already in the browser and overwrite a small portion of it. This is where the cascade becomes very useful.

But the most important argument for CSS is that my clients expect it. many clients are becoming aware of the word CSS and making tables based layouts for several thousand pound websites would be financial suicide for my company.

I personally believe in CSS, but those who do not, they may have to get on board before they get left behind in this fast changing industry. For sure being CSS able has improved my workload, there is no question about that.

PS, can we make this text box bigger as its awkward to type into?

Comment by David Sawers on March 8th 2007

Martin,

I made the comment box bigger. Hope that helps.

There's no doubt CSS is here to stay and serious web developers have little choice but to embrace it.

Just a shame it's such a pig to use.

Comment by Kjell Bleivik on March 17th 2007

[Quote] Couple of important issues regarding tables though. No where in the XHTML draft does it say that tables cannot be used for layout, and they are not the most hindering issue for accessibility. However tables for layout does have a big effect on upcoming technologies such as XHTML+Voice, try to get Opera 9 to read to you a tables based layout website and the visually impaired user will make no sense of it! Sorry David, but whoever told you to use CSS instead of a table to layout tabular data is 100% wrong. This seriously breaks semantics. [/Quote]

My view on tables. Tables are for tabular data.

Be consistent when using tables:

Example:
Some recommendations for surfers using screen readers. I do not know how it is on browsers for mobile devices.

1. Use <table summary="This table ..."> Tells the purpose of the table.

2. Use <caption>Shows ...</caption> By default, the browser will generally display the caption above the table. There is a related caption-side CSS property. Example:

table {
caption-side: bottom
}

Using a caption ensures that the text is tied to the table and that is recognized as the table's caption - there is no chance that the screen reader could be interpreted as a separate element.

3. Use table headers: <th> ... </th>