[whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)

Rik Cabanier cabanier at gmail.com
Fri Jun 28 20:19:16 PDT 2013 

On Fri, Jun 28, 2013 at 7:01 PM, Benoit Jacob <jacob.benoit.1 at gmail.com>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.
>

This is what we want for canvas 2d. Everything in it should be consistently
implemented. If not, that's a bug.


> - 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.
>

No, we don't want authors to worry about optional functionality. We
certainly don't want to write a spec that allows it. We do try to make new
features easily detectable.
Of course authors have to deal with different implementation levels because
they need to target different browsers and different versions of the same
browser, but we try to fill that by making new features easily detectable.
Very often the community will create a polyfill so authors can use new
features in older browsers.


> - 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 <wiltzius at chromium.org>
>
>> 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 <cabanier at gmail.com>
>> 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 <wiltzius at chromium.org
>> >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 <cabanier at gmail.com
>> >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 <ian at hixie.ch> 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 <canvas> feature
>> >>> > requests:
>> >>> >
>> >>> > 11399   <canvas> Locking individual color channels (e.g. drawing to
>> >>> alpha
>> >>> >                  only)
>> >>> > 21835   <canvas> Path object should have a way to add paths keeping
>> >>> only
>> >>> >                  the union given a fill rule
>> >>> > 21939   <canvas> Path objects would be much more useful if their
>> >>> >                  individual commands (moveTo, lineTo, etc.) could be
>> >>> >                  inspected from JavaScript [...]
>> >>> > 8794    <canvas> lineWidth = 'hairline'
>> >>> > 11739   <canvas> clearPath() that clears pixels the way clearRect()
>> >>> does,
>> >>> >                  but using a path
>> >>> > 9236    <canvas> Detecting the intersection of Path objects
>> >>> > 9235    <canvas> perspective transformations
>> >>> > 18751   <canvas> a way to get the coordinate of the last point in a
>> >>> path
>> >>> > 21346   <canvas> 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.
>> >>> `._.-(,_..'--(,_..'`-.;.'
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>
>

More information about the whatwg mailing list