Closed Bug 1298557 Opened 8 years ago Closed 8 years ago

CSS precedence incorrect for symbol-based SVG

Categories

(Core :: SVG, defect)

50 Branch
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 265894
Tracking Status
firefox48 --- affected
firefox49 --- affected
firefox50 --- affected

People

(Reporter: me, Unassigned)

Details

Attachments

(1 file)

Attached file 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.
Version: Trunk → 50 Branch
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
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
Closed: 8 years ago
Resolution: --- → INVALID
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)
1. See comment 2. The <symbol> element becomes an <svg> element.

2. Yes
Flags: needinfo?(longsonr)
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?
Filed https://bugs.chromium.org/p/chromium/issues/detail?id=648046. I have no experience filing WebKit bugs, if someone could, please do!
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.
Resolution: INVALID → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: