- From: David Hyatt <hyatt@apple.com>
- Date: Fri, 6 Apr 2007 13:54:30 -0700
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: Doug Schepers <doug.schepers@vectoreal.com>, public-html@w3.org
On Apr 6, 2007, at 1:39 PM, Andrew Fedoniouk wrote: > > > ----- Original Message ----- From: "Doug Schepers" > <doug.schepers@vectoreal.com> > To: <public-html@w3.org> > Sent: Friday, April 06, 2007 12:08 PM > Subject: Re: Canvas > >> Hi, Andrew- >> Andrew Fedoniouk wrote: >>> 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: >>> http://www.terrainformatica.com/sciter/Graphics.whtm >>> It is a) simpler, b) more technically effective and c) free of >>> any royalties. >> And this is yet another reason that 'canvas' is out of scope for >> HTML. Let's not derail real HTML issues --a daunting scope as it >> is-- with inevitably long arguments about a procedural drawing >> protocol. > > Exactly. > > <canvas> as an entity is otrhogonal to the HTML. > I was surprised that people decided to include it even in WHATWG > specification. > Just to be clear, Apple did not propose <canvas> for inclusion in the WHATWG specification. We invented <canvas> for Dashboard, and then Mozilla/Opera thought it was cool and implemented it. As multiple implementations emerged, it was then added in to the WHATWG spec. > If it is pure scripting solution so it should be defined on > scripting layer/DOM specification. Why dedicated <canvas> element > is there at all? What is so <semantic> in it? <canvas> is a dynamic image that can be generated on the fly via JS. There is usefulness to this model, since it allows you to build the bitmap once and then treat it like an image from that point on. > I would expect that any DOM element have getGraphics() method. > I agree with this conceptually (that the 2d-context API would be the way to draw in both cases). However <canvas> still serves a useful purpose for one-time bitmap generation. The kind of custom drawing that would work on arbitrary DOM elements would (in my opinion) be a bit different, since you would probably process actual paint events and not force the retention of a separate bitmap buffer. Forcing a separate buffer would not make much sense for containers where you have to paint your children as well. I'm kind of surprised that people think this element is orthogonal to HTML. It is just a dynamic <img>. dave (hyatt@apple.com)
Received on Friday, 6 April 2007 20:55:11 UTC