svg:symbol element incorectly matches the element selector "svg"

RESOLVED DUPLICATE of bug 265894

Status

()

Core
Layout
RESOLVED DUPLICATE of bug 265894
a year ago
2 months ago

People

(Reporter: Artur, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

a year ago
Created attachment 8746472 [details]
css-svg-fill-bug.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.87 Safari/537.36

Steps to reproduce:

For example:
Line 1: svg.icon {fill: red;}
Line 2: .example-class, svg.icon2 {fill: blue;}



Actual results:

Line 1 wins, but that is not correct.


Expected results:

Line 2 must have the priority.

Updated

a year ago
Component: Untriaged → Layout
Product: Firefox → Core

Comment 1

a year ago
Can you upload a minimal testcase please?
Flags: needinfo?(artur.sopelnik93)

Updated

a year ago
Keywords: testcase-wanted
(Reporter)

Comment 2

a year ago
Testcase:
http://codepen.io/artursopelnik/pen/qZJyOZ
Created attachment 8747129 [details]
reporter's testcase
Summary: CSS Bug: SVG - Fill priority buging → incorrect CSS cascading with "svg" selector and <svg:use> pointing to <svg:symbol>
Created attachment 8747136 [details]
slightly simpler testcase
Looking at the frame tree, we have:

>              SVGOuterSVG(svg)(2)@3d50ab8 {0,0,18000,9000} [state=0000060800110010] [content=3d6ab80] [sc=3d50708]<
>                SVGOuterSVGAnonChild(svg)(2)@3d50c18 {0,0,0,0} vis-overflow=0,0,18000,9000 scr-overflow=0,0,18000,9000 [state=0000180800010000] [content=3d6ab80] [sc=3d50b70:-moz-svg-outer-svg-anon-child]<
>                  SVGUse(use)(0)@3d50fb0 {0,0,0,0} vis-overflow=0,0,18000,9000 scr-overflow=0,0,18000,9000 [state=0000080800010000] [content=3d669a0] [sc=3d50cf0^3d50708^3d4c2e0^3d4bd70]<
>                    SVGInnerSVG(svg)(-1)@3d51440 {0,0,18000,9000} [state=0000080800010008] [content=3d52860] [sc=3d51100]<
>                      SVGPathGeometry(path)(0)@3d51570 {2629,1251,7703,6258} vis-overflow=2414,34,7915,6430 scr-overflow=2414,34,7915,6430 [state=0000084800010000] transformed [content=3d52740] [sc=3d514c8]
>                    >
>                  >
>                >
>              >

Note that the SVGInnerSVG frame points to a content node that is neither of the svg elements in the content tree (3d6ab80 is the class="icon", 3d4d010 is the class="container".  I'm guessing this content node is incorrectly matching selectors when it really shouldn't be.

Updated

a year ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 265894
I think what's going on is this.  When an svg:use points to a symbol, this code:
https://hg.mozilla.org/mozilla-central/file/8c3fd523d75b/dom/svg/SVGUseElement.cpp#l282
replaces the symbol element with an svg element.  The problem is that this process is not described by the specification (at least not as far as I can tell), and thus it's making an element that we allow to match selectors.

This is probably fixable in a reasonably straightforward way in nsSVGUseFrame::CreateAnonymousContent
https://hg.mozilla.org/mozilla-central/file/8c3fd523d75b/layout/svg/nsSVGUseFrame.cpp#l233
where we could (if we can detect when this has happened; that's the tricky part) append to aElements a ContentInfo struct whose mStyleContext is an anonymous box style context that doesn't match selectors in the document.  It would likely need the same styles in ua.css that the svg element has.
This is a much less general problem than bug 265894.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
On the flip side, bug 1223645 reports the opposite problem, which is that the symbol element does *not* match the "symbol" selector.  That means my proposed fix above probably isn't really the right thing.
Blocks: 1223645
Blocks: 237020
Summary: incorrect CSS cascading with "svg" selector and <svg:use> pointing to <svg:symbol> → svg:symbol element incorectly matches the element selector "svg"

Comment 10

a year ago
It does say in the spec that use is replaced by a svg element in some circumstances: https://www.w3.org/TR/SVG/struct.html#UseElement

Comment 11

a year ago
i.e. The referenced ‘symbol’ and its contents are deep-cloned into the generated tree, with the exception that the ‘symbol’ is replaced by an ‘svg’. This generated ‘svg’ will always have explicit values for attributes ‘width’ and ‘height’.
Depends on: 265894
OK, so a fix for bug 265894 would fix this ... but it's also probably possible to fix this without fixing bug 265894.

Updated

a year ago
Flags: needinfo?(artur.sopelnik93)
Keywords: testcase-wanted

Comment 13

11 months ago
FYI to anyone working on this (or thinking about starting):

In SVG 2, we've re-defined the rules on whether or not <symbol> elements should render in terms of user agent stylesheet:

symbol {
  display: none !important;
}
:host(use) > symbol {
  display: inline !important;
}

The :host(selector) pseudoclass is from CSS Scoping (https://drafts.csswg.org/css-scoping/) and matches the ShadowRoot node if the shadow root's host element matches the selector in the parentheses.

Hopefully, this should make it easier to implement SVG symbol clones as actual `<symbol>` elements, that render just like <svg> elements, not as elements that match the local name "svg".  Note that we've made other changes to symbol to allow x,y,width,height just like on an <svg>; Firefox already supports these through the general attribute cloning rules, but some other browsers didn't.

https://www.w3.org/TR/SVG2/struct.html#SymbolElement

In addition, other changes to use element style matching have been made, to make SVG line up with the rest of Shadow DOM.  I left a note about that on bug 265894.

PS:  If anything in the spec is unclear or impossible to implement, please raise a bug on the SVG Working Group's GitHub repo: https://github.com/w3c/svgwg/issues
Pathchs in bug 265894 fix this bug as well
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago2 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 265894
You need to log in before you can comment on or make changes to this bug.