@xlink:href Aliasing (SVG ISSUE-2042) (was: <link> and <param> in SVG)

Hi, Henri-

Henri Sivonen wrote (on 5/4/09 1:51 PM):
> On May 1, 2009, at 12:13, Doug Schepers wrote:
>> Correct, we haven't worked out the details, but we do plan to
>> "decommission" @xlink:href, allowing @null:href and/or @null:src in
>> its place. The only open questions, IIRC, are whether @null:href and
>> @null:src can be used interchangeably, or if @null:href is for
>> "outbound" links and @null:src for "inbound" ones; and when and where
>> exactly to specify this...
>
> Will there be duplicate DOM properties?

I imagine there would.  I don't see any way around that, unfortunate as 
it is.


>  Will xlink:href take precedence
> to avoid breaking existing content?

I don't see how it would matters to existing content, which will only 
have @xlink:href.  It does matter to older SVG UAs, which won't 
understand the newer syntax.

As far as which takes precedence when both are present, I don't know if 
there's a good way to decide that.  If we intend to replace @xlink:href 
with the other attributes, that seems to dictate that those other 
attributes take precedence; if it is just a matter of aliasing, then 
@xlink:href should.  Suggestions?


> Has the new solution been reviewed to ensure that it doesn't introduce
> issues like id/xml:id or lang/xml:lang dual mechanisms?

No, like I mentioned, we haven't worked out the details.  I'm just 
speculating, hoping to get feedback from the general public.


> (id/xml:id is different, because IDness is special, and lang/xml:lang is
> different, because you can't represent xml:lang in text/html. I'm not
> saying that xlink:href/href comes with similar issues, but it would be
> good to make sure ahead of time that it doesn't.)

Yes, we don't want to get into the same situation as we did with 
@xml:id.  I think the analogy is not quite accurate:  @xml:id took an 
attribute that was already in common usage among many languages, 
including HTML and SVG, and tried to change it to something more-or-less 
incompatible to HTML (it didn't take into account the DOM, among other 
problems); allowing aliases for @xlink:href would actually take an 
element unknown in HTML, and replace it with attributes that HTML UAs 
are already familiar with.

(Granted, it may require additional processing, in that I expect there 
to be property value mirroring, which doesn't have to happen in HTML UAs.)

One issue is that <a> in SVG would look, for all intents and purposes, 
like <a> in HTML, but I'm not aware of any problems that might cause, 
even in mixed-namespace documents.  One difference is that in SVG, <a> 
can be a child of another <a> (where specificity takes precedence), but 
since the <svg:a> element is in the SVG scope, I don't think that would 
break anything.

If you have concrete thoughts about what might break, please let us 
know.  We aren't going to make this change unless there is general 
consensus (not unanimity) among content authors and implementers that 
this would be a good change.


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Tuesday, 5 May 2009 03:27:31 UTC