W3C home > Mailing lists > Public > www-tag@w3.org > April 2008

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

From: Michael Cooper <cooper@w3.org>
Date: Wed, 02 Apr 2008 17:18:18 -0400
Message-ID: <47F3F81A.4010205@w3.org>
To: Al Gilman <Alfred.S.Gilman@IEEE.org>
Cc: Dan Connolly <connolly@w3.org>, Tim Berners-Lee <timbl@w3.org>, TAG List <www-tag@w3.org>, Judy Brewer <jbrewer@w3.org>, W3C WAI-PFWG <w3c-wai-pf@w3.org>
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/>
Received on Wednesday, 2 April 2008 21:18:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:55 GMT