@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

["~:'' ありがとうございました"]

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

Doug, I don't know if you are familiar with my website, but I have been
deploying inline SVG on pages for quite some time now.  In any case,
there are some real issues that need to be worked out.  Examples include
what <![CDATA[ ]>> means, and how tags like <script> are handled by SVG
unaware browsers.  (Possibly <title> too, but that turns out to be less
of an issue).

Related:

http://intertwingly.net/blog/2007/09/11/SVG-on-IE-via-Silverlight-Revisited
http://intertwingly.net/blog/2007/08/02/HTML5-and-Distributed-Extensibility

- Sam Ruby

[Henri Sivonen]

On Oct 12, 2007, at 19:09, Doug Schepers wrote:

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

Do you mean you'd like to bring in the complication of arbitrary  
namespace prefixes? I'd like make the following deviations from SVG-
as-XML syntax:
  1) I'd like to minimize the need of tokenizer parametrization to  
toggling case folding behavior and, if we must, CDATA sections.  
Specifically, I think attribute tokenization should run the same code  
as attribute tokenization for the HTML parts of text/html.
  2) I'd like to avoid supporting arbitrary namespace prefixes both  
in order to sidestep issues in shipped IE versions and in order to  
relieve authors of namespace syntax. (xlink: should probably be  
considered non-arbitrary and hard-wired.)

More concretely, I've been thinking something like this might work:
  * Case folding in the tokenizer should be made conditional so that  
potentially camelCap names in <svg> subtrees would not be case-folded.
    - Issue: Should case folding be toggled on and off (in which case  
tokenizing "<svg " would happen in the case-folding state allowing  
"<SvG ") or should names be collected unfolded and then whole names  
conditionally case-folded (in which case we could require "<svg " to  
be in lower case)?
    - Issue 2: If the latter, to avoid expensively case-folding whole  
start tag tokens *including* attributes later on, the tokenizer  
should probably have to know about tag names that turn on the case-
preserving mode before looking for attributes but the tree builder  
should be the part of the parser telling the tokenizer to switch back  
to the case folding mode. This would be ugly but probably necessary.
  * Start tag tokens should have a flag about the /> presence. The  
tree builder would ignore this for HTML elements but would pop  
immediately for SVG elements.
  * The <svg> element would establish "an SVG scope" in the tree  
builder. The <svg> start tag token would itself be handled in the  
HTML state of the tree builder so that the <svg> element would be  
subject to foster parenting.
  * When in an SVG scope, the tree builder would ignore the HTML tree  
building rules. This means that stray tags looking like HTML tags  
could not cause the tree builder to pop out of the SVG scope. While  
in the SVG scope, the tree builder would assign the SVG namespace URI  
to the element nodes it creates.
    - Issue: What to do if there is a prefixed element?
  * When in the SVG scope, a start tag token would unconditionally  
result in the corresponding element node to be appended to the  
current node. (And if the /> flag is set on the token, the node would  
be popped immediately.)
  * When in the SVG scope, an end tag token would cause a  
corresponding element to be searched starting with the current node  
towards the start of the SVG scope (and no further). If an element  
were found in scope, the stack would be popped until that element got  
popped. If there were no such element in scope, the end tag would be  
ignored. Any outcome but a single pop would be a parse error.
  * When the current node is a foreignObject element in an SVG scope,  
the start tag token <html> would establish a "nested HTML scope". </
html>, <body> and </body> would act like "normal" tokens in a nested  
HTML scope. Specifically, any token other than </html> encountered in  
a nested HTML scope would be unable to break out of the nested HTML  
scope.
  * Attributes with the name "xlink:href" on the tokenization level  
would be reported by the tokenizer as local name "href" in the XLink  
namespace.
  * xmlns or xmlns:* attributes would have no meaning and would be  
non-conforming except xmlns="http://www.w3.org/2000/svg" and  
xmlns:xlink="http://www.w3.org/1999/xlink" would be allowed as  
"talismans" on the <svg> start tag.

The above trial balloon proposal is designed to optimize SVG  
integration in text/html in *future* browsers in a way that would  
create a namespace-aware DOM that current DOM-based SVG  
implementations would grok immediately but would at the same time  
remove namespace declaration syntax from the sight of authors. The  
proposal specifically isn't designed to clone the colon-based  
namespaces-in-text/html mechanism of IE. OTOH, it shouldn't interfere  
with it, either, except perhaps for xlink:href, which could be worked  
around by introducing href.

