[whatwg] Request: Canvas Tag CSS

Greg Houston gregory.houston at gmail.com
Tue Apr 8 11:28:52 PDT 2008

I will take the responses as votes, and the nays overwhelmingly win.
Thank you for your consideration and debate.

In the sum, the primary reason against is that changes to the CSS
would not immediately effect the canvas drawing, which is the accepted
behavior of CSS, i.e., instant results.

The primary reasons for were, 1. not having to locate site styling in
two different locations(e.g., the CSS and an ini file) with the caveat
that dynamic changes to the CSS would not effect the canvas until the
canvas was re-rendered, and 2, not requiring a complex search and
replace when the UA could do this work.

There were further reasons for and against for both.

On Tue, Apr 8, 2008 at 9:38 AM, Krzysztof Żelechowski
<giecrilj at stegny.2a.pl> wrote:
>  Dnia 08-04-2008, Wt o godzinie 12:39 +0200, Thomas Broyer pisze:

>  > In my opinion, you'd rather have a script consisting only of variable
>  > definitions (à la *.ini or *.properties files) and have your designers
>  > only update this file (and never touch nor even see the script
>  > responsible for the actual drawing).
>  I would recommend using functions instead of variables,
>  or using JSON for the whole feature set.

Currently in my use case a user can style each <canvas> instance with
either the ini.js or an XHR JSON data request. The styling is stored
in a JavaScript object that is passed as an argument to the
constructor that creates each instance of the canvas.



More information about the whatwg mailing list