W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: Canvas (was: Microsoft has now joined the HTML Working Group)

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 6 Apr 2007 11:39:13 -0700
Message-ID: <004a01c7787b$054113d0$3501a8c0@TERRA>
To: "Doug Schepers" <doug.schepers@vectoreal.com>, "Maciej Stachowiak" <mjs@apple.com>
Cc: <public-html@w3.org>

----- Original Message ----- 
From: "Doug Schepers" <doug.schepers@vectoreal.com>
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: <public-html@w3.org>
Sent: Friday, April 06, 2007 10:59 AM
Subject: Canvas (was: Microsoft has now joined the HTML Working Group)

> Hi, Maciej-
> Maciej Stachowiak wrote:
>> On Apr 5, 2007, at 3:40 PM, Doug Schepers wrote:
>>> Surely this would be handled under the W3C Graphics Activity [1], not 
>>> the HTML Activity?
>> I think new HTML elements and DOM APIs are in scope for the HTML Working 
>> Group. These may include graphics capabilities, just as Graphics Activity 
>> specs include hypertext capabilities.
>> More specifically, the charter calls for:
>> * A language evolved from HTML4 for describing the semantics of documents 
>> and applications on the World Wide Web. This will be a complete 
>> specification, not a delta specification.
>> * Document Object Model (DOM) interfaces providing APIs for such a 
>> language.
>> Clearly, <canvas> would be covered by these categories and indeed is used 
>> by HTML web applications today.
> I don't see how your conclusion is derived from those points in the 
> charter; that seems an overly broad interpretation.  The SVG WG in the 
> past has been accused of scope-creep, which delayed its progress and 
> publication; it's had to take pains to separate out the more generalizable 
> part of the SVG Tiny 1.2 spec to the WebAPI WG.  I don't want HTML to get 
> bogged down in this same mire.
> 'canvas' is sufficiently different to the HTML functionality and 
> philosophy that I think it should be a separate specification, possibly as 
> a joint Task Force between groups from both the HTML and Graphics 
> Activities.  I honestly think it could move faster this way.  It's not a 
> huge spec, so it could be published quickly and without being dependent 
> upon the entirety of the HTML spec.
> Notable differences are:
> * no DOM
> * no semantic richness
> * unable to be styled via CSS (or the like)
> * an idiosyncratic API unlike anything in HTML
> It's really a black box.  I also don't see why its use should be 
> restricted to HTML... it could be used in SVG or WebCGM, too.
> Obviously, this decision is not up to me, but if Apple chooses to make 
> this royalty-free, I think it should be for all W3C technologies, not just 

I agree, <canvas> is a cool feature but it is far from HTML per se.

I am not sure about legal issues related to the current <canvas>
propsal. If there are any of them then I propse to use my specification:
It is a) simpler, b) more technically effective and c) free of any 

E.g. I do not understand why createLinearGradient / addColorStop
was designed this way - why it requires seperate object (Gradient?)
to be created.  What is the scope of this object and why it is needed?

Simple function like fillLinearGradient with variable
number of parameters can be used instead. This is at least more effective.

In case of ECMAScript managed execution environment
it is better to implement drawing as a pure stream alike process -
please no additional objects with unclear live cycle.

Andrew Fedoniouk.
Received on Friday, 6 April 2007 18:46:41 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:18 UTC