1003185 - CSS :hover pseudoclass can target content in a <use> subtree

Status: RESOLVED DUPLICATE of bug 265894

(Core :: SVG, defect)

Description

[Dirk Schulze]

Attachment: test case

CSS selectors on <use> element should not target the referenced element. The element within the instance tree should be a "copy" of the referenced element.

The rectangle in the demo should not turn rect on mouse hover.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase with the referenced element visible

As this testcase shows, the :hover on the <use>'d copy does *not* trigger the referenced element -- it only triggers style changes in the <use> clone.

So the bug (if there is one) is that the <use> clone is responding to selectors on "#rect" (the ID of its target). Does that violate some spec? That kind of seems desirable to me.

Comment 2

[Dirk Schulze]

Are you sure that this just happens with ID selectors? Did you try it with class selectors? Or other kind of selectors?

Comment 3

[Daniel Holbert [:dholbert]]

I expect it happens with other selectors too.  (which I think is normal)  We clone the element, including its attributes.

Can you elaborate on what you think the bug is here?

Comment 4

[Daniel Holbert [:dholbert]]

(To be clear, my adjustment of the bug summary was simply clarifying what is actually happening in your initial testcase. The original summary was incorrect.)

Comment 5

[Dirk Schulze]

Well, Firefox allows the user to traverse the instance tree with CSS. We have that with JS and this is going to be removed in SVG2 ... requested by Firefox and Blink. So it is kind of interesting that it is supported with CSS. However, the spec does not take CSS selectors into account at all. I would say it is underspecified.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase with manually-duplicated <rect> element (with same ID)

Here's a testcase like the previous one I attached, with the <rect> hand-duplicated instead of using <use>.

We behave the same on this one (as I'd expect us to).

Chrome (dev channel) also matches Firefox on this one. However, it doesn't respond to hover events on the <use> clone, in the previous two testcases here.  That seems like a Chrome bug to me; I'd expect the previous testcase and this testcase that I'm attaching now to behave identically.  (Though I might be missing something).

Comment 7

[Daniel Holbert [:dholbert]]

(Sorry, comment 6 passed Comment 5 in midair.)

That is interesting. Personally, I'd expect CSS selectors to work, or else <use>-cloning doesn't really seem like it'd be an effective clone (visually).

Comment 8

[Daniel Holbert [:dholbert]]

SVG11 says:
 # A ‘use’ element has the same visual effect as if the ‘use’
 # element were replaced by the following generated content:
 # [...]
 # In the generated content, the ‘use’ will be replaced by ‘g’,
 # [...]. The referenced object and its contents are deep-cloned
 # into the generated tree.
 #
 # [...]the copy (deep clone) of the referenced resource carries
 # along with it the "cascaded" property values resulting from
 # the CSS cascade on the original (i.e., referenced) elements.
http://www.w3.org/TR/SVG11/struct.html#UseElement

SVG 1.2 has a similar section (search for "CSS cascade on the original"):
https://svgwg.org/svg2-draft/struct.html#UseElement

So I don't think this is underspecified, and I think Firefox's behavior here matches the spec. Feel free to reopen if I'm missing something, though.

Comment 9

[Daniel Holbert [:dholbert]]

Oh, sorry, I forgot about the :hover part. I agree that what we do for that case doesn't seem to match the spec (and the spec doesn't mention pseudo-classes and is perhaps underspecified on what should happen there).

Comment 10

[Daniel Holbert [:dholbert]]

(Updating summary to be about comment 9, since that's the only thing about the testcases here that might be potentially non-spec-conforming IIUC.)

Cameron, do you know what the spec wants to have happen here? Reading the spec literally, it sounds like "#rect:hover" should affect the rendering of the <use> subtree when the *original* element (#rect) is hovered, since that affects <specquote>the "cascaded" property values on the original ... elements</specquote>.

But I'm not sure that's a particularly useful (ha!) behavior.

Comment 11

[Philip Rogers]

The SVG1.x spec predates shadow dom so I'm not sure it's useful to follow it here (SVG2 has a todo to clean the use section up).

I don't think :hover should change the used elements, only the primary one. The CSS scoping spec has ::shadow which can be used to poke into the used elements.

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Philip Rogers from comment #11)
> I don't think :hover should change the used elements, only the primary one.

Should this be true of other (more persistent) pseudoclasses like :visited & :link, too?

Comment 13

[Philip Rogers]

Daniel,
That's a great question. I think :visited and :link should work because they are page level concepts that apply to the shadow tree too, but I'm just flying by the seat of my pants here. I've cc'ed Tab and Daniel as well in case they know more.

Comment 14

[Robert Longson [:longsonr]]

This is just bug 265894 (again).

Comment 15

[Daniel Holbert [:dholbert]]

ah right, bug 265894 comment 5's has a spec-quote about selectors not applying to the cloned dom tree, which seems to mean :hover shouldn't apply.

So, yup -- it looks like:
 (a) Gecko honoring :hover inside of <use> runs against the spec
 (b) this is covered by bug 265894

Duping.