Re: handling XLink deprecation

Hi David,

David Dailey:
> For the two parts of the proposal that affect me most (at least in
> ways that I'm aware):
>
> --change xlink:href to href for: <a>, <altGlyph>, the animation
> elements, <color-profile>, <filter>, <font-face-uri>, <glyphRef>,
> gradient elements, <mpath>, <pattern>, <textPath>, <tref> and <use>
>
> and --change xlink:href to src for: <cursor>, <feImage>, <image> and
> <script>
>
> I can see the logic (and I've always thought xlink and the associated
> namespace hoopla was unfortunate). But, it runs a bit counter to some
> thoughts I have had about making SVG more internally consistent
> (instead of consistent with HTML which suffers from severe fits of
> feudal bickering) -- wouldn't it be nice if one syntax for referring
> to all "modifiers" (gradients, patterns, filters, animations, uses,
> replicates, clipPaths, masks, etc.) were in place. Why have "#Q" for
> some and url(#Q) for others? I always have to look up an example to
> figure out the syntax for the particular modifier de l'heure that I
> am using. It seems the two issues are related in a way.

(Internal vs external consistency is something I struggle with too!  An 
obvious one is: do we use camel case for new element names to be 
consistent with the existing ones, or all lower case for consistency 
with HTML?)

The fact that in some places you use url(#Q) and others just #Q is 
unfortunate, but I don't know how easy that would be to change.  CSS 
properties can't take raw URLs without "url()" around them, due to that 
being incompatible with the CSS parser (I imagine).  Allowing "url()" in 
existing xlink:href="" attributes seems wrong too; "url(#Q)" has a 
particular existing meaning when interpreted as a URI reference.

I think this issue isn't new for SVG, either.  In HTML, you have <img 
src="url" style="background-image: url(x)">.

Received on Wednesday, 22 August 2012 00:32:29 UTC