Re: ARIA States and Properties Meeting

On Oct 24, 2007, at 10:02, David Woolley wrote:

> Richard Schwerdtfeger wrote:
>
>> 2. Colon is not an option for text/html
>> We cannot use the colon instead of a hyphen, because a colon in  
>> attribute names causes problems in IE. For example, you cannot use  
>> CSS
>
> Interestingly, though, IE is the strongest precedent for using : as as
> namespace separator in documents served as text/html.  It is used  
> for VML and for the Microsoft Office supplementary markup.

The colon is used in VML, which is IE-only, and MS Office  
*supplementary* markup that is for MS Office-to-MS Office round- 
tripping and browsers are even expected not to do stuff with that  
supplementary markup. The colon is not used for existing cross- 
browser features in text/html.

Scripting discrepancies between browsers are bad for script authors.  
The aria-* avoids those problems, since it uses interoperably  
implemented parsing and DOM features.

There is *no* way of introducing a colon-based syntax to text/html  
without creating a scripting discrepancy *somewhere*. This is simply  
because shipped IE and shipped Gecko/WebKit/Opera do different things  
with the colon, so even if new browsers changed their behavior,  
there'd have to be a discrepancy with either shipped IE or shipped  
Gecko/WebKit/Opera (or both).

Using the IE precedent would mean that the exact behavior of what IE  
does with the colon would have to be discovered, specified and  
implemented in the Firefox 3 and Opera 9.5 timeframe. This is  
seriously not feasible. Moreover, it would cause a DOM discrepancy  
with past Firefox and Opera releases. Even if that was overlooked, it  
would create a scripting/DOM discrepancy between the text/html  
serialization of HTML5 and the application/xhtml+xml serialization of  
HTML5, because the way IE represents colon-based namespaces in the  
HTML DOM is different from how Namespaces in XML are represented in  
DOM Level 2 Core.

OTOH, if you required IE to change their stuff to match DOM Level 2  
Core, you wouldn't be using IE precedent but you'd be doing something  
new and *incompatible*.

The reasonable practical course of action that allows for consistent  
scripting across browsers and serializations is to steer away from  
the colon.

>> *6. Currently proposed solutions for ARIA states and properties  
>> (not role)*
>> A. Use hyphenated property everywhere .
>> Pros: consistent
>> Cons: The issue that has been raised on this is that SVG already  
>> has properties with hyphens in it. However, proponents of hyphen  
>> state that SVG has no properties starting with "aria-" so it is  
>> not a real problem,
>
> This means that either ARIA attributes have to be part of the core  
> of XHTML, SVG, etc.,

No, the specs that define XHTML and SVG could make a normative  
reference to an ARIA spec and refrain from defining aria-* attributes  
on their own. There is no technical reason why spec organization and  
division into namespaces (in the sense of Namespaces in XML) would  
have to be the same.

> or that you have the ugly situation of having two different  
> syntaxes for namespacing co-exist,

Note that aria-* is "namespacing" only in the spec organization  
sense. It isn't namespacing in the parsing/DOM sense.

> one of which is only available to official standards, because it  
> cannot guarantee global uniqueness otherwise.

Global uniqueness is a red herring. Collisions with pre-existing HTML  
and SVG attributes are the real technical concern for *Web*  
accessibility. aria-* does not collide with pre-existing HTML or SVG  
attributes, so collisions are not a problem with the aria-* scheme.  
Collisions with attributes from *theoretical* *non-Web* languages  
aren't a real technical concern for enabling *Web* accessibility-- 
just like making the id attribute in no namespace have ID semantics  
would have worked just fine for Web languages and xml:id addresses a  
theoretical non-Web problem.

When developing specs for the Web, we shouldn't let theoretical non- 
Web concerns add complexity.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 24 October 2007 11:57:08 UTC