Super-fine Markup Semantics (2nd September 2007)
There is a fairly steady stream of illconceived markup ideas being sent to HTMLWG’s mailing list. This is a little rant about it to get it out of my system without spamming the contributors to HTML5.
Armchair Engineering
From adding embedrel for <img> as a required attribute (complete with flaming the Editor) to a set of new phrase elements like <book-title>, <ships-name> and <Linnaean-binomial>, there’s plenty to chuckle about.
I tried to caution the speculation and got told I was purging semantics and motivated by theoretical purity. Ouch, dude! Well, not sure how I managed to “purge” semantics for elements which don’t exist. But anyway, ouch!
So maybe I’ll repeat one of my previous blog messages using these super-fine markup suggestions. I could make up a bunch more, just for fun. This wouldn’t just be to take the piss, mind. Well, mostly it would. But maybe it will also help demonstrate how entirely pointless super-fine semantics like those would be in a web page.
Or maybe it would show how totally essential they are for anything to be accessible? Yeah, I have doubts.
Experts are n00bs!
Even expert authors who really care about markup rarely use special-purpose elements. Even those we’ve had for more than a decade. Or, they use them wrongly:
<strong>instead of<code>(or maybe<samp>as they are URIs).<samp>instead of<code>;<b>instead of<dfn>.<span class>instead of<code>.<var>instead of<code>;<code>not used for function names.<em>instead of<var>;<div class><p><code>instead of<pre><code>or<pre><kbd>.- Occassional
<i>or <tt> instead of<code>(or maybe<var>or maybe<dfn>). <em>used instead of<dfn>; nothing used for inline code samples; block code samples just use<pre>when they could use<pre><code>.<code>instead of<samp>.<code>instead of<kbd>.<samp>,<kbd>and<var>don’t match HTML4 definitions;<u>(deprecated) used in the absence of<mnemonic-access-key-indicator>.- None of them used even though they could be.
- Even little sites made by Sole Traders who really care rarely use them.
You’ll have a hard time finding them on the mainstream web.
How would adding more specialised elements increase the chance of them being used more widely and more correctly? More confusion and less proper use are the likely results going by these studies and the markup I come across daily.
User Needs
Another aspect is the deafening silence from users pleading for super-fine markup semantics. People I talk to complain about:
- long waiting times;
- things not being where they thought they should be;
- confusing instructions;
- and things not working as they expected.
That’s usability stuff, not format limitations.
Disabled User Needs
The disability support organisations cry out for:
- add
alttext; - write high quality
alttext; - break content into sections;
- “front-load” page titles, headings, paragraphs and links;
- use
titlesparingly; - use heading elements, list elements and the other basic structural elements.
That’s authoring stuff, not format limitations.
UAs and Information Overload
User aren’t experiencing problems which need <book-title>. Or for class to be exposed. Indeed, why would anyone want to know their mouse is over class='post hentry uncustomized-post-template' or that their virtual cursor has started reading through that part of the page?
These proposals suggest extraordinary verbosity be fly-tipped upon users. That is not what benefits text-to-speech users, for example.
My 2p
Relaxing the semantics of special-purpose elements seems more useful:
- The spec would better match what authors do.
- Authors could trust the definitions a bit more.
- Newbies can use the nearest match and UAs would be fine with it.
HTMLWG Participants and W3C WAI are already pooling their resources. Together, the standard can be balanced with what users actually need, what authors actually do and what ATs can actually deliver. Let’s keep it real.