From whatwg Sat Jun 29 02:01:01 2013 From: Benoit Jacob Date: Sat, 29 Jun 2013 02:01:01 +0000 To: whatwg Subject: Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d) Message-Id: X-MARC-Message: https://marc.info/?l=whatwg&m=137247127802814 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. - Let any additional feature be an "extension". Using the feature requires first explicitly calling context.getExtension("featurename"); . This helps ensuring that Web pages don't accidentally rely on that feature, and instead, make a conscious portability-vs-features trade-off. - Consider, similar to WebGL, further tightening this process by letting any new feature start at "draft" status and wait a bit before being "approved". 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. If there is any doubt that such a model can be useful in practice, WebGL has been very successful so far at combining fast feature iteration with tight cross-browser compatibility, using a similar model. See this document: http://www.khronos.org/registry/webgl/extensions/ .,. except it needs updating to reflect the recent move away from vendor prefixes to flags, by some major browsers. Benoit 2013/6/28 Tom Wiltzius > I agree there isn't a risk of these unrelated additional features not > matching their hypothetical specs. > > However, my concern is Ian's comment that he'd prefer not to add additional > features to the spec -- some of the ones being actively developed in > Chromium aren't added yet, and I'd hate for them to not get added even if > we have consensus on their behavior and early implementations. > > To quote Ian's initial message: > > """I think before we add more features, it's important that we figure out > which browsers want to implement which features, and that we start with > the highest priority ones."""" > > ... so I'm trying to provide context about what Chromium is currently > implementing, and hence what might be higher priority to spec. > > > On Fri, Jun 28, 2013 at 12:48 PM, Rik Cabanier wrote: > > > As long as those features don't build upon other unimplemented features, > > there should be no risk. > > However, accessibility (=hit regions) is a must and should be tackled as > > soon as possible. > > > > Rik > > > > > > On Fri, Jun 28, 2013 at 12:30 PM, 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? > >> > >> > >> On Fri, Jun 14, 2013 at 11:54 AM, Rik Cabanier >wrote: > >> > >>> I agree that hit regions should be high on the priority list. They've > >>> been > >>> in the spec for a while and are absolutely required for accessibility. > >>> I will try to follow up on this feature with the browsers. We recently > >>> added a basic Path object to WebKit and I know that mozilla is looking > at > >>> the path object. > >>> > >>> At this point, I wouldn't ask to add begin/endLayer to the spec. > Instead, > >>> we will talk to the browser vendors and work on implementing the > feature. > >>> Just putting it in the spec is not enough to get an implementation... > >>> > >>> On Fri, Jun 14, 2013 at 10:42 AM, Ian Hickson wrote: > >>> > >>> > On Fri, 14 Jun 2013, Brian Salomon wrote: > >>> > > > >>> > > As an implementor, we would prefer the layer approach. This would > >>> have > >>> > > lower overhead in Chromium/Skia. We can make better decisions about > >>> > > caching and deferred rendering. It also seems like a really handy > API > >>> > > for devs, especially the ability to inherit the graphics state. > Would > >>> > > the spec have anything to say about beginLayer()/endLayer() > >>> balancing, > >>> > > especially with respect to RAF? > >>> > > >>> > I have no ojection to adding this to the spec, but right now the spec > >>> has > >>> > a bunch of features that aren't implemented, and there's a long list > of > >>> > other features people want that aren't yet specced. I'm very hesitant > >>> to > >>> > get the spec further and further away from implementations. > >>> > > >>> > For example, here are some of the bug numbers for feature > >>> > requests: > >>> > > >>> > 11399 Locking individual color channels (e.g. drawing to > >>> alpha > >>> > only) > >>> > 21835 Path object should have a way to add paths keeping > >>> only > >>> > the union given a fill rule > >>> > 21939 Path objects would be much more useful if their > >>> > individual commands (moveTo, lineTo, etc.) could be > >>> > inspected from JavaScript [...] > >>> > 8794 lineWidth = 'hairline' > >>> > 11739 clearPath() that clears pixels the way clearRect() > >>> does, > >>> > but using a path > >>> > 9236 Detecting the intersection of Path objects > >>> > 9235 perspective transformations > >>> > 18751 a way to get the coordinate of the last point in a > >>> path > >>> > 21346 Have ImageBitmap expose height and width attributes > >>> > > >>> > (Bugs accessible from https://www.w3.org/Bugs/Public/) > >>> > > >>> > There's also the printCallback API proposal from Mozilla: > >>> > > >>> > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0371.html > >>> > > >>> > Adding a parameter to drawImage for sprite sheets to avoid bleeding, > >>> > proposal from Chrome: > >>> > > >>> > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0088.html > >>> > > >>> > Stroke alignment: > >>> > > >>> > http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Jul/0238.html > >>> > > >>> > Page flipping instead of double buffering: > >>> > > >>> > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/0073.html > >>> > > >>> > Inner shadows: > >>> > > >>> > > >>> > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/038079.html > >>> > > >>> > > >>> > Plus, as I mentioned, things in the spec that aren't implemented > >>> widely: > >>> > Right now, the things in the spec that aren't widely implemented are > >>> the > >>> > things that were needed for accessibility (hit regions) and the > things > >>> > that are the basis for some of the most-requested features (Paths). > >>> > > >>> > > >>> > I think before we add more features, it's important that we figure > out > >>> > which browsers want to implement which features, and that we start > with > >>> > the highest priority ones. > >>> > > >>> > -- > >>> > Ian Hickson U+1047E )\._.,--....,'``. > >>> fL > >>> > http://ln.hixie.ch/ U+263A /, _.. \ _\ > ;`._ > >>> ,. > >>> > Things that are impossible just take longer. > >>> `._.-(,_..'--(,_..'`-.;.' > >>> > > >>> > >> > >> > > >