W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2015

Re: [whatwg] Splitting CanvasRenderingContext2D

From: Ian Kilpatrick <ikilpatrick@chromium.org>
Date: Tue, 1 Dec 2015 17:26:18 -0800
Message-ID: <CAJL3UpQbBMnkaCrYOnKCF7pBNfQ0mfL79KUP_mGuBAV9cGuRCw@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: whatwg <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
Great, thanks all.

I'll put together the start of a PR this week (just modifying the IDL) so
that we can start discussing name / where everything goes.

Thanks,
Ian

On Tue, Dec 1, 2015 at 12:11 PM, Justin Novosad <junov@google.com> wrote:

> I think it may be possible to do this refactor without changing the order
> of things since the current IDL has things grouped into categories that
> more or less map to what Ian is suggesting.
>
> I am currently in the middle of working on a pull request for the
> OffscreenCanvas propsal, and I have to say I would very much like to rebase
> it on top of what Ian is suggesting so that I could easily define an
> "OffscreenRenderingContext2D" that excludes or redefines APIs that interact
> with the Document or view.
>
> On Tue, Dec 1, 2015 at 11:55 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
> > On 12/1/15 11:40 AM, Domenic Denicola wrote:
> >
> >> Since it has no web-visible impact
> >>
> >
> > That may or may not be true.  For example, it's quite likely to change,
> in
> > practice, the enumeration order for properties on the obect.  Of course
> > there is no spec defining that enumeration order right now... but in
> > practice I believe UAs mostly do it in the IDL order.
> >
> > Normally I wouldn't worry about it, but there is known content out there
> > that depends on the enumeration order of _some_ things on this particular
> > interface.  See https://bugzilla.mozilla.org/show_bug.cgi?id=631117 and
> > https://bugzilla.mozilla.org/show_bug.cgi?id=623437 (note that these are
> > about different URLs, though caused by the same underlying issue).
> >
> > In practice I expect that an interface split that keeps arc() and arcTo()
> > together in this case will be OK.  I just want to point out that the risk
> > here is sadly nonzero.
> >
> > -Boris
> >
>
Received on Wednesday, 2 December 2015 01:26:51 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:36 UTC