Given that Gecko is implementing the unprefixed getItems (see https://bugzilla.mozilla.org/show_bug.cgi?id=591467), I don't see benefits in implementing with webkit prefix. Also, it's still under a compile-time flag so we can prefix it before enabling the flag by default if we strongly feel like it.
- Ryosuke On Thu, Sep 22, 2011 at 2:32 PM, Charles Pritchard <ch...@jumis.com> wrote: > On 9/22/2011 2:13 PM, Ian Hickson wrote: > >> On Fri, 23 Sep 2011, Dean Jackson wrote: >> >>> However, isn't prefixing designed to avoid incompatibilities in spec >>> changes, not incompatibilities between implementations? Ensuring no >>> conflicts in implementations doesn't matter too much if the spec >>> changes. >>> >> It's designed to ensure that authors can reliably use a name and expect to >> get the same result in any UA that supports that name. >> >> I'm not going to change the spec in a way that conflicts with that -- if >> the spec has to change, it'll change either in a compatible way (e.g. to >> match what was actually implemented), or in a way that doesn't conflict >> (e.g. by changing the name in the spec). >> >> >> Note I'm not talking about Microdata in particular. I don't even know >>> what that spec is :) I'm just talking about the general approach. If the >>> world can guarantee that this spec will never change, then I guess your >>> technique works. >>> >>> FWIW, there is an in-between approach, which is the one used by WebGL. >>> It defines a prefix that all implementations share. >>> >>> canvas.getContext("**experimental-webgl"); >>> >> That'll just result in that name becoming the standard. >> > > I would like "some kind" of fast track method for these kind of issues. > Something like a "Request for dropping prefix" RfDP protocol would be > super. > > "RfDP: Microdata". First the spec editor would have to vouch for it, then, > if Moz, MS, Opera, Apple and Google reps can give a nod within a few weeks, > we've got something. > > I'd really like to avoid repeats of the CSS "-vnd-transform" baggage, when > possible. > WebKit went back and forth on BlobBuilder. Now it's at: > "WebKitBlobBuilder". That was not so fun. > That's another situation I'd like to avoid. > > For this particular method, the microdata section, I'm happy enough hearing > that the spec editor will vouch for it. > If that's the precedent, I'll take it. I'd like to learn how we can build > on that precedent. > > Reps from the major vendors have been quite responsive this year. I know > they can't "commit" to supporting > an API in a short time frame (such as the File API), but they have been > great about voicing issues. > > > -Charles > > ______________________________**_________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**dev<http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev> >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev