nikosandronikos
commented
8 years ago 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
, they really shouldn't be a render-blocking error when re-using an
Attributes are already defined to use the initial value if they fail to parse (by grammar or by prose).
From SVG 2:
The Initial value column gives the initial value for the attribute. When an attribute fails to parse according to the specified CSS Value Definition Syntax, ABNF or EBNF grammar, or if parsing according to the URL Standard or by the prose describing how to parse the attribute indicates failure, the attribute is assumed to have been specified as the given initial value.
AmeliaBR
The SVG 1.1 specs say, with regards to width + height on
<use>:Nothing very surprising about that. The same text is used for pretty much every other shape that takes
widthandheightvalues.But there are two problems:
widthandheightdoesn't actually have any effect on the rendering of the re-used graphics if the<use>references anything that isn't<svg>or<symbol>.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
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 ofautofor 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.