1433360 - Using use and fixed-size <symbol> does not resize the element to fit into tiny container <svg> (like in Chrome)

Status: RESOLVED INVALID

(Core :: SVG, defect, P3)

Description

[Karl Dubost💡 :karlcow]

Attachment: viewbox-svg-symbol.html

This is a spin-off of the webcompat issue https://webcompat.com/issues/15076

A reduced test case is available at 
https://codepen.io/webcompat/pen/OzKyXd
In attachment too. 

<svg class="search-icon" width="22">
    <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#search-icon"></use>
</svg>

<svg class="search-icon" viewBox="0 0 40 40" width="22">
    <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#search-icon"></use>
</svg>

<svg>
  <symbol width="40" height="40" viewBox="0 0 40 40" xmlns="http://www.w3.org/2000/svg" id="search-icon"><path d="M26.806 29.012a16.312 16.312 0 0 1-10.427 3.746C7.33 32.758 0 25.425 0 16.378 0 7.334 7.333 0 16.38 0c9.045 0 16.378 7.333 16.378 16.38 0 3.96-1.406 7.593-3.746 10.426L39.547 37.34c.607.608.61 1.59-.004 2.203a1.56 1.56 0 0 1-2.202.004L26.808 29.012zm-10.427.627c7.32 0 13.26-5.94 13.26-13.26 0-7.325-5.94-13.26-13.26-13.26-7.325 0-13.26 5.935-13.26 13.26 0 7.32 5.935 13.26 13.26 13.26z" fill-rule="evenodd"></path></symbol>
</svg>

in Firefox, the second one will have the right size. The first one is cut out.
in Chrome, the two have the expected (by developers) right size.

Comment 1

[Karl Dubost💡 :karlcow]

Adding jwatt and longsonr who will have a better understanding if a bug should be opened against Blink/WebKit or if Gecko should be fixed.

Comment 2

[Karl Dubost💡 :karlcow]

Attachment: svg-rendering

Adding the rendering in Chrome Canary 66.0.3331.0 and Firefox Nightly 60.0a1 (2018-01-24) (64-bit)

Comment 3

[Daniel Holbert [:dholbert]]

Chrome is correct per SVG 1.1. We're correct per SVG 2 (which has an update on this particular point).  So, we're correct.

The specific difference is on what the "width" and "height" attributes should be on the <svg> element that's produced in the <use> "shadow DOM".

The Chrome / SVG 1.1 behavior:
------------------------------
SVG 1.1 says:
> If the ‘use’ element references a ‘symbol’ element:
> [...] If attributes ‘width’ and/or ‘height’ are provided on the ‘use’ element,
> then these attributes will be transferred to the generated ‘svg’. If attributes
> ‘width’ and/or ‘height’ are not specified, the generated ‘svg’ element will use
> values of '100%' for these attributes.
https://www.w3.org/TR/SVG11/struct.html#SymbolElement

Since the testcase has no width or height attribute on <use>, these attributes default to 100% on the cloned <svg>. So it ends up being as wide as the outer <svg> (which happens to be 22px wide in this case).

The Firefos / SVG 2 behavior:
-----------------------------
> The ... width and height geometry properties have the same effect
> as on an ‘svg’ element, when the ‘symbol’ is instantiated by a ‘use’ element.
https://svgwg.org/svg2-draft/struct.html#SymbolElement

In other words, the <symbol>'s width and height attributes are preserved and copied through (if they're provided). There's an additional green "Note" saying that this is new in SVG 2.


So, this is indeed a Chrome bug.

From an authoring perspective -- the correct way for an author to get this to work (without repeating viewBox everywhere) would be to put width="22" on the <use> element itself, rather than (or along with) putting it on the outer SVG element. If your testcase started out...
  <svg class="search-icon" width="22">
      <use width="22" ...
           ^^^^^^^^^^
(note the width here)
...then it would produce the desired result in Firefox, I think.

Comment 4

[Robert Longson [:longsonr]]

Attachment: inline rendering

The <svg> element's viewBox transforms its children to fit into its width and height. Omit it and this doesn't/shouldn't happen.

I'll inline the <use> element and you can now see Chrome and Firefox display identically, what's more it's the same as Firefox's <use> rendering.

Comment 5

[Robert Longson [:longsonr]]

Daniel is right this is new in SVG to try to be consistent with the inline case.

Comment 6

[Daniel Holbert [:dholbert]]

karlcow or longsonr: if you'd be up for filing a blink/webkit bug, that'd great (no worries if you don't get to it though -- I'll file one in the morning if nobody else has yet).

Here's a reduced tetstcase which is better at demonstrating the issue & suitable for use in a bug report -- specifically, it shows that Chrome (and I imagine Safari) ignores a <symbol>'s width and height attributes in their use-clone:
https://jsfiddle.net/ucr60v1a/

Comment 7

[Daniel Holbert [:dholbert]]

Filed bugs:
 https://bugs.chromium.org/p/chromium/issues/detail?id=806289
 https://bugs.webkit.org/show_bug.cgi?id=182172
 https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/15641029/

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #3)
> If your testcase started out...
>   <svg class="search-icon" width="22">
>       <use width="22" ...
>            ^^^^^^^^^^
> (note the width here)
> ...then it would produce the desired result in Firefox, I think.

FWIW, authors could also have:
   <svg class="search-icon" width="22">
       <use width="100%" ...
to avoid having to duplicate the magic-number "22" in multiple places.  This is a way to explicitly ask for the older SVG 1.1 (implemented-in-Chrome) behavior.