Everyone wants their thing to be HTML
April 8th, 2009
Sam Ruby: The goal here is not to repeat the exercise where people present use cases and continue to have the HTML working group be a gatekeeper and king maker and sole determinant as to which features are permissible and which are not in the open web. Specifically, if RDFa is “out”, then I see HTML5 and XHTML2 continuing their separate ways.
I don’t see a problem with HTML5 and XHTML2 continuing their separate ways. I do see a problem with some features being made part of HTML. Examples include a laughably underspecified SQL syntax, a video element that isn’t interoperable, and an RDF syntax that uses namespaces in text/html and QNames in content. Maybe we can all agree that those examples don’t belong in the HTML specification at this point. But then the problem shifts to one of endorsement. People want the HTML specification to tell them what they’re doing is OK. I don’t think the HTML document should do that either.
Sam is right that author conformance requirements are contentious and rooted in non-technical matters. I would say the same is true of distributed extensibility mechanisms, XHTML, and other issues that have landed in the HTML WG. My plan is to produce a draft that is smaller than my last one. It will not include XHTML of any kind, and it will characterize elements and attributes that are not defined by the HTML specification as “not part of HTML”. This characterization will apply to the <audio> element and RDFa alike.
People interested in continuing work on XHTML, RDFa, <audio>, and a host of other things should work to produce interoperable implementations of their technology. Versions of the HTML specification targeting later dates, such as Ian Hickson’s excellent draft, will probably incorporate successful efforts.
April 8th, 2009 at 12:40 pm
How will your draft deal with ARIA?
April 8th, 2009 at 1:10 pm
If by ARIA, you mean WAI-ARIA 1.0, that is clearly newer than the rough cut off point of <canvas> that I have previously used.
So, it won’t be in the HTML vocabulary of my draft. Hopefully, that will be taken as a simple statement of fact.
At some point in the future, HTML may contain a mechanism that makes people feel their use of any outside vocabulary is OK. Currently, there is no such mechanism.
April 8th, 2009 at 1:31 pm
Cool.
The way I would characterize it is that nothing in your draft would preclude WAI-ARIA 1.0 from being published separately, used by content producers, implemented by browser vendors, included in subsequent editions of your draft (should your draft ever make it to the Recommendation status), or even being included in a XSD schema should somebody (clearly not either you or I) ever be inclined to produce such a silly thing.
And the status of audio and RDFa are precisely the same from your perspective.
Let me know if I mischaracterized your position in any way.
April 8th, 2009 at 1:49 pm
Perhaps you have subtly mischaracterized it. Finding the right language will be difficult.
My goal is to find language that will prevent people from pointing at the HTML specification to justify their opinion of an extension. When evaluating an HTML extension, I don’t want people to point at my document and say “what you’re doing is illegal”. I also don’t want people to point at the HTML specification and say “what I’m doing is OK”.
In other words, a given extension should be debated on its merits, and the HTML specification is not a crystal ball.
April 8th, 2009 at 2:42 pm
Rob,
At the risk of sounding like a one-tune player, I an curious about how you propose to handle non-conformant elements? Yes, I mean CANVAS – as I mentioned to a colleague the other day, if you think @alt was contentious, you ain’t seen nothing yet; CANVAS is light years ahead of mere static images, and it will very likely be a predominant delivery mechanism as we move forward on the web.
http://tinyurl.com/ateans
You state that your rough cut-off point is CANVAS, so you too seem to feel that it’s inclusion in the next-gen HTML language is both necessary and inevitable. (It’s here today, so that’s actually somewhat moot, Pandora’s Box is already open)
Given that CANVAS is here to stay, then what steps will be cemented into your draft that ensures that this future content will be accessible to all users – this is a very serious and legitimate question, yet one that *nobody* seems prepared to answer, either because they can’t, or because they are unwilling to do so.
No extreme position today, simply an open question: what and how do we ensure that nobody is left behind with CANVAS?
(…and I don’t think I’m the only one thinking that question)
April 8th, 2009 at 3:14 pm
Robert,
How do you solve validation issue in your plan? (Here I’m really talking about the community aspect of it, not the technical aspects.)
April 8th, 2009 at 3:47 pm
John, you’re not the only one by far.
I too would like to know the answer to that. Whether or not it’s held back now, it will still be supported by browsers and therefore ‘out in the wild’.
How is the accessibility of this element being addressed at the moment and how will the issue be resolved?