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

Re: Non-goal for HTML: Picture-perfect rendering

From: Charles McCathieNevile <chaals@opera.com>
Date: Thu, 19 Apr 2007 04:04:56 +0200
To: "Karl Dubost" <karl@w3.org>, "David Hyatt" <hyatt@apple.com>
Cc: "HTML WG" <public-html@w3.org>
Message-ID: <op.tq0deig1wxe0ny@widsith.local>

On Wed, 18 Apr 2007 04:26:19 +0200, Karl Dubost <karl@w3.org> wrote:

> Le 17 avr. 2007 à 08:53, David Hyatt a écrit :
>> As I've said in a previous thread, <canvas> is a dynamic <img>, so
>> I don't see any reason to object to the element purely on the
>> grounds that it primarily defines a visual object.
>
> Would you consider that the authoring part is irrelevant?
> I'm not saying it is bad, just looking for use case scenario on how
> it is difficult or not for authors to produce a graphics.

Hmm. There are simple canvas drawing tools that could be used to create an image in canvas remarkably easily. There are assorted advantages ot having canvas, like the fact that it enables easily editable images...

>> However I also don't see the harm in inclusion of the graphics
>> context API in the same specification mainly because of the time/
>> effort that would be involved standardizing it somewhere else (and
>> those responsible for the three implementations of canvas that
>> exist already are actively participating in this group).
>
> As I said in the past, even if done by this WG, I have the feeling
> that it would speed up the process to make it a small individual
> specification.
> As an example, Web API has been quite quick for XMLHttpRequest Object.

Hmm. For a variety of reasons (not least that XHR is quite old, and the pre-existing implementations were not that compatible in a number of points) I don't think XHR was nearly as quick as I would expect a basic canvas spec to be.

...
> So I have the feeling that going with an HTML Task Force taking the
> canvas part in a small spec would really speed up the process.
> 	It is more agile in the method.
> It will give satisfaction to the WG for having published something
> more quickly than the whole HTML specification (that will take a lot
> more time).

This is one possible way to proceed. The old HTML working group, many years ago, did a bunch of work on modularising HTML. I seem to record that Murray was instrumental in doing the DTD magic that at the time was considered a necessity. So there is a precedent for building HTML from pieces. The HTML 5 spec has some parts that go across the entire spec, like the construction of the DOM, but as I understand it even those don't actually imfluence exery single element.

Working out whether to make parts at a time, or whether to just build a spec in one solid piece, is something for the group to consider seperately to whether or not an API for immediate mode graphics is useful for the interoperability of HTML as used on the Web, IMHO. 

As chair of the WebAPI group, it seems that while it would in principle be in scope for that group to take on the work, it is also in scope for this group, and this group currently has a much better level of real participation from Apple, Microsoft (who have both been quiet in WebAPI recently) and Mozilla (who have been invisible for months).

cheers

Chaals

-- 
  Charles McCathieNevile, Opera Software: Standards Group
  hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com          Try Opera 9.1     http://opera.com
Received on Thursday, 19 April 2007 02:04:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:53 GMT