Re: [whatwg] Adding 2D Canvas features
On Mon, 30 Sep 2013, Tom Wiltzius wrote: > On Fri, Sep 27, 2013 at 2:21 PM, Ian Hickson wrote: > > On Thu, 5 Sep 2013, Tom Wiltzius wrote: > > > > > > Meanwhile this doesn't change the other Canvas2D-related work > > > ongoing in the Chromium project, so we're still keen to see some new > > > features added to the Canvas spec. Ian if it would help to identify > > > items in the spec that Chromium doesn't intend to implement (at > > > least any time soon), we can attempt to do so. > > > > If there are specific things in the spec that you think are bad and > > should be removed, please do raise them on the mailing list, yes. > > I think we're reasonably certain that *HD methods should be removed, but > those are the only solid ones. Yeah those are going to be cut, I'm just trying to figure out how to replace them. See: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/thread.html#msg68 > > If there are specific things not in the spec that you have > > implemented, then please file a bug pointing to the documentation for > > whatever you have implemented, using: http://whatwg.org/newbug > > > > If there's multiple implementations, and HTML is the right spec, then > > I'll pretty much automatically spec it. Otherwise, it'll be based on > > whether it makes sense and has use cases. (So far example, I haven't > > added canvas text decoration APIs, which have been raised as something > > Chrome might implement, as discussed in my last e-mail to this list. > > The alpha parameter, though, needs speccing, I just haven't gotten > > around to it yet -- it's on my list though.) > > Great, I was wondering specifically about the status of the alpha > attribute-- glad to hear it's just spec'ing that needs to happen, I > wasn't clear on if this was blocked on "no new features" or not. Thanks! The idea of limiting the rate of spec additions is to limit the rate of new implementations. If the implementations already exist, there's no point not adding it to the spec. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding 2D Canvas features
On Fri, Sep 27, 2013 at 2:21 PM, Ian Hickson wrote: > On Thu, 5 Sep 2013, Tom Wiltzius wrote: > > > > Meanwhile this doesn't change the other Canvas2D-related work ongoing in > > the Chromium project, so we're still keen to see some new features added > > to the Canvas spec. Ian if it would help to identify items in the spec > > that Chromium doesn't intend to implement (at least any time soon), we > > can attempt to do so. > > If there are specific things in the spec that you think are bad and should > be removed, please do raise them on the mailing list, yes. > I think we're reasonably certain that *HD methods should be removed, but those are the only solid ones. > > If there are specific things not in the spec that you have implemented, > then please file a bug pointing to the documentation for whatever you have > implemented, using: http://whatwg.org/newbug > > If there's multiple implementations, and HTML is the right spec, then I'll > pretty much automatically spec it. Otherwise, it'll be based on whether it > makes sense and has use cases. (So far example, I haven't added canvas > text decoration APIs, which have been raised as something Chrome might > implement, as discussed in my last e-mail to this list. The alpha > parameter, though, needs speccing, I just haven't gotten around to it > yet -- it's on my list though.) > Great, I was wondering specifically about the status of the alpha attribute-- glad to hear it's just spec'ing that needs to happen, I wasn't clear on if this was blocked on "no new features" or not. Thanks! > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Re: [whatwg] Adding 2D Canvas features
On Thu, 5 Sep 2013, Tom Wiltzius wrote: > > Meanwhile this doesn't change the other Canvas2D-related work ongoing in > the Chromium project, so we're still keen to see some new features added > to the Canvas spec. Ian if it would help to identify items in the spec > that Chromium doesn't intend to implement (at least any time soon), we > can attempt to do so. If there are specific things in the spec that you think are bad and should be removed, please do raise them on the mailing list, yes. If there are specific things not in the spec that you have implemented, then please file a bug pointing to the documentation for whatever you have implemented, using: http://whatwg.org/newbug If there's multiple implementations, and HTML is the right spec, then I'll pretty much automatically spec it. Otherwise, it'll be based on whether it makes sense and has use cases. (So far example, I haven't added canvas text decoration APIs, which have been raised as something Chrome might implement, as discussed in my last e-mail to this list. The alpha parameter, though, needs speccing, I just haven't gotten around to it yet -- it's on my list though.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding 2D Canvas features
On Thu, Sep 5, 2013 at 3:19 PM, Simon Sarris wrote: > Just FYI, Chrome now has a relatively new bug for "Canvas v5 API > additions" that references all the missing features that some posters were > concerned about. > > The default take from this bug report is that all of these are > greenlighted to be worked on (no objections so far) > > https://code.google.com/p/chromium/issues/detail?id=281529 > > This bug is now (as of a few days ago) referenced at chromestatus.comunder > the Canvas feature's implementation status: > > http://www.chromestatus.com/features/5100084685438976 > Yes, although that's probably somewhat misleading as the Chromium contributor who volunteered to help implement those is only human and it's a rather long list. I'll be working with him to prioritize, but it's not like suddenly these can all happen. Meanwhile this doesn't change the other Canvas2D-related work ongoing in the Chromium project, so we're still keen to see some new features added to the Canvas spec. Ian if it would help to identify items in the spec that Chromium doesn't intend to implement (at least any time soon), we can attempt to do so. > > > Simon >
Re: [whatwg] Adding 2D Canvas features
Just FYI, Chrome now has a relatively new bug for "Canvas v5 API additions" that references all the missing features that some posters were concerned about. The default take from this bug report is that all of these are greenlighted to be worked on (no objections so far) https://code.google.com/p/chromium/issues/detail?id=281529 This bug is now (as of a few days ago) referenced at chromestatus.com under the Canvas feature's implementation status: http://www.chromestatus.com/features/5100084685438976 Simon
Re: [whatwg] Adding 2D Canvas features
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
Yes, those should be taken out. On Tue, Jul 9, 2013 at 8:40 AM, Stephen White wrote: > Conversely, if it helps to bring the spec closer to the implementations, > one thing we do not intend to implement in Chrome is the automatic high-DPI > canvas scaling (ie., auto-doubling of backing stores, getImageDataHD(), > putImageDataHD(), etc). > > I believe Apple has also announced that they are dropping support for this > in Safari 7. > > Stephen > > > > On Fri, Jun 28, 2013 at 3: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: >> > > >> > > 11399Locking individual color channels (e.g. drawing to >> alpha >> > > only) >> > > 21835Path object should have a way to add paths keeping >> only >> > > the union given a fill rule >> > > 21939Path objects would be much more useful if their >> > > individual commands (moveTo, lineTo, etc.) could be >> > > inspected from JavaScript [...] >> > > 8794 lineWidth = 'hairline' >> > > 11739clearPath() that clears pixels the way clearRect() >> does, >> > > but using a path >> > > 9236 Detecting the intersection of Path objects >> > > 9235 perspective transformations >> > > 18751a way to get the coordinate of the last point in a >> path >> > > 21346Have 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. >> > > >> > > -- >> > >
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
Conversely, if it helps to bring the spec closer to the implementations, one thing we do not intend to implement in Chrome is the automatic high-DPI canvas scaling (ie., auto-doubling of backing stores, getImageDataHD(), putImageDataHD(), etc). I believe Apple has also announced that they are dropping support for this in Safari 7. Stephen On Fri, Jun 28, 2013 at 3: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: > > > > > > 11399Locking individual color channels (e.g. drawing to > alpha > > > only) > > > 21835Path object should have a way to add paths keeping > only > > > the union given a fill rule > > > 21939Path objects would be much more useful if their > > > individual commands (moveTo, lineTo, etc.) could be > > > inspected from JavaScript [...] > > > 8794 lineWidth = 'hairline' > > > 11739clearPath() that clears pixels the way clearRect() > does, > > > but using a path > > > 9236 Detecting the intersection of Path objects > > > 9235 perspective transformations > > > 18751a way to get the coordinate of the last point in a > path > > > 21346Have 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. > `._.-(,_..'--(,_..'`-.;.' > > > > > >
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
On Mon, Jul 8, 2013 at 9:01 AM, Jonas Sicking wrote: > > On Jul 3, 2013 4:38 PM, "Justin Novosad" wrote: > > > > On Mon, Jul 1, 2013 at 3:15 PM, Tom Wiltzius > wrote: > > > > > On Sun, Jun 30, 2013 at 11:49 PM, Mark Callow < > callow.m...@artspark.co.jp > > > >wrote: > > > > > > > I thought some pretty strong objections were raised to text > decoration. > > > > Why are you actively developing it? > > > > > > > > > > There were some concerns cited, as well as some unresolved debate > about the > > > exact shape of the API, but my read is that the objections aren't > > > sufficiently fundamental to block prototyping (such that we might gain > some > > > implementation experience to inform the API's development). > > > > > > > > The strong objections were more general opposition to the use of text in > 2D > > canvas because of its various shortcomings (accessibility, crawling, etc) > > IMHO, that is a completely different debate than the question of whether > or > > not the canvas text should have more bells and whistles. > > That seems highly related. Adding more features to functionality that is > bad for users seems to encourage authors to create pages that are bad for > users. Also, it seems strange to spend time implementing new features while > actively discouraging people from using them. > > / Jonas > Even though text in canvases is generally discouraged, there are still valid cases where it is a desirable feature. For better or worse, canvas text is already out there and being used in many places; in games and interactive apps in particular. The way to move forward from here is to fix the problems we are currently facing with canvas text rather than stopping to improve text in hopes that people will abandon it so that we'll someday be able to deprecate it. Making canvas text friendlier to the web is possible, but I'll admit we have a long way to go. A big step in that direction is the canvas HitRegion feature, which we intend to implement in Blink. It will be possible to use HitRegions to make canvas text scrape-able (i.e. screen reader friendly, searchable, etc.). -Justin
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
On Jul 3, 2013 4:38 PM, "Justin Novosad" wrote: > > On Mon, Jul 1, 2013 at 3:15 PM, Tom Wiltzius wrote: > > > On Sun, Jun 30, 2013 at 11:49 PM, Mark Callow < callow.m...@artspark.co.jp > > >wrote: > > > > > I thought some pretty strong objections were raised to text decoration. > > > Why are you actively developing it? > > > > > > > There were some concerns cited, as well as some unresolved debate about the > > exact shape of the API, but my read is that the objections aren't > > sufficiently fundamental to block prototyping (such that we might gain some > > implementation experience to inform the API's development). > > > > > The strong objections were more general opposition to the use of text in 2D > canvas because of its various shortcomings (accessibility, crawling, etc) > IMHO, that is a completely different debate than the question of whether or > not the canvas text should have more bells and whistles. That seems highly related. Adding more features to functionality that is bad for users seems to encourage authors to create pages that are bad for users. Also, it seems strange to spend time implementing new features while actively discouraging people from using them. / Jonas
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
On Mon, Jul 1, 2013 at 3:15 PM, Tom Wiltzius wrote: > On Sun, Jun 30, 2013 at 11:49 PM, Mark Callow >wrote: > > > I thought some pretty strong objections were raised to text decoration. > > Why are you actively developing it? > > > > There were some concerns cited, as well as some unresolved debate about the > exact shape of the API, but my read is that the objections aren't > sufficiently fundamental to block prototyping (such that we might gain some > implementation experience to inform the API's development). > > The strong objections were more general opposition to the use of text in 2D canvas because of its various shortcomings (accessibility, crawling, etc) IMHO, that is a completely different debate than the question of whether or not the canvas text should have more bells and whistles.
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
On Sun, Jun 30, 2013 at 11:49 PM, Mark Callow wrote: > On 2013/06/29 4:30, Tom Wiltzius wrote: > > The only major Canvas2D features being actively developed in Chromium right > now are: > > - having a canvas context "alpha" attribute > - text decoration > > I thought some pretty strong objections were raised to text decoration. > Why are you actively developing it? > There were some concerns cited, as well as some unresolved debate about the exact shape of the API, but my read is that the objections aren't sufficiently fundamental to block prototyping (such that we might gain some implementation experience to inform the API's development). More to the point of this thread, this feature is being implemented behind a flag in Chromium and presumably won't be enabled by default until such a time as it appears to have a hope of being standard. My only question is whether it's really the case that no new features will be added to the Canvas2D spec until some of the existing features without implementions are implemented. I also hoped to address Ian's implied question about what browsers are interested in implementing what features by pointing out what's currently going on in Chromium. If, as Rik suggests, this moratorium isn't serious enough to block features that are being implemented and that have buy-in from multiple browsers, then I have no further concerns. > Regards > > -Mark > -- > 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 > 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます. > > NOTE: This electronic mail message may contain confidential and privileged > information from HI Corporation. If you are not the intended recipient, any > disclosure, photocopying, distribution or use of the contents of the > received information is prohibited. If you have received this e-mail in > error, please notify the sender immediately and permanently delete this > message and all related copies. >
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
On 2013/06/29 4:30, Tom Wiltzius wrote: > The only major Canvas2D features being actively developed in Chromium right > now are: > > - having a canvas context "alpha" attribute > - text decoration I thought some pretty strong objections were raised to text decoration. Why are you actively developing it? Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
On Fri, Jun 28, 2013 at 7:01 PM, 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.
>
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
>
>> 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 d
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
On Fri, Jun 28, 2013 at 6:35 PM, Tom Wiltzius wrote: > 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. > 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.) > > 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. > 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. For instance, is google following up with mozilla to land the context "alpha" attribute or talking to Safari if they can implement it? > > > 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: > > 11399Locking individual color channels (e.g. drawing to alpha > only) > 21835Path object should have a way to add paths keeping only > the union given a fill rule > 21939Path objects would be much more useful if their > individual commands (moveTo, lineTo, etc.) could be > inspected from JavaScript [...] > 8794 lineWidth = 'hairline' > 11739clearPath() that clears pixels the way clearRect() does, > but using a path > 9236 Detecting the intersection of Path objects > 9235 perspective transformations > 18751a way to get the coordinate of the last point in a path > 21346Have ImageBitmap expose height and
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
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:
> >>> >
> >>> > 11399Locking individual color channels (e.g. drawing to
>
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
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: >>> > >>> > 11399Locking individual color channels (e.g. drawing to >>> alpha >>> > only) >>> > 21835Path object should have a way to add paths keeping >>> only >>> > the union given a fill rule >>> > 21939Path objects would be much more useful if their >>> > individual commands (moveTo, lineTo, etc.) could be >>> > inspected from JavaScript [...] >>> > 8794 lineWidth = 'hairline' >>> > 11739clearPath() that clears pixels the way clearRect() >>> does, >>> > but using a path >>> > 9236 Detecting the intersection of Path objects >>> > 9235 perspective transformations >>> > 18751a way to get the coordinate of the last point in a >>> path >>> > 21346Have 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 t
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
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: >> > >> > 11399Locking individual color channels (e.g. drawing to >> alpha >> > only) >> > 21835Path object should have a way to add paths keeping only >> > the union given a fill rule >> > 21939Path objects would be much more useful if their >> > individual commands (moveTo, lineTo, etc.) could be >> > inspected from JavaScript [...] >> > 8794 lineWidth = 'hairline' >> > 11739clearPath() that clears pixels the way clearRect() >> does, >> > but using a path >> > 9236 Detecting the intersection of Path objects >> > 9235 perspective transformations >> > 18751a way to get the coordinate of the last point in a path >> > 21346Have 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. `._.-(,_..'--(,_..'`-.;.' >> > >> > >
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
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: > > > > 11399Locking individual color channels (e.g. drawing to alpha > > only) > > 21835Path object should have a way to add paths keeping only > > the union given a fill rule > > 21939Path objects would be much more useful if their > > individual commands (moveTo, lineTo, etc.) could be > > inspected from JavaScript [...] > > 8794 lineWidth = 'hairline' > > 11739clearPath() that clears pixels the way clearRect() does, > > but using a path > > 9236 Detecting the intersection of Path objects > > 9235 perspective transformations > > 18751a way to get the coordinate of the last point in a path > > 21346Have 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. `._.-(,_..'--(,_..'`-.;.' > > >
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
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: > > 11399Locking individual color channels (e.g. drawing to alpha > only) > 21835Path object should have a way to add paths keeping only > the union given a fill rule > 21939Path objects would be much more useful if their > individual commands (moveTo, lineTo, etc.) could be > inspected from JavaScript [...] > 8794 lineWidth = 'hairline' > 11739clearPath() that clears pixels the way clearRect() does, > but using a path > 9236 Detecting the intersection of Path objects > 9235 perspective transformations > 18751a way to get the coordinate of the last point in a path > 21346Have 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. `._.-(,_..'--(,_..'`-.;.' >
Re: [whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
On Jun 14, 2013, at 10:42 AM, Ian Hickson wrote: > 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. I think that is exactly the point of Rik's mail. Figure out if people are interested and get the propriety of this feature. I think this is a very important part and I would like to see blending and filters on groups. I think using layers is the way to go for that. It is also the way graphic libraries group elements internally for graphical operations. I checked CG, Cairo Graphics, Rik checked Direct2D/3D and it is possible to implement there. Brian confirms that Skia does it the same way. (As a matter of fact, if it wouldn't, it would never have been possible to run WebKit/Blink on top of Skia.) So other than a lot of the not implemented parts of the spec, this is something that can be implemented cross browsers. As you say, the question is just if browser vendors will support it. Greetings, Dirk
[whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
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: 11399Locking individual color channels (e.g. drawing to alpha only) 21835Path object should have a way to add paths keeping only the union given a fill rule 21939Path objects would be much more useful if their individual commands (moveTo, lineTo, etc.) could be inspected from JavaScript [...] 8794 lineWidth = 'hairline' 11739clearPath() that clears pixels the way clearRect() does, but using a path 9236 Detecting the intersection of Path objects 9235 perspective transformations 18751a way to get the coordinate of the last point in a path 21346Have 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. `._.-(,_..'--(,_..'`-.;.'
