@role in SVG

[Doug Schepers-3]

Hi, SVG community-

The SVG WG likes the functionality and extensibility that the 'role
attribute affords, and the potential for increased accessibility, so we
do want to include it in SVG (and to see it implemented as soon as
possible, so authors can use it right away).  We've talked about how
best to do so, and we'd like to solicit opinions from interested
parties, including the other Working Groups involved, implementors, and
authors.

To summarize the options, we can include the 'role' attribute in the
XHTML namespace, or as a native null-namespace attribute.  Each approach
has benefits and problems.

1) XHTML Namespace
<svg
   xmlns="http://www.w3.org/2000/svg"
   xmlns:xlink="http://www.w3.org/1999/xlink"
   xmlns:xhtml="http://www.w3.org/1999/xhtml"
   xmlns:aaa="http://www.w3.org/2005/07/aaa">
   <g xhtml:role="checkbox" aaa:checked="true">...</g>
</svg>

Pros:
* does not require any changes to SVG syntax... automatically available
via XML's innate extensibility mechanism
* conforms to current version of the Role spec [1]

Cons:
* is slightly harder to author (requires working knowledge of
namespaces, or good voodoo skills)
* differs in syntax from how it would work in XHTML and HTML5 (so may be
harder to learn, and possibly to implement)
* more verbose


2) Native Non-Namespaced Attribute
<svg
   xmlns="http://www.w3.org/2000/svg"
   xmlns:xlink="http://www.w3.org/1999/xlink"
   xmlns:aaa="http://www.w3.org/2005/07/aaa">
   <g role="checkbox" aaa:checked="true">...</g>
</svg>


Pros:
* more similar in syntax to XHTML and HTML5 (easier to use and maybe
implement)
* less verbose
* maybe less error-prone for authoring, mash-ups, compound documents

Cons:
* would require a change to SVG (see details below)
* would require change to Role spec to allow "host language" (SVG) to
incorporate it into its own language (note that there is precedent for
this in the previous version of the Role spec [2], not sure why it was
changed)

Neutral:
* still requires knowledge of namespaces, but only for including ARIA


Changes Required to SVG Specifications

As mentioned, including 'role' via the XHTML namespace requires no
changes to SVG (though would benefit from a Note on the details), but I
understand that some might not find it the cleanest or most
author-friendly solution.  So, the SVG WG is open to include it directly
in the SVG language, if that's the solution the community feels is best
(and if it is allowed by the Role spec).

If we are to include it in the language, just how we do so depends on
which version of SVG.  We can't add it as a feature to SVG 1.1 or before
(adding features that change conformance to a past version is not
allowed in the W3C Process), but we could do so for SVG 1.2 Full with
few or no problems.  There is a chance we could do it for SVG 1.2 Tiny,
because it's not yet in PR, but adding features at this late stage might
not sit well with the standards community (though the implementors on
the WG assure us that merely adding an attribute is trivial).  We would
like to do it, but not if it's seen as unacceptable by the standards
community.

Another factor is that we don't want to be dependent upon the Role
Attribute  and the CURIE specs for our Rec-Track exit criteria.  But
neither do we want to specify it separately (or differently) than that
spec.  A possible solution is that, for SVG 1.2 Tiny, we would include
it as an attribute whose value is a space-separated list of strings, and
when the Role and CURIE specs are more mature, in the SVG 1.2 Full
timeframe, we would change the specification of 'role' to refer to those
specs.  This is not a very clean solution, but it would get the 'role'
attribute out there, and let authors create content now in as easy a
manner as possible.


Changes Required to Role Attribute Specification

As mentioned before, for this to happen, the Role Attribute spec would
need to explicitly allow SVG to do it.  We'd like feedback from the
XHTML2 WG on this.  It would be ideal, perhaps, if the Role spec
optionally allowed the values to be strings instead of CURIEs (as
specified in a host language), but that may be a bridge too far.


Prompt feedback on this issue would be greatly appreciated.


[1] http://www.w3.org/TR/xhtml-role/
[2] http://www.w3.org/TR/2006/WD-xhtml-role-20060725/#docconf

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

