Re: @role in SVG

Hi, Henri-

Henri Sivonen wrote (on 10/10/2007 3:47 PM):
> 
> On Oct 10, 2007, at 21:13, Doug Schepers wrote:
> 
>> 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.

Why not?  It seems very pragmatic to me.


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

And to what extent is that?  I suspect that most browser implementors 
would be most happy to have some definitive specification or proposal to 
implement interoperably, more than they would want any given solution.

As far as I've seen, opinions differ among various employees of each 
browser vendor, so I'd like to know that an opinion expressed is the 
official and studied one of a vendor, not merely the opinion of one 
employee.  The whole point of our asking for feedback is to get the 
whole range of opinions, so we can reach the best conclusion before we 
ask all the browser vendors to implement it.


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

Well, that's worth considering, but again, out of scope for the topic of 
how to adopt @role in SVG.  It would require a considerable (and 
incompatible) rewrite of SVG, and I'm not at all convinced that that is 
really what is best for open standards in the face of market pressure. 
Can you supply justification for this, beyond purity of design?


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

The same could be said of namespaced content of any kind, including SVG 
inline with XHTML.  If I move a <svg:circle> outside of its root 
element, I will have exactly the same problem.  Do you see a solution to 
this larger issue?


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

That's not my impression of ARIA.  Getting and setting attribute values, 
yes, but not moving them around from element to element randomly...


>> 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.
> 
> I don't see why the DOM interfaces couldn't be defined in one place 
> either way. 

It's not necessarily a technical issue, but one of organization and ease 
of implementation.  For example, there are many SVG UAs that don't 
implement HTML, and so having to reference HTML normatively would mean 
that the UA implementor would have to find exactly those parts of HTML 
that they need to implement.  As far as I can tell so far, the current 
state of the HTML 5 spec seems pretty intertwingled, which doesn't give 
me much confidence that any given bit could be safely referenced by SVG. 
  It also makes updating and tracking changes to the referenced spec 
needlessly complicated.

It's also a PITA in terms of W3C Process, but that's another matter.


> However, so far, ARIA seems to work on top of DOM Core
> without specific interfaces.

So far.  But since it may have a complex value type, there is reason to 
consider that might change in the future.


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

Both politically and technically.

Technically, SVG is able to rely on another spec to define such things 
as parsing and other low-level details that are meant to be shared among 
all related languages.  Without that basis, we would have to define all 
these things in the SVG spec (again, more work I hope isn't necessary), 
as is being done in HTML 5.  And again for every other language.  It 
doesn't seem a cost-effective long-term solution, and is only reasonable 
in HTML 5 because of legacy content.


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

But given that they exist, how much more problem is it to generalize the 
model?  And don't you have to deal with this already, given that you may 
have to also parse inline SVG?


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

Received on Wednesday, 10 October 2007 22:03:14 UTC