- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 5 Sep 2013 20:59:45 +0000 (UTC)
- To: Tom Wiltzius <wiltzius@chromium.org>, Benoit Jacob <jacob.benoit.1@gmail.com>, Rik Cabanier <cabanier@gmail.com>
- Cc: whatwg@whatwg.org
On Fri, 28 Jun 2013, Tom Wiltzius wrote: > > The only major Canvas2D features being actively developed in Chromium > right now are: > > - having a canvas context "alpha" attribute > - text decoration > - compositing and blending > - canvas access in workers > > (easily referenced from http://www.chromestatus.com/features) > > It is concerning to me that the list of other unimplemented features > that aren't being worked on could block the standardization of the above > (all of which have been discussed on this list at one point, but not all > of which are in the spec yet). > > How can we help reconcile this discrepancy? My goal is for the spec to match the browsers as closely as possible while providing direction for the next set of new features. >From my point of view, therefore, there's two ways to reconcile this discrepancy: either the browsers implement what's in the spec, or the spec changes to drop the things that aren't getting implemented. On Fri, 28 Jun 2013, Benoit Jacob wrote: > > Has the Canvas 2D community considered a WebGL-like model to the > introduction of additional features? > > By "the WebGL model", I mean: > - Define a core feature set that's conservative and limited, but > consistently implemented by all browsers. Enforce consistent support for > it by an exhaustive conformance test suite. That's the model we're trying to follow. > - Let any additional feature be an "extension". The goal is for there to be none of these. > - Consider, similar to WebGL, further tightening this process by letting > any new feature start at "draft" status and wait a bit before being > "approved". That doesn't work. Nobody cares if something is approved or not -- they'll use it if it works and it's what they want. Once people use it, it's not going anywhere, and the spec is de-facto frozen. > Typically, the difference that this makes is that "draft" extensions > would be exposed by browsers only "behind a flag" (a browser option > that's not enabled by default). Prerequisites for "approval" would > include: having been implemented and stable for some time, and being > covered by a conformance test. You can't tell if something is stable until people are using it, so hiding features behind a flag, once their implementation is complete, doesn't help. On Fri, 28 Jun 2013, Rik Cabanier wrote: > > If you can get them into 2 stable browsers, I'm very sure that Ian will add > it to the specification. > It seems that Ian is mostly concerned that we're adding more and more > features to the document but they are not being worked on. This makes the > WHATWG spec less useful since you can't tell what's implemented or not. (It > also makes a lot of useless work for Ian if he has to cut it later.) Precisely. > I think what's needed is that the person who proposes a feature and gets > it accepted on the mailing list, also needs to follow up and coordinate > with the browsers so it actually gets implemented. Certainly a one-browser feature is no good, specced or not. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 5 September 2013 21:00:13 UTC