The retroguard returns: Some SGML comments

The otherwise honourable Acid2 test dredged up something I had hoped I wouldn’t see again. Most tests are CSS tests, parsing and layout, but they also threw in an old misfeature from HTML’s past. If you look at the test’s source code you will find “ERROR”. An HTML comment followed by “ERROR”, right? No, unlike in the more modern XML "" are not comment delimiters, “--” is. In SGML so ERROR is actually a part of a long comment. Easy to see, isn’t it?

In theory HTML is a SGML application so SGML rules apply. In practice there has never been a SGML web browser and there never will. For a long time Opera was alone in supporting some SGML-isms like “--” comment delimiters until we removed them around Opera 5 or 6, but Opera wasn’t even close to being a SGML browser so all we did was to add quirks and give no benefits.

Mozilla later made exactly the same mistake as we did and they are still doing it. This causes an interoperability problem as Mozilla will fail on this comment and other browsers don’t. The obvious solution would be for Mozilla to change their browser, but WaSP opted for the other option instead. If that view wins through web developers will be bound to count their hyphens. Any multiple of four is good, anything else is bad.

Opera and XSLT

New member beckfield started two threads on XSLT and Opera, one civil, one less so. That is fairly topical as the recent buzzword AJAX (no relation) includes XSLT and Opera does not.

There is no discussion about XSLT on the server side, transformations is what web servers do, but client-side transformations would put XSLT into another role. XSLT will have to think like a client and is it up to the task?

This has not been an issue due to the dearth of XSLT-enhanced web pages, there is just a handful sites on the web though Google Maps is one of those, but as far as I know nobody has studied this. Where does client-side XSLT really fit in with the Web UI (HTML, CSS, JS) and how well does it adapt to the user’s environment?

Forms and function

Forms handling is among the most important functions in a browser, the HTML 2.0 forms are seriously outdated and news.com.com considers the forms alternatives. As I see it there isn’t a conflict Web Forms 2.0 vs XForms. Web Forms is designed partially XForms compatible. There are substantial differences that run deeper than on the syntactic level (such as the names of the elements) and there is no tool today that can automatially turn arbitrary XForms forms into Web Forms. Some, probably most, forms will be very similar in the two languages both in structure and functionality and could be converted easily.

Media, style, and access

The css Zen Garden has done more than any other site to evangelize that having a simple, expressive markup will allow you to create a great variety of displays. Even so I am struck with how similar most of the designs are, just throwing in different pictures. It is the same with Opera skins. Many are pretty, more are ugly, some are plain weird. But only a few are original. Neither are conformity breaking or pragmatic.

Simple markup and baroque styles is also more mallable, something that matters most in the field where I spend most of my time, between device independence (device is most of the time Opera-speak for phone), accessibility, and multimodality (which in Opera most of the time means Voice). They all have similar, but not identical, requirements, there are even a few features that would be a boon for one group of users but detrimental for others.

(more…)

Printing with CSS

I’ve spent more time with other media than print lately, but this article on XML.com, Printing XML: Why CSS Is Better than XSL, is well worth the read.

I have no opinion of XSL-FO as a print formatter, relative to for instance Postscript. What I have noted is that the printer vendors have been working hard on using XHTML and CSS as printer drivers.

Now, if we were to get over the “printer-friendly version” habit…

More revolution or evolution

It was too tempting to stay away from and nobody has been able to. An election where the liberal pro-Europe candidate was predicted the winner by the exit poll, but the incumbent is declared the winner in a process where the election itself got the most of the attention, leaving the country split by geography. On deeper inspection the candidates aren’t as different as presented by their propagandists, but the differences that remain are still real.

Ukraine is the biggest country in Europe by area (if you disqualify Russia as Eurasian) and among the largest by population. Even though it has been peripheral in the grand power schemes of the continent (as its name indicates), it is simply too large to ignore.

The fall of the Soviet Union did not mean a fall in corruption. Ukraine has been more thoroughly pillaged than Russia, and is now seen as the 19th most corrupt country in the world according to one index. Elections are never completely fair anywhere, among other things they usually favour the incumbent, and if they can be manipulated they will. But in this case the system isn’t just bent, it is crooked, and the Ukrainians deserve better.

I think these last months have been good for Ukraine, on the principle of “one more push”. Ukraine and even Russia have conditional democracy, democracy with flaws. There may not be a velvet or rose revolution, but discounting a Yugoslavia breakdown and doubting a Belorus path, any change will be for the better.

HTML withdrawal

Yesterday I finally left the HTML working group. While it was a recent discussion that made me ask myself what was the point in staying, I have grown more disenchanted over the years.

Unlike some I don’t agree that XHTML 2.0 is an unmitigated disaster. There is much good stuff in the spec. It is also the first structural work on HTML since HTML 4.01, five years ago. In the meantime the focus has been to make HTML XML-compatible and to split HTML into modules. Whether HTML is formulated in XML or in some kind of SGML matters, but it isn’t important relative to how the language itself should evolve. HTML 4 is overdue for an update.

XML (and thus XHTML) has two obvious advantages. It separates between syntax errors (well-formedness) and expectation errors (validity), and the character set of the document is not in doubt. The XHTML modularization itself isn’t that useful for practical purposes where the conformance rules and the implicit fallback principle (ignore what you don’t understand) is what you need. A side effect of the work on XHTML 2.0 is that XHTML Modularization will be updated to actually describe the modules in the document itself, and not by reference to HTML 4.01 as has been the case up until now.

The revolutionary aspect of XHTML 2.0 was overdone. I don’t think the W3C, or browser vendors, or web editor vendors, or any other organization or group has control over the web or its formats. I don’t overly worry about Microsoft either. They tried to replace the web before and failed spectacularly. They might try again, but if they do they will fail again. The web is the world’s largest installed base. It will change, but not on command. A decade ago change by decree might have been feasible, but this is the difference between shepherding a flock of hundreds of sheep and one of several billions. That flock goes where it wants to go, not where we want it to go.