Re: @role in SVG

On Oct 11, 2007, at 01:03, Doug Schepers wrote:

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

The idea of interleaving two completely unrelated lists of tokens in  
one attribute seems intuitively brittle considering the history of  
<object> that was supposed to be the element of all trades.

Perhaps it can be arranged that consumers of different token  
sequences can safely skip the tokens of the other interleaved  
sequence without collisions and without too severe performance  
problems. However, if making this skipping work requires qNames in  
content to avoid collisions, I'd take two attributes over qNames in  
one attribute any day.

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

The Bugzilla action is at
https://bugzilla.mozilla.org/show_bug.cgi?id=396632

Simon Pieters from Opera is drafting spec text and I haven't heard  
anything unfavorable from Opera.

As far as I've noticed, the other browser implementors have been silent.

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

It seems to me that vendor-level official pronouncements about  
particular spec features are relatively rare compared to casual  
opinions and actions of the people who work on a particular feature.

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

Ease of authoring arising for the purity of namespaceless attributes.  
Also, it would simplify inline SVG in text/html.

However, due to backwards compatibility considerations, getting rid  
of the xlink prefix might not be worth it. It doesn't mean that it is  
a good idea to introduce more of the same, though.

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

That's not the same thing at all. The namespace,local pair for  
element and attribute names is resolved and frozen at node creation  
time and isn't affected if the node is moved around.

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

No, the ARIA attributes themselves are not expected to get moved  
around, but in an Ajax app, it is reasonable to expect elements that  
host ARIA attributes to get cloned or moved around.

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

Well, since SVG in browsers shares the DOM implementation with the  
HTML part of the engine, the HTML DOM legacy leaks to SVG as well and  
it would be reasonable for SVG to inherit stuff from the browser DOM  
legacy instead of inheriting stuff from the non-browser XML space.

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

The problem is you cannot generalize them in a way that doesn't either
  1) complicate non-browser apps that build on XML tools and want to  
push text/html handling out of the core to the IO boundary
or
  2) break DOM scripting backwards compat in browsers.

> And don't you have to deal with this already, given that you may  
> have to also parse inline SVG?

We don't do inline SVG in text/html yet. Personally, I hope we'll get  
there. However, if we do, the main SVG complications will be the  
xlink mapping, the /> syntax and SVG-native camelCaps. I don't think  
it is a good idea to introduce more complications if we are already  
entertaining inline SVG in text/html as a possibility.

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

Received on Friday, 12 October 2007 11:24:22 UTC