Last Comment Bug 268135 - CSS pseudo classes don't work well in SVG (especially on text)
: CSS pseudo classes don't work well in SVG (especially on text)
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
-- normal (vote)
: ---
Assigned To: General SVG Bugs
: Hixie (not reading bugmail)
: Jet Villegas (:jet)
Depends on: 267657 267664
  Show dependency treegraph
Reported: 2004-11-06 10:36 PST by jonathan chetwynd
Modified: 2007-03-16 04:27 PDT (History)
4 users (show)
jwatt: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

should both circles be green? (309 bytes, image/svg+xml)
2004-12-08 04:54 PST, jonathan chetwynd
no flags Details
The circle should be green in this testcase (307 bytes, image/svg+xml)
2005-01-31 10:36 PST, Boris Zbarsky [:bz] (still a bit busy)
no flags Details

Description User image jonathan chetwynd 2004-11-06 10:36:45 PST
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:
Comment 1 User image Hixie (not reading bugmail) 2004-11-06 20:48:23 PST
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.
Comment 2 User image jonathan chetwynd 2004-11-06 23:29:47 PST
<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
Comment 3 User image Justin Wood (:Callek) [away until Feb 27] 2004-11-06 23:44:58 PST
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
Comment 4 User image Justin Wood (:Callek) [away until Feb 27] 2004-11-07 00:36:24 PST
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)

Comment 5 User image Doug Schepers 2004-11-07 00:46:23 PST
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.
Comment 6 User image Hixie (not reading bugmail) 2004-11-07 01:17:19 PST
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 User image jonathan chetwynd 2004-11-07 01:52:06 PST

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 User image Doug Schepers 2004-11-07 02:31:36 PST
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.
Comment 9 User image jonathan chetwynd 2004-11-08 07:21:05 PST
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" />
Comment 10 User image Hixie (not reading bugmail) 2004-12-04 17:45:28 PST
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.
Comment 11 User image jonathan chetwynd 2004-12-08 04:54:24 PST
Created attachment 168209 [details]
should both circles be green?
Comment 12 User image jonathan chetwynd 2004-12-08 04:59:11 PST
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? 
Comment 13 User image Hixie (not reading bugmail) 2004-12-08 06:27:20 PST
According to XLink, xlink:type="" is required, yes. This issue has been raised
with the SVG working group.
Comment 14 User image Boris Zbarsky [:bz] (still a bit busy) 2005-01-31 10:36:42 PST
Created attachment 172984 [details]
The circle should be green in this testcase
Comment 15 User image Hixie (not reading bugmail) 2005-02-01 08:10:29 PST
bz: Why?
Comment 16 User image Jonathan Watt [:jwatt] 2005-02-08 05:26:02 PST
I don't think bz saw that since he wasn't CC'ed. He is now.
Comment 17 User image Boris Zbarsky [:bz] (still a bit busy) 2005-02-08 08:03:41 PST
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.
Comment 18 User image Hixie (not reading bugmail) 2005-02-08 08:52:14 PST
bz: Could you point to the relevant part of the spec? I couldn't find it when I
looked, which is why I asked.
Comment 19 User image Boris Zbarsky [:bz] (still a bit busy) 2005-02-08 09:09:47 PST
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....

Comment 20 User image Hixie (not reading bugmail) 2005-02-08 09:39:12 PST
So then any <svg:a> element matches :link?
Comment 21 User image Boris Zbarsky [:bz] (still a bit busy) 2005-02-08 09:50:47 PST
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 User image Anne (:annevk) 2005-03-22 10:10:34 PST
This seems to work without |xlink:type| now. Not sure if that is desired but it
Comment 23 User image chris 2005-07-21 16:58:57 PDT
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 User image jonathan chetwynd 2006-03-21 01:50:13 PST
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 User image chris 2006-03-21 05:23:33 PST
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>
Comment 26 User image Jonathan Watt [:jwatt] 2007-01-06 08:48:38 PST
My work on bug 267664 will fix this bug as originally reported as well as the two testcases. Marking as a duplicate.

*** This bug has been marked as a duplicate of bug 267664 ***
Comment 27 User image Boris Zbarsky [:bz] (still a bit busy) 2007-01-07 18:52:28 PST
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.
Comment 28 User image jonathan chetwynd 2007-02-01 05:39:57 PST

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...
Comment 29 User image Boris Zbarsky [:bz] (still a bit busy) 2007-02-01 08:44:58 PST
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).
Comment 30 User image jonathan chetwynd 2007-02-01 10:07:38 PST

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
Comment 31 User image Boris Zbarsky [:bz] (still a bit busy) 2007-02-01 10:20:01 PST
> 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 User image jonathan chetwynd 2007-02-01 12:07:32 PST
#31 bz: my error, cheers
Comment 33 User image Hixie (not reading bugmail) 2007-02-28 17:22:48 PST
(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.

Note You need to log in before you can comment on or make changes to this bug.