Re: @role in SVG

Hi, Henri-

Thanks for the reply.  (I'm particularly glad to have the feedback of 
the HTML 5 guys on this, since we want to coordinate with you as much as 
possible.)

Henri Sivonen wrote (on 10/10/2007 11:21 AM):
> 
> I'm curious why a third way isn't mentioned:
> 3) Non-Namespaced Attributes for both role and states/properties with 
> the latter prefixed with "aria-" (and no qNames in content but opaque 
> strings):
> <svg
>   xmlns="http://www.w3.org/2000/svg"
>   xmlns:xlink="http://www.w3.org/1999/xlink">
>   <g role="checkbox" aria-checked="true">...</g>
> </svg>

That's an orthogonal issue to how @role is integrated into SVG.  It's 
worth talking about, but I think it can be addressed as a separate 
issue.  @role in SVG will likely have more uses than accessibility.

Comments inline:

> Pros:
>  * Matches what has recently been proposed for (X)HTML5 and XUL. Good 
> both for implementation and author skill portability.

I agree that having a shared syntax is a worthwhile goal, for the 
reasons you mention.  Since there have been no technical decisions yet 
made for HTML5, it's hard to know what the status of that proposal is, 
especially since it is not quite in line with the XHTML Role Attribute 
Module spec.  Is there some general consensus on the proposal?


>  * Fewer namespaces to deal with (i.e. easier).

Once the author has to deal with namespaces, it's not entirely clear 
that fewer namespaces is easier.  It is shorter, for sure.


>  * Copy-paste-friendly.

That goes hand in hand with shared syntax.  I will grant that requiring 
NS declarations is slightly less friendly (requires copying the 
NS-declaration as well as the target content that uses it), but if we 
are aligned on syntax, it's just about as copy-paste friendly either way.


>  * DOM-friendly. (qNames in content are *bad* in the DOM.)

Can you elaborate on that?


>  * Not a chameleon namespace per se. The attributes would be in no 
> namespace in XHTML5, SVG and XUL.

I don't think that inherently avoids the issue I raised, that there may 
be potential interfaces implemented on the attribute in one language and 
not the others (which raises the same problems as chameleon namespaces, 
whether or not it's precisely the same).  The easiest resolution to that 
issue is an agreement that the attribute is defined in one mutually 
exclusive place, and that all changes are specified only in that single 
specification.  (FWIW, I don't see this as a pro or con, either way.)


>  * Semantics and processing can still be imported by normative reference 
> from wherever they get defined for HTML5. No need to spec all this in 
> the SVG spec.

Agreed.  But if it's going to be shared, and we know that ahead of time, 
it would be far better to split out any semantics and processing that we 
need in a separate document, and reference it from both specs, with each 
language specifying only the language-specific aspects of it.  (Again, 
this is not really a "pro", in that it doesn't support either position, 
but it is something to be considered.)


> Cons:
>  * Not what the WAI PFWG draft currently says.

That spec could be changed, if there is a technically sound alternative.


>  * Unorthodox in terms of XML architecture.

Not that XML is perfect, but yes, since SVG is based on XML, that is a 
real challenge.

You seem to be in favor of the null-namespace option, but the strongest 
reason you give seems to be the shared syntax.  Can you supply a reason 
that the XHTML-namespace option won't work for both SVG and (X)HTML5 
equally well?

Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

Received on Wednesday, 10 October 2007 18:13:23 UTC