Currently, SVG defines several the use of the href attribute on several different elements to use the XLink namespace, for both "incoming" (references) and "outgoing" (hyperlinks) links.
The SVG WG is considering allowing the href attribute to be used without the xlink: prefix, and possibly to allow incoming references to use the src attribute, for syntactic similarity to HTML, for SVG 2.0 (this does not affect SVG 1.1).
If this is going to be done, the time to do it is now, while SVG is not yet ubiquitous.
The current plan for handling this in SVG 2.0 is to allow the href attribute to be used without the xlink: prefix anywhere the xlink:href attribute is allowed. The href attribute (which we believe will be used more going forward) will take precedence over the xlink:href attribute if both are present and there is a conflict. This applies both to attribute values and to the DOM property getter/setter, for parsing and for DOM operations.
- The href attribute takes precedence over the xlink:href attribute
- If there is only an href attribute, the resulting property will have the value of the href attribute
- If there is only an xlink:href attribute, the resulting property will have the value of the xlink:href attribute
- If there is both an xlink:href attribute and an href attribute, there is a single resulting href property, with the value of the href attribute
- When serialized, all attribute are retained as set in the original document
For serialization, user agents should use href without the XLink namespace declaration or prefix.
Authoring tools should should output href without the XLink namespace declaration or prefix.
All user agents must support both 'xlink:href and href as input.
We are interested in hearing feedback for this idea.
Some background and factors for consideration are listed below.
The src attribute has different options, which are not yet resolved:
- The use of the src attribute is not defined (that is, it does nothing)
- The use of the src attribute changes the behavior of the element
The use of XLink-namespaced attributes in SVG is often challenging to content creators new to the language and to XML namespaces. In particular:
- the XLink declaration may be accidentally omitted, especially in copy-paste cases, making the XLink prefix (normally "xlink:") unbound, causing an error.
- the XLink declaration may have a typo (the correct declaration looks like this: xmlns:xlink="http://www.w3.org/1999/xlink"), causing an error.
- setting the xlink:href attribute via script often trips people up; here are some typical mistakes (in this case, setting the <image> attribute, but the same applies for getting and setting the attributes on <use>, <a>, etc.):
- el.setAttribute( "href", "foo.png" );
- el.setAttribute( "xlink:href", "foo.png" );
- el.setAttributeNS( "xlink:href", "foo.png" );
- el.setAttributeNS( "xlink", "href", "foo.png" );
- el.setAttributeNS( xlink, "href", "foo.png" ); (where there is no JS variable called "xlink")
- el.setAttributeNS( "http://www.w3.org/1999/xlink", "href", "foo.png" ); (Correct)
- var xlinkns = "http://www.w3.org/1999/xlink"; el.setAttributeNS( xlinkns, "href", "foo.png" ); (Correct)
HTML vs SVG image elements
The SVG <image> element has several differences with the HTML <img> element, which can trip up authors coming from HTML to SVG:
- <img> references images using the src attribute, while SVG <image> uses the href attribute (in the XLink namespace, currently)
- The SVG <image> element must be closed, either with a slash at the end of the element, or with a closing tag, while HTML <img> should not be closed
- The SVG <image> element may contain child content, while HTML <img> cannot
- The HTML <img> element defaults to the native dimensions of the referenced raster image, while SVG <image> defaults to a width and height of 0, and must be explicitly set to specific dimensions.
Factors for consideration
href and xlink:href on same element, and error handling
If SVG allows the href attribute without the XLink namespace prefix, authors may wish to supply the same attribute in the XLink namespace, for backwards compatibility with older browsers, plugins, and authoring tools. This leads to the question of what a user agent should do if both attributes are present, especially if their values are not the same:
- which attribute should take precedence, href or xlink:href?
- what should be the namespace of the .href property on the element's DOM interface?
- what should happen when one or the other is set by script or animated?
- should the value be "mirrored" among both of them?
- should there be a difference between using the .href property and setAttribute/NS?
src on <image>
The SVG WG has discussed whether to allow the SVG <image> element to allow the use of src in addition to href, for syntactic similarity with the HTML <img> element.
However, this would raise several new problems:
- how does src work with respect to href or xlink:href
- which attribute value takes precedence?
- what is the name of the DOM attribute?
- if the DOM attribute is set for one, is is changed for all?
- will this confuse authors who expect <svg:image> and <html:img> to work the same?
After discussion, the SVG WG believes that, especially in light of the differences between the SVG and HTML elements, it is better at this point to be self-consistent within SVG in the use of href as the single attribute for both inbound and outbound links, making it easier to learn and more intuitive to use.
Note: HTML is not universally consistent in distinguishing between inbound (or "content replacement") and outbound links in its use of attribute names, so there is not a single precedent:
- <a> uses href (outbound)
- <link> uses href (inbound and outbound)
- <img> uses src (inbound)
- <iframe> uses src (inbound)
- <script> uses src (inbound?)
- <embed> uses src (inbound)
- <object> uses data (inbound)
- <applet> uses code (inbound)