New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Compat



Sign in to add a comment
link

Issue 806289: Blink incorrectly disregards "width" and "height" attributes on SVG <symbol> element

Reported by dholb...@gmail.com, Jan 26 2018 Project Member

Issue description

Chrome Version: (copy from chrome://version)
OS: (e.g. Win7, OSX 10.9.5, etc...)

What steps will reproduce the problem?
(1) Visit https://jsfiddle.net/mca17zyk/

What is the expected result?
 Small purple rectangle and square. (Each 20px tall.)

What happens instead?
 The square is huge.

Please use labels and text to provide additional information.
Per SVG2, the square (really, the <use>-generated <svg> element that gets filled with a 100%-sized purple rect) should take its width/height attributes from the <symbol> element that it cloned.  That <symbol> element has width=20 height=20, so its <svg> clone should as well.

The rectangle (the first purple thing in the testcase) works correctly because it explicitly overrides the width and height by setting those attributes on the use element itself. But if they're unset on <use>, then we should use the ones from the <symbol>.

Blink's behavior here would be correct per SVG 1.1:
https://www.w3.org/TR/SVG11/struct.html#SymbolElement

...but it's incorrect per SVG 2:
https://svgwg.org/svg2-draft/struct.html#SymbolElement

The specific commit in the SVG 2 spec repo is here:
https://github.com/w3c/svgwg/commit/ca0f76bf83825505e17d8b69ead26b01d3bc75dc#diff-6e6915b15fe92e713aecbcc7786991f6R449
That commit added x,y,width,height to <symbol>, and added prose saying they should have the same effect on clones-of-<symbol> as they have on an <svg> element.


Firefox gives "Expected Results" here.
 

Comment 1 by dholb...@gmail.com, Jan 26 2018

Chrome Version: Google Chrome	65.0.3325.18 (Official Build) dev (64-bit)
My OS: Ubuntu 17.10

Comment 2 by schenney@chromium.org, Jan 26 2018

Labels: -Pri-3 Pri-2
Status: Available (was: Untriaged)

Comment 3 by dholb...@gmail.com, Jan 26 2018

I filed WebKit/Edge bugs as well, for the record:
 https://bugs.webkit.org/show_bug.cgi?id=182172
 https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/15641029/

(I'm also attaching the testcase just in case the jsfiddle disappears.)
test.html
880 bytes View Download

Comment 4 by schenney@chromium.org, Jan 26 2018

Thanks very much.

Comment 5 by f...@opera.com, Jan 30 2018

Labels: -Type-Bug Type-Compat
So there's a potential compat issue hiding here (I gathered from reading the external correspondence...) Fairly limited but still.

Comment 6 by dholb...@gmail.com, Jan 30 2018

Yeah, this bug report originated in a webcompat.com issue (where the author was originally depending on the Chrome behavior here & hence Firefox was getting a broken rendering -- but they've since fixed their site to not depend on any particular behavior):  https://webcompat.com/issues/15076

Comment 7 by f...@opera.com, Feb 1 2018

Labels: Hotlist-Interop

Comment 8 by sheriffbot@chromium.org, Feb 1

Project Member
Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 9 by f...@opera.com, Feb 1

Status: Available (was: Untriaged)

Sign in to add a comment