This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17284 - The type of fillStyle/strokeStyle should probably be |(DOMString or CanvasGradient or CanvasPattern)|
Summary: The type of fillStyle/strokeStyle should probably be |(DOMString or CanvasGra...
Status: RESOLVED INVALID
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML Canvas 2D Context (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: rcabanie
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-01 12:36 UTC by contributor
Modified: 2012-09-28 04:19 UTC (History)
4 users (show)

See Also:

Attachments

Description contributor 2012-06-01 12:36:07 UTC 
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
Comment 1 Ms2ger 2012-06-01 12:37:28 UTC 
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.
Comment 2 contributor 2012-07-18 07:22:40 UTC 
This bug was cloned to create bug 17952 as part of operation convergence.
Comment 3 Ms2ger 2012-08-15 17:13:32 UTC 
Filter on [Idon'tcareaboutHTMLWGbugspam].
Comment 4 rcabanie 2012-08-22 04:11:07 UTC 
The spec for fillStyle/strokeStyle states:
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.

Since you can assign any value, the IDL has to state this. 
Unless you propose to change the prose, the IDL is correct as-is.
Comment 5 rcabanie 2012-08-23 19:59:27 UTC 
EDITOR'S RESPONSE: 
This is an Editor's Response to your comment. If
you are satisfied with this response, please change the state of
this bug to CLOSED. If you have additional information and would
like the Editor to reconsider, please reopen this bug. If you would
like to escalate the issue to the full HTML Working Group, please
add the TrackerRequest keyword to this bug, and suggest title and
text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this
document:
       http://dev.w3.org/html5/decision-policy/decision-policy.html
Comment 6 rcabanie 2012-09-28 04:19:11 UTC 
(In reply to comment #5)
> EDITOR'S RESPONSE: 
> This is an Editor's Response to your comment. If
> you are satisfied with this response, please change the state of
> this bug to CLOSED. If you have additional information and would
> like the Editor to reconsider, please reopen this bug. If you would
> like to escalate the issue to the full HTML Working Group, please
> add the TrackerRequest keyword to this bug, and suggest title and
> text for the Tracker Issue; or you may create a Tracker Issue
> yourself, if you are able to do so. For more details, see this
> document:
>        http://dev.w3.org/html5/decision-policy/decision-policy.html

After further testing, the new IDL matches some browsers.
I will integrate change the version of the W3C spec to reflect the correct behavior.