Re: Next steps for the ARIA syntax discussion

I agree with Henri.  If ARIA is not going to use namespacing based scripting it will make it very confusing to developers and processors to know how to code and interpret the ARIA attributes.  They will look like they are using namespacing, but really are not being coded or processed as namespaced atttributes.  

Did the w3c architecture group comment on how javascript should manipulate these attributes or how browsers were suppose to handle these attributes?

Jon

---- Original message ----
>Date: Wed, 14 May 2008 21:36:11 +0300
>From: Henri Sivonen <hsivonen@iki.fi>  
>Subject: Re: Next steps for the ARIA syntax discussion  
>To: "www-tag@w3.org" <www-tag@w3.org>
>Cc: "public-html@w3.org" <public-html@w3.org>, "public-xhtml2@w3.org" <public-xhtml2@w3.org>, "wai-xtech@w3.org" <wai-xtech@w3.org>
>
>
>On May 14, 2008, at 19:22, Williams, Stuart (HP Labs, Bristol) wrote:
>
>>  2) Is the cost-benefit analysis in [1] missing any substantive
>>     considerations,
>
>
>Yes, it is.
>
>First, the "Matches CSS Selector" result for SVG looks weird. I don't  
>see which test case this result came from.
>
>Second, the DOM behavior part focuses on getAttribute instead of also  
>considering setAttribute and setAttributeNS and it whatever they  
>mutate the DOM into matches a CSS selector consistently across  
>browsers and across parsing origins of the DOM (XML vs. text/html).
>
>Here's a demo that shows how using setAttribute with the colon in the  
>XML mode produces a different attribute node from what an XML parser  
>creates on parsing an attribute with the colon (in Firefox 3b5, Safari  
>3.1 and Opera 9.5):
>http://simon.html5.org/test/aria/colon-vs-dash/
>The get an attribute node that matches what the parser made, you need  
>to use setAttributeNS. The hyphenated alternative works with either  
>setter.
>
>Moving to getAttribute/setAttribute with the colon and expecting  
>dispatch on qName as opposed to URI,localName pair (to work around the  
>above issue) would give up on Namespaces in XML processing. The right  
>way to dispatch in a Namespace-aware implementation is on the  
>URI,localName pair--not on the qName. I don't see how breaking  
>Namespaces in XML processing in this case would lessen author  
>confusion (you'd have a colon but you wouldn't actually expect proper  
>Namespaces processing on it) or promote architectural correctness  
>compared to using the hyphen approach which doesn't require breaking  
>Namespaces-wise correct dispatch on the URI,localName pair (the URI is  
>"" and the localName includes the hyphenated prefix).
>
>It is claimed that the colon is strategically preferable, but there  
>doesn't even seem to be a feasible plan for unbreaking dispatch by  
>making it a URI,localName dispatch *later* when content out there  
>would already be depending on dispatch on the qName.
>
>In summary, using the colon with getAttribute/setAttribute sacrifices  
>pure Namespaces in XML processing in order to keep up the appearances  
>with the colon. I posit that this is more harmful than sidestepping  
>the problems of Namespaces by using a delimiter that isn't sensitive  
>to Namespaces processing. Having two different delimiters that behave  
>Namespace-wise differently with each other but self-consistently is  
>better that having one delimiter that behaves Namespace-wise  
>differently with itself in different contexts.
>
>Finally, the considerations on the cost of changing code focus on the  
>programming effort to change the code. The more significant cost of a  
>change at this point would be the lost network effect value from  
>breaking the uniform hyphenated syntax support across products from  
>multiple vendors.
>
>-- 
>Henri Sivonen
>hsivonen@iki.fi
>http://hsivonen.iki.fi/
>
>
>
Jon Gunderson, Ph.D.
Coordinator Information Technology Accessibility
Disability Resources and Educational Services

Rehabilitation Education Center
Room 86
1207 S. Oak Street
Champaign, Illinois 61821

Voice: (217) 244-5870

WWW: http://www.cita.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/

Received on Wednesday, 14 May 2008 18:46:51 UTC