Re: Next steps for the ARIA syntax discussion

Dear Anne and TAG,

On May 15, 2008, at 12:56 PM, Anne van Kesteren wrote:
> <snip>
> On Wed, 14 May 2008 18:22:26 +0200, Williams, Stuart (HP Labs,  
> Bristol) <skw@hp.com> wrote:
>>  3) The TAG's working hypothesis is that "aria:" is both technically
>>     feasible and strategically preferable, ...
>
> aria:* creates an inconsistency between HTML and XHTML that we don't  
> have with aria-*:
>
> 1) For HTML we would need to introduce a number of "aria:*"  
> attributes in the null namespace and for XHTML and SVG we would need  
> to introduce a number of "*" attributes in the ARIA namespace.
>
> 2) For styling authors would need to use [aria\:*] in HTML and  
> @namespace x "ARIA namespace"; [x|*] in XHTML and SVG
>
> 3) For scripting authors would need to use getAttribute("aria:*") /  
> setAttribute("aria:*", ...) in HTML and getAttributeNS("ARIA  
> namespace", "*") / setAttributeNS("ARIA namespace", "*", ...) in  
> XHTML and SVG.
>
> The cost here is not on implementors, but authors. The design the  
> TAG advocates will make transitioning towards XML even more  
> complicated than it already is. In the HTML WG we drafted a design  
> principle called "DOM Consistency" which is basically guiding us in  
> ensuring that the above does not happen.

Could you provide a link to this document? The Serialization Dependent  
Processing Differences document[1].

>
> I think http://www.w3.org/QA/2008/05/syntax_for_aria_costbenefit_an.html 
>  is very misleading and misrepresenting this cost to authors:
>
> 1) It simply says to use [aria|*] for CSS in the XML case but that  
> would not actually work. It also requires an @namespace at rule.
>
> 2) In a similar way it suggests that you can simply use aria:* in  
> XML but that would also not actually work. It would give you a  
> namespace well-formedness violation as you have not declared  
> xmlns:aria somewhere in scope.
>
> 3) It says getAttribute() will function properly in the XML case but  
> that would only work if the author of the page had an agreement with  
> the script author about what prefix will be used which is something  
> you should not rely upon. It does not mention setting the attribute  
> which is something that's very important for ARIA (the whole idea is  
> that dynamic changes are exposed to AT).
>
> 4) It has a column "XHTML (as if HTML)" which is something that only  
> exists in some legacy specification theory and is not actually  
> implemented as such by the four leading browser vendors.
>
> 5) It has the implicit suggestion there will be a million more  
> vocabularies that browsers will have to add support for in similar  
> fashion as they have to support HTML, SVG, MathML, and ARIA. Given  
> the Web's history so far it seems unwise to add so much complexity  
> for something that might happen. Once it does happen, we can then  
> look at the requirements and see how to solve it. Just like we do  
> with ARIA now.
>
> 6) It suggests that SVG would not have to be changed if used the  
> magic of namespaces. That seems higly unlikely because even then you  
> will have to define the interaction with the semantics of various  
> SVG elements. In addition, adding complexity to the SVG  
> specification and schemas is acceptable if it reduces complexity for  
> authors. In the HTML WG we call this "Priority of Constituencies".

I think a big part of the problem is the irrational attempt to keep  
namespaces out of the text/html serialization. If we included  
namespaces in HTML5, then we could consistently add 'aria:describedby'  
and other aria attributes to HTML5 in their own namesapce in both  
serializations.  CSS and DOM would then be completely consistent in  
both serializations. The only thing I can see gained by not codifying  
namespaces in the text/html serialization is it provides a continued  
privileged positiong to IE over other browsers. Whereas adding  
namespaces helps us solve many of our problems (especially  
inconsistencies between our two serializations). It takes care of SVG  
and ARIA and MathML, and so on. In the case of ARIA we could even  
include the aria prefix as predefined in both serializations of HTML  
(i.e., defining on the html element: xmlns:aria='<aria namespace  
uri>' ).

You also mention the null namespace in this email in the context of  
helping authors. The proliferation of the null namespace is — in my  
view — a misinterpretation of the namespaces recommendation that  
already causes some of the same headaches you describe in your  
critique of TAG. In my view the null namespace should not exist in a  
namespaced document processed by a namespace aware application.  
Instead unprefixed attributes should be attached to the same namespace  
as their parent elements. Perhaps I'm missing something that null  
namespaces are supposed to solve, but I know that they create many  
headaches for processing applications (other than pure client  
consumers) and authors too who never likely expect their attributes in  
a namespaced document to end up in anything other than a namespace.  
Too much of the discussion is focussed on helping vanilla client UAs  
at the expense of authors and authoring and other more involved UAs  
(though veiled in the language of helping authors and their tools).

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/SerializationDependentProcessingDifferences?highlight=%28HTML%29 
 >