[svgwg] Clarify effect of invalid values for width & height on <use> elements

AmeliaBR has just created a new issue for 
https://github.com/w3c/svgwg:

== Clarify effect of invalid values for width & height on <use> 
elements ==
The SVG 1.1 specs say, with regards to width + height on `<use>`:

> A negative value is an error (see Error processing). A value of zero
 disables rendering of this element.

Nothing very surprising about that. The same text is used for pretty 
much every other shape that takes `width` and `height` values.

But there are two problems:

- Any other value of `width` and `height` doesn't actually have any 
effect on the rendering of the re-used graphics if the `<use>` 
references anything that isn't `<svg>` or `<symbol>`.

- Current implementations are so inconsistent it's funny.

Demo for testing current browser implementations: 
http://jsbin.com/tixihodafe/1/edit?html,css,output
Or download [a zip of a stand-alone SVG 
version](https://github.com/w3c/svgwg/files/351182/use-width-height-error.zip)




For re-used basic shapes, Chrome, Edge, Safari, and Inkscape happily 
render the shapes regardless of width/height values.  However, Firefox
 follows the spec to the letter and does not render when width & 
height are 0 or negative.

For symbols, I would expect that invalid values of width & height mean
 no rendering.  In Firefox, once again that's true.  In Chrome, Edge 
and Inkscape, the 0 values effectively mean no rendering.  

But negative values are fun.  
Edge and Inkscape apply a negative scaling factor, so that the symbol 
gets reflected to the opposite side of its positioning point.  Chrome 
just ignores the negative value as if it wasn't specified (so that the
 symbol gets width/height  of 100%).  

Finally, Safari ignores _both_ the negative values and the zero 
values, using 100% in either case.

***So...***  my recommendation, and what I'm using in the text I'm 
drafting: 

Define valid values of width & height on `<use>` purely through their 
effect on the rendered content.  If the attributes don't have an 
effect (because the re-used content is a simple shape or a `<g>`), 
don't worry about error checking.  If the re-used content is a 
`<symbol>` or a `<svg>`, *and* it doesn't have its own width/height 
specified, then a value of 0 disables rendering, the same as it would 
if set on the symbol/svg itself.

(PS, I'm already writing it up so that width & height are valid style 
properties on `<symbol>`, as discussed in #142, and so that the 
attributes on the `<use>` element only have an effect if the 
symbol/svg has a computed value of `auto` for the corresponding style 
property, regardless of how that property was set in the CSS cascade.)

***But*** here's the final confusion: 

Because width & height on most elements have been upgraded to 
presentation attributes, and because CSS allows invalid negative 
values to be ignored *at parse time*, if you set a negative 
height/width directly on an `<svg>`, it should be ignored, and the 
auto/100% behavior would apply.

However, width & height on the `<use>` element are *not* currently 
defined as presentation attributes.  They are just regular SVG/XML 
attributes.  So, we can decide: are negative values ignored as if they
 were never set (so initial value applies) or are they an error that 
disables rendering?  I'm leaning towards ignored, so it's consistent 
with the presentation attribute behavior.  Also, if negative values 
aren't going to be a render-blocking error when re-using a `<g>`, they
 really shouldn't be a render-blocking error when re-using an `<svg>`.

If you're keeping score, that means that I'm suggesting that the Blink
 behavior would be correct, & everyone else would need to change 
something.


Please view or discuss this issue at 
https://github.com/w3c/svgwg/issues/193 using your GitHub account

Received on Thursday, 7 July 2016 01:17:28 UTC