Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Mon, 1 Oct 2012, Glenn Maynard wrote: Primary goals: + have the new page use a different event loop if possible (new process) + have the window of the new page not be able to reach the opener via a named window.open() or target= As a result, I think these are also necessary features: ... + have the new page be in a new browsing context It doesn't seem like you need a new browsing context to achieve both of the above. (Maybe it's easier to implement in today's multi-process browsers, if you happen to be opening a new tab at the same time you start a new process, but that seems like an implementation detail.) You need a new WindowProxy object, otherwise anything that had access to it before still has access, and thus can't be in a new event loop. Saying you need a new WindowProxy object is basically equivalent to saying you need a new browsing context. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On 10/02/2012 02:34 AM, Boris Zbarsky wrote: On 10/1/12 6:10 PM, Ian Hickson wrote: On Tue, 19 Jun 2012, Boris Zbarsky wrote: On 6/19/12 1:56 PM, Charlie Reis wrote: That's from the [if] the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other part, which is quite vague. This is, imo, the part that says unrelated browsing contexts should not be able to reach each other by name. It's only vague because hixie wanted all current implementations to be conforming, I think. Which I believe is a mistake. I'm happy to make the spec not match implementations, if the implementations are going to change to match the spec. :-) I certainly plan to change Gecko to make this stuff less lose there. I have no idea why this part of the spec is special enough to get undefined behaviour when we have tried to avoid it on general principle everywhere else.
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Tue, 2 Oct 2012, James Graham wrote: On 10/02/2012 02:34 AM, Boris Zbarsky wrote: On 10/1/12 6:10 PM, Ian Hickson wrote: On Tue, 19 Jun 2012, Boris Zbarsky wrote: On 6/19/12 1:56 PM, Charlie Reis wrote: That's from the [if] the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other part, which is quite vague. This is, imo, the part that says unrelated browsing contexts should not be able to reach each other by name. It's only vague because hixie wanted all current implementations to be conforming, I think. Which I believe is a mistake. I'm happy to make the spec not match implementations, if the implementations are going to change to match the spec. :-) I certainly plan to change Gecko to make this stuff less lose there. I have no idea why this part of the spec is special enough to get undefined behaviour when we have tried to avoid it on general principle everywhere else. Can you figure out how to describe what browsers do in more detail than the spec currently gives, and in a way where it makes sense to allow what that description covers but not subtly different things? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video feedback
On Sep 17, 2012, at 12:43 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 9 Jul 2012, adam k wrote: i have a 25fps video, h264, with a burned in timecode. it seems to be off by 1 frame when i compare the burned in timecode to the calculated timecode. i'm using rob coenen's test app at http://www.massive-interactive.nl/html5_video/smpte_test_universal.html to load my own video. what's the process here to report issues? please let me know whatever formal or informal steps are required and i'll gladly follow them. Depends on the browser. Which browser? i'm aware that crooked framerates (i.e. the notorious 29.97) were not supported when frame accuracy was implemented. in my tests, 29.97DF timecodes were incorrect by 1 to 3 frames at any given point. will there ever be support for crooked framerate accuracy? i would be more than happy to contribute whatever i can to help test it and make it possible. can someone comment on this? This is a Quality of Implementation issue, basically. I believe there's nothing inherently in the API that would make accuracy to such timecodes impossible. TLDR; for precise navigation, you need to use a a rational time class, rather than a float value. The nature of floating point math makes precise frame navigation difficult, if not impossible. Rob's test is especially hairy, given that each frame has a timing bound of [startTime, endTime), and his test attempts to navigate directly to the startTime of a given frame, a value which gives approximately zero room for error. I'm most familiar with MPEG containers, but I believe the following is also true of the WebM container: times are represented by a rational number, timeValue / timeScale, where both numerator and denominator are unsigned integers. To seek to a particular media time, we must convert a floating-point time value into this rational time format (e.g. when calculating the 4th frame's start time, from 3 * 1/29.97 to 3 * 1001/3). If there is a floating-point error in the wrong direction (e.g., as above, a numerator of 3002 vs 3003), the end result will not be the frame's startTime, but one timeScale before it. We've fixed some frame accuracy bugs in WebKit (and Chromium) by carefully rounding the incoming floating point time value, taking into account the media's time scale, and rounding to the nearest 1/timeScale value. This fixes Rob's precision test, but at the expense of precision. (I.e. in a 30 fps movie, currentTime = 0.99 / 30 will navigate to the second frame, not the first, due to rounding, which is technically incorrect.) This is a common problem, and Apple media frameworks (for example) therefore provide rational time classes which provide enough accuracy for precise navigation (e.g. QTTime, CMTime). Using a floating point number to represent time with any precision is not generally accepted as good practice when these rational time classes are available. -Jer
Re: [whatwg] video feedback
On Wed, Oct 3, 2012 at 6:41 AM, Jer Noble jer.no...@apple.com wrote: On Sep 17, 2012, at 12:43 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 9 Jul 2012, adam k wrote: i have a 25fps video, h264, with a burned in timecode. it seems to be off by 1 frame when i compare the burned in timecode to the calculated timecode. i'm using rob coenen's test app at http://www.massive-interactive.nl/html5_video/smpte_test_universal.html to load my own video. what's the process here to report issues? please let me know whatever formal or informal steps are required and i'll gladly follow them. Depends on the browser. Which browser? i'm aware that crooked framerates (i.e. the notorious 29.97) were not supported when frame accuracy was implemented. in my tests, 29.97DF timecodes were incorrect by 1 to 3 frames at any given point. will there ever be support for crooked framerate accuracy? i would be more than happy to contribute whatever i can to help test it and make it possible. can someone comment on this? This is a Quality of Implementation issue, basically. I believe there's nothing inherently in the API that would make accuracy to such timecodes impossible. TLDR; for precise navigation, you need to use a a rational time class, rather than a float value. The nature of floating point math makes precise frame navigation difficult, if not impossible. Rob's test is especially hairy, given that each frame has a timing bound of [startTime, endTime), and his test attempts to navigate directly to the startTime of a given frame, a value which gives approximately zero room for error. I'm most familiar with MPEG containers, but I believe the following is also true of the WebM container: times are represented by a rational number, timeValue / timeScale, where both numerator and denominator are unsigned integers. FYI: the Ogg container also uses rational numbers to represent time. To seek to a particular media time, we must convert a floating-point time value into this rational time format (e.g. when calculating the 4th frame's start time, from 3 * 1/29.97 to 3 * 1001/3). If there is a floating-point error in the wrong direction (e.g., as above, a numerator of 3002 vs 3003), the end result will not be the frame's startTime, but one timeScale before it. We've fixed some frame accuracy bugs in WebKit (and Chromium) by carefully rounding the incoming floating point time value, taking into account the media's time scale, and rounding to the nearest 1/timeScale value. This fixes Rob's precision test, but at the expense of precision. (I.e. in a 30 fps movie, currentTime = 0.99 / 30 will navigate to the second frame, not the first, due to rounding, which is technically incorrect.) This is a common problem, and Apple media frameworks (for example) therefore provide rational time classes which provide enough accuracy for precise navigation (e.g. QTTime, CMTime). Using a floating point number to represent time with any precision is not generally accepted as good practice when these rational time classes are available. -Jer
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
