Re: Next steps for the ARIA syntax discussion

> 3) The TAG's working hypothesis is that "aria:" is both technically  
> feasible and strategically preferable, on the grounds that the long-  
> term benefits of a consistent approach to extensibility across all  
> the Web languages outweighs the short-term costs of making the  
> change at this time:
> (to the WAI PF WG): Would you consider specifying 'aria:' in the  
> next WD of ARIA;
> (to the implementers): Could you see your way to changing your  
> implementation/spec. to comply?

WebKit (the browser engine used in Safari and other browsers) now has  
a partial implementation of ARIA on trunk.

Prefixing ARIA attributes with aria: instead of aria- creates some  
difficulties.

1) It would require changing the core architecture of the DOM to match  
on localname+prefix instead of localname+namespaceURI in this case.  
This core work would be risky, and may hurt performance. To expand on  
this: WebKit's core DOM has a type called QualifiedName which contains  
a localname, a prefix, and a namespaceURI. This class is designed to  
carry a prefix but match exclusively on the prefix and namespaceURI  
for equality comparisons and hashing. It is used throughout the engine  
everywhere that names appear. It would be challenging to support an  
exception to sometimes match differently. I would also be worried  
about security risk from time-of-check / time-of-use bugs if we had  
two different ways of matching qnames.

2) If we switch to matching ARIA attributes on localName+prefix, and  
content depends on this, it would be hard to switch to real namespace  
processing later.

3) Behavior between HTML and XML (including XHTML) for DOM method  
calls on such attributes would become inconsistent.


I would also point out that changing to an "aria:" prefix with  
matching based on prefix also violates a premise of ARIA: that it  
should be deployable without architectural changes to core web  
technology. It is designed as an add-on technology, where the only  
needed changes are in assistive technologies and the part of UAs that  
binds to them.

In addition, I question the conclusions of the linked study:

1) As shown by Henri Sivonen, DOM access is not uniform between HTML  
and XML languages for a colon-prefixed attribute.

2) The reimplementation cost of using a colon but without namespace  
processing is not "modest".

3) The aria- prefix is used only for ARIA, as far as I know, no one  
intends to apply this approach to other vocabulary extensions. Thus, I  
do not think "scope creep" is likely. Furthermore, using a : prefix  
without namespace processing seems to create the same or greater risk  
of scope creep, inconsistency with XML namespace-based extensibility,  
and a new paradigm for 'namespace'. Worse yet, we will have a notion  
of namespace that is spelled the same as Namespaces in XML but has  
different semantics.


And finally, there is a premise in this discussion that using a prefix  
with a colon, but without namespace processing, makes it easier to  
transition to namespace processing in the future. If we treat "aria:"  
as  magical prefix and ignore namespaces, then if content depends on  
this we will likely not be able to ever change this. Thus, I think  
using "aria:" without namespace processing makes it harder to  
introduce "aria:" *with* namespace processing in the future, as  
compared to "aria-". If anyone wishes to argue otherwise, I would like  
to see a description of how this transition could occur, not just an  
assumption that it will. Past experience with this sort of thing does  
not leave me optimistic. For example, allowing XHTML to be sent as  
text/html but parsed as HTML has made it effectively impossible to  
ever process such documents as XML.

Regards,
Maciej