- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Sat, 7 Apr 2007 17:40:21 -0700
- To: "David Hyatt" <hyatt@apple.com>
- Cc: "Doug Schepers" <doug.schepers@vectoreal.com>, <public-html@w3.org>
----- Original Message ----- From: "David Hyatt" <hyatt@apple.com> To: "Andrew Fedoniouk" <news@terrainformatica.com> Cc: "Doug Schepers" <doug.schepers@vectoreal.com>; <public-html@w3.org> Sent: Friday, April 06, 2007 1:54 PM Subject: Re: Canvas > 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. If it is just an image then what was/is wrong with existing Image object and <img> that are there from the primordial Navigator? <img id="canvas" src="placeholder.gif" /> <script> var img = $("#canvas"); var gfx = img.graphics( 300,300, "white" ); gfx.line(...); </script> or so. > >> 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. I am personally not against client side bitmap generation but this canvas design and how it was injected in HTML gives an impression of it as a "foreign matter" or some quick fix of some particular problem in some particular application/situation. > 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 don't think that processing actual paint events is really required. See: We do have the Image object so we can: 1) Change its constructor to support creation of bitmaps/buffers: var canvas = new Image(300,300, "orange"); 2) Add to it getGraphics() method: var gfx = canvas.getGraphics(...); 3) By using Image.src method we can attach it as src of the <img> or <object> or as CSS: background-image to any DOM element. so any element can get custom image. For me this is more natural solution at least. > > I'm kind of surprised that people think this element is orthogonal to > HTML. It is just a dynamic <img>. <canvas> is a synonym of <img> element that has no reasonable backward or no-script compatibility - that is why it creates such an impression. IMO, <img src="noscript.gif"> with scriptable graphics makes significantly more sense in context of html then the <canvas>. Andrew Fedoniouk. http://terrainformatica.com
Received on Sunday, 8 April 2007 00:40:49 UTC