CSS precedence incorrect for symbol-based SVG

RESOLVED DUPLICATE of bug 265894

Status

()

Core
SVG
--
major
RESOLVED DUPLICATE of bug 265894
a year ago
10 months ago

People

(Reporter: silverwind, Unassigned)

Tracking

50 Branch
Points:
---

Firefox Tracking Flags

(firefox48 affected, firefox49 affected, firefox50 affected)

Details

Attachments

(1 attachment)

(Reporter)

Description

a year ago
Created attachment 8785497 [details]
symbol-precedence.html

See attached example. Both squares are affected by these CSS rules:

    svg {fill: red}
    .square {fill: blue}

According to CSS precedence rules, the class selector should win, so both squares should be blue. The first square, which is using a symbol through `xlink:href` is incorrectly showing a red `fill` property.

Interestingly, the DevTools Inspector correctly shows the blue color as active style, but it is rendered differently.
(Reporter)

Updated

a year ago
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: affected → ---
Version: Trunk → 50 Branch
(Reporter)

Comment 1

a year ago
Noticed that when appending a extra `svg` selector after the class, like

    .square svg {fill: blue}

it works as expected. Maybe <use> is adding a invisibe wrapper <svg> of some sort?
Component: CSS Parsing and Computation → SVG

Comment 2

a year ago
It is adding an svg wrapper and what's more it is supposed to.

https://www.w3.org/TR/SVG/struct.html#UseElement

The referenced ‘symbol’ and its contents are deep-cloned into the generated tree, with the exception that the ‘symbol’ is replaced by an ‘svg’.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
(Reporter)

Comment 3

a year ago
That raises a few questions:

1) The spec says "the graphical contents of that element is included/drawn at that given point". The content of #symbol in my example is just the <path>, not the wrapping <svg>.

2) This is a web compatibilty issue. Chromium and Safari both do not clone the <svg> parent. Are you saying they are wrong?
Flags: needinfo?(longsonr)

Comment 4

a year ago
1. See comment 2. The <symbol> element becomes an <svg> element.

2. Yes
Flags: needinfo?(longsonr)
(Reporter)

Comment 5

a year ago
Well, looks like this is a case of a ambiguous spec. I'll workaround through

    svg > use > svg { all: inherit }
(In reply to silverwind from comment #3)
> 2) This is a web compatibilty issue. Chromium and Safari both do not clone
> the <svg> parent. Are you saying they are wrong?

Do we know if there are bugs filed against Blink/WebKit for this?
(Reporter)

Comment 7

11 months ago
Filed https://bugs.chromium.org/p/chromium/issues/detail?id=648046. I have no experience filing WebKit bugs, if someone could, please do!
(Reporter)

Comment 8

11 months ago
Turns out this is actually a dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=265894. The `svg` CSS rule should not actually be able to reach into the Shadow DOM, so Blink and Webkit are behaving correctly.
(Reporter)

Updated

11 months ago
Resolution: INVALID → DUPLICATE
Duplicate of bug: 265894
You need to log in before you can comment on or make changes to this bug.