Re: @role in SVG

On Oct 10, 2007, at 21:13, Doug Schepers wrote:

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

I'm not sure using the same attribute as the ARIA hook and as  
something unrelated is a good idea.

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

There seems to be browser implementor consensus to the extent they  
have stated opinion.

>>  * 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.

If SVG got a built-in href='' also, it would put namespaces  
completely out of sight except for the default incantation on the  
root element.

>>  * DOM-friendly. (qNames in content are *bad* in the DOM.)
>
> Can you elaborate on that?

DOM doesn't capture the namespace mapping scope at the node creation  
time. It doesn't even provide API-native convenience methods for  
resolving qNames-in-content into NS,localName pairs. Even if you  
bother to walk the tree using code you wrote yourself because DOM  
didn't do it for you, the meaning of qNames is brittle when nodes are  
moved around. When you walk towards the root you may find very  
different ns declarations if the node you start from has been moved  
to another subtree after the initial DOM build.

QNames in content are a tolerable match for use cases where a static  
XML file is parsed using a SAX parser (e.g. when compiling an XSLT  
transformation). However, qNames in content are a really bad match  
for dynamic DOM manipulation which is what ARIA is all about.

>>  * 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.)

I don't see why the DOM interfaces couldn't be defined in one place  
either way. However, so far, ARIA seems to work on top of DOM Core  
without specific interfaces.

>>  * Unorthodox in terms of XML architecture.
>
> Not that XML is perfect, but yes, since SVG is based on XML, that  
> is a real challenge.

Politically, yes. Technically, not necessarily. :-)

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

It is desirable to be able to write (X)HTML5 processing application  
internals once so that swapping the parser or serializer at the IO  
boundary disrupts the app internals minimally. This means going with  
the constraints of text/html which can only do no-namespace  
attributes. Even the handful of subtle differences we have now  
between HTML5 and XHTML5 are a pain (e.g. lang vs. xml:lang).

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

Received on Wednesday, 10 October 2007 19:47:55 UTC