W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: Use Cases for The <canvas> Element

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Thu, 02 Aug 2007 07:32:03 -0400
Message-ID: <46B1C0B3.7040604@earthlink.net>
To: Sander Tekelenburg <st@isoc.nl>
CC: public-html@w3.org

Sander Tekelenburg wrote:
> At 05:57 -0400 UTC, on 2007-08-01, Doug Schepers wrote:
>>>> Sander Tekelenburg wrote:
>>>>> As hard as I try, I don't see how to interpret that as anything else
>>>>> then "UA vendors will do what they want, the rest of you will
>>>>> just have to play by some rules we set for you".
>> I'm very confused by this attitude.  Specifications without
>> implementations are useless.
> Sure. But the point was that proposals were constantly being dismissed with
> the argument that they must first demonstrate the need as well as that the
> proposed solution is the best possible one. Yet at the same time it appears
> to be deemed unnecessary to provide such demonstrations for new things that
> at this point already happen to be in the current version of the spec,
> apparently "because they are already implemented in UAs".

   It's an apples and oranges comparison. You're saying that "best
solution" (which have probably already been discussed on the WHATWG
mailing list in the case of <canvas>, by the way) should always trump a
solution with preexisting multiple implementations that already have a
user base. The quality of the solution and existence of implementations
that are in use must both be weighed against each other. If this were
not the case, we could just scrap HTML 5.0 and all go work on XHTML 2.0,
because implementations of HTML don't matter.

   (Note that I do feel that there is a good argument for keeping the
|headers| attribute, due to existing implementations and the fact that
there are no features that encompass its entire functionality.)

> (Sure, we hear that if there are problems with such already implemented
> features, they will have to be addressed. But we all understand that once
> something has [been implemented] by several UAs, the room to address issues,
> will get smaller and smaller.)

   The best way to handle this is to track the issues and lobby heavily
to get those issues corrected while use of the feature is still limited.
 Once a feature becomes widely used in a particular form, the fact that
it isn't in a spec is irrelevant. There's a difference between working
to improve a feature and stonewalling it for ideological reasons.
Perhaps it's better to talk about specific issue rather than general
ideology, and the situation may resolve itself.
Received on Thursday, 2 August 2007 11:32:49 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC