On Thu, Sep 22, 2011 at 2:32 PM, Charles Pritchard
<chuck@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.
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