Hacker News Reader

Comment by arcatek | Hacker News Reader

I kinda agree, but one has to concede that XHTML has failed for a reason.

XHTML failed because doing the old, broken, tag-soupy mess still worked exactly as well from the user perspective. You just can't get people to work harder for invisible benefits. In a sense, it's a reason, but it doesn't mean that tag soup is a good thing.

I often wonder how different the internet would be if Postel's prescription never gained traction and fail-fast behavior were the norm instead.

Also because all of the tooling was terrible and extensibility was non-existent. It's easy to imagine a world where XHTML worked out better because the browsers provided clear, informative errors rather than a blank page, someone at the W3C cared enough to have a usable validator which produced helpful warnings and errors, and attention was paid to the less friendly bits of the XML ecosystem[1].

Instead, it felt like we had a bunch of people who though that big lofty standards were so obviously correct that everyone else would take care of those boring implementation details, and 99.9999% of web developers correctly realized that there was very little measurable downside to sticking with something which was known to work.

1. Simple examples: namespacing is a good idea but it leads to gratuitous toil in most tools – e.g. a valid XML document which has <foo> should just work if you write a selector for /foo, as present in the document, rather than requiring you to do kludgey things like have to lard up every parser registering the same namespaces which are also declared in the document and writing fully-qualified selectors like /mychosenprefix:foo or /{http://example.org/fooschema/1.0}foo for every tag, every time.

Similarly, getting XPath 2.0 support to actually ship in enough tools to be usable would have made one of the better selling points for using XML actually exist as far as the average working programmer is concerned.

Writing proper XML tools is very difficult. XMLs are usually parsed without considering the dtd. It seems the dtds are just for humans to read. As you mention, XML becomes more interesting with extensibility. IMHO XSLT is the key technology for that but unfortunately there is no reasonable support for XSLT 2 because the standard is just too complex. And XSLT 1 is barely interesting to use.

By the way, there's SLAX, it's isomorphic to XSLT but with nicer syntax. Nice approach but anyways, the standards are horribly complex and stiff.

The main lesson I've learned from this is that a spec is far more likely to be successful if it's paired with at least one working implementation and more than trivial test data. Writing a validator is both important for adoption and perhaps more so for flushing out parts of the spec which are too hard to implement or annoying to work with.

Maybe it never would have taken off because many more people would get frustrated trying to make something show up on the screen and give up. Or get frustrated trying to make tools that produced something that all of the browsers would display no matter what weird things the users did.

Maybe it would be so bad that somebody else would make a new, more permissive standard that took off instead.

Maybe all of that has already happened.

Maybe that line from Battlestar Galactica was right - All of this has happened before; all of this will happen again.

It would probably be a lot smaller!

Reply on news.ycombinator.com