17952 2012-07-18 07:22:37 +0000 The type of fillStyle/strokeStyle should probably be |(DOMString or CanvasGradient or CanvasPattern)| 2012-09-28 04:17:30 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#2dcontext P3 normal Unsorted 1 contributor ian cabanier ian mike Ms2ger contributor oldest_to_newest 70365 0 contributor 2012-07-18 07:22:37 +0000 This was was cloned from bug 17284 as part of operation convergence. Originally filed: 2012-06-01 12:36:00 +0000 ================================================================================ #0 contributor@whatwg.org 2012-06-01 12:36:07 +0000 -------------------------------------------------------------------------------- Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html Multipage: http://www.whatwg.org/C#2dcontext Complete: http://www.whatwg.org/c#2dcontext Comment: The type of fillStyle/strokeStyle should probably be |(DOMString or CanvasGradient or CanvasPattern)| Posted from: 91.181.38.75 by ms2ger@gmail.com User agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20120108 Firefox/12.0a1 ================================================================================ #1 Ms2ger 2012-06-01 12:37:28 +0000 -------------------------------------------------------------------------------- Currently the spec isn't terribly clear on what should happen for, for example, ctx.fillStyle = { valueOf: function() { return "blue" } }. Deferring to WebIDL would fix that. ================================================================================ 72669 1 contributor 2012-08-23 22:11:43 +0000 Checked in as WHATWG revision r7260. Check-in comment: Clean up some IDLs that use 'any' to specify the exact type instead, and clean up some surrounding markup http://html5.org/tools/web-apps-tracker?from=7259&to=7260 72695 2 Ms2ger 2012-08-24 07:03:30 +0000 The prose still stays: > If the value is a string but cannot be parsed as a CSS <color> value, > or is neither a string, a CanvasGradient, nor a CanvasPattern, then > it must be ignored, and the attribute must retain its previous value. "or is neither a string, a CanvasGradient, nor a CanvasPattern," is now handled in WebIDL, and should be dropped. 72861 3 ian 2012-08-27 22:19:56 +0000 Oops. 72863 4 contributor 2012-08-27 22:21:48 +0000 Checked in as WHATWG revision r7287. Check-in comment: Remove redundant text. http://html5.org/tools/web-apps-tracker?from=7286&to=7287 72879 5 Ms2ger 2012-08-28 06:45:02 +0000 Thanks! 73149 6 cabanier 2012-09-02 02:32:36 +0000 (In reply to comment #1) > Checked in as WHATWG revision r7260. > Check-in comment: Clean up some IDLs that use 'any' to specify the exact type > instead, and clean up some surrounding markup > http://html5.org/tools/web-apps-tracker?from=7259&to=7260 This change modifies the behavior that all browsers have. Currently "ctx.fillStyle = { valueOf: function() { return "blue" } }" is ignored because it is not a string, canvaspattern or a gradient. No browser will cast the object to a string. Current behavior is to accept 'any' 73150 7 Ms2ger 2012-09-02 07:51:15 +0000 First of all, ToString({ valueOf: function() { return "blue" } }) is "[object Object]". Second, why would you want this to be inconsistent with the sensible WebIDL behaviour? 73157 8 cabanier 2012-09-02 21:47:13 +0000 (In reply to comment #7) > First of all, ToString({ valueOf: function() { return "blue" } }) is "[object > Object]". Second, why would you want this to be inconsistent with the sensible > WebIDL behaviour? sorry, copy/paste error. What is working with the IDL and not before is if you pass this: fillStyle = { toString(): { return "blue"; } } I don't disagree that this might make more sense, but it is a change of behavior (which was an IDL that took 'any'). 74718 9 ian 2012-09-28 04:12:16 +0000 Changing behaviour is fine if it's an edge case and the new behaviour is saner. It's an issue if it isn't compatible with legacy content, but do we have any reason to believe that is the case? Marking FIXED again, in the absence of such information. 74719 10 cabanier 2012-09-28 04:17:30 +0000 (In reply to comment #9) > Changing behaviour is fine if it's an edge case and the new behaviour is saner. > It's an issue if it isn't compatible with legacy content, but do we have any > reason to believe that is the case? > > Marking FIXED again, in the absence of such information. I agree. We did some more tests and this matches behavior on some browsers. This will be changed in the W3 version of the spec as well.