The approach outlined above could be used for MathML as well.  
However, in that case, the tokenizer should probably me modified to  
switch to MathML entity tables when the tree builder is in a MathML  
scope.

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

I agree it would make sense to talk about it at the Tech Plenary.

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

[Jirka Kosek]

Henri Sivonen wrote:

> The above trial balloon proposal is designed to optimize SVG integration
> in text/html in *future* browsers in a way that would create a
> namespace-aware DOM

Hmm, and why to support SVG (or any other embedded vocabulary) in HTML
serialization at all. XML serialization can be used without any problems
for such purposes. I think that cleaner approach is to switch from HTML
to XML syntax if you want to use XML features. Trying to emulate XML
features in HTML syntax is way to hell.

--
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@...      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

[Simon Pieters-3]

On Sat, 13 Oct 2007 16:43:59 +0200, Henri Sivonen <hsivonen@...> wrote:

> Do you mean you'd like to bring in the complication of arbitrary  
> namespace prefixes? I'd like make the following deviations from SVG-
> as-XML syntax:

I think it should be possible to have the same SVG markup to work both  
when parsed as XML and when parsed with the HTML parser (to the same  
extent as you can have HTML markup that works both when parsed as XML and  
when parsed with the HTML parser), and moreover, it should be possible to  
write scripts that fix up the DOM afterwards for legacy UAs.


>   1) I'd like to minimize the need of tokenizer parametrization to  
> toggling case folding behavior and, if we must, CDATA sections.

CDATA sections and the content model flag are interesting.

In legacy UAs, <script> and <style> will be parsed as CDATA elements, and  
<title> and <textArea> as RCDATA. Doing the same in new UAs is nice  
because that makes sure that content will degrade reasonably in legacy  
UAs, and makes it easier to write scripts that fixes the DOM for legacy  
UAs. For <script>, <style> and <title> this would not be a problem, since  
they normally only contain text, but <textArea> is more problematic since  
it can contain elements. (<textArea> is new in SVG 1.2 and apparently  
there isn't much content using it yet. Renaming that element would make  
this issue go away.)

Also, authors are already used to doing "<script>//<![CDATA[" when working  
with markup that needs to work as both HTML and XHTML, so having the same  
rules for SVG in HTML is likely what authors would expect.

Having all SVG elements be PCDATA (as in XML) would probably mean that we  
also have to introduce CDATA sections (since authors don't want to write  
"&&" in their scripts, and it would be harder to make things work  
in legacy UAs).

