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

Status: RESOLVED DUPLICATE of bug 265894

(Core :: Layout, defect)

Description

[Artur]

Attachment: 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.

Comment 1

[Robert Longson [:longsonr]]

Can you upload a minimal testcase please?

Comment 2

[Artur]

Testcase:
http://codepen.io/artursopelnik/pen/qZJyOZ

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: reporter's testcase

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: slightly simpler testcase

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is a much less general problem than bug 265894.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 10

[Robert Longson [:longsonr]]

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

[Robert Longson [:longsonr]]

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’.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

OK, so a fix for bug 265894 would fix this ... but it's also probably possible to fix this without fixing bug 265894.

Comment 13

[Amelia Bellamy-Royds]

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

[u459114]

Pathchs in bug 265894 fix this bug as well