> 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