[webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit

Charles Pritchard chuck at jumis.com
Thu Sep 22 14:32:19 PDT 2011

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.


More information about the webkit-dev mailing list