[Jonathan Chetwynd]

as I previously mentioned it appears that there has been no response from any naive users.

It's my opinion, already expressed that this change has not been presented in a means presentable to such an audience.

I am for instance not able to ask non-expert audiences for their opinion to feed back into discussions.

I do not consider it sufficient that the WG is excited by this possibility.

Rather than imagining the pros and cons.

Please take the opportunity to ask.

regards

Jonathan Chetwynd

Accessibility Consultant on Media Literacy and the Internet

On 10 Oct 2007, at 01:59, Doug Schepers wrote:

Hi, SVG community-

The SVG WG likes the functionality and extensibility that the 'role attribute affords, and the potential for increased accessibility, so we do want to include it in SVG (and to see it implemented as soon as possible, so authors can use it right away).  We've talked about how best to do so, and we'd like to solicit opinions from interested parties, including the other Working Groups involved, implementors, and authors.

To summarize the options, we can include the 'role' attribute in the XHTML namespace, or as a native null-namespace attribute.  Each approach has benefits and problems.

1) XHTML Namespace

<svg

  xmlns="http://www.w3.org/2000/svg"

  xmlns:xlink="http://www.w3.org/1999/xlink"

  xmlns:xhtml="http://www.w3.org/1999/xhtml"

  xmlns:aaa="http://www.w3.org/2005/07/aaa">

  <g xhtml:role="checkbox" aaa:checked="true">...</g>

</svg>

Pros:

* does not require any changes to SVG syntax... automatically available via XML's innate extensibility mechanism

* conforms to current version of the Role spec [1]

Cons:

* is slightly harder to author (requires working knowledge of namespaces, or good voodoo skills)

* differs in syntax from how it would work in XHTML and HTML5 (so may be harder to learn, and possibly to implement)

* more verbose

2) Native Non-Namespaced Attribute

<svg

  xmlns="http://www.w3.org/2000/svg"

  xmlns:xlink="http://www.w3.org/1999/xlink"

  xmlns:aaa="http://www.w3.org/2005/07/aaa">

  <g role="checkbox" aaa:checked="true">...</g>

</svg>

Pros:

* more similar in syntax to XHTML and HTML5 (easier to use and maybe implement)

* less verbose

* maybe less error-prone for authoring, mash-ups, compound documents

Cons:

* would require a change to SVG (see details below)

* would require change to Role spec to allow "host language" (SVG) to incorporate it into its own language (note that there is precedent for this in the previous version of the Role spec [2], not sure why it was changed)

Neutral:

* still requires knowledge of namespaces, but only for including ARIA

Changes Required to SVG Specifications

As mentioned, including 'role' via the XHTML namespace requires no changes to SVG (though would benefit from a Note on the details), but I understand that some might not find it the cleanest or most author-friendly solution.  So, the SVG WG is open to include it directly in the SVG language, if that's the solution the community feels is best (and if it is allowed by the Role spec).

If we are to include it in the language, just how we do so depends on which version of SVG.  We can't add it as a feature to SVG 1.1 or before (adding features that change conformance to a past version is not allowed in the W3C Process), but we could do so for SVG 1.2 Full with few or no problems.  There is a chance we could do it for SVG 1.2 Tiny, because it's not yet in PR, but adding features at this late stage might not sit well with the standards community (though the implementors on the WG assure us that merely adding an attribute is trivial).  We would like to do it, but not if it's seen as unacceptable by the standards community.

Another factor is that we don't want to be dependent upon the Role Attribute  and the CURIE specs for our Rec-Track exit criteria.  But neither do we want to specify it separately (or differently) than that spec.  A possible solution is that, for SVG 1.2 Tiny, we would include it as an attribute whose value is a space-separated list of strings, and when the Role and CURIE specs are more mature, in the SVG 1.2 Full timeframe, we would change the specification of 'role' to refer to those specs.  This is not a very clean solution, but it would get the 'role' attribute out there, and let authors create content now in as easy a manner as possible.

Changes Required to Role Attribute Specification

