[whatwg] Canvas and DOM elements

[Peter Hall]

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.

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.

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.

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/5b07723d/attachment-0001.htm>