Re: ACTION-924: canvas and SVG draft text / comments

> I think what I wrote is reasonable for the average
> developer

Let me try once more to paraphrase (in a 
somewhat extreme form) the text: 

"SVG and canvas provide different technical
features. Look at the specifications of SVG and
those of canvas and decide which one provides
the functionality you need; then use the
corresponding technology."

Is that a best practice?
 
> deliberately so...
> there are a lot of other factors that go into making good
> "do this server-side or client-side" decisions

As presented, canvas seems a second choice --
one may use it if one does not need all the
functionality of SVG. But actually, there is
an even more obvious second choice: generating
"fairly static graphics" on the server -- this
is actually the default choice if one wants to
cover less capable phones that do not support
the new HTML 5 features as required by BP
3.6.4.

So we are not looking at a general "server-
side vs. client-side" decision process, but at
the compelling grounds to use canvas vs. other
major technologies to create mobile graphics. Ignoring the basic server-generated graphics
is, in this respect, improper.

> > The sum of these considerations would be that there
> are
> > compelling reasons NOT to use canvas
> 
> I understand that this is your "bias"

It is a logical conclusion from the little
information there is in the text. Actually, I
find SVG a bit complex, and I can see some
advantages in canvas. For instance, and with
reference to the MWABP document itself: 

Canvas is a markup element, and is "filled in"
via Javascript code. Thus, we can apply the
optimizations proposed in 3.4.5 "Minimize 
External Resources" by coalescing all 
canvas-scripts with other Javascripts, or
even within the main markup page itself. This
is not possible with SVG, which always requires
its own file to be transmitted separately from
the other resources. If network latency is a 
problem, consider using canvas instead of SVG.

That's it. A reason to use canvas instead of
SVG, that is based on a true best practice.

> > To put the question in another light: what were the
> > compelling reasons and use cases to include canvas
> > in HTML 5
> 
> IMHO that is *way* beyond the scope of this document

Well, W3C people took a decision to include
canvas in HTML 5. Hence, there must have been
a justification for it. Therefore, there must
be compelling reasons to use canvas, which were
deemed inadequately fulfilled by other 
available technologies such as SVG. Thus, we
might learn about what those are to enlighten
our work. Whence my question.

> canvas is real
> and it is being used
> so we need to address it...
> whether any one of us thinks canvas or HTML5
> is A Good Idea
> or not

Are you saying that since people have started
using canvas, we must somehow find a way to
construe its utilization as a best practice,
even if we are unable to state any compelling
argument for this, and even if we must ignore
other serviceable technologies that fulfil the
same role adequately?

I strongly argue in favour of including Flash
lite too, since Flash lite is real, and it is
being used, so we need to address it -- 
whether any one of us thinks Flash lite is a 
Good Idea or not...


E.Casais

Received on Thursday, 3 September 2009 21:43:38 UTC