W3C home > Mailing lists > Public > public-bpwg@w3.org > September 2009

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

From: Jo Rabin <jrabin@mtld.mobi>
Date: Fri, 04 Sep 2009 09:43:30 +0100
Message-ID: <4AA0D332.4040208@mtld.mobi>
To: public-bpwg@w3.org
I don't think we explicitly state it anywhere but we do seem to be 
biased towards "public" and "open" and "royalty-free" or "license free", 
and I think that's fair enough because I think we should not be in the 
business of promoting one vendor's proprietary technology over 
another's. If we promoted the use of Flash Lite then vendors of other 
products could reasonably ask why we did not mention their products, and 
it's not our job to assess the competitive merits of competing 
proprietary technologies.

The formula we have used in the past is to refer to "other vendor 
specific initiatives" which at least acknowledges their existence and 
might prompt the curious reader to find out more.

The other side of this coin is that I think we need to be careful not to 
promote technologies solely on the basis that they are "open" or 
"public", which I'm afraid I think we have been on the verge of doing 
before.

It seems to me that SVG is widely supported on mobiles today. I'm afraid 
I don't know how widely supported Canvas is or what plans mobile browser 
vendors have to support it.

I think Eduardo makes (as usual) a very strong point when he says we 
should be discussing the alternatives when technology is not available. 
So somewhere in the proposed text I would expect to see some reference 
to minimizing production costs, maybe creating in SVG and serving other 
media types when this is not supported.

There are other aspects to this, which may be ultra vires for us but are 
worth mentioning, while we are talking about this subject. I could be 
accused of being a declarative irredentist here, but it seems to me that 
an important aspect of the Web is that content on it is discoverable. 
This suggests to me, that by preference content in the web should be 
presented in a structured markup form, rather than using procedural 
mechanisms that may produce the same results from a human consumer's 
point of view, but which from a machine readability point of view are 
more-or-less opaque.

Jo

On 03/09/2009 21:59, Eduardo Casais wrote:
> You are correctly raising two issues, and my
> contention is that none of them is properly
> addressed (in the limited scope of graphics
> functions) in the current proposal.
> 
>> 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. 
>> To me it seems there should be a standard for people
>> that use Canvas and a standard for people that use SVG.
> 
> The MWABP is a best practices document. Hence,
> if there is a choice of technologies, a best
> practice indicates which technology is more
> appropriate depending on the circumstances.
> The second aspect is that, within a
> technology, there might be more appopriate
> ways of using it than others, which is another
> type of best practice.
> 
> Currently, the proposed text does not provide
> compelling reasons as to why SVG should be 
> used rather than canvas (or vice-versa), except
> for the single weak reference to one technical
> feature. 
> 
> It does not provide any guidance whatsoever about how to use each of the technology by
> itself (but this was admittedly not the
> original mission of the editor).
> 
>> 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.
> 
> And this is why I mentioned Flash lite, a
> widespread technology that is squarely in the
> same scope as SVG and canvas but is not even
> mentioned.
> 
> As you rightfully point out, companies give
> priority to the technologies for which they
> have or can find skilled personnel. In this
> sense a best practice is not a law: by giving
> a justifed preference to some technologies
> depending on the development context, it 
> highlights the trade-offs, pitfalls and 
> possible difficulties of using other available
> technologies. E.g. "if you want to develop
> this kind of functionality, then the preferred
> way is to use technology X, which compared to
> technology Y has such and such advantages 
> regarding portability, performance, whatever.
> On the other hand, for this other kind of 
> application, technology Y is preferrable, 
> because of accessibility". Then the developer
> knows what he is up to.
> 
> E.Casais
> 
> 
>       
> 
Received on Friday, 4 September 2009 08:44:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:02 UTC