[webkit-dev] Vendor Prefixing, was Re: New feature announcement - Implement HTML5 Microdata in WebKit

[Charles Pritchard]

On 9/22/2011 2:42 PM, James Robinson wrote:
>
>
> On Thu, Sep 22, 2011 at 2:32 PM, Charles Pritchard <chuck at jumis.com 
> <mailto:chuck at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110922/a3b48444/attachment.html>