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

Maybe I'm misunderstanding what W3C is.  Shouldn't W3C be the non-bias
member that says, if your going to use this technology, this is the
standards to follow?   Not, don't use this technology for that, use this
instead.   Technology, unfortunately, is regulated by money.  If the company
has a SVG developer in house, then that's what they will use.  If they have
a Canvas developer, they're not going to start looking for someone that
knows SVG.

To me it seems there should be a standard for people that use Canvas and a
standard for people that use SVG.   Lets face it, not everyone is IBM, GE,
or Microsoft and have money to burn so they can hire people for each
technology they want to work with.  And lets also face these companies that
do have money to burn, make their own standards, not following someone
elses.

Plus, when you start tell people what technologies to use instead of
standardizing the technology, people start looking more closely at who your
friends are and make sure your not bias about your decisions and making W3C
more unreliable.


On Thu, Sep 3, 2009 at 1:45 PM, Eduardo Casais <casays@yahoo.com> wrote:

> > well
> > I *do* try to point out
> > the basic decision-elements
> >
> > SVG if you need DOM access and richness
> > Canvas if you don't
>
> The decision elements must be based on application
> functionality, performance issues, portability, security,
> accessibility, usability, in other words, requirements
> -- not on the features of the technology. "Use SVG if
> you need DOM, canvas if you do not" is as interesting
> and instructive as stating "use XHTML if you need strong
> markup validation, use HTML if you do not" -- or "use
> C++ if you need object-oriented functions, C if you do
> not". Why would you need the features under
> consideration? Why would it be a good practice to rely
> upon them or conversely to forgo them?
>
> > got a suggestion that puts canvas and SVG in the
> > same heading-phrase?
>
> Alas no, except that at this point I would slightly tend to
> propose "Use SVG for dynamic graphics; generate static
> graphics on the server; avoid canvas".
>
> > the choice of whether to generate stuff
> > server-side or client-side
> > seems to me beyond the scope of this little section
>
> That is a pretty limited view of the affair. If canvas are
> not good for dynamic graphics (there, use SVG), and
> are just ok "to whip up something lightweight and fairly
> static" then one can as well pre-generate the fairly static
> content (with whatever suitable: Flash, GIF...) on the
> server, and send a simple file to the terminal, instead of
> having to send a file AND running code on the terminal.
> The sum of these considerations would be that there are
> compelling reasons NOT to use canvas -- because it
> either does not provide dynamics, or because of its
> presumably inferior performance. Once again, if there
> are cases where canvas implements some categories of
> application functionality with better peformance, or
> usability, or portability, or security, etc, etc, than other
> technologies, then these should be made clear, since
> they would be the basis for a best practice.
>
> To put the question in another light: what were the
> compelling reasons and use cases to include canvas
> in HTML 5 (excluding a natural craving for creeping
> featurism)?
>
>
> E.Casais
>
>
>
>
>


-- 
Gavin