Re: [whatwg] [canvas] Path object
On Tue, Oct 9, 2012 at 1:29 AM, Ian Hickson i...@hixie.ch wrote: We could only change Path, since the others are already deployed. We could add new constructors, but that would just be new redundancy, and thus probably isn't worth it. FWIW, I think adding new constructors to make things more convenient for authors can definitely be worth it. E.g. I'm strongly considering adding new Document() so you no longer need document.implementation.createDocument(..., ..., ...). Similarly we already added new Event() and friends to substantially improve the custom events situation. -- http://annevankesteren.nl/
Re: [whatwg] [canvas] Path object
On Tue, 9 Oct 2012, Anne van Kesteren wrote: On Tue, Oct 9, 2012 at 1:29 AM, Ian Hickson i...@hixie.ch wrote: We could only change Path, since the others are already deployed. We could add new constructors, but that would just be new redundancy, and thus probably isn't worth it. FWIW, I think adding new constructors to make things more convenient for authors can definitely be worth it. E.g. I'm strongly considering adding new Document() so you no longer need document.implementation.createDocument(..., ..., ...). Similarly we already added new Event() and friends to substantially improve the custom events situation. For new features I completely agree, but for old features we have to be really careful about not adding redundancy, IMHO. Events are used quite a lot and the new constructors did much more than just make the API consistent -- it also made it way simpler, to the point where what was three lines of code with dozens of ambiguous arguments is now a single line of very readable code. With the canvas objects it's not at all clear to me that we'd get the same win. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] Path object
On Sat, 22 Sep 2012, Elliott Sprehn 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. The name is based in part on the idea that it should be useful outside of Canvas as well. The old names are legacy we can't change. We also have createLinearGradient() and createPattern(), but this new thing is new Path. As a general rule on the platform as a whole we're moving towards constructors. The gradient and pattern objects, again, are a legacy that we can't change (we could add redundant constructors as well, but generally I recommend against adding redundancy as it doesn't add anything useful but does add confusion and implementation costs). On Tue, 2 Oct 2012, Elliott Sprehn 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. We've added tons of stuff to Window, and I'm sure we'll add more. The question is just whether it causes breakage; if it does, we'll change the name. That's what implementation testing is for. :-) As a general rule, capitalised names like Path aren't usually a big deal. On Tue, 2 Oct 2012, Elliott Sprehn wrote: What about unifying all of these as: new GraphicsPath() new GraphicsLinearGradient() new GraphicsRadialGradient() new GraphicsPattern() and fixing HTML5 canvas to support these new constructors instead? We could only change Path, since the others are already deployed. We could add new constructors, but that would just be new redundancy, and thus probably isn't worth it. @hixie: How was it decided that this wasn't going to break the web? It wasn't. That remains to be seen. On Wed, 3 Oct 2012, Simon Pieters wrote: $ grep -aPc \s(?i:(id|name))\s*=\s*(\|')?Path((\|')|(\s||/)) web200904 85 85 out of ~600,000 pages is 0.014%. Not too small (about an order of magnitude more than the number of XHTML pages served as XML I found a few years ago in Google's index), but still pretty small. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] Path object
On Wed, Oct 3, 2012 at 10:08 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/3/12 11:04 PM, Boris Zbarsky wrote: I decided it wasn't worth punishing our users further if no one else in the world cared about this. (I hope the other browser vendors' rationale isn't actually not caring about it.) Oh, and for the record we added gsp support in standards mode in Firefox 14. We kept the warning when it was used until Firefox 15, somewhat by accident; at that point we removed it, since warning on something every UA implements and the spec requires is a bit pointless. It's not pointless: it discourages people from doing things that increase the chances of their page breaking in the future, and makes it easier for developers to ensure their own code isn't doing it by accident. (Of course, it would be nice to do this in validators, but that's not very practical with static analysis.) -- Glenn Maynard
Re: [whatwg] [canvas] Path object
On 10/5/12 4:59 PM, Glenn Maynard wrote: (I hope the other browser vendors' rationale isn't actually not caring about it.) Some of them simply care about backwards compat more than about getting rid of the global scope polluter. But some, as far as I can tell, really don't care at all. Like don't respond to any questions on the matter. But the upshot is the same. Oh, and for the record we added gsp support in standards mode in Firefox 14. We kept the warning when it was used until Firefox 15, somewhat by accident; at that point we removed it, since warning on something every UA implements and the spec requires is a bit pointless. It's not pointless: it discourages people from doing things that increase the chances of their page breaking in the future, and makes it easier for developers to ensure their own code isn't doing it by accident. Yes, but at the cost of performance and memory usage that just doesn't seem worthwhile here. And web developers get annoyed when UAs warn about various spec-compliant stuff they're doing, in my experience. So here we are. -Boris
Re: [whatwg] [canvas] Path object
On Fri, Oct 5, 2012 at 4:17 PM, Boris Zbarsky bzbar...@mit.edu wrote: Yes, but at the cost of performance and memory usage that just doesn't seem worthwhile here. Is there really a nontrivial cost to a one-time warning, the first time a window attribute is resolved this way? (Warning once per ID would be nice, but warning once per page load serves the purpose.) It sounds like a single branch at most. And web developers get annoyed when UAs warn about various spec-compliant stuff they're doing, in my experience. I'm a web developer, and I get annoyed at not being told when I'm doing something obviously bad, so you'll have to pick which group to annoy: people who want to write reliable webpages, or those who don't. -- Glenn Maynard
Re: [whatwg] [canvas] Path object
Can you please move this discussion to another thread and discuss the Path object on this thread? Greetings, Dirk On Oct 5, 2012, at 2:56 PM, Glenn Maynard gl...@zewt.org wrote: On Fri, Oct 5, 2012 at 4:17 PM, Boris Zbarsky bzbar...@mit.edu wrote: Yes, but at the cost of performance and memory usage that just doesn't seem worthwhile here. Is there really a nontrivial cost to a one-time warning, the first time a window attribute is resolved this way? (Warning once per ID would be nice, but warning once per page load serves the purpose.) It sounds like a single branch at most. And web developers get annoyed when UAs warn about various spec-compliant stuff they're doing, in my experience. I'm a web developer, and I get annoyed at not being told when I'm doing something obviously bad, so you'll have to pick which group to annoy: people who want to write reliable webpages, or those who don't. -- Glenn Maynard
Re: [whatwg] [canvas] Path object
On Oct 2, 2012, at 4:58 PM, Elliott Sprehn espr...@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 Wed, 03 Oct 2012 05:12:46 +0200, Maciej Stachowiak m...@apple.com wrote: Can we get data on prevalence of such pages? Data set: http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/ $ grep -aPc \s(?i:(id|name))\s*=\s*(\|')?Path((\|')|(\s||/)) stevef-all 0 $ grep -aPc \s(?i:(id|name))\s*=\s*(\|')?Audio((\|')|(\s||/)) stevef-all 2 $ grep -aPc \s(?i:(id|name))\s*=\s*(\|')?URL((\|')|(\s||/)) stevef-all 18 Data set: http://dotnetdotcom.org/ $ grep -aPc \s(?i:(id|name))\s*=\s*(\|')?Path((\|')|(\s||/)) web200904 85 $ grep -aPc \s(?i:(id|name))\s*=\s*(\|')?Audio((\|')|(\s||/)) web200904 27 $ grep -aPc \s(?i:(id|name))\s*=\s*(\|')?URL((\|')|(\s||/)) web200904 1357 (I don't have data on how many of these also do something like form onsubmit=return validate(URL) etc.) -- Simon Pieters Opera Software
Re: [whatwg] [canvas] Path object
On 10/3/12 1:31 AM, Charles Pritchard wrote: Mozilla has an extensive system for bug reporting. You mean like a bug database? I suspect their switch between various versions is related to their data as captured by those systems. I suspect that's bollocks, with all due respect. They have publicized how they track bug reports from the browser, and in doing so, how they analyze what breaks the web. I am unaware of such a system. Link please? I'd really like to make use of it, if it exists. ;) -Boris
Re: [whatwg] [canvas] Path object
This subthread has crossed the line of what is acceptable on this mailing list. I'd like to remind everyone that discussion on this list should focus on technical issues and not on process discussions, and that all communication should be respectful, and avoid presenting wild speculation as facts. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] Path object
On Wed, Oct 3, 2012 at 2:01 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Oct 2, 2012 at 7:16 PM, Charles Pritchard ch...@jumis.com wrote: I think moz already made the move to require document.getElementById for these cases. It looks like they did in FF13 (in standards mode, not quirks mode), but no longer in FF15. I'm surprised this was even considered, never mind deployed--it must break tons of pages. Gecko *always* required getElementById in standards mode, until FF15. That's why most pages worked (and still do) without element IDs in the global scope. But no-one else was willing to follow suit, so we dropped it. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [whatwg] [canvas] Path object
On Wed, Oct 3, 2012 at 8:44 PM, Robert O'Callahan rob...@ocallahan.orgwrote: Gecko *always* required getElementById in standards mode, until FF15. That's why most pages worked (and still do) without element IDs in the global scope. But no-one else was willing to follow suit, so we dropped it. That's unfortunate. It's one of the most pathologically broken behaviors on the platform; now there will be nothing discouraging people from using it. I think this was a net win despite the cost to interoperability. -- Glenn Maynard
Re: [whatwg] [canvas] Path object
On 10/3/12 10:19 PM, Glenn Maynard wrote: That's unfortunate. It's one of the most pathologically broken behaviors on the platform; now there will be nothing discouraging people from using it. I think this was a net win despite the cost to interoperability. That is as may be, but: 1) Every single other UA implemented the global scope polluter in standards mode. 2) The spec called for it to be implemented in standards mode. Repeated requests that the spec be changed got denied with see point 1. 3) Repeated requests for other UAs to drop support for the global scope polluter in standards mode were met with either silence or great surprise that Gecko had the behavior it did, followed by silence. 4) The growing number of web developers who only bother testing in WebKit meant that there were more and more sites that were breaking in Gecko due to relying on the global scope polluter. 5) Other browser vendors were putting out conformance and performance tests that relied on the global scope polluter to function. I decided it wasn't worth punishing our users further if no one else in the world cared about this. -Boris
Re: [whatwg] [canvas] Path object
On 10/3/12 11:04 PM, Boris Zbarsky wrote: I decided it wasn't worth punishing our users further if no one else in the world cared about this. Oh, and for the record we added gsp support in standards mode in Firefox 14. We kept the warning when it was used until Firefox 15, somewhat by accident; at that point we removed it, since warning on something every UA implements and the spec requires is a bit pointless. -Boris
Re: [whatwg] [canvas] Path object
On Sat, Sep 22, 2012 at 9:17 PM, Elliott Sprehn espr...@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
Re: [whatwg] [canvas] Path object
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. jackalm...@gmail.com wrote: On Sat, Sep 22, 2012 at 9:17 PM, Elliott Sprehn espr...@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
Re: [whatwg] [canvas] Path object
On Oct 2, 2012, at 3:00 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sat, Sep 22, 2012 at 9:17 PM, Elliott Sprehn espr...@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. We could have createPath() on the 2d context object return an opaque CanvasPath object without stepping on any toes with the SVGWG. Presently, with Canvas, I was hoping for a bit of stability-- the suggestion of deprecating the createGradient and pattern methods seems to be going in the other direction, further blurring the boundaries of the API. -Charles
Re: [whatwg] [canvas] Path object
On Tue, Oct 2, 2012 at 4:58 PM, Elliott Sprehn espr...@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. It would have been useful to bring this up as a problem in your original email. ^_^ I have no opinion on this. Its effect depends entirely on how much breakage it actually causes. ~TJ
Re: [whatwg] [canvas] Path object
On Oct 2, 2012, at 5:09 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Oct 2, 2012 at 4:58 PM, Elliott Sprehn espr...@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. It would have been useful to bring this up as a problem in your original email. ^_^ I have no opinion on this. Its effect depends entirely on how much breakage it actually causes. I think moz already made the move to require document.getElementById for these cases.
Re: [whatwg] [canvas] Path object
On Tue, Oct 2, 2012 at 6:01 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Oct 2, 2012 at 4:58 PM, Elliott Sprehn espr...@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. Surely it's not a non-starter in general, or else no new APIs could ever be added to the platform--at worst it just means picking a less generic name. I assume that's not strictly needed; URL must be a more common ID than Path. (Path makes me think of URL paths, though. Something like DrawPath would be a little clearer.) What about unifying all of these as: new GraphicsPath() new GraphicsLinearGradient() new GraphicsRadialGradient() new GraphicsPattern() and fixing HTML5 canvas to support these new constructors instead? I'm a little surprised about the window.URL change that went through recently. There must be tons of input id=URL's around, and lots of old form generating code accessed them through window.id. @hixie: How was it decided that this wasn't going to break the web? - E
Re: [whatwg] [canvas] Path object
On Oct 2, 2012, at 6:05 PM, Elliott Sprehn espr...@gmail.com wrote: On Tue, Oct 2, 2012 at 6:01 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Oct 2, 2012 at 4:58 PM, Elliott Sprehn espr...@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. Surely it's not a non-starter in general, or else no new APIs could ever be added to the platform--at worst it just means picking a less generic name. I assume that's not strictly needed; URL must be a more common ID than Path. (Path makes me think of URL paths, though. Something like DrawPath would be a little clearer.) What about unifying all of these as: new GraphicsPath() new GraphicsLinearGradient() new GraphicsRadialGradient() new GraphicsPattern() and fixing HTML5 canvas to support these new constructors instead? I'm a little surprised about the window.URL change that went through recently. There must be tons of input id=URL's around, and lots of old form generating code accessed them through window.id. @hixie: How was it decided that this wasn't going to break the web? Mozilla has a massive platform for collecting and analyzing user/software feedback. I'd imagine they've got good metrics on web-breaking moves. Chrome, from my experience, relies on bug reports on their issues site; Microsoft and Apple go slow and keep things opaque/in-house. WHATWG watches, suggests and makes changes based on the eventual consensus. As for html5 Canvas; other than the accessibility issues addressed in the past two years, I wouldn't say it's broken. We're now looking at a new version of it. I think it was called version 5 by Hixie. I wanted vendors to solidify consensus on a version close to what currently exists, with minor changes for accessibility. The WHATWG and W3C have chosen instead to make broad changes, as proposed in version 5/the Hixie-Atkins draft. So, it's on the table. As always, browser vendors will decide on the actual direction. I'm still for making a snapshot with createPath and an opaque CanvasPath, and saving version 5 for the more distant 3-year future and HTML6. The W3C and WHATWG have gone ahead with version 5, with support from an Apple employee. -Charles
Re: [whatwg] [canvas] Path object
On Tue, Oct 2, 2012 at 6:22 PM, Charles Pritchard ch...@jumis.com wrote: I wanted vendors to solidify consensus on a version close to what currently exists, with minor changes for accessibility. The WHATWG and W3C have chosen instead to make broad changes, as proposed in version 5/the Hixie-Atkins draft. Out of curiosity, why are you using the term the Hixie-Atkins draft? That usage seems bizarre. ~TJ
Re: [whatwg] [canvas] Path object
On Oct 2, 2012, at 6:25 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Oct 2, 2012 at 6:22 PM, Charles Pritchard ch...@jumis.com wrote: I wanted vendors to solidify consensus on a version close to what currently exists, with minor changes for accessibility. The WHATWG and W3C have chosen instead to make broad changes, as proposed in version 5/the Hixie-Atkins draft. Out of curiosity, why are you using the term the Hixie-Atkins draft? That usage seems bizarre. The two of you composed an submitted the change in its entirety; it's a large departure in IDL from earlier drafts which reflected implementations as initiated by Apple's draft. The draft is a synthesis of what appears to be two years of feedback from developers and others on the WHATWG and W3C mailing lists. All of the methods were first proposed in the draft; they were not proposed in their IDL form by others. In it's introduction, and the discussion surrounding its introduction, I noticed that Atkins and Hixie had worked to create a coherent proposal based on input; Hixie has expressed directly that he'd prefer to see use cases, not IDL/spec proposals. -Charles
Re: [whatwg] [canvas] Path object
On Tue, Oct 2, 2012 at 6:34 PM, Charles Pritchard ch...@jumis.com wrote: On Oct 2, 2012, at 6:25 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Oct 2, 2012 at 6:22 PM, Charles Pritchard ch...@jumis.com wrote: I wanted vendors to solidify consensus on a version close to what currently exists, with minor changes for accessibility. The WHATWG and W3C have chosen instead to make broad changes, as proposed in version 5/the Hixie-Atkins draft. Out of curiosity, why are you using the term the Hixie-Atkins draft? That usage seems bizarre. The two of you composed an submitted the change in its entirety; it's a large departure in IDL from earlier drafts which reflected implementations as initiated by Apple's draft. The draft is a synthesis of what appears to be two years of feedback from developers and others on the WHATWG and W3C mailing lists. All of the methods were first proposed in the draft; they were not proposed in their IDL form by others. In it's introduction, and the discussion surrounding its introduction, I noticed that Atkins and Hixie had worked to create a coherent proposal based on input; Hixie has expressed directly that he'd prefer to see use cases, not IDL/spec proposals. I have absolutely no idea what you are talking about. I didn't write any of the canvas spec. I've given feedback on the list, but not significantly more than others interested in the topic. I did help brainstorm some of the interface stuff in #whatwg when Hixie was writing it, but so did others. Calling it the Hixie-Atkins draft is unwarranted and weird. Just call it the whatwg canvas spec or something. ~TJ
Re: [whatwg] [canvas] Path object
On Oct 2, 2012, at 6:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Oct 2, 2012 at 6:34 PM, Charles Pritchard ch...@jumis.com wrote: On Oct 2, 2012, at 6:25 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Oct 2, 2012 at 6:22 PM, Charles Pritchard ch...@jumis.com wrote: I wanted vendors to solidify consensus on a version close to what currently exists, with minor changes for accessibility. The WHATWG and W3C have chosen instead to make broad changes, as proposed in version 5/the Hixie-Atkins draft. Out of curiosity, why are you using the term the Hixie-Atkins draft? That usage seems bizarre. The two of you composed an submitted the change in its entirety; it's a large departure in IDL from earlier drafts which reflected implementations as initiated by Apple's draft. The draft is a synthesis of what appears to be two years of feedback from developers and others on the WHATWG and W3C mailing lists. All of the methods were first proposed in the draft; they were not proposed in their IDL form by others. In it's introduction, and the discussion surrounding its introduction, I noticed that Atkins and Hixie had worked to create a coherent proposal based on input; Hixie has expressed directly that he'd prefer to see use cases, not IDL/spec proposals. I have absolutely no idea what you are talking about. I didn't write any of the canvas spec. I've given feedback on the list, but not significantly more than others interested in the topic. I did help brainstorm some of the interface stuff in #whatwg when Hixie was writing it, but so did others. Calling it the Hixie-Atkins draft is unwarranted and weird. Just call it the whatwg canvas spec or something. I apologize for overemphasizing your involvement. It seems that it would have been more appropriate to call it the Hixie spec. That WHATWG as a forum did not vet nor develop a public consensus about the proposal; it's the work of a single author in contrast to earlier Canvas specifications. It recommends, it does not document. I appreciate your continued collaboration with Hixie, I am sorry I mischaracterized it on this and other forums. At this point, it does seem appropriate to call it a proposal. No vendors have implemented the changes. -Charles
Re: [whatwg] [canvas] Path object
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 m...@apple.com wrote: Can we get data on prevalence of such pages? - Maciej On Oct 2, 2012, at 4:58 PM, Elliott Sprehn espr...@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. jackalm...@gmail.com wrote: On Sat, Sep 22, 2012 at 9:17 PM, Elliott Sprehn espr...@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
Re: [whatwg] [canvas] Path object
Charles, Your whole message here is bizarre and disruptive: - Your claims about the data gathering capabilities of varying browser vendors are arbitrary, incorrect (in the cases I know of), and off-topic for this list. - Your reference to the Hixie-Atkins draft is unwarranted and strange. - There has been no announcement of HTML6, let alone a schedule for it. - Mysteriously citing an Apple employee also seems strange and rude. Please reconsider this style of communication, and let's stick to discussion of actual technical issues on this list. Regards, Maciej On Oct 2, 2012, at 6:22 PM, Charles Pritchard ch...@jumis.com wrote: On Oct 2, 2012, at 6:05 PM, Elliott Sprehn espr...@gmail.com wrote: On Tue, Oct 2, 2012 at 6:01 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Oct 2, 2012 at 4:58 PM, Elliott Sprehn espr...@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. Surely it's not a non-starter in general, or else no new APIs could ever be added to the platform--at worst it just means picking a less generic name. I assume that's not strictly needed; URL must be a more common ID than Path. (Path makes me think of URL paths, though. Something like DrawPath would be a little clearer.) What about unifying all of these as: new GraphicsPath() new GraphicsLinearGradient() new GraphicsRadialGradient() new GraphicsPattern() and fixing HTML5 canvas to support these new constructors instead? I'm a little surprised about the window.URL change that went through recently. There must be tons of input id=URL's around, and lots of old form generating code accessed them through window.id. @hixie: How was it decided that this wasn't going to break the web? Mozilla has a massive platform for collecting and analyzing user/software feedback. I'd imagine they've got good metrics on web-breaking moves. Chrome, from my experience, relies on bug reports on their issues site; Microsoft and Apple go slow and keep things opaque/in-house. WHATWG watches, suggests and makes changes based on the eventual consensus. As for html5 Canvas; other than the accessibility issues addressed in the past two years, I wouldn't say it's broken. We're now looking at a new version of it. I think it was called version 5 by Hixie. I wanted vendors to solidify consensus on a version close to what currently exists, with minor changes for accessibility. The WHATWG and W3C have chosen instead to make broad changes, as proposed in version 5/the Hixie-Atkins draft. So, it's on the table. As always, browser vendors will decide on the actual direction. I'm still for making a snapshot with createPath and an opaque CanvasPath, and saving version 5 for the more distant 3-year future and HTML6. The W3C and WHATWG have gone ahead with version 5, with support from an Apple employee. -Charles
Re: [whatwg] [canvas] Path object
On Oct 2, 2012, at 8:17 PM, Maciej Stachowiak m...@apple.com wrote: Charles, Your whole message here is bizarre and disruptive: - Your claims about the data gathering capabilities of varying browser vendors are arbitrary, incorrect (in the cases I know of), and off-topic for this list. Mozilla has an extensive system for bug reporting. I suspect their switch between various versions is related to their data as captured by those systems. They have publicized how they track bug reports from the browser, and in doing so, how they analyze what breaks the web. Posts on that system are public and available through web searches. Additionally, anyone with a computer and a few hundred dollars can run through something like common crawl for a quantitative analysis of general HTML content. If it's going to be more than that, I can't speak to MS and Apple practices as they are quite opaque. I can speak as a developer to another developer about Chromium practices having worked for some time to issue and follow up ok but reports with their system. I can point to release cycles, which are well documented on public sites like wikipedia. - Your reference to the Hixie-Atkins draft is unwarranted and strange. It's been my form of reference for several months without incident. Hixie put the proposal forward, Tab was actively discussing it on the lists, as well as a part of its synthesis. He has already spoken on the matter and you were present and subscribed to both lists it was discussed on. I addressed Tab Atkins in my last response. Tab does have a significant role in this process, as do you, but I seem to have misinterpreted his involvement in the authoring of the versions under discussion. - There has been no announcement of HTML6, let alone a schedule for it. It's referred to as HTML next, the W3C chairs as well as the change of editors has been a signifier of HTML5 wrapping up. The phrase has been in common use for some time. The schedule is about HTML5. - Mysteriously citing an Apple employee also seems strange and rude. We're on the Internet, public-canvas-API is a public mailing list and the w3c is a fairly transparent organization. There are several employees at Apple involved in the standards process. I apologize for the ambiguity. Please reconsider this style of communication, and let's stick to discussion of actual technical issues on this list. I've brought up versioning, API development and a prior proposal. Those are technical issues. I also spoke to another developer about the standards process; it's a process involving people as well as the technical. If developers are going to wade into this, I'd like to share a little bit about the atomosphere; if that's a cultural issue better left off-list, then I'm afraid I have little left to offer publicly. The W3C decision on the technical spec was quite transparent. The proposal is available on the W3C wiki and lists. Developers are free to read that log. I assume when they ask questions similar to the ones I've posed, they may be coming from a perspective similar to my own. I responded with informal but direct language about my own observations. I'm sorry that you found them disruptive. This has been a long process, I hope Canvas developers approaching the spec to understand some of the efforts put into it. If my efforts are counter-productive, that's certainly not my intent. I am aware of several public and private messages suggesting that my involvement is not aiding vendor-developers. I'd hoped to advocate for end-developers who are not code-contributors to browser vendors. That has been my intent. Regards, Maciej On Oct 2, 2012, at 6:22 PM, Charles Pritchard ch...@jumis.com wrote: On Oct 2, 2012, at 6:05 PM, Elliott Sprehn espr...@gmail.com wrote: On Tue, Oct 2, 2012 at 6:01 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Oct 2, 2012 at 4:58 PM, Elliott Sprehn espr...@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. Surely it's not a non-starter in general, or else no new APIs could ever be added to the platform--at worst it just means picking a less generic name. I assume that's not strictly needed; URL must be a more common ID than Path. (Path makes me think of URL paths, though. Something like DrawPath would be a little clearer.) What about unifying all of these as: new GraphicsPath() new GraphicsLinearGradient() new GraphicsRadialGradient() new GraphicsPattern() and fixing HTML5 canvas to support these new constructors instead? I'm a little surprised about the window.URL change that went through recently. There must be tons of input id=URL's around, and lots of old form generating code accessed them through window.id. @hixie: How was it decided that this wasn't going to break the web? Mozilla has a
Re: [whatwg] [canvas] Path object
We proposed this in the public-canvas-api working group. There may be some tricky parts with transforms. From an implementation perspective, createPath (returns opaque CanvasPath) and beginPath(CanvasPath) is the easiest and most direct. The tricky part happens when you're in a loop with transforms as: rotate(15); beginPath(createPath()); will rotate another 15 degrees because the transform is applied twice. Of course, if you've worked with canvas and pattern before, you're used to handling inverse transforms when appopriate. -Charles On Sep 22, 2012, at 9:17 PM, Elliott Sprehn espr...@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? - Elliott
