Before I begin to break it down (tl;dr - it isn't a very good API) it's worth remembering that HTML has been (almost?) explicitly designed not to be a screen rendering language. The W3C values semantic description over visual representation. So this shouldn't be taken as a criticism of their competence, just their architectural choices.
The most important aspects of an API are orthogonality (it doesn't repeat itself), predictability (given an API call, I can figure out how to use it) and terseness (you don't need to perform obscure ceremonies - think Java boilerplate - to get where you want to go).
HTML-Screen's chief weakness is in orthogonality: there are so many elements that do the same thing when rendered to screen. There are specialised elements like the form controls, but the two biggest chunks of HTML consist of things that define a rectangle onscreen that can have things in it, and things that denote a range of text that can have some visual styling applied to it.
There are subtle visual differences between <p> and <div> - most user agents render <p> with a bit of extra bottom margin, but fundamentally they play the same role. HTML 5 adds yet more rectangles: <section>, <article>, <aside> etc. These all have semantic meaning, yes, but reduced to pixels, they're rectangles. The inline text markers are worse: HTML 5 even preserves the <b>, <i>, <em>, <strong> group.
Even if we're adhering to the semantic route there are simply two many options, which means that simple stereotyped content (news stories, say) on one site are guaranteed to be built in a different way on another, which means that if you want to merge or reuse content you still have to write an adaptation layer to munge them together.
Even if we're adhering to the semantic route there are simply two many options, which means that simple stereotyped content (news stories, say) on one site are guaranteed to be built in a different way on another, which means that if you want to merge or reuse content you still have to write an adaptation layer to munge them together.
Predictability is improving - you can probably work out what the <section> and <article> elements do, but older HTML elements which are still part of the standard are cryptic - if you didn't already know there's no way you could work out what <a> is for, or <dd>, <dl> etc.
The area HTML triumphs, of course, is in its terseness. This is a valid HTML document:
<body>Hello</body>
There's very little effort required to make a page and make it it link to another page. Provided you don't care what it looks like.
If you do care then you quickly find yourself suffering from the number one problem caused by the fact that HTML was not designed as a screen API: none of the bloody browsers agree what it should look like. The lack of a set of visual compliances for HTML means that browsers are free to interpret raw HTML however they want. To achieve a consistent look you have to specify everything in CSS (with the odd Javascript shimmy thrown in) and even then you may be defeated.
My feeling is that the semantic project is worthy, but misleading. We've had 20 years of semantic led markup development, and reuse on the web still starts with writing a web-scraper (I've done it myself over and over).
I'd like to have the option to forget about semantics when developing and simply concentrate on making things look the way they should, if the content I'm trying to present is free of semantic reusability (and given I work in web advertising, that's a given). But I'd like the tool I use to support that approach rather than fight it.
1. Yes, technically it's the DOM, but HTML gets written nonetheless.
No comments:
Post a Comment