[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WEBKIT_ extensions



On Fri, Nov 18, 2011 at 9:38 AM, Chris Marrin <cmarrin@apple.com> wrote:
>
> On Nov 17, 2011, at 5:42 PM, Kenneth Russell wrote:
>
> ...
> Glenn, to address your question further:
> 1. I feel that having multiple browsers implement the same prototype
> extension independently will expose ill-defined areas more quickly, and
> allow the extension and its conformance tests to converge more quickly.
> 2. Requiring a vendor prefix implies that there will be two nearly identical
> copies of the extension in the registry during its prototyping phase.
> Keeping them in sync will likely be my responsibility, and from a selfish
> perspective, I am opposed to having to do this work, which I consider
> useless.
>
> I don't follow this reasoning. There would only ever be one proposal of a
> given extension, and its name would be the unprefixed name it is intended to
> have when ratified.

I see; I misunderstood this in your proposal above. This is much more
palatable, since the specification will not have to be duplicated.

It would minimally be necessary to list in the draft spec the names
under which the extension is supported at the current time, including
vendor prefixes. Making this implicit would be confusing for
developers. This is a minor detail though.

This idea sounds good to me. I see your point about the vendor prefix
giving web authors the chance to make their code work if one browser
auto-updates to a more recent draft of the extension but another won't
for a few weeks longer.

> There would never be a vendor specific proposal in the
> public wiki.

For the purpose of developing a multi-browser extension, yes -- but we
shouldn't forbid the possibility. MOZ_window_region_texture is a good
example of a WebGL spec that is very browser-specific and yet which
should probably be in the WebGL extension registry.

> If two vendors had different ideas about a given feature, I
> could imagine both submitting proposals with their take on that feature. In
> that case, each would need a different extension name and (presumably) each
> would implement their own proposal, complete with a vendor specific prefix.
> But I don't think that's likely to happen. I think it's much more likely
> that, if two vendors had different ideas about the same feature, they'd hash
> out their differences and submit a single proposal. But even in that case,
> as I've said before, I think each vendor using their own prefix during
> development is the best approach.

OK. This sounds good. Any objections to or other comments on this approach?

-Ken

> -----
> ~Chris
> cmarrin@apple.com
>
>
>
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------