[whatwg] Canvas and DOM elements

[Andrew Fedoniouk]

Hi, Peter,
  ----- Original Message ----- 
  From: Peter Hall 
  To: Andrew Fedoniouk 
  Cc: whatwg at whatwg.org 
  Sent: Tuesday, May 09, 2006 11:57 AM
  Subject: Re: [whatwg] Canvas and DOM elements


  I disagree, for a number of reasons.

  1. When an element is resized, the bitmap and context get re-initialized to their default state. This doesn't happen in any other scenario, and I think it would be non-obvious and difficult to work with. For example, if you draw a custom bullet point, you wouldn't want to redraw it every time you resize the element, since the actual graphic isn't changing size. Best practice would evolve to discourage your suggested usage by always using a dedicated <div> for graphics.

This is also what I don't like in <canvas> solution. It forces to use some screen buffer for drawing.
Strictly speaking this is not the best way to draw in significant number of situations. Your bullet case is a good example.

I think it is better to have Element.onPaint( Canvas gx, int width, int height ) event and 
method getContext() available for Image only.

This way is possible to implement ligthweight simple rendering like bullets and buffered rendering
using Image if needed.  This is at least more flexible.

Another idea for drawing bullets - to design some mechanism to use Image + getCanvas + sort of setStyleAttribute("list-image", that_image)



  2. It's much cleaner to keep all the canvas-related attributes and methods together, without having to contaminate other DOM elements, that aren't going to use them.

canvas-related attributes ? You mean those width and height?  
They are optional anyway. 
If you need to define dimension of something exactly by width and height attributes then you can use <img> or <object> and draw on them.

canvas-related method is only one - getContext(). And as I said it can be eliminated by using onPaint event.


  3. Your argument about placing graphics above and below other content seems invalid. Since, <canvas> supports transparency, you could position it above or below any other element, and get the same effect.

In my opinion what is really invalid is use of <canvas> in the way you explained.
How would you position it above and below? Again by using scripts or/and moving all things out of static positioning? 

In the way it is defined <canvas> is just a special kind of <object>, so why not use existing <object> then? 
As far as I understand <object> was specially designed to serve such purposes.

Andrew Fedoniouk.
http://terrainformatica.com




  Peter


  On 5/9/06, Martijn <martijn.martijn at gmail.com> wrote:
    On 5/5/06, Andrew Fedoniouk <news at terrainformatica.com> wrote:
    >
    > Having dedicated DOM element (<canvas>) for drawings looks a bit strange as
    > a design decision. 
    > Logically any block DOM element can provide graphics.
    > Ideally getContext method should have one more parameter - layer -
    > background/content/foreground -
    > so graphics could be mixed with the content of the element, drawn on top 
    > and/or below the content.

    Yeah, I think you make a good point here.

    Regards,
    Martijn


    > <optional>
    > Only as an example, Sciter allows to draw on any block element:
    > http://terrainformatica.com/sciter/sciter.zip at
    > http://terrainformatica.com/sciter/
    > Samples are in /samples/graphics/*.htm 
    > </optional>
    >
    > Andrew Fedoniouk.
    > http://terrainformatica.com
    >
    >
    >
    >


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20060509/5f016948/attachment-0001.htm>