Closed Bug 1508028 Opened 4 years ago Closed 3 years ago
stroke-miterlimit minimum should now be 0 instead of 1
Bug 1508028 - Change stroke-miterlimit restriction from GreaterThanOrEqualToOneNumber to NonNegativeNumber.
47 bytes, text/x-phabricator-request
|Details | Review|
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Steps to reproduce: https://jsfiddle.net/ericwilligers/w57hm1Lc/ SVG 1.1 had a minimum stroke-miterlimit of 1: https://www.w3.org/TR/SVG11/painting.html#StrokeMiterlimitProperty https://bugzilla.mozilla.org/show_bug.cgi?id=470706 SVG 2 Draft changes the minimum to 0: https://svgwg.org/svg2-draft/painting.html#LineJoin "A negative value for stroke-miterlimit must be treated as an illegal value. Previous versions of the SVG specification also stated that values between 0 and 1 were in error, but ..." Blink/Edge/Safari accept values from 0. Actual results: Firefox rejects stroke-miterlimit values less than 1 Expected results: Firefox should only reject stroke-miterlimit values less than 0 Then Firefox would be consistent with SVG 2 Draft and Blink/Edge/Safari
Reproduced the issue on Firefox 65.0a1 20181120220133 / 64.0b11 20181119162153/ 63.0.3 20181114214635 on Ubuntu 16.04 & Windows 10.
bug 649960 seems to be already fixed, at leased, I cannot see a wrong behaviour in my example in current versions anymore (or only, if I dynamically change the size of the SVG, that might be a hint, that only the accuracy is low). And it seems not to be related. About this issue: Because the miter angle is always between 0 and 180 degree, miterLength/stroke-width will be always larger than or equal 1. Therefore it is not meaningful, if authors note values smaller than 1. SVG 1.1 is correct here. But the formula is the same in 1.1 and 2 anyway, therefore no other behaviour (the comment in the SVG 2 draft about other historically definitions is wrong, at least concerning SVG). The SVG 2 draft seems not to describe, what to do with values smaller than 1, presumably the behaviour can be the same as for 1, in this case there is no difference between stroke-linejoin miter or bevel anyway, because the two segments join smoothly without a corner.
Firefox Nightly fails the proposed parsing WPT https://github.com/web-platform-tests/wpt/pull/14114/files#diff-6ccd6c8fdf1f64bb82fa2696d5bb9648 Fail e.style['stroke-miterlimit'] = "0" should set the property value Fail e.style['stroke-miterlimit'] = "0.5" should set the property value Pass e.style['stroke-miterlimit'] = "1" should set the property value Pass e.style['stroke-miterlimit'] = "7.5" should set the property value
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Attachment #9045545 - Attachment description: Bug 1508028 - Change stroke-miterlimit restriction from GreaterThanOrEqualToOneNumber to NonNegativeNumber. r=jwatt → Bug 1508028 - Change stroke-miterlimit restriction from GreaterThanOrEqualToOneNumber to NonNegativeNumber.
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/fbbc4b0c00c3 Change stroke-miterlimit restriction from GreaterThanOrEqualToOneNumber to NonNegativeNumber. r=longsonr,emilio
You need to log in before you can comment on or make changes to this bug.