NUT CONFERENCE

CSS provides a way around this: the text-transform property. This allows you to write your content in full-sentence case, and display it in full uppercase or lowercase as desired for stylistic reasons. For example, if your design calls for <h2> tags to be in uppercase, use

h2 {
text-transform: uppercase;
}

Of course, this allows you to simply remove the property if you change your site design; no content needs to be rewritten.

Some offenders even publish an RSS feed using uppercase titles. Never do this. People who want to syndicate your feed normally want it in sentence case, and there's no way to force that to happen if you aren't publishing the RSS feed using proper sentence case.

It's possible to use a custom image for these bullets, by way of the CSS list-style-image property. This is a great way to carry your site's theme through into the content.

If you can't be bothered to draw custom images, you can at least make your bullets agree with the font using the list-style-type. With sans-serif fonts, square bullets usually look more professional. If you are using serif fonts – and this is a bad idea incidentally, because they aren't as legible on a screen – use circle or disc (ie. unfilled circular) bullets.

Obviously, this means that for any site that IE7 breaks, it is failing on the standards-compliant CSS. But equally, as I noted before, not as many sites break as was expected. So that's pretty good news.

But for the sites that do break, and future sites in general, the situation is a mess. It's now necessary to split IE7 styles into different, conditionally included files, either by selecting on UA (which is unreliable) or use a gut-wrenchingly sickening IE misfeature called "conditional comments". IE6 rules need to be moved too, as IE7 will have significant common ground with IE6 and you don't want to have to maintain two copied of any rule that is shared.

Having rules split between different files makes it harder to work with, because in CSS you need to literally compare selectors to work out the precedence. * html is much easier to work with because you can place your IE rule right next to your real browser rule, and easily cross-reference the differences. Or if you change the real-browser rule, you can also amend the IE rule at the same time. More annoyingly, if you already have a tidy collection of CSS stylesheets importing one another with the @import statement, you have to either collect your IE styles in one file, or duplicate the tree for IE. Neither is very maintainable. The @import statement is not very useful anyway though, because CSS's precedence rules don't allow CSS to be modularised in an elegant way.

In Microsoft's defence, they are looking for a painless route to standards compliance that in all honestly does not exist. But I apportion the blame entirely to them, for two reasons. First, it was they who let the situation regarding standards compliance get so out of hand first; in effect, they are five years too late in starting to take this course of action. Secondly, bundling IE with Windows is one of the most devastatingly damaging things they have ever done. The cost to businesses worldwide could run into hundreds of millions, if not billions of dollars, and this money is not even paying Microsoft shareholders: it's being flushed down the toilet. Web designers to some extent profit from it at the expense of other businesses, but even so, we would rather not have to do it because we would then simply be able to achieve more. We would probably charge more or less the same, but all sites would be stunningly beautiful with rich interactivity.

CSS, has its own problems, of course, but these would have been very hard to predict all that time ago when it was drawn up:

• Selector-based stylesheets cannot be refactored without reference to a schema for the source document.
• CSS cannot deal with varying capabilities across implementations.
• CSS cannot be modularised, because selectors can very easily collide and supercede each other, dependent on the way the selector is described rather than the structure of the module. For modularised HTML/CSS 'components', you really need to prevent styles being overriden unless explicitly requested.
• CSS units cannot be specified as an arithmetic operation on unknowns, such as '(1em-3px)'. This means dimensions measured in ems (useful for text) are incompatible with lengths measured in pixels (useful for images).
• CSS has insufficient control of vertical positioning. The basic operations available are "the vertical order is the same as the document order", "x is at this vertical position", and with a bit of creativity with floating blocks, "x follows all of these", plus one modifier, "all my descendants lay out relative to me".
• CSS doesn't allow constants. This means that you have to repeat constants, say colour codes or border styles, and change them in more than one place.
• CSS has some bizarre quirks. For example, it doesn't include padding in the width and height dimensions, so if you increase the padding, you have to decrease the width correspondingly. IE for years did the opposite, which is totally wrong but much more intuitive.
• CSS selectors are lacking tidy disjunctions and assertions, things that exist nicely in XPath. It's possible to work around these, but not necessarily succinctly.

There is no good way I know of refactoring selector-driven stylesheets. Procedural styling, such as that used by smarty or even vanilla PHP, is easy. Styling starts in one place and flows in a controlled way through to the end. Selectors make life difficult because you don't know what is going to match where or what is overridden by a different selector elsewhere. It's very difficult to work out how it works, even with comments, because you don't know which comments are immediately relevant and besides, they refer to a document structure which is dynamically generated.

I've never managed to cleanly refactor CSS and I've not really tried with XSL, because it looks difficult for all the same reasons. With XSL there's an intermediate XML structure that can be refactored, but this is generated procedurally. But for the presentation layer – CSS, XSL and to some extent Javascript – if anyone knows a better way of refactoring than throwing it all out and starting again, please let me know.