Edge incorrectly disregards "width" and "height" attributes on SVG <symbol> element

Issue #15641029 • Assigned to Bogdan B.


Daniel H.
Jan 26, 2018
This issue is public.
Found in
  • Microsoft Edge
  • Chrome
  • Safari
Reported by 1 person

Sign in to watch or report this issue.

Steps to reproduce

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

Edge’s behavior here would be correct per SVG 1.1:

…but it’s incorrect per SVG 2:

The specific commit in the SVG 2 spec repo is here:
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. Safari, Chrome, and Edge (version 16) give “Actual Results” (i.e. they haven’t updated to align with this bit of SVG2 yet).
Chrome/Blink bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=806289
Safari/WebKit bug report: https://bugs.webkit.org/show_bug.cgi?id=182172


1 attachment

Comments and activity

  • Thanks for your report. It sounds accurate, but this doesn’t seem a high-priority issue unfortunately.

  • That’s fair. I’m just reporting as due-dilligence – since we got a bug report[1] about Firefox’s (correct) behavior (which seemed broken to the developer likely just because they’d developed/tested in another browser), and in investigating that issue, I realized we’re the only ones to implement this particular bit of spec text so far.

    I don’t know if this causing webcompat issues beyond that one case (which I believe the web developer has now addressed on their end).

    [1] https://webcompat.com/issues/15076

  • Microsoft Edge Team

    Changed Assigned To to “James M.”

    Changed Assigned To to “Bogdan B.”

    Changed Status to “Won’t fix”

    Changed Status from “Won’t fix”

  • Reactivating auto-resolved valid bugs reported by web dev community. Those were not expected to be resolved. We apologize for any inconvenience!

  • Microsoft Edge Team

    Changed Assigned To to “Bogdan B.”

You need to sign in to your Microsoft account to add a comment.

Sign in