This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 17760 as part of operation convergence. Originally filed: 2012-07-12 15:56:00 +0000 Original reporter: kkrueger <krisk@microsoft.com> ================================================================================ #0 kkrueger 2012-07-12 15:56:19 +0000 -------------------------------------------------------------------------------- For compatibility and interoperability it would seem far safer to not throw an exception when createPattern(canvas, null) is used. In the below list of browsers that treat this as a 'repeat' e.g. createPattern(canvas, 'repeat'). The previous version of the spec had a normative statement that matched the majority of browsers. The latest version of the spec changed this normative statement. Previous Spec 'If the empty string or null is specified, repeat must be assumed. If an unrecognized value is given, then the user agent must raise a SYNTAX_ERR exception' Current working draft has changed to 'If the empty string is specified, repeat must be assumed. If an unrecognized value is given, then the user agent must raise a SYNTAX_ERR exception.' Treats null as 'repeat' Firefox 13.1 Internet Explorer 9 Chrome 20 Opera 12 does indeed raise an exception when passed 'null' Test Case http://www.w3c-test.org/html/tests/submission/PhilipTaylor/canvas/2d.pattern.repeat.null.html Related Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=17141 ================================================================================ #1 Ms2ger 2012-07-17 15:32:52 +0000 -------------------------------------------------------------------------------- Nightly also throws. ================================================================================
I plan to fix this to match implementations (by changing the method's declaration to have its second argument's type be "DOMString?" instead of "DOMString").
Note that two implementations do, in fact, follow the spec. I don't see a reason to change the spec here.
(In reply to comment #2) > Note that two implementations do, in fact, follow the spec. I don't see a > reason to change the spec here. the majority of browsers doesn't follow it though. Only 1 shipping browser has this feature which was introduced by accident.
Stringifying null to 'null' was a deliberate decision, not an accident.
(In reply to comment #4) > Stringifying null to 'null' was a deliberate decision, not an accident. Can you elaborate? Was the change in the spec deliberate or the change in Opera or nightly?
Upon further testing, both Firefox and Opera do this right. So actually I don't think we should change the spec. (What the spec says now makes more sense than what it used to say, so even though the change was accidental I don't think it's a problem. I would only recommend changing it back if the browsers all interoperated on the less ideal behaviour, which they don't.)
(In reply to comment #6) > Upon further testing, both Firefox and Opera do this right. So actually I don't > think we should change the spec. > > (What the spec says now makes more sense than what it used to say, so even > though the change was accidental I don't think it's a problem. I would only > recommend changing it back if the browsers all interoperated on the less ideal > behaviour, which they don't.) FYI Current shipping Firefox does not implement this.
I'm reverting the development versions of Firefox to the shipping behavior for now, for what it's worth. I don't think there's anything to be had from changing the behavior of Gecko here in a way that might cause web pages to throw when they used to not throw. Accordingly, I think the spec should grow a [TreatNullAs=EmptyString] here.
I updated the spec, since none of the browsers moved to the saner behaviour.
Adding "needs-testcase" keyword to flag that http://w3c-test.org/testrunner/2dcontext/fill-and-stroke-styles/2d.pattern.repeat.null.html needs to be updated.