- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Thu, 29 May 2008 14:40:31 -0400
- To: ht@inf.ed.ac.uk (Henry S. Thompson)
- Cc: "public-html@w3.org WG" <public-html@w3.org>, "public-xhtml2@w3.org WG" <public-xhtml2@w3.org>, List WAI PF <w3c-wai-pf@w3.org>, "wai-xtech@w3.org WAI-XTECH" <wai-xtech@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>
On 29 May 2008, at 8:13 AM, Henry S. Thompson wrote: > The reality as I see it is that ARIA integration into the text/html > world is going to be messy and bug-prone in the short term no matter > what we do. If you contrast the simplicity of either your or my > simple checkbox example [1] [2], which only works in some browsers, > with the complexity of the genuinely interoperable versions [3] [4], > the familiar pattern of non-obvious cleverness which is the reality of > fully interoperable Web 2.0 Javascript is evident. Yes, I agree that "Web Application programming is not for the faint of heart." On the other hand, we regard the unnecessary problems that 'aria:' would introduce to be an unnecessary straw to lay on the camel's back. We are already seriously at risk that what we ask application authors to do is too complex for them to learn before they abandon the attempt. 'aria:' threatens to push this over the brink to where the application author public opinion congeals around 'unworkable' and we are dead. There is a difference between there being wrong things a programmer can do, and building bugs into the infrastructure that they have to decipher and work around. Let's not go to the latter? > Of course it's a judgement call, but giving DOM consistency a veto > seems to me an over-reaction, when doing so isn't even sufficient to > give us interoperable solutions. Consistency in the DOM programming platform across host languages is very important for compound documents and the emergency of a multilingual Web. This gets a vote, but not a veto. But consistency in the state-machine behavior of a widget state is a make-or-break requirement; something we have to deliver or not bother trying. In this sense, the coherence of the DOM programming interface does have a veto for WAI-ARIA. If we can't win usage by Web Application authors writing CSS+Script+[X]HTML applications, we shouldn't bother. It is a question of what sort of consistency that you are talking about. If it's the idea that the same script works in HTML and XHTML, then the costs and benefits derive in the timeframe and to the extent that application authors and sites take up XHTML. This is a long-term migration issue and the benefits accrue to the consistent version, not to 'aria:' . But if it's the kind of inconsistency that Aaron stumbled upon, where the behavior is different depending on whether you set the state from the hypertext or the DOM method -- that's an intolerable failure of determinism in a programming platform. We can't expect application developers to accept that. No amount of future gold at the end of the rainbow should lure us down that path. http://lists.w3.org/Archives/Public/www-tag/2008May/0202.html > So, I end up still weighing the long-term value for the whole W3C > community of a clean extensibility story, with the specific benefit > for ARIA of _not_ requiring detailed bilateral negotiation with every > WG that owns an XML language into which ARIA should integrate, more > highly that the marginal cost of aria: vs. aria- to text/html script > writers. Henry, with all due respect, you don't understand the appropriate costs and benefits. The costs of not using "Namespaces in XML" directly for insertion into host languages start with the first language after HTML, XHTML, SVG. The cost of reverting to the colon at this time would be at least a year in schedule creep. It is the accessibility community and the application writing community who have the costs and benefits. And IMHO for both of these, we should drop all host languages beyond HTML if that was what it took to recover that year's slip. We haven't done that, no matter what it may seem. The cost of waiving automatic insertion in XML formats beyond SVG is imperceptibly small, in the WAI-ARIA-appropriate cost metric. http://lists.w3.org/Archives/Public/www-tag/2008May/0185.html Having to create a separate insertion strategy for minority languages is a preferable cost to throwing the ARIA train off the rails at this point, which 'aria:' would do. And we don't even have to go there. Thanks to your probing, we have learned that (a) most of the native attributes of XHMTL and SVG are in no namespace (per the Namespaces Rec) anyway. (b) no-namespace attributes and Namespaces play fine together. .. so yes, we are considering rolling back to defining _in our specification_ only the no-namespace insertion _in our specification_, *without preventing* other, later experiments in borrowing the vocabulary, using other techniques. Al > ht > > [1] http://www.mozilla.org/access/dhtml/checkbox-colons.xhtml > [2] http://www.w3.org/XML/2008/04/ARIA-Testing/leventhal-colon- > xhtml.html > [3] http://test.cita.uiuc.edu/aria/checkbox/checkbox1.php > [4] http://www.w3.org/XML/2008/04/ARIA-Testing/uct-colon-xhtml.html > - -- > Henry S. Thompson, HCRC Language Technology Group, University of > Edinburgh > Half-time member of W3C Team > 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 > 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail really from me _always_ has this .sig -- mail without it is > forged spam] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFIPp33kjnJixAXWBoRAmOQAJoD2N/vBaPhVRjlQ9NigQ0QwI0rpgCfUD2o > HQz2RtOwO1uo9cPQHFwWPqY= > =JEHT > -----END PGP SIGNATURE----- >
Received on Thursday, 29 May 2008 18:42:51 UTC