Bug 22500 - hyperlinked text parts aren't rendered
Summary: hyperlinked text parts aren't rendered
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://kaioa.com/svg/webkit_linktest.svg
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-25 15:26 PST by Jos Hirth
Modified: 2011-05-17 07:35 PDT (History)
4 users (show)

See Also:


Attachments
demonstrates text and tspan with anchors, tested on moz, opera, batik, and webkit (847 bytes, image/svg+xml)
2009-07-28 04:45 PDT, jay
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jos Hirth 2008-11-25 15:26:19 PST
The example file contains the text "foo link foo" where "link" is wrapped with an <a> element whose "xlink:href" attribute has the value "http://example.com". It basically looks like this:

<text [...]>
  <tspan>foo <a xlink:href="http://example.com">link</a> foo</tspan>
</text>

--

WebKit-r38708 only renders "foo foo". The same goes for current versions of Chrome and Safari.

--

Hyperlinking a whole <text> element does work fine though.

E.g. the following works as it should:
<a [...]><text [...]><tspan [...]>foo</tspan></text></a>

While the specs don't allow a <tspan> as a child of <a>, #PCDATA is valid. See:
http://www.w3.org/TR/SVG/linking.html#Links (#PCDATA is listed first in SVG.a.content)

So something like the following should work:
<text [...]><tspan [...]><a [...]>foo</a></tspan></text>

And indeed it's valid and other browsers such as Firefox or Opera display it correctly and the link is also clickable (<tspan> as child of <a> also works there - even if it isn't valid).
Comment 1 Daniel Darabos 2009-01-30 03:26:26 PST
I can confirm this bug. FF3 displays the link and it is clickable, Chrome does not display the link at all.
Comment 2 Eric Seidel (no email) 2009-04-28 17:21:10 PDT
<a> tags are not allowed inside <tspan> according to the SVG 1.1 DTD:

<!ENTITY % SVG.TextContent.extra.class "" >
<!ENTITY % SVG.TextContent.class
    "| %SVG.tspan.qname; | %SVG.tref.qname; | %SVG.textPath.qname;
     | %SVG.altGlyph.qname; %SVG.TextContent.extra.class;"
>

http://www.w3.org/TR/SVG11/svgdtd.html

This looks like a bug in Firefox which we should file with mozilla.
Comment 3 Jos Hirth 2009-04-28 18:36:47 PDT
Aren't you looking at the wrong thingy?

http://www.w3.org/TR/SVG11/text.html#TSpanElement

<!ENTITY % SVG.tspan.content
    "( #PCDATA | %SVG.tspan.qname; | %SVG.tref.qname; | %SVG.altGlyph.qname;
     | %SVG.animate.qname; | %SVG.set.qname; | %SVG.animateColor.qname;
     | %SVG.Description.class; %SVG.Hyperlink.class;
       %SVG.tspan.extra.content; )*"
>

There... %SVG.Hyperlink.class.
Comment 4 jay 2009-07-28 04:41:57 PDT
The example given validates using the w3c validator,

mozilla, batik and opera display the anchor content.

as stated anchor in text is supported by webkit

there is a clear use case as per the example.

#3 suggests imho correctly that the DTD already states that tspan may include an anchor:

<!ENTITY % SVG.tspan.content
    "( #PCDATA | %SVG.tspan.qname; | %SVG.tref.qname; | %SVG.altGlyph.qname;
     | %SVG.animate.qname; | %SVG.set.qname; | %SVG.animateColor.qname;
     | %SVG.Description.class; %SVG.Hyperlink.class;
       %SVG.tspan.extra.content; )*"
>

common-sense dictates that if the spec had required tspan not to contain anchor, this would be raised as an errata, and this bug could be raised with the working group.
Comment 5 jay 2009-07-28 04:45:53 PDT
Created attachment 33615 [details]
demonstrates text and tspan with anchors, tested on moz, opera, batik, and webkit
Comment 6 Rob Buis 2011-05-16 19:06:49 PDT
I think this works nowadays.
Cheers,

Rob.
Comment 7 Jos Hirth 2011-05-17 07:27:46 PDT
Yes, it does look indeed like it was fixed in the meantime. Thanks for taking a look, Rob. :)
Comment 8 Rob Buis 2011-05-17 07:35:19 PDT
Hi Jos,

(In reply to comment #7)
> Yes, it does look indeed like it was fixed in the meantime. Thanks for taking a look, Rob. :)

No problem :) I like to close old reports so we can concentrate on fixing what is still broken today :)
Cheers,

Rob.