The default bug view has changed. See this FAQ.

CSS pseudo classes don't work well in SVG (especially on text)




13 years ago
10 years ago


(Reporter: jonathan chetwynd, Unassigned)


Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)



(2 attachments)



13 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1

In an SVG user agent that supports CSS style sheets, the following facilities
from [CSS2] must be supported:
CSS2's  dynamic pseudo-classes :hover, :active and :focus and pseudo-classes 
:first-child, :visited, :link and :lang. 

Reproducible: Always
Steps to Reproduce:

my apologies, but I am not clear as to how the working group intended pseudo
classes to be implemented in a standardised way.

I have raised this with the SVGWG:
Mozilla's SVG supports most of the pseudo-classes from CSS3 Selectors, as well
as all the above..

If you have a testcase showing a case where it doesn't work, please reopen this
bug and attach the testcase.
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME

Comment 2

13 years ago
<svg xmlns=""
<style type="text/css"><![CDATA[
rect { stroke:black; stroke-width:10}
a :visited rect { stroke:red;  }
<a xlink:href=""><rect x="100" y="100"
width="100" height="50" fill="grey"/></a>

from something similar suggested by Jim here:

Ian, it might be helpful if you supplied a working example :-)
as I say nothing works for me in batik, asv3.1 or mozSVG
Resolution: WORKSFORME → ---

Comment 3

13 years ago
your syntax of CSS on that is wrong

a:visited rect { foo: bar; }

is what you want, |a :visited rect| actually has a descendant selector from the
'a' element to a :visited class (if it were legal) would match the following:

<svg xmlns=""
<a><a xlink:href="SomeplaceIBeen"><rect x="100" y="100"
width="100" height="50" fill="grey"/></a></a>

re-marking RESO/WFM  please reopen if there are further problems to Ian's statement
Last Resolved: 13 years ago13 years ago
Resolution: --- → WORKSFORME

Comment 4

13 years ago
erm reopening after talk on moznet's #svg channel regarding this, I cannot prove
one way or the other on this bug, seems I have a few blocking bugs in regards to
xlink and rendering of the svg |a| element...(in my nightly)

Resolution: WORKSFORME → ---

Comment 5

13 years ago
Please see various testcases at:

In these, not only are the links not colored correctly, but they do not render
at all. 

I think those tests should prove that it's a pervasive issue, applicable to both
shapes and text, with 'a' as a child or a parent.

Additionally, I think that it's not very rigorous to make claims about Mozilla's
SVG CSS support without actually making tests on it.
I did test it, it works fine:

Note that in your tests you don't include the xlink:type="" attribute which is
required by XLink. (Mozilla doesn't read external DTDs so it doesn't see the
#FIXED attribute declarations.)

It isn't entirely clear to me from reading the SVG spec whether or not Mozilla
is supposed to assume xlink:type="simple" on <svg:a> elements even if it is absent.

Comment 7

13 years ago

appreciate your code

however I tested with the most recent mac build and a recent pc build, in both
cases maroon is never displayed.

I don't know why this should be.

however hover 
works in both cheers :-)

Comment 8

13 years ago
My apologies, Ian. I see that it does work if you include xlink:type='simple',
as you say.

However, it seems clear to me from the SVG1.1 Spec that 'simple' should be
assumed for <svg:a />:
"In SVG, only simple links are available."

Additionally, there are no cases of xlink:type being explicitly defined in any
of the SVG testsuite examples or in the illustrative examples that use <a>. Its
value is indicated as '#FIXED'. 

Nonetheless, I can see why you view it as open to interpretation... that's one
of the problems with DTDs.

Thanks for following up on it so promptly. However, I think that this should
stay as a bug until the requirement for including xlink:type is removed. I might
be wrong here... SVG doesn't require it, but you say XLink does, so it's up to a
judgement call. That being said, it seems extraneous to include it, and existing
content will be broken if it's required.


13 years ago
Summary: are pseudo classes implemented? → xlink:type="simple" was: are pseudo classes implemented?

Comment 9

13 years ago
implementation needs thorough testing. see:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<svg xmlns="" height="200" width="650">

 <desc>Hover over the second blue circle. it should get a stable red stroke,
instead it oscillates as mouse moves.</desc>
  <desc>Hover over the third blue circle. a rect with red stroke appears, but is
missing segment in mac version</desc>
 <style type="text/css" id="css"><![CDATA[
circle { fill: blue; }
circle:hover + .border {visibility: visible;}

 <circle cx="100" cy="100" r="90"/>
 <circle cx="300" cy="100" r="90" />

  <circle cx="300" cy="100" r="90" class="border" fill="none" stroke-width="10"
stroke="red" visibility="hidden"/>
  <circle cx="500" cy="100" r="90" id="mcircle" />
  <rect x="500" y="60" rx="5" ry="5" width="130" height="80" fill="none"
stroke="red" stroke-width="10" visibility="hidden" class="border" />
Depends on: 267657
This bug needs:
 * a single clear testcase, attached to the bug using the attachment feature
 * clear steps to reproduce using that testcase
 * an explanation of what happens that is considered the bug
 * an explanation of what exactly should happen instead for the bug to be fixed
 * clear quotes from the spec explaining why

At the moment it has none of these.
Whiteboard: INVALID? (unclear what the bug is)

Comment 11

13 years ago
Created attachment 168209 [details]
should both circles be green?


13 years ago
Attachment #168209 - Attachment mime type: text/html → image/svg+xml

Comment 12

13 years ago
The attachment demonstrates that a:visited css styling only works where
xlink:type="simple" is stated.

Is it a requirement that - xlink:type="simple" - be included for each link?
this is verbose and will break those pages which are already published and don't.

is 'simple' the default? 
According to XLink, xlink:type="" is required, yes. This issue has been raised
with the SVG working group.
Created attachment 172984 [details]
The circle should be green in this testcase
bz: Why?
I don't think bz saw that since he wasn't CC'ed. He is now.
Because :link should match SVG <a> nodes with an xlink:href, per the SVG spec?

And yes, I'm aware that this may be a bogosity in the spec; the testcase was
just a useful testcase for this bug as reported, since the original testcase
attached here was way too confusing for me to follow and I needed something
against which to test my proposed changes for bug 267657.
bz: Could you point to the relevant part of the spec? I couldn't find it when I
looked, which is why I asked.
CSS2.1 says [1]:

  The document language determines which elements are hyperlink source anchors.

SVG 1.1 says [2]:

  SVG provides an 'a' element, analogous to HTML's 'a' element, to indicate
  links (also known as hyperlinks or Web links).

Sounds like they're even using the same terminology ("hyperlink"), and the
analogy with HTML (which is explicitly given by an example in the CSS
specification) makes the case even stronger.

Now I admit the SVG spec could explicitly say that :link matches.  But as it is,
it says these suckers are hyperlinks and the CSS spec says that :link matches
"hyperlinks" as defined by the document language.

If you'd prefer, I can raise the issue with the SVG WG to explicitly define what
:link and :visited match in SVG....

So then any <svg:a> element matches :link?
Dunno.  Per criteria like that, it's not clear what should match :link in HTML
either -- it's not defined anywhere that I can see (note that the CSS definition
doesn't make much sense, since it's possible to have an HTML <a href=""> that is
not a link if the href string is such that a URI cannot be constructed from it).

It seems that there are some fundamental assumptions being made about what a
"link" is in both CSS and SVG; it would be good to make these assumptions more

Comment 22

12 years ago
This seems to work without |xlink:type| now. Not sure if that is desired but it

Comment 23

12 years ago
bz, I agree that it couldn't get much clearer, that the a element is for
hyperlinks and thus, is a link, and thus, :link and :visited apply. However, I
am happy to add words to the spec saying so explicitly if this really was
unclear. (Its actually more unclear for :hover, where some implementors seem to
think it only applies to links).

ih, yes, XLink 1.0 does indeed require xlink:type="simple" and yes, a #FIXED in
the DTD really does men it can't take any other value and yes, XML does not
require fetching the external DTD subset for non-validating parsers. This is
being fixed in XLink 1.1, which explicitly states that unless a link is
explicitly stated to be some other type, its of type simple. jc, jw, ds, that
should address the verbosity and existing content concerns.

I have also added pseudoclass tests to the SVG 1.1 testsuite.

Comment 24

11 years ago
re #23

Chris, where are the pseudoclass tests in the SVG 1.1 testsuite?

I checked through today but couldn't find them, 


Comment 25

11 years ago
The testsuite has not been republished since I made comment #23 (mainly because we have been dealing with the flood of lc comments). So, you won't find the pseudoclass test in the published test suite, until we republish.

Here is the descriptive prose for the test:

                Tests the dynamic pseudoclasses :link, :visited, :active, :hover
 and :focus. For the test to work, you must have previously visited ../linkingTo
c-t.svg which you can do by traversing the "Visited" link, going back to this te
st file, and reloading if necessary.</Paragraph>
             <Paragraph>The link marked "visited" should now be purple, while th
e "Unvisited" link is blue.</Paragraph>
             <Paragraph>Hover the pointing device over the "Hover me" and then,
over the "And me, too!". As each of the two text strings text is hovered, it sho
uld turn a dark orange color while the other string should be black. If you do n
ot have a pointing device, or if it provides pick but not hover (eg a stylus on
a PDA) skip the hover portion of the test.</Paragraph>
<Paragraph>Finally, select some of the "Select me" text. As you do so, the whole
 "Select me" text should turn pale green. If the device you are using does not s
upport text selection, eg a mobile phone, you may skip this part of the test.</Paragraph>

and here is the svg of the test, minus administrative material like the test number, cvs version, owner, reviewer, etc

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1 Basic//EN" "
<svg xmlns="" xmlns:xlink="
k" version="1.1" baseProfile="basic" id="svg-root" width="100%" height="100%" vi
ewBox="0 0 480 360">
  <title id="test-title">$RCSfile: styling-css-06-b.svg,v $</title>
  <g id="test-body-content">
    <style type="text/css">
    :link {fill: #33F}
    :visited {fill: rgb(138, 43, 226)}
    :active {text-decoration: underline; fill: red }
    :hover {fill: rgb(255, 140, 0) }
    :focus { fill: rgb( 0, 255, 127) }
    <g font-size="30">
      <text x="50" y="100" id="act"><a xlink:href="../linkingToc-t.svg">Visited</a></text>
      <text x="250" y="100"><a xlink:href="">Unvisited</a></text>
      <text x="50" y="170"><a xlink:href="../linkingToc-t.svg">Hover me</a></text>
      <text x="250" y="170">And me, too!</text>
      <text x="150" y="240" id="sel">Select me</text>
My work on bug 267664 will fix this bug as originally reported as well as the two testcases. Marking as a duplicate.
Last Resolved: 13 years ago10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 267664
For what it's worth, it's better to treat that relationship via dependencies...

In any case, we still need these testcases added to the test suite.
Flags: in-testsuite-

Comment 28

10 years ago

please compare with recent Opera

strange but for whatever reason 2 lines of text are missing.

similarly Chris' example #25 also is missing text.

apologies if this should be a separate bug, but I can't close, when the examples provided don't work...
Resolution: DUPLICATE → ---
You're seeing bug 330059.  Please do not reopen bugs that have passing testcases unless you actually have a testcase _for_that_bug_ that fails.  In this case you could have trivially checked that your testcase is not related (e.g. by removing the ":visited" in it and noticing that nothing changes).
Last Resolved: 10 years ago10 years ago
Depends on: 267664
Flags: in-testsuite- → in-testsuite?
Resolution: --- → FIXED

Comment 30

10 years ago

Boris, it's not clear that this issue is related to bug 330059.
some text in <a> is rendered other is not.

this bug may have passed your test, however at least three others are listed which currently fail
> some text in <a> is rendered other is not.

No.  All the text in <a> inside <text> is not rendered.  At least over here.

Which three others?

Comment 32

10 years ago
#31 bz: my error, cheers
(In reply to comment #21)
> Dunno.  Per criteria like that, it's not clear what should 
> match :link in HTML either -- it's not defined anywhere that I 
> can see (note that the CSS definition doesn't make much sense, 
> since it's possible to have an HTML <a href=""> that is not a 
> link if the href string is such that a URI cannot be 
> constructed from it).

HTML5 now clarifies exactly what is a hyperlink and what isn't.
Checked in reftests:
Flags: in-testsuite? → in-testsuite+
OS: Mac OS X → All
Hardware: Macintosh → All
Summary: xlink:type="simple" was: are pseudo classes implemented? → CSS pseudo classes don't work well in SVG (especially on text)
Whiteboard: INVALID? (unclear what the bug is)
You need to log in before you can comment on or make changes to this bug.