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

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.

-- 
Simon Pieters
Opera Software



> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
>
>

Received on Thursday, 20 March 2008 19:02:37 UTC