> Specifically, I think attribute tokenization should run the same code as  
> attribute tokenization for the HTML parts of text/html.
>   2) I'd like to avoid supporting arbitrary namespace prefixes both in  
> order to sidestep issues in shipped IE versions and in order to relieve  
> authors of namespace syntax. (xlink: should probably be considered  
> non-arbitrary and hard-wired.)
>
> More concretely, I've been thinking something like this might work:
>   * Case folding in the tokenizer should be made conditional so that  
> potentially camelCap names in <svg> subtrees would not be case-folded.
>     - Issue: Should case folding be toggled on and off (in which case  
> tokenizing "<svg " would happen in the case-folding state allowing "<SvG  
> ") or should names be collected unfolded and then whole names  
> conditionally case-folded (in which case we could require "<svg " to be  
> in lower case)?
>     - Issue 2: If the latter, to avoid expensively case-folding whole  
> start tag tokens *including* attributes later on, the tokenizer should  
> probably have to know about tag names that turn on the case-preserving  
> mode before looking for attributes but the tree builder should be the  
> part of the parser telling the tokenizer to switch back to the case  
> folding mode. This would be ugly but probably necessary.

I don't think it's necessary to require the svg start tag to be lowercase  
if doing so would be a performance problem, but I don't feel strongly  
about it. It is however necessary to get the case of the attributes of the  
svg start tag right because of (at least) the viewBox="" attribute.


>   * Start tag tokens should have a flag about the /> presence. The tree  
> builder would ignore this for HTML elements but would pop immediately  
> for SVG elements.

Doing so for "script", "style", "title" and "textArea" would mess up  
legacy UAs badly.

>   * The <svg> element would establish "an SVG scope" in the tree  
> builder. The <svg> start tag token would itself be handled in the HTML  
> state of the tree builder so that the <svg> element would be subject to  
> foster parenting.
>   * When in an SVG scope, the tree builder would ignore the HTML tree  
> building rules. This means that stray tags looking like HTML tags could  
> not cause the tree builder to pop out of the SVG scope. While in the SVG  
> scope, the tree builder would assign the SVG namespace URI to the  
> element nodes it creates.
>     - Issue: What to do if there is a prefixed element?

Do the same as what you do with a prefixed element outside SVG scope  
(i.e., include the prefix and the colon in the local name).

>   * When in the SVG scope, a start tag token would unconditionally  
> result in the corresponding element node to be appended to the current  
> node. (And if the /> flag is set on the token, the node would be popped  
> immediately.)
>   * When in the SVG scope, an end tag token would cause a corresponding  
> element to be searched starting with the current node towards the start  
> of the SVG scope (and no further). If an element were found in scope,  
> the stack would be popped until that element got popped. If there were  
> no such element in scope, the end tag would be ignored. Any outcome but  
> a single pop would be a parse error.
>   * When the current node is a foreignObject element in an SVG scope,  
> the start tag token <html> would establish a "nested HTML scope". </
> html>, <body> and </body> would act like "normal" tokens in a nested  
> HTML scope. Specifically, any token other than </html> encountered in a  
> nested HTML scope would be unable to break out of the nested HTML scope.

I think it makes more sense to make <foreignObject> itself switch back to  
normal "in body". The common case seems to be to just have a <div> as  
child when you use XHTML in a <foreignObject>.


>   * Attributes with the name "xlink:href" on the tokenization level  
> would be reported by the tokenizer as local name "href" in the XLink  
> namespace.
>   * xmlns or xmlns:* attributes would have no meaning and would be  
> non-conforming except xmlns="http://www.w3.org/2000/svg" and  
> xmlns:xlink="http://www.w3.org/1999/xlink" would be allowed as  
> "talismans" on the <svg> start tag.

Allowing the xmlns="http://www.w3.org/1999/xhtml" talisman on the child of  
foreignObject, too (perhaps only for <div>?).


> [...]

--
Simon Pieters
Opera Software

[Doug Schepers-3]

Hi, Henri-

There's a small chance that I'm not as conversant in the details of the
HTML5 parser as you, so I don't know the constraints that it has when
dealing with SVG (or any XML, for that matter).  However, I was able to
follow the steps you described, even if I'm not fully aware of the
rationale behind all of them.  Thanks for the detailed analysis... it
was both edifying and encouraging.


Henri Sivonen wrote (on 10/13/2007 10:43 AM):
>
> Do you mean you'd like to bring in the complication of arbitrary
> namespace prefixes?

Not necessarily.  I'm fine with imposing certain limitations on SVG
content, assuming that it's a set of limitations that can be easily
obeyed by authoring tools (and which, preferably, existing authoring
tools abide by anyway).  The most important thing for me is that SVG
fragments from an HTML+SVG (SVG-in-HTML) compound document could be
extracted as standalone SVG documents; the second most important thing
is that the most likely content from standalone SVG documents should
work as an SVG fragment in HTML (this is second because I think it is
likely that this will be the case, given existing SVG content-creation
tools).


> I'd like make the following deviations from
> SVG-as-XML syntax:
>  1) I'd like to minimize the need of tokenizer parametrization to
> toggling case folding behavior and, if we must, CDATA sections.

Strictly speaking, CDATA sections are not required in SVG, but as you
know, script will break in an XML parser it if doesn't escape its "<"
and "&" characters.  The majority of SVG authoring tools, I suspect, are
not script-aware: they are just drawing apps that export to SVG; people
savvy enough to be scripting can be expected to take precautions and
read FAQs to resolve their problems there.

Even drawing tools, though, are likely to use CSS, and may automatically
enclose it in a CDATA section "just to be safe".  It would be worthwhile
to look at the survey of tools and see if they do this, and if so, if
they can be encouraged to change this practice.

I would prefer that CDATA be allowed, but it's not a deal-breaker.  I
confess I don't know why it's a problem in the HTML parser, though, if
you care to explain.

Most tools do include XML prologs and DOCTYPES in their SVG output...
what affect will this have on a whole-file copy-paste into HTML, in
terms of parsing?


> Specifically, I think attribute tokenization should run the same code as
> attribute tokenization for the HTML parts of text/html.

Could you elaborate on that?  What are the implications?


>  2) I'd like to avoid supporting arbitrary namespace prefixes both in
> order to sidestep issues in shipped IE versions and in order to relieve
> authors of namespace syntax. (xlink: should probably be considered
> non-arbitrary and hard-wired.)

