Re: Next steps for the ARIA syntax discussion

On Wed, 14 May 2008 18:22:26 +0200, Williams, Stuart (HP Labs, Bristol)  
<skw@hp.com> wrote:

> At a relatively late stage in the development of the ARIA specification,  
> the TAG was invited to consider the question of the markup syntax for  
> ARIA states and properties, in particular the question of whether the  
> attributes encoding them in HTML- and XML-based languages should be  
> written 'aria-...' (hereafter "the dash approach") or 'aria:...'  
> (hereafter "the colon approach").

There seems to be some misconception here. The major problem I see is that  
the PF group proposed a non-null namespace for aria attributes except when  
they are used in HTML. The TAG's counterproposal is to use attributes with  
two names - in HTML the local name would include "aria:" which would not  
be the case in XML, and further proposed to constrain the allowed  
namespace prefix in XML (to be "aria"). I have an action item to calrify  
the PF proposal, so that the null namespace is always used, with aria-  
used as a grouping prefix to further disambiguate these attributes within  
the null namespace.

I believe that actually meets the TAG's goal of preserving the namespace  
architecture, the implementors' goal of preserving the namespace  
architecture, authors' desire for some simple syntax they can generate  
with a low risk of error, and everybody's desire that ARIA works easily in  
HTML, SVG, XHTML, and anywhere else we think it would be useful.

There are no other attributes I know of whose *local* name includes a  
colon, for the very good reason that this character introduces collisions  
with the namespaces spec.

There are plenty of attributes whose local name includes a hypen, with SVG  
specifying about 70 including a number with two hypens in their names. SVG  
uses "font-" as a groupng prefix for about a dozen attributes (some of  
which have the same name but different meaning in different contexts) and  
various other grouping prefixes (fill-, stroke-) with no apparent ill  
effects.

In both cases we are talking about attributes whose namespace is null. As  
in

  <foo xmlns:aria="" aria:aria-describedBy="#baz">
or
createAttribute(null,'some-attribute')

This is the same namespace that all the attributes in HTML have, and  
almost all the attributes in SVG (some linking and generic xml things are  
in a seperate namespace).

In order to work with HTML, which is not namespace-aware, as well as  
XHTML, SVG, MathML and anywhere else we can see this being used, the null  
namespace is actually the only viable option. The alternatives involve  
either constraining the prefixes allowed (often suggested but there seems  
no clear justification for it here) or doing some serious magic to guess  
when we have real namespaces and when we have pretend namespaces. Both the  
alternatives create scenarios where copying between HTML and XML seems  
likely to introduce frequent errors that are difficult to trap.

Given that these attributes all have a namespace, but that it is one which  
is already rather crowded, it made sense to introduce some mechanism to  
*further* disambiguate the attributes *within* their namespace. The  
"aria-" prefix for the attribute names is that mechanism.

This seems like a reasonable design pattern. Anything that has to work  
with HTML and XML has to use the null namespace for attributes to preserve  
compatibility, but should try to avoid clashing with the myriad attributes  
already there. Some identifying prefix (anything legitimate in the names  
of attributes) seems like a good idea. (A hypen, given its use in  
ECMAScript to signify subtraction, may not be the best choice in an ideal  
world, but it is something that seems to come naturally at least to  
english speakers and there is precedent within DOM Styles for dealing with  
it in a simple enough way).

(As a corollary, anyone developing an XML attribute not intended to be  
mixed with HTML should be advised to give their attributes a non-null  
namespace)

> Based in part on a re-examination of the facts on the ground as regards  
> existing browser implementations, and in part on consideration of the  
> more general issue of language extensibility in the long term, (both  
> reported in _Syntax for ARIA: Cost-benefit analysis" [1]), the TAG has  
> arrived at the working hypothesis that the colon approach is both  
> technically feasible and strategically preferable.
...
> Accordingly, we would like to invite you to consider three questions:
>
>   1) Are the facts about the current state of play with respect to how
>      current implementations work as set out in [1] reasonably
>      accurate;

Reasonably.

>   2) Is the cost-benefit analysis in [1] missing any substantive
>      considerations, particularly as regards the cost of changing
>      implementations given testing timeframes, product release cycles,
>      etc.;

Yes. Several current implementations (including ours) are ready for  
shipping, and removing this now would throw schedules and planning, so it  
would need to be demonstrated that there was a major problem in the way  
this is implemented (as opposed to the specification).

>   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;

I am hopeful that the PFWG will have, later today when I get the work  
done, a proposal that clarifies that the namespace associated with the  
aria attributes is the empty string, in all cases, and that no local names  
have colons in them ever. I guess that is a no, from my part...

>       (to the implementers): Could you see your way to changing your
>                              implementation/spec. to comply?

We would only reluctantly do this if other implementors did it first, in  
order to preserve compatibility. We consider it a serious architectural  
mistake to introduce a colon into an attribute's local name, and we  
believe that using these attributes in the null namespace in fact  
carefully preserves the namespace mechanism as a whole. In short: We could  
in theory be dragged kicking and screaming to do this thing we regard as  
unbridled lunacy, but we're not in a hurry and it would cause some real  
damage to make this change.

cheers

Chaals

> We would be happy to work with you to move forward quickly to a final  
> resolution on this question.
>
> Stuart Williams (co-chair)
> for and on behalf of the W3C Technical Architecture Group (TAG)
>
> [1] http://www.w3.org/QA/2008/05/syntax_for_aria_costbenefit_an.html
> --
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks  
> RG12 1HN
> Registered No: 690597 England
>
>



-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Received on Thursday, 22 May 2008 07:04:48 UTC