Re: no-namespace href in SVG

Hi, Maciej-

Maciej Stachowiak wrote (on 10/11/2007 4:17 AM):
> 
> On Oct 10, 2007, at 3:03 PM, Doug Schepers wrote:
> 
>>> 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?
> 
> I don't see how it would require major changes or incompatible changes. 
> Supporting both href and xlink:href would be compatible and pretty minor 
> change to the spec. I'm not sure if the increased ease of authoring 
> would be worth the transition cost, but I wouldn't dismiss it out of hand.

It would still be backwards-incompatible.  New content (that only used 
'null:href') would not work in SVG1.1 UAs.  Right now, the most popular 
and functional plugin (ASV) for the most popular browser (IE) is no 
longer being updated, so the largest user base would not be able to use 
links in new SVG content.  It's similar for some other older 
implementations targeted toward mobile devices (where SVG is also 
growing), but mobile devices have a more rapid turnover, so it's less of 
a problem there.  Let's hope that a better solution for SVG in IE turns 
up, so this objection disappears.

Further, having both 'href' and 'xlink:href' could confuse authors as 
much as help them.  For expert authors, there is almost no gain, other 
than a few keystrokes; for copy-paste authors, they would see two 
different syntaces and and could easily infer that they have 2 different 
sets of functionality, and would not know "when to use which one", and 
when to declare the namespace.  This would be exacerbated if we allow 
'src' instead of 'xlink:href' for embedding/inclusion, as you suggested 
on IRC.  We would see all sorts of Frankenstein content like:

   <svg:image xlink:href="pic1.png" src="myPic.jpg" />

(Which raises the minor issue of what happens when someone changes the 
'href' attribute via script or declarative animation and not the 
'xlink:href' attribute, or vice versa?  Do both change?  If they are 
different in the markup, as above, which one takes precedence?  Which is 
most intuitive for authors?  These issues are probably easily resolved, 
defined, and implemented, but would need to be addressed.  Another issue 
that will come up with compound documents is how to deal with, for 
example, a non-namespaced 'alt' attribute on an <svg:image>, or an 
<svg:title> or <html:title> element as child of an <html:img>... that 
gets a little more tricky.)

In its mildest form, having both would lead to deliberate reduplication 
"just to be safe" (like 'name' and 'id' in HTML), which would eliminate 
the benefit and actually make the content more verbose (and no easier to 
author).

Since UAs would have to support both, it makes implementation no easier. 
(And doesn't it essentially introduce the issue of attribute aliasing on 
the same element, or is that not a problem?)  I'm more concerned with 
authors and end-users than I am with implementors and spec-writers, but 
I'm not yet sure it's a significant gain for authors.


Okay, so that's why I think it's not a decision entered into lightly. 
On the flip side, there are reasons it would be a good idea, and ways in 
which it won't cause harm.

I will confirm that this *is* a common problem for new authors, 
especially when scripting.  They don't know about namespaces, and so try 
to do things like:

   myImage.setAttribute( "href", "#mySymbol" );

or even:

   myUse.setAttributeNS( null, "xlink:href", "#mySymbol" );

This is a pretty understandable error.  Then again, I've never seen 
someone remain confused, or make the same mistake, once namespaces and 
the proper syntax are explained (which I've always found easy to do). 
That's not to say it's not a barrier, but it's a pretty low one in my 
experience.


I also acknowledge that for HTML authors not previously familiar with 
SVG (a large number, I'd expect) who are making inline SVG (i.e. a 
compound document), it would be both more convenient and more intuitive 
to have shared syntax with HTML wherever possible, including 
(especially?) the <a> element.

The idea was also mentioned in #html that SVG could have different 
syntax in namespace-unaware HTML than in XHTML+SVG or standalone SVG; I 
want to say that this is a terrible idea, and would lead to brittle 
content that's not copy-paste-friendly.  If SVG does allow null-NS 
'href', it should do the same in any context.  A more acceptable 
solution would be to have an "implied" namespace attached to 'xlink:', 
such that no NS declaration would be needed in HTML (and possibly in SVG?).


Although ASV (the Adobe SVG Viewer) does require the 'xlink:' namespace 
prefix, it *does not* require the XLink namespace declaration.  So, the 
"implied" declaration solution is actually pretty viable, and is 
copy-paste-friendly in that it doesn't require you to also copy the NS 
declaration.  Note: because FF is more strict about NS declaration, this 
broke a lot of content developed for ASV.  (I used to be in favor of 
this strictness, for both SVG and XLink NS declaration in the root, but 
I've come around to prefer the other side, because it's more author 
friendly, and there are relatively few "implied" namespaces that would 
be needed... XLink, XHTML, and SVG, and maybe a couple more are all 
common, with others needing explicit NS declarations.  Don't know how 
doable this is, but it's my favorite compromise.)


Not speaking for the SVG WG, I think it would have been better --with 
20/20 hindsight-- not to have referenced the XLink spec (or at least not 
required the 'xlink:' prefix), but I'm sure it seemed like a good idea 
at the time.  But on the whole, SVG has a lot less legacy baggage than 
traditional HTML, and I'm not certain that it needs to have the same 
extreme measures taken with it as are being done for HTML 5.

<fluff>
Finally, I don't see how you read, "that's worth considering" as 
"dismiss it out of hand".  That sorta implies that the SVG WG is being 
dismissive and inflexible (maybe you didn't mean that... I hope not).  I 
want to correct that impression.  In the last few months, especially, we 
have taken pains to find out how we can more closely work with the HTML 
WG (and the HTML 5 language) to make it easier on authors (and to 
improve communications between our 2 groups in general).  It's in SVG's 
best interest to make it easy for authors to include SVG in HTML, either 
by reference or direct inclusion.  The subject has also come up in the 
CDF WG, and is being discussed very seriously.  We understand the market 
and technical realities that HTML browsers are facing, and we want to 
work with you however we can.  But that's not to say we can 
significantly change SVG without a lot of careful consideration; just as 
HTML, we cannot ignore legacy content and User Agents.

As evidence, consider that I indicated openness to the idea of a no-NS 
'href' to you and others on a the #html IRC channel just a couple days 
ago; I'm probably minuted on logs of the SVG WG (of which you are a 
member) as having brought up the topic a few times (specifically in the 
light of ease of authoring and concordance with HTML 5).  We have also 
discussed (in both SVG and CDF) the idea of "implied" namespaces (though 
not everyone is sold on it) and integration into HTML 5, completely 
independently of any suggestion by the WHATWG (and I have photographic 
proof :) ).  My favorite example is how to accommodate a casual author 
who wants to copy-paste some SVG she made in Inkscape into her blog, 
where she doesn't control the format (HTML vs. XHTML) and is unable to 
declare namespaces in the document root; this is a real-world problem, 
and I'm hoping it's one that can be solved in an author-friendly way.

Our first instinct when the issue of the 'role' attribute (and the 
larger topic of ARIA integration) was brought up was to try to converge 
with HTML syntactically and functionally, which is why we brought it to 
a public forum.  I'm hoping we can make that happen.  But cooperation is 
a two-way street, and we also hope for some reciprocal flexibility, 
patience, and respect from the HTML WG when considering these issues.
</fluff>

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

Received on Thursday, 11 October 2007 16:09:17 UTC