I think it's reasonable both to limit arbitrary namespace prefixes in
HTML+SVG, and to hard-wire the XLink namespace.  That SVG-fragment
content will still work as expected in a standalone SVG UA, and most
people trying to do clever things in namespaces will probably be using
XHTML+SVG anyway.


> The above trial balloon proposal is designed to optimize SVG integration
> in text/html in *future* browsers in a way that would create a
> namespace-aware DOM that current DOM-based SVG implementations would
> grok immediately but would at the same time remove namespace declaration
> syntax from the sight of authors. The proposal specifically isn't
> designed to clone the colon-based namespaces-in-text/html mechanism of
> IE. OTOH, it shouldn't interfere with it, either, except perhaps for
> xlink:href, which could be worked around by introducing href.

I'm still on the fence about 'null:href'.  Can you explain in detail why
this is so problematic in HTML5 (especially given that SVG isn't
natively supported in IE anyway)?


> The approach outlined above could be used for MathML as well. However,
> in that case, the tokenizer should probably me modified to switch to
> MathML entity tables when the tree builder is in a MathML scope.

I agree it's a good idea to look at the most common XML presentation
formats and generalize the solution.


> I agree it would make sense to talk about it at the Tech Plenary.

I'll coordinate with the respective chairs and try to lock down a time
and day.  We can communicate offlist about who would be good to have
around and what their attendance schedules are.

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

[Sam Ruby]

Jirka Kosek wrote:

> Henri Sivonen wrote:
>
>> The above trial balloon proposal is designed to optimize SVG integration
>> in text/html in *future* browsers in a way that would create a
>> namespace-aware DOM
>
> Hmm, and why to support SVG (or any other embedded vocabulary) in HTML
> serialization at all. XML serialization can be used without any problems
> for such purposes. I think that cleaner approach is to switch from HTML
> to XML syntax if you want to use XML features. Trying to emulate XML
> features in HTML syntax is way to hell.

Two reasons:

1) People often author content which is inserted into a larger context.
  Blogs, wikis, comments, are but a few examples.  Requiring the entire
page to be xml well formed, and requiring that none of the page be
displayed if there is any well formedness errors, is a non-starter for
most sites.  I'd love to see the day when svg could be copy/pasted into
MySpace and MathML copy/pasted into Facebook, and have it "just work".

2) There are is well-known and widely deployed browser which will not
display content served as application/xhtml+xml at all.

- Sam Ruby

[Doug Schepers-3]

Hi, Sam-

Sam Ruby wrote (on 10/12/2007 3:58 PM):
>
> Doug, I don't know if you are familiar with my website, but I have been
> deploying inline SVG on pages for quite some time now.  

Yes, of course I am.  I was very pleased to see the SVG logo turn up
there, one of the first uses in the wild.  Your blog is always very
interesting, lots of good experimentation there.


> In any case,
> there are some real issues that need to be worked out.  Examples include
> what <![CDATA[ ]>> means, and how tags like <script> are handled by SVG
> unaware browsers.  (Possibly <title> too, but that turns out to be less
> of an issue).

I'm becoming more aware of those.  I hope none of them are deal-breakers.


> Related:
>
> http://intertwingly.net/blog/2007/09/11/SVG-on-IE-via-Silverlight-Revisited
> http://intertwingly.net/blog/2007/08/02/HTML5-and-Distributed-Extensibility

I hadn't read that second link... yes, it seems like a good proposal.
Are there any strong objections to it?

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

[David Woolley (E.L)]

Sam Ruby wrote:

>
> 1) People often author content which is inserted into a larger context.
>  Blogs, wikis, comments, are but a few examples.  Requiring the entire
> page to be xml well formed, and requiring that none of the page be
> displayed if there is any well formedness errors, is a non-starter for

What you are basically saying is that the whole XML concept is flawed.
As I understand it, the reason for requiring well-formedness is not, as
some people seem to think, so that you can detect and throw out
documents with very poor syntax, but so that you can mix languages and
safely embed content, i.e. it is to support the X in XML.  A
well-formedness violation basically means that you no longer know which
language (namespace) you are in, and that's why parsers are expected to
abort.

I think the HTML5 approach would end up being to add yet more error
recovery rules, to cover SVG in HTML cases, MathML, in SVG in HTML
cases, etc.

> most sites.  I'd love to see the day when svg could be copy/pasted into
> MySpace and MathML copy/pasted into Facebook, and have it "just work".

