Currently, Mozilla sets the "color" property to be link-colored (blue or purple, depending on visitedness) on <a> elements in SVG. This overrides the value of 'color' that the <a> element would otherwise inherit from its parent. Not that this behavior isn't normally visible, since SVG doesn't do anything with the 'color' property most of the time. But it *is* visible if you set fill="currentColor" on the <a> or something inside of it. This behavior makes us give incorrect results on the SVG 1.1F2 test animate-elem-78-t.html (linked in URL field). Look at the bottom-right rect on that test (which jumps right & left) -- when it's in its leftmost position, it's link-colored (blue or purple), whereas everything else in that test is pinkish in that state. It's expected (by the test) to match everything else -- the inherited value of 'color' is the 'pinkish' color, and the <a> has fill="currentColor" in an apparent attempt to use that inherited color-value, but we end up ignoring the inherited value and use a link-color instead. (Luckily the PNG reference case only shows the block in its rightmost position, when it's got the correct color. :)) In Opera & Chromium, the rect is pinkish like everything else, so I think we're alone in our behavior here. I don't think our behavior is particularly useful or sensible, so I'd argue that we should match Opera & Chromium. Reduced testcase coming up in a minute.
Summary: Consider not setting "color" property for <a> elements in SVG → Firefox modifies the "color" property for <a> elements in SVG
Created attachment 450214 [details] testcase 1 See this self-describing testcase. My expected rendering for this testcase would be for all of the lines to be green (except the bottom one, which has no 'fill' value set). Opera & Chromium have that rendering, while Firefox 3.0.18 up through today's mozilla-central nightly show the first two lines as being purple & blue, respectively. (I haven't tested any earlier Firefox versions.)
The patch for bug 570354 didn't fix this then?
> I don't think our behavior is particularly useful or sensible Our behavior is basically the result of the :link and :visited rules in the pref stylesheet. Are you arguing that those should not apply to SVG links? Why not?
No, the patch for bug 570354 has no effect here.
(In reply to comment #3) > Are you arguing that those should not apply to SVG links? > Why not? Yes. Firstly, those rules *aren't particularly useful* for SVG links, since: (a) Most of the time they aren't going to have any visible effect. (unlike HTML, where 'color' actually controls the text color). (b) No other SVG implementation that I know of applies these rules to SVG, so authors can't rely on them. Secondly, since we're the only implementation that applies these rules (AFAIK), they sort of create an interop issue, where we're the odd one out. And thirdly, based on animate-elem-78-t.html, it looks like the SVG spec doesn't think (or doesn't know?) that these rules should be applied. So, based on the above, yes -- I'd argue that the default :link/:visited rules shouldn't apply to SVG links. I don't feel strongly on this point, though, and I'm willing to be convinced otherwise. (though in that case, we'd want to ask www-svg about changing animate-elem-78-t.html)
OK, I think I buy that. Do we still want the moz-any-link rules from ua.css applying to svg:a? What about the :-moz-any-link:active rule from the prefs sheet? For the rest, PresShell::CreatePreferenceStyleSheet will need to add an @namespace rule, the indices for the other rules it inserts will need to be adjusted, and well'll want to change the *|*:link selector to *|*:not(svg|*):link (and similar for :visited) in PresShell::SetPrefLinkRules, right?
http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-styling-css-06-b.html indicates that to get visited and colouring it seems like the author is expected to use the an explicit :visited rule.
You need to log in before you can comment on or make changes to this bug.