As mentioned before, for this to happen, the Role Attribute spec would need to explicitly allow SVG to do it.  We'd like feedback from the XHTML2 WG on this.  It would be ideal, perhaps, if the Role spec optionally allowed the values to be strings instead of CURIEs (as specified in a host language), but that may be a bridge too far.

Prompt feedback on this issue would be greatly appreciated.

[1] http://www.w3.org/TR/xhtml-role/

[2] http://www.w3.org/TR/2006/WD-xhtml-role-20060725/#docconf

Regards-

-Doug Schepers

W3C Staff Contact, SVG, CDF, and WebAPI

[Doug Schepers-3]

Hi, Jonathan-

Please define "naive users".  As I said, if you wish to represent a
constituency, you will have to stop using such vague terms, or we cannot
begin to answer your questions.

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

~:'' ありがとうございました。 wrote (on 10/10/2007 2:24 AM):

> as I previously mentioned it appears that there has been no response
> from any naive users.
>
> It's my opinion, already expressed that this change has not been
> presented in a means presentable to such an audience.
>
> I am for instance not able to ask non-expert audiences for their opinion
> to feed back into discussions.
>
> I do not consider it sufficient that the WG is excited by this possibility.
>
> Rather than imagining the pros and cons.
> Please take the opportunity to ask.
>
> regards
>
> Jonathan Chetwynd
> Accessibility Consultant on Media Literacy and the Internet

[Henri Sivonen]

On Oct 10, 2007, at 03:59, Doug Schepers wrote:

> 1) XHTML Namespace
> <svg
>   xmlns="http://www.w3.org/2000/svg"
>   xmlns:xlink="http://www.w3.org/1999/xlink"
>   xmlns:xhtml="http://www.w3.org/1999/xhtml"
>   xmlns:aaa="http://www.w3.org/2005/07/aaa">
>   <g xhtml:role="checkbox" aaa:checked="true">...</g>
> </svg>

> 2) Native Non-Namespaced Attribute
> <svg
>   xmlns="http://www.w3.org/2000/svg"
>   xmlns:xlink="http://www.w3.org/1999/xlink"
>   xmlns:aaa="http://www.w3.org/2005/07/aaa">
>   <g role="checkbox" aaa:checked="true">...</g>
> </svg>

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>

Pros:
  * Matches what has recently been proposed for (X)HTML5 and XUL.  
Good both for implementation and author skill portability.
  * Fewer namespaces to deal with (i.e. easier).
  * Copy-paste-friendly.
  * DOM-friendly. (qNames in content are *bad* in the DOM.)
  * Not a chameleon namespace per se. The attributes would be in no  
namespace in XHTML5, SVG and XUL.
  * 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.

Cons:
  * Not what the WAI PFWG draft currently says.
  * Unorthodox in terms of XML architecture.

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

[Doug Schepers-3]

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

[Henri Sivonen]

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@...
http://hsivonen.iki.fi/

[Bjoern Hoehrmann]

* Henri Sivonen wrote:
>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.

I have a hard time following your criticism. It is true that the DOM is
unaware of possible dependencies between some content and its context,
and moving nodes without reconstructing the context may have undesirable
or unexpected effects. This is true for most inherited declarations and
relative references (the language of the node may change due to xml:lang
attributes, resource identifiers may change due to xml:base attributes,
event handlers may behave differently because the node's parent changed,
"QNames" may resolve to different names due to xmlns attributes, etc.)

That's a rather general problem, and beyond that, I am not sure what you
are saying. The DOM retains namespace declarations, you can query and
update them and you can easily look up the namespace name for a prefix
or the prefix for a namespace name; you might have missed .lookupPrefix,
.isDefaultNamespace, and .lookupNamespaceURI, otherwise I don't see why
you would walk the tree yourself.

Making yet more convenient methods would be difficult due to differences
in "QName" semantics and limitations in the usual programming languages;
for example, XML Schema maps unprefixed names to the declared default
namespace, Atom link relations map them to http://www.iana.org/... and
XSLT maps them to no namespace at all, and neither Java nor ECMAScript
support tuples as return value unless you wrap them inside something --
and then it'd be difficult to see how that's better than using split().