That was the key design aim of XML!

Incidentally, as noted in one of my replies to a recent thread on
www-html, it is not a good idea for blog engines, etc., to simply copy
third party content into the matrix.  They should be restricting it to
content that is "well formed" in all intended languages, as part of
making safe.  If it isn't well formed, some browsers may not correctly
detect the end of the embedded content, or may be tricked into
recognising early, thus frustrating the sort of "untrusted" marking that
was being proposed in that thread, and requiring that any trust marking
be orthogonal to the DOM structure.
>
> 2) There are is well-known and widely deployed browser which will not
> display content served as application/xhtml+xml at all.

Those browsers support embedded VML, not embedded SVG (and actually do
so using full XML namespace syntax, even though that is not supposed to
be used in documents served as text/html!

Note, in general, I think cross-posting between mailing lists is a bad
idea, as replies are likely to get rejected or moderated on most of
them, but I've made an exception in this case and even added www-html,
which seems to me to a more appropriate to discuss whether the XML
concept was a mistake.  Please note that I am only subscribed to www-svg
and www-html, amongst the lists used.

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[Doug Schepers-3]

Hi, David-

Please don't derail what is a very productive, practical discussion with
ideological rants about the nature, purpose, and quality of XML.  All
this can accomplish is starting a flame war that none of us have time for.

The case of SVG in XHTML is very clear and obvious, and the details are
being worked out in the CDF WG.  Because they are both XML, they blend
together neatly.

What we are talking about here is something very different --the
blending of 2 different species of markup-- and therefore has different
constraints.  SVG in plain old HTML has many pragmatic use cases, and we
are trying to work out what challenges it will face and how to solve
them in a way that it Just Works for authors.

As regards cross-posting, I think it needs to be done to make sure that
all interested parties can coordinate on the issue.  The CDF, SVG, HTML
WGs all have a stake in this.  I think a lack of such cooperation and
collaboration has gotten us into a lot of trouble that could have been
solved by establishing clear channels of communication early on.

Finally, Sam was not attacking XML, as you insinuate.  He was presenting
facts about challenges SVG-in-HTML faces.

XML is OK.  HTML is OK.  They should kiss and make up.

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

David Woolley wrote (on 10/14/2007 5:21 AM):

>
> Sam Ruby wrote:
>
>>
>> 1) People often author content which is inserted into a larger
>> context.  Blogs, wikis, comments, are but a few examples.  Requiring
>> the entire page to be xml well formed, and requiring that none of the
>> page be displayed if there is any well formedness errors, is a
>> non-starter for
>
> What you are basically saying is that the whole XML concept is flawed.
> As I understand it, the reason for requiring well-formedness is not, as
> some people seem to think, so that you can detect and throw out
> documents with very poor syntax, but so that you can mix languages and
> safely embed content, i.e. it is to support the X in XML.  A
> well-formedness violation basically means that you no longer know which
> language (namespace) you are in, and that's why parsers are expected to
> abort.
>
> I think the HTML5 approach would end up being to add yet more error
> recovery rules, to cover SVG in HTML cases, MathML, in SVG in HTML
> cases, etc.
>
>> most sites.  I'd love to see the day when svg could be copy/pasted
>> into MySpace and MathML copy/pasted into Facebook, and have it "just
>> work".
>
> That was the key design aim of XML!
>
> Incidentally, as noted in one of my replies to a recent thread on
> www-html, it is not a good idea for blog engines, etc., to simply copy
> third party content into the matrix.  They should be restricting it to
> content that is "well formed" in all intended languages, as part of
> making safe.  If it isn't well formed, some browsers may not correctly
> detect the end of the embedded content, or may be tricked into
> recognising early, thus frustrating the sort of "untrusted" marking that
> was being proposed in that thread, and requiring that any trust marking
> be orthogonal to the DOM structure.
>>
>> 2) There are is well-known and widely deployed browser which will not
>> display content served as application/xhtml+xml at all.
>
> Those browsers support embedded VML, not embedded SVG (and actually do
> so using full XML namespace syntax, even though that is not supposed to
> be used in documents served as text/html!
>
> Note, in general, I think cross-posting between mailing lists is a bad
> idea, as replies are likely to get rejected or moderated on most of
> them, but I've made an exception in this case and even added www-html,
> which seems to me to a more appropriate to discuss whether the XML
> concept was a mistake.  Please note that I am only subscribed to www-svg
> and www-html, amongst the lists used.
>

--