New Main Element Approved, then Blocked
When I saw main proposed as an element a few months ago (or content or maincontent as alternate names), I didn’t think the process to fold it into the HTML specification would move very quickly.
Much to my surprise on the W3C HTML Working Group mailing list the main element not only got a draft HTML5 extension specification quickly, it also worked its way through the process to become approved as a First Public Working Draft on Tuesday (yesterday) the 27th of November.
And so the process appears to be working.
Except the W3C is just one of the standards bodies working on HTML5. There is also WHATWG, the body that years ago picked up the then-discarded HTML specification from W3C and started to carry it forward to HTML5. Now the two groups work together, with the W3C working on versioned specifications with WHATWG working on the ever-evolving standard.
Over on the WHATWG mailing list, main doesn’t seem to be getting much traction from the editor, which leaves it in a bit of limbo. WHATWG does, however, try to reflect in its specification approach that which is already in place in the browsers. For example, if the browser makers suddenly supported main, then WHATWG would consider it viable.
Except WHATWG was started by, and is still made up of, people from the browser makers Apple, Mozilla and Opera. Others contribute, but its membership can heavily influence the direction browsers take.
When the author of the main extension specification started to add support for main to WebKit (the core of Apple Safari and Google Chrome), the WebKit bug report quickly turned into a fresh debate over the merit of the main element — by none other than the WHATWG editor.
Mozilla team members have pre-emptively stated that they do not support main being added to HTML5, but they did so on the WebKit mailing list. The argument against main being added as a patch to the browsers is this:
Shopping a patch to implementors, to get something into a standard spec by asserting de-facto status based on the patch(es) landing, is bad form.
Sadly, it seems the same circular argument is being used to block main in the WHATWG HTML specification. By blocking its implementation in browsers, WHATWG members can claim there is no real-world support and so no need to add it to the specification (this is assuming the arguments against the use cases still stand). Then it’s a matter of pushing back at the W3C HTML Working Group to let it wither over there.
Even the author of the use cases for the main element appears to have thrown in the towel at WHATWG.
There is still some hope, however. Both Opera and Internet Explorer representatives have not argued against it and have even offered some support:
@aardrian nothing definitive from opera but @zcorpan appered to support it and helped. got a non objection from IE at TPAC
— Steve Faulkner (@stevefaulkner) November 28, 2012
Bear in mind, all this has happened in roughly a 48 hour window. Much more will happen, but the start of this process is certainly not as positive as I had hoped (disclosure, I voted for it on the W3C list). Even if you aren’t in favor of the main element, this is still a telling view into the standards-making process.
Update, January 31, 2013
And there it is, main has appeared in the WHATWG version of the HTML specification.
Update: September 10, 2015
More than three years later, the WHATWG specification still allows (and advocates for) multiple main elements. I could speculate that they hated having to implement it, so making it diverge from the intent and W3C spec is the easiest way to sow confusion and argue for its pointlessness down the road.
Steve Faulkner filed a bug (Consider aligning WHATWG main element definition with W3C definition #100) against the WHATWG spec to have it updated to match the W3C spec.
Given the WHATWG editors’ seeming unwillingness to provide any data or evidence to back up their position, I don’t hold out a lot of hope. Case in point &8212; when a self-described screen reader user offered her feedback and an example, the WHATWG editor responded with an image with no alternative text.
WHATWG editor responds to blind user, on issue to help blind users, with an image lacking alternative text. https://t.co/LUkJDks9CE #a11y
— Adrian Roselli (@aardrian) September 10, 2015Every time the WHATWG editor makes any assertion about accessibility, we all need to question it. There’s plenty of other evidence in the archives, but this one is the tops.
Sadly, it also demonstrates that he just doesn’t get it.
5 Comments
Reply Hi Adrian, there has been a lot of positive movement in the last 24 hours. James Craig a respected accessibility engineer (and editor of W3C WAI-ARIA and Indie UI specs)has responded forcefully in favour of implementing the main element in webkit and has backed up his support by demolishing hixies arguments against. The emails to the webkit dev list overnight on main, are well worth a read.
Reply yeah, it's sort of funny that the WHATWG assert arguments from authority are baseless in the development of web standards, yet what we have is an authority based argument from the WHATWG for not adding a feature to HTML…
Reply Steve, It's nice to see the next 24 hours brightened up a bit for <main>, but when people are willing to accept that WHATWG's position is the same as the editor's position, regardless of lack of any consensus throughout the WHATWG membership, it still feels like it has a long way to go.
Reply To be fair, an authority based argument -not- to go forward and add something is just about the only valid use of appeal to authority I can imagine. That's not to say that the WHATWG shouldn't respond to implementations, but just that if there aren't any implementations, then it's fine for a reject to come directly from the editor until the evidence for inclusion outweighs the meager against of his authority-based rejection.
Least, that's how I view it.
Reply […] favor of <main> as originally proposed (with only one instance per page). I also wrote about my frustrations with the different approaches by WHATWG, W3C and browsers on implementing it back in […]
Leave a Comment or Response