standards -- up side and down side

[miriam_e]

Standards are generally a good thing, in that they encourage interoperability and thus widen the choices of the average slob like me. But slavish adherence to standards can turn them into something like a religion. In that case they block further development and restrict our choices.

One of my favorite standards is HTML (HyperText Markup Language). It allows simple, efficient styling of information, enhancing its presentation in a way that it will fit on many different display resolutions. A simple, well-designed page using the basic HTML tags will usually display equally well on a young geek's super high resolution monitor, as on an 800x600 monitor for a little old lady with vision difficulties. Of course many people forget this lovely ability to adapt to various displays and you end up having to scroll right and left as well as down when viewing their documents. But on the whole HTML is a wonderful standard.

As with most standards though, HTML seems to be in danger turning into a kind of over-complicated religion. Simple things that made life easy are being forced into more complicated things.

Here is an example: the <center>...</center> is in danger of being extinguished ("deprecated" in the jargon weird-speak) because we are able to add a more verbose and complicated option and parameter to many other tags (<p align="center">, <h1 align="center">, and so on). But if I need to center an image, heading, sub-heading and a block of text it is much more logical to surround the whole group with a single tag once rather than having to add stuff to every tag.

Another example is the fanatical requirement to close all tags -- even ones that don't need closing. The paragraph tag (<p>) doesn't really need the </p> closing tag because it's clear that a new <p> starts the next paragraph. The same is true of <li>, <dt>, and <dd> list tags, but it reaches it greatest absurdity in the <br> line break tag which can't possibly take a close tag, because all it is to break a line. Now religious adherents to the all tags must close order are trying to enforce a change to <br /> which is just stupid.

Yet another example is the devotion to the idea that whitespace must be collapsed. Mostly this collapsing whitespace has been a good thing because it is what has enabled HTML to work so well across many different displays, but it was taken too far when it was decided that TAB characters must not be shown. Ever since then people have had to resort to ridiculously complex ways to display aligned text, using tables, clear images, the PRE tag, DL lists, the BLOCKQUOTE tag, CSS and inline styles, for the want of a simple <tab> tag. I know the arguments about excluding TABs, but when you examine them carefully they don't really make much sense. Line breaks are allowed, as are non-breaking spaces (&nbsp;), and TABs are actually allowed between <pre>...</pre> tags, though they only work properly if you use a monospaced font because they get converted to multiple spaces. Judicious use of a <tab> tag or displaying real tabs inside PRE tags, so that it works even with proportional fonts, would save so much work and hassle. I did a little search this morning and you would not believe how often this has been a problem for people over the years.

All this extra stuff (added closing tags complex workarounds to align text) doesn't sound like much to complain about, but when editing HTML source by hand as I do, it adds terribly to the clutter on the page. It also contributes to what is known as "creeping featurism", where more and more small changes are added to something so that eventually it eventually becomes absurdly unwieldy and complicated. I know my desire for a <tab> tag would add yet another feature and could be charged as contributing to that problem, but actually it works to simplify HTML by giving people a simple solution to a common problem instead of forcing them to resort to complex, non-standard ones.

Simplicity. Interoperability.

Comments

[annie-lyne.livejournal.com]

Closing all tags is useful when you're trying to shoehorn an XML parser into parsing HTML (ie, XHTML).

[miriam-e.livejournal.com]

Good point Annie, and I'm sure that you are right that this is what powers a lot of these decisions, but this argument is actually the reverse of what people should be thinking. It should not be about what is easier for the programmer of the parser, who after all does it only once, the focus should be on how easy it is for the end users, who all together have to construct millions of documents with it. I ran up against this in the 3D community often after they decided to opt for the fashionable XML way of doing things. Life was made harder for the world designer so that the parser is easier to make. The viewer is made only a few times, whereas the poor world builders have to juggle a clumsily designed system have to use it to make hundreds of thousands of worlds. This is akin to a short carpenter making all the doors a meter tall because it is easier for him, when the house will be owned by ordinary height people.

When I first learned about XML I thought it was a truly brilliant idea. Unfortunately it never seemed to fulfill its promise of easily displaying music, chemistry, mathematics, etc, in ordinary pages. And one of its greatest attractions, the "semantic web", which would add meaningful tags to things, enabling easy access to information turned out to be basically impossible because there can never be just one way of cataloging information.

I think XML will end up being one of the biggest fashion mistakes in computer history -- something that looks like a great idea, but causes lots of subtle problems further on.

HTML

[mfg9999.livejournal.com]

This is probably the reason why I'm still using the Transitional version of HTML 4.01 - somethings are more of a pain in CSS.

M.