- From: Aaron M Leventhal <aleventh@us.ibm.com>
- Date: Thu, 29 May 2008 18:10:57 +0200
- To: ht@inf.ed.ac.uk (Henry S. Thompson)
- Cc: "public-html@w3.org" <public-html@w3.org>, "public-xhtml2@w3.org" <public-xhtml2@w3.org>, w3c-wai-pf@w3.org, "wai-xtech@w3.org" <wai-xtech@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
- Message-ID: <OF8A1A3F2A.988255DE-ONC1257458.0054BC7D-C1257458.00590CC3@us.ibm.com>
ht@inf.ed.ac.uk (Henry S. Thompson) wrote on 05/29/2008 02:13:43 PM: > Aaron M Leventhal writes: > I have never said that the aria: approach was without problems. My > efforts throughout this discussion have been directed at accurately > identifying the costs of _both_ approaches, so that a thoughtful and > well-informed decision can be made based on the agreed facts. You > have identified a problem that I missed, and that's a good thing, > because it adds to the facts we have in front of us. But it doesn't > necessarily determine the decision. Yes, the aria: approach causes bugs. These are bugs in the most fundamental thing -- property setting. Undermining the foundations of ARIA in this way does not just destroy confidence in the software ecosystem based on ARIA. All bets are off when the DOM for an attribute/property pair can differ even within a single runtime a given page. In only 10 minutes I found problems that can hide themselves from authors & testers. We can't know the ripple effects when just setting a property becomes buggy. Every time we look we will find weirder and weirder bugs. Property setting cannot be buggy. > We have to set against the problems with aria: the medium- and > long-term negative aspects of the aria- approach, which focusses on > ease of ARIA integration in text/html environments at the expense of > costly integration throughout the application/...+xml universe. From > my perspective, the cost of aria: in the text/html environment is > modest, manageable, and declining over time, whereas the cost of aria- > in the application/...+xml universe is large and permanent. The aria- approach doesn't cost app/..xml anything. The hard-to-predict colon approach does. Others have explained this better, but it clearly does muddy the waters for colon when it can mean 2 different things. Authors won't adopt something so unpredictable. They want to know their stuff won't break because of quirks in the underlying infrastructure. > 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. This argument like many of the others is like the Chewbacca defense. It makes me wonder why we're debating. The act of setting a property in ARIA is not currently messy or bug prone. It's as easy as A=B. Using your proposal would make that buggy. Software depends on the dependability of setting A=B. Bugs in setting properties would mean anything that sets properties (which is basically everything) would need to be checked for defects. > 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. This is also mot debatable. Ok, anyone who thinks that DOM consistency within the same run of a page is not an absolute must, please come forward and support HT. I'm sorry, but I think you'll have a hard time finding people willing to support that if they understand it. > 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. I agree, let's go for cleanliness. Mashing together two meanings for colon makes XML namespaces much messier, even worse than I realized before trying it on a simple example. - Aaron > > 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 16:14:13 UTC