Regardless of an ENABLE flag, be certain to use the webkit prefix. document.getItems(typeNames) turns into document.webkitGetItems(typeNames) Note that it's easy to implement this in pure javascript as a prototype. -Charles On 9/22/2011 8:00 AM, Adam Barth wrote:

Just so I understand, you're talking about the DOM APIs for interacting with microdata, right? I know there was some controversy in the HTML working group about Microdata versus RDFa. It's not 100% clear to me which of those technologies will "win out" in the end, but it seems valuable to implement this feature behind an ENABLE flag.

Adam

On Thu, Sep 22, 2011 at 4:48 AM, Arko Saha<nghq36@motorola.com> wrote:

...

Hi, I have been looking at HTML5 Microdata implementation in Webkit. Microdata is a specification used to nest semantics within existing content on web pages. Search engines, web crawlers, and browsers can extract and process Microdata from a web page and use it to provide a richer browsing experience for users. Microdata helps technologies such as search engines and web crawlers better understand what information is contained in a web page, providing better search results. Here is the spec : http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#micro... I have logged a bug for this and also attached a basic implementation patch for the same. Master bug: https://bugs.webkit.org/show_bug.cgi?id=68609 Please let me know your suggestions/views regarding this. Thanks in advance. Arko Saha _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org 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

On 23/09/2011, at 5:59 AM, Ian Hickson wrote:

On Thu, 22 Sep 2011, Charles Pritchard wrote:

...

Regardless of an ENABLE flag, be certain to use the webkit prefix. document.getItems(typeNames) turns into document.webkitGetItems(typeNames)

Note that it's easy to implement this in pure javascript as a prototype.

Assuming the patch implements the spec correctly, no need to use a prefix -- I'll track the implementations and ensure no conflicts.

That's an interesting approach to prefixing - I commend the volunteering of your time. 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. 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"); Dean

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

On 9/22/2011 2:42 PM, James Robinson wrote:

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

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.

Please post this feedback to some thread where it's relevant, not on a WebKit development mailing list discussion about a specific feature.

James Robinson, this thread is about introducing a specific feature, Microdata, into the WebKit code base. ENABLE flags are present, vendor prefixing is absent. https://bugs.webkit.org/attachment.cgi?id=108313&action=review <https://bugs.webkit.org/attachment.cgi?id=108313&action=review> I have no intention of sending irrelevant e-mails to your inbox, nor derailing this conversation. I think we can all agree that Arko Saha's work is welcome. The patch is quite simple, it's easy to review. I do not believe I've stepped outside the thread, nor do I believe Dean Jackson was being counter-productive when he pointed out that vendor prefixing is not an issue "particular" to this feature. Dean Jackson and Ian Hickson spoke about whether or not the vendor prefix should be included. Ian suggested that vendors should skip vendor prefixing. Dean is a bit more cautious, and has good reason to be. WebKit's experience with File API encountered quite a bit of criticism from other vendors. Both Adam Barth and Dean would like to avoid "controversy" with other vendors. That's the impression I'm getting. My concern, on this WebKit development mailing list, is that introducing another method -without- vendor prefixing may create some tension that WebKit developers would like to avoid. It simple patch. As far as I can tell, vendor prefixing is exactly what should be discussed. The patch can be approved by one person, the decision on whether or not to prefix the method name should be discussed by multiple vendors. WebKit serves multiple vendors. Again, I'm not trying to get in your inbox, James. If this still makes no sense to you, or I've misunderstood other WebKit developers, I do apologize. I'm trying to contribute, I'm not always successful at it. -Charles

FWIW, Opera is planning to ship this unprefixed. http://dev.opera.com/articles/view/microdata-and-the-microdata-dom-api/

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 <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.

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>

On Oct 12, 2011, at 4:12 PM, Ryosuke Niwa wrote:

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.

In the WebKit context, the need to prefix should be driven by the spec maturity level, not just the fact that the feature is optional and experimental for now. In this case, we expect a very low likelihood of incompatible changes to the spec. So it seems fine to omit the prefix, just as we would for an experimental implementation of a stable specification. That being said, we may want to revisit this choice before turning the feature on by default. Regards, Maciej