Re: [svgwg] stroke-miterlimit: invalid value behavior?

@fsoder, I actually made a test & that's not quite what's happening.
https://codepen.io/AmeliaBR/pen/dqQqyQ?editors=0100

So to describe what you're seeing: The pink polyline is being animated (with SMIL, or a JS polyfill if SMIL isn't supported) to change the miter distance, from 1 to 10+. The pattern of blue lines in the background mark out integer values of the miter limit, relative to the vertex point (purple circle). When the miter hits the miter limit, it will suddenly be cut back to a bevel corner. You can also check DevTools to see which values are being thrown out by the parser, or any changes in the computed style.

Results:

- Chrome (v69) and Safari (v11): negative values for `stroke-miterlimit` are discarded by the parser. Values between 0 and 1 are clamped to 1 for rendering/used-value time.
- Edge (v17): all number values are accepted by the parser, anything less than 1 is clamped to 1 at rendering.
- Firefox (v63): any value less than 1 is discarded by the parser.

Going by the (vaguely worded) [general rule on clamping values in SVG 1.1 Implementation Requirements](https://www.w3.org/TR/SVG11/implnote.html#RangeClamping) (defer error-checking as late as possible, with recommendations for using clamping for the specific examples), I'd say the Edge implementation is correct (don't clamp until as late as possible). But based on the text in the `stroke-miterlimit` property itself (values must be 1 or greater, other values are errors), I'd say that Firefox is correct.

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/545#issuecomment-422576540 using your GitHub account

Received on Tuesday, 18 September 2018 22:18:14 UTC