Could you perhaps rephrase what problems you see here, other than the
first I've mentioned above?
--
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: [phone] · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[Doug Schepers-3]

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

[Henri Sivonen]

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@...
http://hsivonen.iki.fi/

[Henri Sivonen]

On Oct 10, 2007, at 23:48, Bjoern Hoehrmann wrote:

> * Henri Sivonen wrote:
>> 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.
>
> I have a hard time following your criticism. It is true that the  
> DOM is
> unaware of possible dependencies between some content and its context,
> and moving nodes without reconstructing the context may have  
> undesirable
> or unexpected effects. This is true for most inherited declarations  
> and
> relative references (the language of the node may change due to  
> xml:lang
> attributes, resource identifiers may change due to xml:base  
> attributes,
> event handlers may behave differently because the node's parent  
> changed,
> "QNames" may resolve to different names due to xmlns attributes, etc.)
>
> That's a rather general problem, and beyond that, I am not sure  
> what you
> are saying.

It is a general problem for anything that is specified to inherit  
along the tree and isn't captured in the node at the node creation  
time. That xml:lang is brittle doesn't make qNames in content less  
brittle.

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

[Doug Schepers-3]

Hi, Henri-

Henri Sivonen wrote (on 10/12/2007 7:23 AM):
>
> 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.

Thanks for outlining the challenges to integrating SVG into text/html,
from an HTML5 standpoint.  That's very helpful.

I also want that to happen, and would like to facilitate that when the
time comes.  Also like you, I do have certain concerns about how it's
done.  I'll give you my viewpoint (which is not necessarily shared by
the rest of the SVG or CDF WGs).

 From a technical and market viewpoint (an odd pairing, perhaps), I feel
very strongly that SVG-in-HTML should maintain identical markup syntax
with standalone SVG (or SVG-in-XHTML, and probably X/HTML-in-SVG); any
differences between the two syntaces would be actively harmful to SVG.
For example, someone who copy-pasted an SVG fragment from HTML and tried
to use it as a standalone file, or imported it into an SVG file (perhaps
in an automated mashup) would get unexpected and probably disastrous
results.  Those inconsistencies would leave casual authors with a bad
impression of SVG, and force advanced authors to make elaborate
workarounds.  The goal, from the perspective of the SVG WG, would be to
make it easier --not harder-- for authors, and to increase the use of
SVG (and specifically not to drive authors into the hands of vendors of
proprietary formats).  I'm not saying that the SVG WG is not willing to
consider reasonable compromises, just that the end result of should be a
uniform syntax for SVG.

 From a logistics standpoint, this work should be done in coordination
between the HTML, SVG, and CDF Working Groups.  All have a vested
interest in it, and each has a unique set of perspectives, needs, and
knowledge.  Perhaps we can begin talking about it at the upcoming Tech
Plenary.  We are all busy with other things right now, but opening the
dialog will prepare us for what we'll need to consider going forward.

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

[Sam Ruby]

Doug Schepers wrote:

>
> Hi, Henri-
>
> Henri Sivonen wrote (on 10/12/2007 7:23 AM):
>>
>> 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.
>
> Thanks for outlining the challenges to integrating SVG into text/html,
> from an HTML5 standpoint.  That's very helpful.
>
> I also want that to happen, and would like to facilitate that when the
> time comes.  Also like you, I do have certain concerns about how it's
> done.  I'll give you my viewpoint (which is not necessarily shared by
> the rest of the SVG or CDF WGs).
>
>  From a technical and market viewpoint (an odd pairing, perhaps), I feel
> very strongly that SVG-in-HTML should maintain identical markup syntax
> with standalone SVG (or SVG-in-XHTML, and probably X/HTML-in-SVG); any
> differences between the two syntaces would be actively harmful to SVG.
> For example, someone who copy-pasted an SVG fragment from HTML and tried
> to use it as a standalone file, or imported it into an SVG file (perhaps
> in