- From: Rik Cabanier <cabanier@gmail.com>
- Date: Tue, 2 Oct 2012 20:15:35 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: WHATWG <whatwg@whatwg.org>, Elliott Sprehn <esprehn@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
Yes, our friends from Google and maybe MS (through Bing?) should be able to run a query on their database. Rik On Tue, Oct 2, 2012 at 8:12 PM, Maciej Stachowiak <mjs@apple.com> wrote: > > Can we get data on prevalence of such pages? > > - Maciej > > On Oct 2, 2012, at 4:58 PM, Elliott Sprehn <esprehn@gmail.com> wrote: > > > What of the fact that this breaks existing pages with <input > > id="Path"> that access it as just Path? Historically this has been a > > non-starter for new APIs. > > > > On Tue, Oct 2, 2012 at 3:00 PM, Tab Atkins Jr. <jackalmage@gmail.com> > wrote: > >> On Sat, Sep 22, 2012 at 9:17 PM, Elliott Sprehn <esprehn@gmail.com> > wrote: > >>> I was looking at the canvas Path API and had some concerns. In > >>> particular it's inconsistent with the rest of canvas: > >>> > >>> We already have CanvasGradient and CanvasPattern in the global > >>> namespace, so this should probably be called CanvasPath. > >>> > >>> We also have createLinearGradient() and createPattern(), but this new > >>> thing is "new Path". > >>> > >>> Could we get some consistency here? Like adding new CanvasGradient() > >>> (or a createPath() method) to match up with Path and renaming this > >>> thing CanvasPath? > >> > >> I think the SVGWG would be opposed to that - we rather like the Path > >> api and would appreciate being able to appropriate it for our own uses > >> (merging with the <path> API). > >> > >> I'm fine with gradients/patterns moving to a plain constructor rather > >> than a factory method, though. > >> > >> ~TJ > >
Received on Wednesday, 3 October 2012 03:16:05 UTC