Wandering Thoughts archives

CSS is assembly language

I was struck by a thought today: CSS is an assembly language. This explains a lot of its issues, because (like other assembly languages) it suffers from the problem that you can't communicate your high-level intentions, only your low-level actions.

The whole rat's nest of columnar layout issues and the ensuing irritations are where CSS's true colours show through most clearly. But it's not the only area; almost everywhere you look, CSS is about the low-level stuff. You can set colours, but not colour relationships.

This also neatly explains the experience of creating CSS. Ignoring the browser quirks, it is still just as tedious and irritating as writing any other low-level language; you jump through an awful lot of peculiar hoops to get your results.

Now that I've realized this, I may be a little more relaxed when I have to deal with CSS. It doesn't make CSS any nicer, but it does make it less irritating now that I understand where it's coming from. (I can transfer the irritation to the people who still haven't given us a high-level layout language.)

(This shouldn't be too surprising, since a good part of CSS was designed by people who just wanted low level PDF-like control over page layout. That's an assembly level function if there ever was one.)

On the various meanings of <tag />

With the growth of XHTML, some HTML documents have started sprouting things of the form '<tag />' or '<tag/>', intended to represent empty tags. Sometimes this is due to attempts at XHTML to HTML compatibility, and sometimes it's just due to HTML superstitions. (Most people who write HTML are not experts and have not read the W3C specifications, so superstitions are not uncommon.)

These people and documents are making a mistake. Unfortunately, there are three entirely separate things that <tag /> can mean:

• if you are actually successfully serving XHTML, this is an empty (self-closed) element. (Hopefully it is an element that can actually be empty.)

• in HTML in all the major web browsers, this means 'tag, with an attribute called "/"'.

• in strictly compliant HTML, including as parsed by the W3C validator, this means '<tag>>', because it is actually a SGML feature called minimization.

The difference between validators and browsers is an especially pernicious gotcha; a web page can pass validation, but in a completely different way than how a browser will interpret it. (It happens because validators usually use a real SGML parser, completely with all of the obscure features, but browsers do not.)

It is very fortunate that no popular browser actually implements tag minimization, because no one expects them to. Also, HTML has some remarkably dark corners where you can get eaten by a grue.

If you want to read more about this, Empty elements in SGML, HTML, and XHTML will give you all of the detail and background that you could want. (There you will also find a nice example of why you should always put attribute values in quotes.)

(I owe my exposure to these pages and this issue to plasmaturm.org and Frank Hecker. And in truth in advertising, the final impetus for writing this down was provided by this blog entry.)

A spectacular web spammer failure

In the spirit of earlier heroic failures, I just saw someone attempt to put an entire POST form in the actual HTTP request. No, really. The incoming request looked something like this:

login=%5Burl%3Dhttp%3A%2F%2Fwww.nextlevelnews.com%2F [.. elided ..] %2F70.html%0D%0A+&view=login&page=blog%2Flinks%2FBestToolPOST /~cks/space/.login HTTP/1.1

This is perhaps the most abject spammer failure I've seen.

(It also confirms that web spammers are targeting my login form as well as the 'post a new comment' form; I have a theory on that, which doesn't fit in this margin.)

Unsurprisingly, the request came from a charter.com cablemodem that is currently in bl.spamcop.net and the CBL, among other places.