Re: State and Status of WAI-ARIA approach to host-language embedding

As this discussion about ARIA implementation has progressed, it seems 
that not all people may have the same understanding of the premises 
behind the discussion. In attempt to clarify things, I have prepared a 
summary document, available at 
http://www.w3.org/2008/03/aria-implementation. This is an explanation of 
the concerns as the PFWG understand them, and an attempt to clarify its 
position with respect to them. I hope this serves as a useful input to 
further discussion.

Michael

Al Gilman wrote:
>
>
> On 13 Mar 2008, at 1:19 PM, Dan Connolly wrote:
>
>>
>> Al Gilman wrote:
>> [..]
>>>>      -- What is et problem with browsers handling a colon in an HTML
>>>> tag name?  Pointers?
>>>>
>>> The colon works in three mutually incompatible ways in
>>>  1) text/html in IE
>>>  2) text/html in Gecko/WebKit/Opera
>>>  3) XML (including application/xhtml+xml in Gecko/WebKit/Opera)
>>
>> Would you please elaborate? preferably in the form of test cases?
>> i.e. specific example documents?
>
> Henri Sivonen and Simon Pieters contributed the discussion quoted
> below, that I can't improve upon.
>
> Note in particular that there are specification-based differences
> in the behavior.  Yes, it's a difference built into the way the
> Web works today, and yes, there is an implementation glitch or two here
> and there that exacerbates the problem; but *even if the
> implementation glitches weren't there,* there would still be a problem 
> with
> using colons in the attribute-names of the WAI-ARIA attributes.
>
> So it's not just "a problem with the current implementations."  It's
> a problem with the HTML and XML specifications requiring different 
> things.
>
> Al
>
> -- 
>     From:       simonp@opera.com
>     Subject:     Re: test cases to demonstrate differences?
>     Date:     March 19, 2008 7:32:05 PM EDT
>
> On Tue, 18 Mar 2008 13:20:01 +0100, Henri Sivonen <hsivonen@iki.fi> 
> wrote:
>
>
>> Here's what I would have sent on my own but didn't. Feel free to 
>> present my points as yours.
>>
>
> Thanks Henri for writing this email; I'll augment with some additional 
> points below.
> [...]
>> On Mar 18, 2008, at 04:02, Al Gilman wrote:
>>
>>> Begin forwarded message:
>>>
>>>> Al Gilman wrote:
>>>> [..]
>>>>
>>>>>>     -- What is et problem with browsers handling a colon in an HTML
>>>>>> tag name?  Pointers?
>>>>>>
>>>>>>
>>>>> The colon works in three mutually incompatible ways in
>>>>> 1) text/html in IE
>>>>> 2) text/html in Gecko/WebKit/Opera
>>>>> 3) XML (including application/xhtml+xml in Gecko/WebKit/Opera)
>>>>>
>>>>
>>>> Would you please elaborate? preferably in the form of test cases?
>>>> i.e. specific example documents?
>>>> [...]
>>>
>> There's a demo of how different syntaxes behave with getters and 
>> selectors:
>> http://simon.html5.org/test/aria/colon-vs-dash/
>>
>
> Now also features setters.
>
>> Browsershots:
>> http://browsershots.org/http://simon.html5.org/test/aria/colon-vs-dash/
>>
>
> Requests 1 to 3 are of the old demo; request 4 is of the new demo.
>
>> Things to note:
>>   * IE6 doesn't support attribute selectors at all, so the test is 
>> moot in IE6.
>>   * The IE7 screenshot in group 1 has failed to load all the iframes, 
>> see group 3 instead.
>>   * The colon breaks attribute selectors in IE7. The dash does not.
>>   * The selector behavior with the colon is incompatible between HTML 
>> and XHTML in Gecko, Opera and WebKit.
>>   * Konqueror's XHTML processing has bug which makes the colon behave 
>> differently from Gecko, Opera and WebKit.
>>   * The dash works consistently in all the tested browsers that 
>> support attribute selectors. (All but IE6.)
>>   * In browsers that support both XHTML and HTML, the dash works 
>> consistently across XHTML and HTML.
>>
>
>   * setAttribute() with colon results in the HTML-style no-namespace
>     attribute, while setAttributeNS() with colon results in the XML-style
>     namespaced attribute. (Per spec, but probably confusing for authors.)
>
>   * When using the dash, there no need to use namespaces in CSS or *NS
>     methods in the DOM (which are not even implemented in IE). Just
>     straightforward [aria-foo] and get/setAttribute().
>
>> In summary: The dash works consistently in all cases (except IE6 
>> which doesn't support attribute selectors in either case). The colon 
>> causes various kinds of inconsistencies between browsers and within 
>> browsers between serializations.
>>
>>> I think we should also give spec citations for the cases where these
>>> differences are required by specification.  You and Henri had to follow
>>> up to teach me this, and the TAG could well be unclear on this point,
>>> from the record we have of their latest telecon.
>>>
>
> HTML 4.01 has no support for namespaces. The Namespaces in XML spec 
> does not in any way affect HTML or text/html processing. Therefore, 
> the colon has no magic attached to it in text/html. It's a bit hard to 
> point to something that isn't there, but perhaps the non-existence can 
> be demonstrated by inspection: HTML 4.01 and RFC 2854 don't mention 
> the word "namespace":
>
>    
> http://www.google.com/search?q=namespace+site%3Awww.w3.org%2FTR%2Fhtml4%2F 
>
>    
> http://www.google.com/search?q=namespace+site%3Ahttp%3A%2F%2Fwww.ietf.org%2Frfc%2Frfc2854.txt 
>
>
> ...and the only mentions of "html" in the Namespaces in XML spec is in 
> examples that use XHTML.
>
>> In DOM Level 2 Core, the *NS method variants have in their definition 
>> "HTML-only DOM implementations do not need to implement this method." 
>> Clearly, the writers of the spec thought that namespace processing is 
>> not relevant to HTML. Section "1.1.8. XML Namespaces" takes it for 
>> granted that namespaces apply to XML as in the section title and 
>> doesn't even mention HTML.
>> http://www.w3.org/TR/DOM-Level-2-Core/core.html
>>
>> DOM Level 3 Core makes the non-support of namespaces in HTML explicit:
>> "NOT_SUPPORTED_ERR: May be raised if the implementation does not 
>> support the feature "XML" and the language exposed through the 
>> Document does not support XML Namespaces (such as [HTML 4.01]). "
>> http://www.w3.org/TR/DOM-Level-3-Core/core.html
>>
>>> <quote
>>> cite="http://www.w3.org/2008/03/13-tagmem-minutes.html#item02">
>>> is a problem with existing browser implementations
>>> </quote>
>>
>> The recent discussion in the HTML WG relating to namespaces is about 
>> enabling the creation of SVG and MathML DOM fragments by the HTML 5 
>> parsing algorithm. In that case, the legacy is that SVG renderers 
>> expect the *element* nodes to be in the SVG namespace. ARIA is about 
>> attributes and has a very different DOM legacy landscape and very 
>> different time-to-market considerations.
>>
>> Even if the SVG-in-text/html ever goes somewhere, it will be *at 
>> least* one major browser release cycle away. On the other hand, three 
>> out of the top four browsers are about to be updated with ARIA 
>> support with the dash syntax. That's a remarkably good situation from 
>> the Web accessibility point of view. It would be foolish to disrupt 
>> the situation because of a Namespaces in XML-related principle and 
>> delay accessibility features that are acutely needed.
>

-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>