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




3 years ago
3 years ago


(Reporter: Dirk Schulze, Unassigned)



Firefox Tracking Flags

(Not tracked)




(3 attachments)



3 years ago
Created attachment 8414481 [details]
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.
Created attachment 8414537 [details]
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.
Summary: CSS selector on <use> selects referenced element outside the instance tree → CSS ID selector can target a <use> clone of the element with that ID

Comment 2

3 years ago
Are you sure that this just happens with ID selectors? Did you try it with class selectors? Or other kind of selectors?
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?
(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

3 years ago
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.
Created attachment 8414604 [details]
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).
(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).
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.

SVG 1.2 has a similar section (search for "CSS cascade on the original"):

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.
Last Resolved: 3 years ago
Resolution: --- → INVALID
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).
Resolution: INVALID → ---
(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.
Flags: needinfo?(cam)
Summary: CSS ID selector can target a <use> clone of the element with that ID → CSS :hover pseudoclass can target content in a <use> subtree
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk

Comment 11

3 years ago
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.
(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?
Summary: CSS :hover pseudoclass can target content in a <use> subtree → CSS :hover pseudoclass can target content in a <use> subtree (which the spec might (?) eventually disallow)

Comment 13

3 years ago
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

3 years ago
This is just bug 265894 (again).
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

Last Resolved: 3 years ago3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 265894
Flags: needinfo?(cam)
Summary: CSS :hover pseudoclass can target content in a <use> subtree (which the spec might (?) eventually disallow) → CSS :hover pseudoclass can target content in a <use> subtree
You need to log in before you can comment on or make changes to this bug.