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

RESOLVED DUPLICATE of bug 265894

Status

()

defect
RESOLVED DUPLICATE of bug 265894
3 years ago
2 years ago

People

(Reporter: artur.sopelnik93, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

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

3 years ago
Component: Untriaged → Layout
Product: Firefox → Core
Can you upload a minimal testcase please?
Flags: needinfo?(artur.sopelnik93)

Updated

3 years ago
Keywords: testcase-wanted
(Reporter)

Comment 2

3 years ago
Testcase:
http://codepen.io/artursopelnik/pen/qZJyOZ
Summary: CSS Bug: SVG - Fill priority buging → incorrect CSS cascading with "svg" selector and <svg:use> pointing to <svg:symbol>
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years 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
Summary: incorrect CSS cascading with "svg" selector and <svg:use> pointing to <svg:symbol> → svg:symbol element incorectly matches the element selector "svg"
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
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’.
OK, so a fix for bug 265894 would fix this ... but it's also probably possible to fix this without fixing bug 265894.
Flags: needinfo?(artur.sopelnik93)
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

Comment 14

2 years ago
Pathchs in bug 265894 fix this bug as well
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 265894
You need to log in before you can comment on or make changes to this bug.