- From: Shelley Powers <shelleyp@burningbird.net>
- Date: Thu, 13 Aug 2009 12:11:50 -0500
- To: Anne van Kesteren <annevk@opera.com>
- CC: Toby Inkster <tai@g5n.co.uk>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, Adrian Bateman <adrianba@microsoft.com>, David Singer <singer@apple.com>, Dan Connolly <connolly@w3.org>, "public-html@w3.org" <public-html@w3.org>
Anne van Kesteren wrote: > On Thu, 13 Aug 2009 18:49:33 +0200, Shelley Powers <shelleyp@burningbird.net> wrote: > >> Is that the only instance where the HTML 5 specification drills down >> into the Canvas element's 2D API directly? >> >> Again, this is a handshake issue, whereby one requirement the HTML 5 >> specification would have is the ability to obtain a serialization of the >> Canvas object. This is an unfortunate consequence of merging and >> breaking down borders between API and declarative syntax, but I don't >> see it as a showstopper. >> >> There's nothing in this _requirement_ that would overly inhibit >> innovation on the Canvas object. Nor is there anything likely to happen >> with the Canvas object, the 2D immediate mode API, that would impact on >> this handshake between specifications. >> >> But you are right, in this would be normative, not informative. I don't >> see this as a showstopper though, unless we're constrained by HTML 5 not >> being able to specify a normative reference to the new 2D API, because >> the 2D API doesn't have a published specification yet. >> >> In which case, I would think it better to remove the reference to >> ImageData from PostMessage. It could be taken up again in a later HTML >> specification, as folks are fond of saying. I've looked at the existing >> implementations of PostMessage for the various browsers. None have >> implemened ImageData yet. Even if they had, this is the risk they take >> for implementing what's current in a working draft. >> >> As Philipe stated in the HTML-WG IRC, implementations may not support >> passing ImageData objects directly[1], at least with Worker Threads. >> >> This is not a showstopper. >> > > No, the showstopper has always been lack of an editor. However, I thought part of your argument was the need to innovate quicker than we currently do. If we consider ImageData processing in separate processes to be important having to take it out because of the way we edit our specifications seems like it would hinder this particular innovation and be a potential disadvantage of this approach, rather than an advantage. > > > >> [1] http://krijnhoetmer.nl/irc-logs/html-wg/20090802#l-61 >> > > > And perhaps the way its coded in the HTML 5 specification is not the best approach. However, I'm not adverse to it being a normative reference in the HTML 5 specification, but I am concerned about the procedures in place at the W3C about this normative reference. Or perhaps the real issue since the W3C saw fit to disregard its typical procedures when it comes to HTML 5, it can also disregard its procedures when it comes to spinning of sections of the HTML 5 document, because it's better to do so . In other words, we can spin the 2D API into a separate specification, with the understanding that there is a normative reference between it and the HTML 5 specification, and even if the 2D API speeds ahead, or doesn't while it establishes its footing, the real key is that as long as the handshake is honored, maturity level may, or may not, be within one level of each other at any exact moment. Now, if at a later point, the 2D API group were to define a better approach, whatever version of the HTML specification could then discuss whether to incorporate the new version, with the understanding that the older version is only deprecated, not obsolete. For this particular case, though, I doubt there would be a "better" approach, because all this is, is a snapshot of a square of canvas, and pixel states (color) at the time, with appropriate getters/setters to get and set the pixel data. Unless I'm missing something mystically more complicated. Shelley
Received on Thursday, 13 August 2009 17:13:03 UTC