Re: Next steps for the ARIA syntax discussion

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/

Received on Wednesday, 14 May 2008 18:37:06 UTC