Proposal: Not shipping prefixed APIs on the release channel

[Henri Sivonen]

I got Warnocked the last time I tried this
(https://groups.google.com/d/topic/mozilla.dev.platform/5BGtf5GXdxc/discussion).
Let's try again.

In June, dbaron proposed a policy for experimental CSS features
(https://groups.google.com/d/topic/mozilla.dev.platform/itl6mtx2dxI/discussion).
My understanding is that the policy wasn't adopted officially but it
has mostly been adhered to since it was proposed, so it is serving the
same effect. I think it is excellent that Mozilla has stopped creating
more self-inflicted prefixing wounds on the CSS side.

I think we need a similar policy (that is adhered to even if not
official) for Web-exposed APIs.

What is inspiring me to write about this today in particular is
https://bugzilla.mozilla.org/show_bug.cgi?id=795930#c4 about prefixing
ArchiveReader.

Even though CSS and API prefixing don't work in exactly the same way,
I think the harm of prefixing APIs is not sufficiently mitigated by
APIs being different from CSS
(https://bugzilla.mozilla.org/show_bug.cgi?id=795930#c3). In fact,
there is a history of breakage from unprefixing APIs. First, a
substantial part of breakage from CSS unprefixing comes from
unprefixing properties in the CSSOM. Furthermore, breakage happens
even when unprefixing DOM APIs that are unrelated to CSS.

Mozilla itself published IndexedDB tutorials that propagated code that
broke with unprefixed IndexedDB:
https://bugzilla.mozilla.org/show_bug.cgi?id=770844

Any API that puts a function entry point on the window object or that
exposes a constructor on the window object is at risk of suffering
from the same mistake pattern.

On the other hand, if the code had successfully worked with unprefixed
IndexedDB, it would have been a failure of another kind: The whole
point of the prefixing is defeated if authors write code that
anticipates that unprefixed features work the same way as prefixed
features (except for the prefix itself) as far as the purpose of
prefixing is not to constrain the development of the feature with the
code that has been deployed for the prefixed version. If Web
developers anticipate unprefixing so that there sites don't break up
on unprefixing, the supposed benefits of prefixing is lost and,
therefore, prefixing is pointless. In other words, whenever Mozilla’s
own docs or evangelists tell people to write anticipatory code for the
unprefixed case, the efforts of the Gecko development side of Mozilla
to prefix are pointless (or, rather, worse than pointless).

Furthermore, if a Web developer is using only the prefixed version of
an API, it's likely that if the APIs missing, functionality—not mere
style—will be missing. In that sense, one should expect more severe
breakage in the case of removing prefixed APIs than from removing
prefixed style properties.

Also, moz prefixing runs counter to the Mission when stuff doesn't
break in Firefox but breaks in other browsers because a Web developer
only used the moz prefix but not identifiers that work in other
browsers. And even when Web developers perfectly handle all possible
prefixes and perfectly anticipate unprefixing so that nothing breaks,
the resulting developer ergonomics are worse than having a single
identifier per feature. (And, as noted above, when Web developers
anticipate unprefixing perfectly, prefixing becomes pointless, so any
argument that dealing with prefixing is easy to do in JavaScript is
actually an argument for not prefixing in the first place.)

I think we shouldn’t create more self-inflicted wounds like the one
seen with IndexedDB unprefixing above. I think we also should avoid
keeping prefixing as the norm, because as long as prefixing is the
norm, other browsers use prefixes too, and every time they do is an
opportunity for Web developers to write code that does not work in
Firefox.

Therefore, I propose that we adopt the following policy:
1) APIs that are not ready for use by Web developers shall not be
shipped on the release channel (unless preffed off).
2) APIs that are shipped on the release channel shall be shipped
without a prefix.
3) If we ship APIs that don't have specs already, we'll write specs.
4) Once an API has a substantial body of Web content relying on it,
breaking changes should not be made.

It would be nice if we could also adopt a fifth point requiring
another engine to independently implement the feature in its nightly
builds before we ship to the release channel, but it seems that such a
policy point wouldn't fly in the context of the APIs whose release
schedule is tied to the schedule of Firefox OS.

In particular, I'd like to highlight that prefixing is not a solution
that allows breaking changes. Whether you get to make breaking changes
depends on existing content. If you evangelize a feature (which we
do), you are asking for a legacy to be created. The way you avoid a
premature generation of legacy code is *not shipping* on the release
channel! End-users experience the same level of breakage regardless of
whether a feature had a funny name under the hood. Furthermore, if we
actually unprefix stuff instead of shipping with the prefix and
without a prefix forever, the unprefixing point is an additional
breaking change that would be avoided without having the prefix in the
first place. (So far, we've tended to actually unprefix instead of
shipping the prefixed version forever. Shipping the prefixed version
forever would be a problem both for maintenance and in terms of
Mission by letting Web developers fall into the trap of writing
browser-specific code even when they wouldn't have to. See also how
unhappy we are about WebKit keeping prefixes around forever.) Also,
prefixing APIs that are only available to Marketplace applications on
Firefox OS is not a good idea, because we want to evangelize
developers to use those APIs and it would be a bad idea to later pull
the rug from under the developers who were the early adopters of
Firefox OS. (I.e. breaking their apps wouldn’t foster continued
goodwill.)

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Joe Drew]

On 2012-11-06 8:31 AM, Henri Sivonen wrote:
> Therefore, I propose that we adopt the following policy:
> 1) APIs that are not ready for use by Web developers shall not be
> shipped on the release channel (unless preffed off).
> 2) APIs that are shipped on the release channel shall be shipped
> without a prefix.

I am broadly in support of this, but I have a specific concern: Firefox
OS will (or could) require experimental APIs that aren't fully baked
simply because of time constraints. I don't think we should hamstring
the features possible in FxOS to simply stabilize an API.

I would, however, be in favour of the result of s/release
channel/release channel on desktop/g.

joe

[Benoit Jacob]

I support the principle here but I want to make sure that we don't
hurt ourselves by applying good principles more strictly than our
competition.

My concrete example is WebGL extensions. These go through 4 stages:
1. "proposal": no browser must implement it.
2. "draft": implementations must use a vendor prefix.
3. "community approved": implementation without prefix is allowed.
4. "official": same as 3. as far as the present discussion is concerned.

See http://www.khronos.org/registry/webgl/extensions/

My point is that if we apply a strict no-prefixes policy to WebGL
extensions, we are going to have to remove support for all WebGL draft
extensions. Currently this includes all WebGL compressed texture
formats as well as depth textures. No compressed textures means no
advanced games. We might get S3TC to be community approved soon, since
it's been in draft stage for a while, but there is little hope for
other formats. So we would at least kill our mobile/B2G games efforts.

Don't get me wrong, I am not saying that this process is perfect. I
have been advocating for allowing unprefixed implementations earlier
in the process, and for forcing the removal of support for prefixes at
some late stage, but the above describes what we have agreed on in the
WebGL WG. As far as Mozilla is concerned, we are dropping support for
prefixes one Firefox version (6 weeks) after support for the
unprefixed name landed, but I don't know that other browsers are being
so careful to prevent prefix proliferation in this area.

Benoit

2012/11/6 Henri Sivonen <hsiv...@iki.fi>:

> Therefore, I propose that we adopt the following policy:
> 1) APIs that are not ready for use by Web developers shall not be
> shipped on the release channel (unless preffed off).
> 2) APIs that are shipped on the release channel shall be shipped
> without a prefix.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Ehsan Akhgari]

How does this proposal address the question of partially implemented
features? Do we need to implement everything in the spec to be able to
ship something on the release channel?

Ehsan

[Henri Sivonen]

On Wed, Nov 7, 2012 at 7:24 PM, Joe Drew <j...@mozilla.com> wrote:
> On 2012-11-06 8:31 AM, Henri Sivonen wrote:
>>

>> Therefore, I propose that we adopt the following policy:
>> 1) APIs that are not ready for use by Web developers shall not be
>> shipped on the release channel (unless preffed off).
>> 2) APIs that are shipped on the release channel shall be shipped
>> without a prefix.
>

> I am broadly in support of this, but I have a specific concern: Firefox OS
> will (or could) require experimental APIs that aren't fully baked simply
> because of time constraints. I don't think we should hamstring the features
> possible in FxOS to simply stabilize an API.

That's why I didn't use the formulation "experimental" but said "ready
for use". If it is important to get a particular API into Firefox OS,
surely the reason to get it in is to *enable its use*. And if it is
indeed important that it's available for use sooner than later, then
content will become dependent on it sooner than later.

We can't have it both ways: Both ship for immediate use and expect to
be able to make big changes without causing breakage.

If immediate use is deemed important, I think we should commit to the
API design that gets the use. (If we guess the demand wrong and almost
no one uses the API, then we would still get to change it because
changing wouldn't cause too much breakage.) I expect the early
adopters that now buy into our platform evangelism and use Firefox OS
features would be pretty unhappy if we broke their apps later. I also
expect Firefox OS end-users would become unhappy if we broke their
apps later. When third parties are depending on an API, whether on the
Web or in the Marketplace, breaking changes cause the same kind of
developer and end user experience of breakage regardless of whether
the API had a funny name. That is, breakage is breakage when third
parties depend on API regardless of how much we declare something
"experimental".

On the other hand, if a non-fully-baked API is needed only for Gaia
code that Mozilla itself ships and access to the API is blocked from
the general Web or even from Marketplace apps, surely it doesn't
matter for Web-facing breakage if the API is prefixed or not. But
having unprefixed even in the Gaia-only case makes it less work to
declare the API baked later.

I intentionally formulated the policy proposed in such a way that it
doesn't hinder shipping whatever is necessary in Firefox OS, but I
think we shouldn't pretend that a prefix makes it more okay to break
stuff that got shipped in Firefox OS.

[Henri Sivonen]

On Wed, Nov 7, 2012 at 8:11 PM, Benoit Jacob <jacob.b...@gmail.com> wrote:
> My concrete example is WebGL extensions. These go through 4 stages:
> 1. "proposal": no browser must implement it.
> 2. "draft": implementations must use a vendor prefix.

I think stage 2 is a bug to the extent stage 2 reaches the release channel.

> 3. "community approved": implementation without prefix is allowed.
> 4. "official": same as 3. as far as the present discussion is concerned.
>
> See http://www.khronos.org/registry/webgl/extensions/
>
> My point is that if we apply a strict no-prefixes policy to WebGL
> extensions, we are going to have to remove support for all WebGL draft
> extensions.

No. There’s the alternative of shipping those features without prefix.

> Currently this includes all WebGL compressed texture
> formats as well as depth textures. No compressed textures means no
> advanced games.

If it’s something we’d evangelize Web developers to use, I think we
should ship the feature without prefix and then not break the advanced
games that started using the feature. After all, it would be bad to
lure advanced games into using a feature we’ll break later!

> but the above describes what we have agreed on in the
> WebGL WG.

I think we shouldn’t agree to WG policies that involve shipping to the
release channel with prefix.

However, it is considered important that we not reneg on a promise
already made in the WebGL WG, I would rather exclude WebGL from what I
proposed than keep proliferating prefixes in other APIs. Fortunately,
as far as I know, for the vast majority of APIs (everything except
WebGL and CSSOM) there is no promise made in a WG.

[Henri Sivonen]

On Thu, Nov 8, 2012 at 12:03 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> How does this proposal address the question of partially implemented
> features?

If we consider a partial feature ready for use by Web developers, then
we could ship the partial feature on the release channel without
prefix.

> Do we need to implement everything in the spec to be able to ship
> something on the release channel?

No.

[Henri Sivonen]

On Thu, Nov 8, 2012 at 8:41 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
> However, it is considered important that we not reneg on a promise
> already made in the WebGL WG, I would rather exclude WebGL from what I
> proposed than keep proliferating prefixes in other APIs.

However, *if* it is…

[Benoit Jacob]

2012/11/8 Henri Sivonen <hsiv...@iki.fi>:

> On Wed, Nov 7, 2012 at 8:11 PM, Benoit Jacob <jacob.b...@gmail.com> wrote:
>> My concrete example is WebGL extensions. These go through 4 stages:
>> 1. "proposal": no browser must implement it.
>> 2. "draft": implementations must use a vendor prefix.
>
> I think stage 2 is a bug to the extent stage 2 reaches the release channel.

However, it is not a bug that get to fix by ourselves: moving to stage
3 requires WG approval.

>
>> 3. "community approved": implementation without prefix is allowed.
>> 4. "official": same as 3. as far as the present discussion is concerned.
>>
>> See http://www.khronos.org/registry/webgl/extensions/
>>
>> My point is that if we apply a strict no-prefixes policy to WebGL
>> extensions, we are going to have to remove support for all WebGL draft
>> extensions.
>
> No. There’s the alternative of shipping those features without prefix.

That requires moving to stage 3. Requires WG approval.

>
>> Currently this includes all WebGL compressed texture
>> formats as well as depth textures. No compressed textures means no
>> advanced games.
>
> If it’s something we’d evangelize Web developers to use, I think we
> should ship the feature without prefix and then not break the advanced
> games that started using the feature. After all, it would be bad to
> lure advanced games into using a feature we’ll break later!

That's a theoretical problem only so far: in practive, since the
un-prefixed extension generally behaves exactly like the prefixed one,
websites have been good at trying getting both and using whatever they
get.

>
>> but the above describes what we have agreed on in the
>> WebGL WG.
>
> I think we shouldn’t agree to WG policies that involve shipping to the
> release channel with prefix.

We have to find common ground with other browser vendors. Do feel free
to join the WG mailing list (public_webgl@khronos) and try to convince
everyone, though you may want to check the archives first.

> However, it is considered important that we not reneg on a promise
> already made in the WebGL WG, I would rather exclude WebGL from what I

> proposed than keep proliferating prefixes in other APIs. Fortunately,
> as far as I know, for the vast majority of APIs (everything except
> WebGL and CSSOM) there is no promise made in a WG.

I agree that excluding WebGL from the scope of this discussion is the
most likely useful course of action.

Benoit

>
> --
> Henri Sivonen
> hsiv...@iki.fi
> http://hsivonen.iki.fi/

[Ehsan Akhgari]

On 2012-11-08 1:44 AM, Henri Sivonen wrote:
> On Thu, Nov 8, 2012 at 12:03 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>> How does this proposal address the question of partially implemented
>> features?
>
> If we consider a partial feature ready for use by Web developers, then
> we could ship the partial feature on the release channel without
> prefix.

Hmm, well, a partial feature might be considered useful for web
developers, but still finishing the implementation may mean changing the
way that the partial implementation works later on, which is likely to
break stuff that rely on it. I'm not sure how you'd reconcile the two
sides here.

Ehsan

[Henri Sivonen]

On Thu, Nov 8, 2012 at 5:47 PM, Benoit Jacob <jacob.b...@gmail.com> wrote:
> That's a theoretical problem only so far: in practive, since the
> un-prefixed extension generally behaves exactly like the prefixed one,
> websites have been good at trying getting both and using whatever they
> get.

In other words, prefixing has no benefit.

> However, it is not a bug that get to fix by ourselves: moving to stage
> 3 requires WG approval.

...

> That requires moving to stage 3. Requires WG approval.

...

> We have to find common ground with other browser vendors. Do feel free
> to join the WG mailing list (public_webgl@khronos) and try to convince
> everyone, though you may want to check the archives first.

In the case of CSS, no progress was made on getting rid of prefixes as
long as implementers behaved as if the CSS WG has the power to set the
prefixing policy that implementers must follow. The way to make
progress was to just start, as an individual vendor, following the
policy dbaron wrote.

> I agree that excluding WebGL from the scope of this discussion is the
> most likely useful course of action.

OK.

[Henri Sivonen]

Do you have a concrete example from the past where all the following were true:
1) Letting Web authors use a partial feature was considered useful.
2) The partial feature was shipped with prefix.
3) Had the partial feature been shipped without prefix, completing
the feature would have caused worse breakage then unprefixing the
feature.

Or do you have a concrete example from the past where all the
following were true:
1) Letting Web authors use a partial feature was considered useful.
2) The partial feature was shipped without prefix.
3) Completing the feature caused breakage that was worse than the
breakage that would have been caused by shipping the partial feature
with prefix and unprefixing the feature after completion.

?

[jussi.ka...@gmail.com]

I'm strongly in favor of this, I actually even blogged about the subject a while back: http://blog.avd.io/posts/vendor-prefixes . :)

[Robert Kaiser]

Joe Drew schrieb:

I think we should have a pref that just turns on/off all the prefixed
technologies, and ship with that on in the experimental channels and off
on release (I'd say that beta is up for discussion, I'd lean towards off
on beta as we treat beta as RC and want testing there to match release
as much as possible so we don't get surprises when shipping).

This way, we can just ship B2G with that pref on as long as we require
that (I hope it will get stable enough at some point so we can apply the
same principles we're using elsewhere).

Robert Kaiser

[Benoit Jacob]

2012/11/9 Robert Kaiser <ka...@kairo.at>:

> Joe Drew schrieb:
>>
>> On 2012-11-06 8:31 AM, Henri Sivonen wrote:
>>>
>>> Therefore, I propose that we adopt the following policy:
>>> 1) APIs that are not ready for use by Web developers shall not be
>>> shipped on the release channel (unless preffed off).
>>> 2) APIs that are shipped on the release channel shall be shipped
>>> without a prefix.
>>
>>
>> I am broadly in support of this, but I have a specific concern: Firefox
>> OS will (or could) require experimental APIs that aren't fully baked
>> simply because of time constraints. I don't think we should hamstring
>> the features possible in FxOS to simply stabilize an API.
>>
>> I would, however, be in favour of the result of s/release
>> channel/release channel on desktop/g.
>
>
> I think we should have a pref that just turns on/off all the prefixed
> technologies, and ship with that on in the experimental channels and off on
> release

See my earlier email in this thread, we need the draft (hence, in
current WG-approved practice, prefixed) WebGL extensions to support
browser-based games. We don't want people to have to flip a preference
before their browser becomes ready for games.

Benoit

> (I'd say that beta is up for discussion, I'd lean towards off on
> beta as we treat beta as RC and want testing there to match release as much
> as possible so we don't get surprises when shipping).
>
> This way, we can just ship B2G with that pref on as long as we require that
> (I hope it will get stable enough at some point so we can apply the same
> principles we're using elsewhere).
>
> Robert Kaiser
>

[Benoit Jacob]

2012/11/8 Benoit Jacob <jacob.b...@gmail.com>:

> 2012/11/8 Henri Sivonen <hsiv...@iki.fi>:
>> On Wed, Nov 7, 2012 at 8:11 PM, Benoit Jacob <jacob.b...@gmail.com> wrote:
>>> My concrete example is WebGL extensions. These go through 4 stages:
>>> 1. "proposal": no browser must implement it.
>>> 2. "draft": implementations must use a vendor prefix.
>>
>> I think stage 2 is a bug to the extent stage 2 reaches the release channel.
>

> However, it is not a bug that get to fix by ourselves: moving to stage
> 3 requires WG approval.
>
>>

>>> 3. "community approved": implementation without prefix is allowed.
>>> 4. "official": same as 3. as far as the present discussion is concerned.
>>>
>>> See http://www.khronos.org/registry/webgl/extensions/
>>>
>>> My point is that if we apply a strict no-prefixes policy to WebGL
>>> extensions, we are going to have to remove support for all WebGL draft
>>> extensions.
>>
>> No. There’s the alternative of shipping those features without prefix.
>

> That requires moving to stage 3. Requires WG approval.
>
>>

>>> Currently this includes all WebGL compressed texture
>>> formats as well as depth textures. No compressed textures means no
>>> advanced games.
>>
>> If it’s something we’d evangelize Web developers to use, I think we
>> should ship the feature without prefix and then not break the advanced
>> games that started using the feature. After all, it would be bad to
>> lure advanced games into using a feature we’ll break later!
>

> That's a theoretical problem only so far: in practive, since the
> un-prefixed extension generally behaves exactly like the prefixed one,
> websites have been good at trying getting both and using whatever they
> get.
>
>>

>>> but the above describes what we have agreed on in the
>>> WebGL WG.
>>
>> I think we shouldn’t agree to WG policies that involve shipping to the
>> release channel with prefix.
>

> We have to find common ground with other browser vendors. Do feel free
> to join the WG mailing list (public_webgl@khronos) and try to convince
> everyone, though you may want to check the archives first.
>

>> However, it is considered important that we not reneg on a promise
>> already made in the WebGL WG, I would rather exclude WebGL from what I
>> proposed than keep proliferating prefixes in other APIs. Fortunately,
>> as far as I know, for the vast majority of APIs (everything except
>> WebGL and CSSOM) there is no promise made in a WG.
>

> I agree that excluding WebGL from the scope of this discussion is the
> most likely useful course of action.

To be clear though: if we strongly think that the current WebGL
extension prefix rules are not acceptable to us, we can very much do
something about it. When I proposed forcible removal of support for
prefixes in all browsers as soon as an extension reaches "community
approved" (stage 3) status, the objection to my proposal was that each
browser vendor should be free to decide that for itself. By that logic
then, I suppose that we should also be free to ship extensions
unprefixed whenever we want to. I suppose I'm not experienced enough
to decide by myself if the WebGL WG's lean in favor of prefixing draft
extensions should be regarded as binding us.

Benoit

>
> Benoit

>
>>
>> --
>> Henri Sivonen
>> hsiv...@iki.fi
>> http://hsivonen.iki.fi/

[Neil]

Is there any way we can make it so that the prefixed version doesn't
work unless you attempt (and presumably fail) to detect the unprefixed
version?

--
Warning: May contain traces of nuts.

[Ehsan Akhgari]

On 2012-11-09 2:43 AM, Henri Sivonen wrote:
>> Hmm, well, a partial feature might be considered useful for web developers,
>> but still finishing the implementation may mean changing the way that the
>> partial implementation works later on, which is likely to break stuff that
>> rely on it. I'm not sure how you'd reconcile the two sides here.
>
> Do you have a concrete example from the past where all the following were true:
> 1) Letting Web authors use a partial feature was considered useful.
> 2) The partial feature was shipped with prefix.
> 3) Had the partial feature been shipped without prefix, completing
> the feature would have caused worse breakage then unprefixing the
> feature.
>
> Or do you have a concrete example from the past where all the
> following were true:
> 1) Letting Web authors use a partial feature was considered useful.
> 2) The partial feature was shipped without prefix.
> 3) Completing the feature caused breakage that was worse than the
> breakage that would have been caused by shipping the partial feature
> with prefix and unprefixing the feature after completion.

Sort of. Well, from time to time we add a new DOM API which breaks a
website because they expect that name to be available as an expando
property or something. But that's not really important, I'm mostly
concerned about the stuff that we will ship in the future. The specific
thing that I'm worried about is Web Audio which is a huge spec and we
may not be able to implement all of it for quite a while for a variety
of reasons, and it might be difficult to decide whether implementing
more of it will break existing users, because, among other things, the
spec is also changing.

Cheers,
Ehsan

[Henri Sivonen]

On Fri, Nov 9, 2012 at 7:38 PM, Neil <ne...@parkwaycc.co.uk> wrote:
> Is there any way we can make it so that the prefixed version doesn't work
> unless you attempt (and presumably fail) to detect the unprefixed version?

What purpose would the prefix serve in such a scenario?

[Henri Sivonen]

On Fri, Nov 9, 2012 at 10:32 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> Sort of. Well, from time to time we add a new DOM API which breaks a
> website because they expect that name to be available as an expando property
> or something.

Prefixing doesn't fix this problem. It only defers it, which (I think)
is worse than finding incompatibilities early on and changing the
names in the spec not to collide with what’s already used out there.

> But that's not really important, I'm mostly concerned about
> the stuff that we will ship in the future. The specific thing that I'm
> worried about is Web Audio which is a huge spec and we may not be able to
> implement all of it for quite a while for a variety of reasons, and it might
> be difficult to decide whether implementing more of it will break existing
> users, because, among other things, the spec is also changing.

If a spec is actively changing in breaking ways, we shouldn’t ship an
implementation to the release channel. OTOH, once an implementation
has been shipped to the release channel and Web content depends on in,
a reasonable spec editor won’t make breaking changes anymore.

So if we agree that breaking changes are still necessary, we shouldn’t
ship. If we think we need to ship, we need to tell the spec editor not
to make breaking changes anymore.

[jussi.ka...@gmail.com]

I'm strongly in favor of this, I actually even blogged about the subject a while back: http://blog.avd.io/posts/vendor-prefixes . :)

On Friday, 9 November 2012 09:43:45 UTC+2, Henri Sivonen wrote:

[Randell Jesup]

This is a big issue for WebRTC.

The WebRTC API (and MediaStream API via the Media Capture Task Force and
getUserMedia()) is very much still in flux.

Chrome is shipping enabled-by-default soon, and will do so as
RTCPeerConnection. They had been using PeerConnectionNN, where NN was
bumped whenever a breaking change was done.

This was their comment: [1][2]

If you have been following the W3C WebRTC spec and looking at the
Chrome implementation, you will have noticed that our implementation
was not spec compliant.

With this week’s patches to Chromium and Webkit, Chrome is now a
editor’s-draft-compliant WebRTC implementation.

RTCPeerConnection is replacing PeerConnection00. RTCPeerConnection is
the API you will find in the upcoming stable version of Chrome, and the
last major API change before we go to a public stable release.
...
Once WebRTC goes into the stable channel of Chrome, API changes will
be done with a longer, smoother transition period.

However, I'd be *quite* surprised if there were no more breaking changes
to RTCPeerConnection.

Certainly there will be changes for navigator.getUserMedia(), which they have
prefixed as webkitGetUserMedia() (Opera has used getUserMedia(), and had
the API change under them several times.) At TPAC, the getUserMedia()
spec changed significantly.

So our problem will be: what do we ship in FF20? Right now we're behind
a pref, AND we're using mozRTCPeerConnection(). I also have no belief
that the spec will be nailed down for FF20 uplift, though I hope it will
be pretty stable by that point.

I'll point out that APIs have a lot of options other than simple naming:
(please excuse any syntax/etc errors):

* You can directly query for features (mypeercon.supports("JSEP-with-swizzling"));
* You can test for sub-APIs (if (mypeercon.createFunnyOffer != undefined));
* You can design it to support multiple versions (mypeercon = new
RTCPeerConnection("API version NN please"));
* You can use the NN suffix naming ala Chrome (though they've dropped it now):
RTCPeerConnection00/01/etc as breaking changes are incorporated, and try
to support the previous version "for a while" (or for a long while).

Devs will use polyfills to smooth over these differences, as they always
do. These would at least make the polyfills fairly deterministic if the
editors and implementors are careful about marking 'breaking' changes.

WebRTC is a big spec, with lots still to be defined. It will be a Long
Time before it moves past editors-draft stage. We will *not* have a
reasonable option to avoid exposing it; the only question is how to do
so, and how to minimize problems in the future - especially given others
ahead of us on implementation (though we're catching up). We will try
hard to be API-equivalent to Chrome, but that may not be possible
without downgrading our spec-compliance in issues where we're closer to
the draft, for example. If we can't be 100% API-compatible with Chrome,
we'll need to define how a site/app will notice and handle the
differences (i.e. some level of polyfill...).

I wish I had a magic answer that would get the spec finished before
anyone ships this, but that's not happening. Sorry.

[1] http://www.webrtc.org/blog/apiupdatedtoreflectlatesteditorsdraft
[2] http://www.webrtc.org/blog/peerconnection00nowdeprecatedincanary

--
Randell Jesup, Mozilla Corp
remove ".news" for personal email

[Neil]

Henri Sivonen wrote:

>On Fri, Nov 9, 2012 at 7:38 PM, Neil <ne...@parkwaycc.co.uk> wrote:
>
>
>>Is there any way we can make it so that the prefixed version doesn't work unless you attempt (and presumably fail) to detect the unprefixed version?
>>
>>
>What purpose would the prefix serve in such a scenario?
>
>

You'd prefer to provide an unprefixed experimental feature?

[Henri Sivonen]

I’d prefer not to provide experimental features on the release channel.

I deliberately didn't try to propose a prefix-related policy for
experimental features on non-release channels. I expect that if we
adopt the policy of not shipping experimental features on the release
channel, prefixing on non-release channels will stop without a policy
as developers start optimizing for not having to change test cases in
the case where an experimental API doesn't end up changing.

[Henri Sivonen]

On Tue, Nov 13, 2012 at 9:59 AM, Randell Jesup <rjesu...@jesup.org> wrote:
> The WebRTC API (and MediaStream API via the Media Capture Task Force and
> getUserMedia()) is very much still in flux.

I’m not familiar with these specs, so I don’t know why they are still in flux.

> Chrome is shipping enabled-by-default soon, and will do so as
> RTCPeerConnection.

Why do they want to ship something that is still in flux? Who is
expected to use an in-flux API and be able to deal with the API being
in flux? (Web developers in general are not up to the task of tracking
in-flux APIs.)

> Once WebRTC goes into the stable channel of Chrome, API changes will
> be done with a longer, smoother transition period.

There’s a risk that the old API versions stick around forever, then.
Apple will basically never be removing their -webkit- CSS stuff. Also,
the period for Chrome to transition from H.264 to WebM seems to
continue indefinitely.

> However, I'd be *quite* surprised if there were no more breaking changes
> to RTCPeerConnection.

Why and how do the breaking changes arise? Shouldn’t implementors just
say “no” to mere “nice to have” tweaks at this point?

> So our problem will be: what do we ship in FF20?

I am not familiar with the APIs in question, but the policy I proposed
would answer:

Either don’t ship in Firefox 20, if there’s something worthwhile to
wait for, or, if waiting is not an option, ship in Firefox 20 and tell
the WG to stop making breaking changes (enforced by refusing to
implement breaking changes if the WG tries to make them nonetheless).

> I'll point out that APIs have a lot of options other than simple naming:
> (please excuse any syntax/etc errors):
>
> * You can directly query for features (mypeercon.supports("JSEP-with-swizzling"));
> * You can test for sub-APIs (if (mypeercon.createFunnyOffer != undefined));

If "JSEP-with-swizzling" or createFunnyOffer ever went away, Web apps
would break. (One can be sure that a scenario where all Web apps
gracefully handle the feature going away is a theoretical scenario.)

If the plan is for them to never go away, they should just be part of
the spec the way document.write() is even though document.write() is
not a nice feature. In which case the issue reduces to shipping
partial features rather than shipping features with expected breaking
changes.

> * You can design it to support multiple versions (mypeercon = new
> RTCPeerConnection("API version NN please"));
> * You can use the NN suffix naming ala Chrome (though they've dropped it now):
> RTCPeerConnection00/01/etc as breaking changes are incorporated, and try
> to support the previous version "for a while" (or for a long while).

Again, if previous versions never go away, the spec should just define
them all instead of pretending that the old versions went away. But
see also http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html
and http://robert.ocallahan.org/2008/01/http-equiv_22.html .

OTOH, if the plan is that old versions go away, how do you ensure that
developers of Web apps are on board with tracking the API breakage? So
far, telling Web devs that an API is subject to change has never
avoided breakage.

In any case, both Firefox and Chrome supporting RTCPeerConnection00
makes the API more compatible across browsers than Firefox supporting
mozRTCPeerConnection and Chrome supporting webkitRTCPeerConnection, so
I don’t see the WebRTC scenario as being an argument *for* *prefixes*
even though I see WebRTC *might* be an argument *against* refraining
from shipping experimental features on the release channel.

> Devs will use polyfills to smooth over these differences, as they always
> do. These would at least make the polyfills fairly deterministic if the
> editors and implementors are careful about marking 'breaking' changes.

Polyfills work when the person writing a polyfill for an API knows
what the API will be and has a browser that already implements the API
to test with so that the polyfill developer can be test with a real
host browser that the polyfill really moves out of the way when the
API is supported by the browser.

You can't avoid future breakage with polyfills in the scenario where
you assume that the APIs you currently know will go away and you don't
yet know what they will be replaced with.

> WebRTC is a big spec, with lots still to be defined. It will be a Long
> Time before it moves past editors-draft stage. We will *not* have a
> reasonable option to avoid exposing it; the only question is how to do
> so, and how to minimize problems in the future - especially given others
> ahead of us on implementation (though we're catching up). We will try
> hard to be API-equivalent to Chrome, but that may not be possible
> without downgrading our spec-compliance in issues where we're closer to
> the draft, for example. If we can't be 100% API-compatible with Chrome,
> we'll need to define how a site/app will notice and handle the
> differences (i.e. some level of polyfill...).

Why does the draft differ from what Chrome does? Is the difference
worth all the versioning trouble? That is, why not make Chrome’s
behavior the standard if Chrome already has the code that behaves like
that (be definition) and we value (according to what you said)
compatibility with Chrome?

> I wish I had a magic answer that would get the spec finished before
> anyone ships this, but that's not happening. Sorry.

To me, this says that either you will break Web apps or you will end
up supporting all the API revisions that were ever shipped (or no one
ended up using the API before it changed). If the plan is to support
all the API revisions that ever got shipped, the solution is not to
pretend that the later revisions replace old APIs and instead make the
spec grow with side-by-side API alternatives. If the plan is to remove
old API versions, who is the expected user of the APIs that will get
broken? Are the expected users really up to the task of changing their
Web apps to track changing API versions so that browser end users
don’t experience breakage?

Either way, a moz prefix won’t help. (It’s worthless as a “this will
break” signal.)

If the in-flux APIs are shipped only to be used by Google+, Facebook
and a Skype Web app, expecting the Web devs to track API changes might
be realistic. If the expected users are Web developers in general, I
think it's completely unrealistic to expect them to track API changes.

If the idea is to ship something that we know is going to change on
the assumption that it will be used only by the likes of Google,
Facebook or Skype, the right solution might be shipping the APIs,
continue to break the APIs and have the APIs work only one short white
list of domains whose dev teams are believed to be up to the task of
tracking in-flux APIs (to prevent devs who aren’t up to the task from
writing apps that depend on stuff we still want to break).

[Neil]

Henri Sivonen wrote:

>On Tue, Nov 13, 2012 at 12:14 PM, Neil <ne...@parkwaycc.co.uk> wrote:
>
>
>>Henri Sivonen wrote:
>>
>>>On Fri, Nov 9, 2012 at 7:38 PM, Neil <ne...@parkwaycc.co.uk> wrote:
>>>
>>>
>>>>Is there any way we can make it so that the prefixed version doesn't work unless you attempt (and presumably fail) to detect the unprefixed version?
>>>>
>>>>
>>>What purpose would the prefix serve in such a scenario?
>>>
>>>
>>You'd prefer to provide an unprefixed experimental feature?
>>
>>
>I'd prefer not to provide experimental features on the release channel.
>
>

Fair enough, but then your message subject misled me.

[Ehsan Akhgari]

On 2012-11-12 6:01 AM, Henri Sivonen wrote:
> On Fri, Nov 9, 2012 at 10:32 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:

>> Sort of. Well, from time to time we add a new DOM API which breaks a
>> website because they expect that name to be available as an expando property
>> or something.
>
> Prefixing doesn't fix this problem. It only defers it, which (I think)
> is worse than finding incompatibilities early on and changing the
> names in the spec not to collide with what’s already used out there.

I agree. Prefixing in practice is really just a way to make us feel
better about breaking something which we have shipped before, and that's
bad for web developers. But this is sort of an orthogonal discussion.

>> But that's not really important, I'm mostly concerned about
>> the stuff that we will ship in the future. The specific thing that I'm
>> worried about is Web Audio which is a huge spec and we may not be able to
>> implement all of it for quite a while for a variety of reasons, and it might
>> be difficult to decide whether implementing more of it will break existing
>> users, because, among other things, the spec is also changing.
>
> If a spec is actively changing in breaking ways, we shouldn’t ship an
> implementation to the release channel. OTOH, once an implementation
> has been shipped to the release channel and Web content depends on in,
> a reasonable spec editor won’t make breaking changes anymore.
>
> So if we agree that breaking changes are still necessary, we shouldn’t
> ship. If we think we need to ship, we need to tell the spec editor not
> to make breaking changes anymore.

I'm not sure if that call can be made easily in all cases. There might
be parts of a given spec that we don't want to implement because they
are bad ideas, and while we try to fix them in the spec, doing so is not
always possible. Our position on such types of issues might change
because web developers may start depending on those features to an
extent where we have to implement them, and I'm afraid that with the
policy you're proposing, such cases may prevent us from shipping a
feature to the release channel unprefixed for an extended period of time.

Cheers,
Ehsan

[Randell Jesup]

Henri Sivonen <hsiv...@iki.fi> writes:

> On Tue, Nov 13, 2012 at 9:59 AM, Randell Jesup <rjesu...@jesup.org> wrote:
>> The WebRTC API (and MediaStream API via the Media Capture Task Force and
>> getUserMedia()) is very much still in flux.
>
> I’m not familiar with these specs, so I don’t know why they are still in flux.

Mostly because a) they're big, b) they involve complex and
still-being-defined underlying protocols coming from the IETF, like
signaling (JSEP (being defined for WebRTC/rtcweb) and SDP), c) as we get
initial implementations up, gain experience with them and start using
the more complex cases, we're realizing some earlier assumptions were
flawed (the recent getUserMedia() API change to return a (blocked)
stream immediately before permissions are granted (or not) is an
example, to speed call-answer time in apps).

>> Chrome is shipping enabled-by-default soon, and will do so as
>> RTCPeerConnection.
>
> Why do they want to ship something that is still in flux? Who is
> expected to use an in-flux API and be able to deal with the API being
> in flux? (Web developers in general are not up to the task of tracking
> in-flux APIs.)

Telecom/Skype-like/etc service providers very much want to get access to
these and to deal with the flux. These generally are NOT typical web
developers; these tend to be people with a lot of telecom experience
formerly working with SIP or similar applications (sometimes built on
Flash using RTFMP (the author of which is part of the effort)).

Small demo apps may break (or be dropped to a deprecated interface) and
not be updated. This is quite true.

>> Once WebRTC goes into the stable channel of Chrome, API changes will
>> be done with a longer, smoother transition period.
>
> There’s a risk that the old API versions stick around forever, then.
> Apple will basically never be removing their -webkit- CSS stuff. Also,
> the period for Chrome to transition from H.264 to WebM seems to
> continue indefinitely.

Understood, though those are quite different issues from this. And
we've pointedly warned app devs we'd be removing old APIs even if we
support them for a while, and have done so (or rather Chrome has).

>> However, I'd be *quite* surprised if there were no more breaking changes
>> to RTCPeerConnection.
>
> Why and how do the breaking changes arise? Shouldn’t implementors just
> say “no” to mere “nice to have” tweaks at this point?

See above. We're not at the tweak phase, we're finding actual flaws in
functionality as we try to write more complex applications (though it is
firming up; we may be past the major changes phase with the last
getUserMedia change, but I wouldn't put heavy money on it.).

FYI, I may not have been clear: Chrome has dropped the API version
suffix, but they're still prefixed. This means an app can distinguish
between us, but to track finer changes it will need to UA sniff or
feature-detect in some manner (like recently when we implemented
mediastream.stop() and forced apps to use it properly, or when we added
basic constraint support).

I *liked* the version suffix idea because if thing change, you know *and
can key off it temporarily* instead of getting vague "it stopped
working" reports and being forced to only support old or new (or fiddle
with unplanned detection code). Also, as we converge, we can use the
same suffix as Chrome if we have the same API (more applicable to
smaller changes than all of WebRTC, but still useful).

>> So our problem will be: what do we ship in FF20?
>
> I am not familiar with the APIs in question, but the policy I proposed
> would answer:
>
> Either don’t ship in Firefox 20, if there’s something worthwhile to
> wait for, or, if waiting is not an option, ship in Firefox 20 and tell
> the WG to stop making breaking changes (enforced by refusing to
> implement breaking changes if the WG tries to make them nonetheless).

See above. I'm afraid those aren't viable options. We are in close
contact with most people using these APIs, and they generally know the
APIs are in flux, and that they must track changes. It is a somewhat
different community used to interacting with standards bodies (and
dealing with standards like SIP where every device implements a
different subset of the HUGE number of RFCs (plus device-specific
quirks)). Our current state is actually far more "standard" than VoIP
people are used to.

>> I'll point out that APIs have a lot of options other than simple naming:
>> (please excuse any syntax/etc errors):
>>
>> * You can directly query for features (mypeercon.supports("JSEP-with-swizzling"));
>> * You can test for sub-APIs (if (mypeercon.createFunnyOffer != undefined));
>
> If "JSEP-with-swizzling" or createFunnyOffer ever went away, Web apps
> would break. (One can be sure that a scenario where all Web apps
> gracefully handle the feature going away is a theoretical scenario.)

Not so theoretical in this case, though it's not guaranteed. With two
platforms (so far) implementing and progressing unevenly, one must
either prefix/suffix or use feature queries (as we don't want UA sniffing!)

> If the plan is for them to never go away, they should just be part of
> the spec the way document.write() is even though document.write() is
> not a nice feature. In which case the issue reduces to shipping
> partial features rather than shipping features with expected breaking
> changes.

They *are* going away, and we've had no compunction about killing them
and updating the demo/test pages so far. Once we "pref on" (as google
is), the bar will be higher, but we will continue to track the spec and
will not support deprecated APIs for a long period (if at all). We even
have API check code on the WebRTC landing page to determine what API
your browser has and warn you if it's old or incompatible with the
current tests.

>> * You can design it to support multiple versions (mypeercon = new
>> RTCPeerConnection("API version NN please"));
>> * You can use the NN suffix naming ala Chrome (though they've dropped it now):
>> RTCPeerConnection00/01/etc as breaking changes are incorporated, and try
>> to support the previous version "for a while" (or for a long while).
>
> Again, if previous versions never go away, the spec should just define
> them all instead of pretending that the old versions went away. But
> see also http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html
> and http://robert.ocallahan.org/2008/01/http-equiv_22.html .
>
> OTOH, if the plan is that old versions go away, how do you ensure that
> developers of Web apps are on board with tracking the API breakage? So
> far, telling Web devs that an API is subject to change has never
> avoided breakage.

Well, the biggest reason is that these aren't random web devs, these
devs are much more involved in the mailing lists and used to
standards-body tracking (lots of IETF/VoIP people, and people used to
dealing with IETF drafts changing during development). We have lots of
contact with them via the various mailing lists and are using G+,
webrtc.org and our test landing page on github to inform them and move
them forward. Some demos will be abandoned, but that's ok.

> In any case, both Firefox and Chrome supporting RTCPeerConnection00
> makes the API more compatible across browsers than Firefox supporting
> mozRTCPeerConnection and Chrome supporting webkitRTCPeerConnection, so
> I don’t see the WebRTC scenario as being an argument *for* *prefixes*
> even though I see WebRTC *might* be an argument *against* refraining
> from shipping experimental features on the release channel.

The biggest problem here (aluded to above) is that the API is broad
enough and progress by the two sides uneven enough that we haven't ever
had a converged API we could both support yet. We are moving towards
that (at least demos of interop calls), but even those will be done
partially by polyfill and maybe some wireline protocol adapters
temporarily. (Getting ICE (NAT traversal) to be compatible, for example.)

>> Devs will use polyfills to smooth over these differences, as they always
>> do. These would at least make the polyfills fairly deterministic if the
>> editors and implementors are careful about marking 'breaking' changes.
>
> Polyfills work when the person writing a polyfill for an API knows
> what the API will be and has a browser that already implements the API
> to test with so that the polyfill developer can be test with a real
> host browser that the polyfill really moves out of the way when the
> API is supported by the browser.
>
> You can't avoid future breakage with polyfills in the scenario where
> you assume that the APIs you currently know will go away and you don't
> yet know what they will be replaced with.

Polyfills here reduce the pain and breakage, but may not fully eliminate
it, and that's probably ok for this audience.

>> WebRTC is a big spec, with lots still to be defined. It will be a Long
>> Time before it moves past editors-draft stage. We will *not* have a
>> reasonable option to avoid exposing it; the only question is how to do
>> so, and how to minimize problems in the future - especially given others
>> ahead of us on implementation (though we're catching up). We will try
>> hard to be API-equivalent to Chrome, but that may not be possible
>> without downgrading our spec-compliance in issues where we're closer to
>> the draft, for example. If we can't be 100% API-compatible with Chrome,
>> we'll need to define how a site/app will notice and handle the
>> differences (i.e. some level of polyfill...).
>
> Why does the draft differ from what Chrome does? Is the difference
> worth all the versioning trouble? That is, why not make Chrome’s
> behavior the standard if Chrome already has the code that behaves like
> that (be definition) and we value (according to what you said)
> compatibility with Chrome?

Because we find areas where the draft doesn't cover the problemset well,
or areas that we've waved hands at in the draft and now get defined.
Chrome's impl roughly matches a version of the draft, but not
necessarily the current version (Chrome takes time to get to release, or
even Beta), but that's not a final draft. Random example: the stats API
is still in the proposal stage (and bouncing back and forth between IETF
and W3), and getting significant feedback from IETF and from developers
looking at it. The Bandwidth interaction API is still merely a proposal
I made in a W3 bug (repeatedly), though we need an API there to meet the
requirements. And there was considerable discussion of "rehydration" at
IETF: how to handle one side reloading the page in the middle of a call
(often done in web-apps when something "bad" happens in the hope of
resetting state to a sane place, or by accident by the user).

>> I wish I had a magic answer that would get the spec finished before
>> anyone ships this, but that's not happening. Sorry.
>
> To me, this says that either you will break Web apps or you will end
> up supporting all the API revisions that were ever shipped (or no one
> ended up using the API before it changed).

We will break webapps where we have to (and they'll generally know about
it ahead of time).

> If the plan is to support
> all the API revisions that ever got shipped, the solution is not to
> pretend that the later revisions replace old APIs and instead make the
> spec grow with side-by-side API alternatives. If the plan is to remove
> old API versions, who is the expected user of the APIs that will get
> broken?

Generally telecom providers, SBC (Border Controllers aka Gateways), some
people making frameworks, and people using getUserMedia to do
photobooth/etc type demos/apps. Most are just experimenting with it
currently as a sideline to their current products based on Flash, VoIP,
or plugins.

> Are the expected users really up to the task of changing their
> Web apps to track changing API versions so that browser end users
> don’t experience breakage?

Generally yes.

> Either way, a moz prefix won’t help. (It’s worthless as a “this will
> break” signal.)

Agreed. That's why I like suffixes.

> If the in-flux APIs are shipped only to be used by Google+, Facebook
> and a Skype Web app, expecting the Web devs to track API changes might
> be realistic. If the expected users are Web developers in general, I
> think it's completely unrealistic to expect them to track API changes.

Understood. We're in-between, but the devs using them generally are
reasonably able to track (if they can key off something). The only ones
likely to really break are small getUserMedia() demos.

> If the idea is to ship something that we know is going to change on
> the assumption that it will be used only by the likes of Google,
> Facebook or Skype, the right solution might be shipping the APIs,
> continue to break the APIs and have the APIs work only one short white
> list of domains whose dev teams are believed to be up to the task of
> tracking in-flux APIs (to prevent devs who aren’t up to the task from
> writing apps that depend on stuff we still want to break).

It's too large and dynamic a list for that. There are a LOT of people
experimenting with them and making demos and proof-of-concept apps.
They generally all have to follow either rtcweb (IETF), public-webrtc
(W3), or discuss-webrtc (generic group for devs to ask questions) - or
all three (though reading all three is a job in itself...).


I don't believe we have a perfect (or even a great) answer here. I
think suffixes would still be good to have until the API stabilizes. I
like suffixes a lot more as a general concept then vendor prefixes for
DOM APIs.

I'd love a magic wand to wave and finish the spec for us, leaving only
implementation, but it's a feedback circle between implementation and
spec for a while, and a time issue to hammer out the smaller items like
stats, resolution control, what a JS app is allowed to change in JSEP
offers/answers, exact constraint lists, etc.

And I believe WebRTC is a bit (or more) of a special case, with a huge
exposed surface and tons of detail being created for it in the IETF. No
other single feature I expect to see in the next many years is likely to
be as large.

[Mounir Lamouri]

On 06/11/12 13:31, Henri Sivonen wrote:
> Therefore, I propose that we adopt the following policy:
> 1) APIs that are not ready for use by Web developers shall not be
> shipped on the release channel (unless preffed off).

For that, we will need some tools to know if we are building for Release
(and let say Beta) where the feature should be hidden by default, with
opposition to Aurora, Nightly or custom builds where the feature should
be enabled by default.
Also, how would that work for things that doesn't have
Nightly/Aurora/Beta/Release channels?

IMO, this is currently the main reason why prefixing is a pain: we want
to allow devs to try the feature easily and Nightly/Aurora is there for
that but having to disable the feature as soon as it reaches Beta is
just too much maintenance.

Cheers,
--
Mounir

[Gavin Sharp]

On Wed, Nov 14, 2012 at 10:53 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> For that, we will need some tools to know if we are building for Release
> (and let say Beta) where the feature should be hidden by default, with
> opposition to Aurora, Nightly or custom builds where the feature should
> be enabled by default.

We already have ways of doing that (usually based off of
MOZ_UPDATE_CHANNEL). We could introduce some more elegant/robust
solution - we already do it enough that a better solution would
probably be nice. See
https://bugzilla.mozilla.org/show_bug.cgi?id=803276#c4.

> Also, how would that work for things that doesn't have
> Nightly/Aurora/Beta/Release channels?

What do you mean?

Gavin

[Mounir Lamouri]

On 14/11/12 19:27, Gavin Sharp wrote:
> On Wed, Nov 14, 2012 at 10:53 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:
>> For that, we will need some tools to know if we are building for Release
>> (and let say Beta) where the feature should be hidden by default, with
>> opposition to Aurora, Nightly or custom builds where the feature should
>> be enabled by default.
>
> We already have ways of doing that (usually based off of
> MOZ_UPDATE_CHANNEL). We could introduce some more elegant/robust
> solution - we already do it enough that a better solution would
> probably be nice. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=803276#c4.

MOZ_UPDATE_CHANNEL contains a string and AFAIK, we can't use C
preprocessor to compare strings so it might not be enough.

>> Also, how would that work for things that doesn't have
>> Nightly/Aurora/Beta/Release channels?
>
> What do you mean?

I was thinking of things like Firefox OS that might not have such
concept. We should make sure that they do not end up doing the wrong thing.

--
Mounir

[Gavin Sharp]

On Wed, Nov 14, 2012 at 2:23 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> MOZ_UPDATE_CHANNEL contains a string and AFAIK, we can't use C
> preprocessor to compare strings so it might not be enough.

The common solution is to check MOZ_UPDATE_CHANNEL in the Makefile to
adjust defined variables, see e.g.:
http://mxr.mozilla.org/mozilla-central/source/accessible/src/Makefile.in#17
http://mxr.mozilla.org/mozilla-central/source/browser/installer/Makefile.in#83

> I was thinking of things like Firefox OS that might not have such
> concept. We should make sure that they do not end up doing the wrong thing.

Ah, right - I think that's where a better solution like the ones I
alluded to in my previous comment would help. I'm not overly fond of
the various MOZ_UPDATE_CHANNEL (ab)uses :)

Gavin

[Henri Sivonen]

On Tue, Nov 13, 2012 at 8:05 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> On 2012-11-12 6:01 AM, Henri Sivonen wrote:
>>
>> On Fri, Nov 9, 2012 at 10:32 PM, Ehsan Akhgari <ehsan....@gmail.com>
>> wrote:
>>>
>>> Sort of. Well, from time to time we add a new DOM API which breaks a
>>> website because they expect that name to be available as an expando
>>> property
>>> or something.
>>
>> Prefixing doesn't fix this problem. It only defers it, which (I think)
>> is worse than finding incompatibilities early on and changing the
>> names in the spec not to collide with what’s already used out there.
>
> I agree. Prefixing in practice is really just a way to make us feel better
> about breaking something which we have shipped before, and that's bad for
> web developers. But this is sort of an orthogonal discussion.

I think it isn’t orthogonal. I think having a way that makes us feel
better about breaking stuff is something we shouldn’t have. I expect
we’d make better decisions about breakage if we didn’t have an excuse
that allows us to delude ourselves about the fact that breakage is
being caused.

>>> But that's not really important, I'm mostly concerned about
>>> the stuff that we will ship in the future. The specific thing that I'm
>>> worried about is Web Audio which is a huge spec and we may not be able to
>>> implement all of it for quite a while for a variety of reasons, and it
>>> might
>>> be difficult to decide whether implementing more of it will break
>>> existing
>>> users, because, among other things, the spec is also changing.
>>
>>
>> If a spec is actively changing in breaking ways, we shouldn’t ship an
>> implementation to the release channel. OTOH, once an implementation
>> has been shipped to the release channel and Web content depends on in,
>> a reasonable spec editor won’t make breaking changes anymore.
>>
>> So if we agree that breaking changes are still necessary, we shouldn’t
>> ship. If we think we need to ship, we need to tell the spec editor not
>> to make breaking changes anymore.
>
> I'm not sure if that call can be made easily in all cases. There might be
> parts of a given spec that we don't want to implement because they are bad
> ideas, and while we try to fix them in the spec, doing so is not always
> possible. Our position on such types of issues might change because web
> developers may start depending on those features to an extent where we have
> to implement them, and I'm afraid that with the policy you're proposing,
> such cases may prevent us from shipping a feature to the release channel
> unprefixed for an extended period of time.

On Tue, Nov 13, 2012 at 10:14 PM, Randell Jesup <rjesu...@jesup.org> wrote:
> Henri Sivonen <hsiv...@iki.fi> writes:

>> Either way, a moz prefix won’t help. (It’s worthless as a “this will
>> break” signal.)
>
> Agreed.

It seems to me that we won't get agreement on policy about not
shipping experimental features on the release channel. However, it
seems to me that we could be able to agree not to ship moz-prefixed
APIs on the release channel.

So I adjust my policy proposal to:

Therefore, I propose that we adopt the following policy:

1) APIs that are shipped on the release channel shall be shipped
without a prefix.
2) If we ship APIs that don't have specs already, we'll write specs.

I think a policy not to ship moz-prefixed APIs on the release channel
would give enough flexibility to ship experimental features (without
prefix) when market pressure so requires but would generally have
positive consequences that would lead to less breakage for features
that have reached the release channel.

In the case of features that Gecko developers know to be unbaked
without compelling market pressure to ship them in an unbaked state, I
would expect this policy to have the consequence of not shipping such
unbaked features on the release channel. (For this to be easy to
accomplish, there should probably be a C preprocessor define that is
different for Release (and maybe Beta) compared to Aurora, Nightly and
self-built.

In the case of features that are technically in good shape but just
haven't had a standards setting group put their mark on them, I think
this would have the positive effect of discouraging bikeshedding. For
example, if we had shipped the full-screen API without prefix, I
expect we could have avoided the total bikeshed of changing the case
of the letter ‘S’ in “fullScreen”. (It’s so confusing that even MDN
contradicts itself. I’ll fix after sending this email.)

In the case of features where we don't know if the general design will
be accepted as a cross-browser standard, shipping without prefix makes
things better in the case our design gets accepted. With prefixes, we
get breakage either way, so with prefixes we are always betting wrong.
If our design doesn't get accepted, the standard can simply choose a
differently-named API entry point. After all, the space of possible
identifiers is countably infinite.

In case of features like WebRTC where it's almost certain that
breakage will occur, if we ship without prefix, we’ll be no worse off
than shipping with prefix. Breakage occurs either way and experience
shows that a prefix is worthless as a signal of API stability. So even
in cases like WebRTC, it makes sense to bet for the case where
breakage doesn't need to occur (i.e. the spec doesn’t end up changing
after all).

On Wed, Nov 14, 2012 at 8:53 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> On 06/11/12 13:31, Henri Sivonen wrote:
>> Therefore, I propose that we adopt the following policy:
>> 1) APIs that are not ready for use by Web developers shall not be
>> shipped on the release channel (unless preffed off).
>

> For that, we will need some tools to know if we are building for Release
> (and let say Beta) where the feature should be hidden by default, with
> opposition to Aurora, Nightly or custom builds where the feature should
> be enabled by default.

So let’s get a C preprocessor define for that. It shouldn’t be a big
deal to conjure a suitable one into existence.

> Also, how would that work for things that doesn't have
> Nightly/Aurora/Beta/Release channels?

Surely Firefox OS has *some* distinction between release builds and
development builds?

[Ehsan Akhgari]

On 2012-11-27 3:49 AM, Henri Sivonen wrote:
> I think it isn’t orthogonal. I think having a way that makes us feel
> better about breaking stuff is something we shouldn’t have. I expect
> we’d make better decisions about breakage if we didn’t have an excuse
> that allows us to delude ourselves about the fact that breakage is
> being caused.

I totally agree. But note that this is basically rephrasing "prefixing
sucks" in a better way. :-)

> It seems to me that we won't get agreement on policy about not
> shipping experimental features on the release channel. However, it
> seems to me that we could be able to agree not to ship moz-prefixed
> APIs on the release channel.
>
> So I adjust my policy proposal to:
> Therefore, I propose that we adopt the following policy:
> 1) APIs that are shipped on the release channel shall be shipped
> without a prefix.
> 2) If we ship APIs that don't have specs already, we'll write specs.

Where do partial implementations of specs fall here? Can we ship
something unprefixed without implementing the full spec?

> In the case of features where we don't know if the general design will
> be accepted as a cross-browser standard, shipping without prefix makes
> things better in the case our design gets accepted. With prefixes, we
> get breakage either way, so with prefixes we are always betting wrong.
> If our design doesn't get accepted, the standard can simply choose a
> differently-named API entry point. After all, the space of possible
> identifiers is countably infinite.

And what will happen to the original name that we've shipped? Would we
remove support for it at some point?

> On Wed, Nov 14, 2012 at 8:53 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
>> On 06/11/12 13:31, Henri Sivonen wrote:
>>> Therefore, I propose that we adopt the following policy:
>>> 1) APIs that are not ready for use by Web developers shall not be
>>> shipped on the release channel (unless preffed off).
>>
>> For that, we will need some tools to know if we are building for Release
>> (and let say Beta) where the feature should be hidden by default, with
>> opposition to Aurora, Nightly or custom builds where the feature should
>> be enabled by default.
>
> So let’s get a C preprocessor define for that. It shouldn’t be a big
> deal to conjure a suitable one into existence.

Hmm, Web IDL bindings already support exposing names hidden behind a
pref, so we can technically do without the C preprocessor macro that
you're proposing, at least for the stuff that we can use Web IDL
bindings for (and that's what everybody is using for the new APIs,
right? ;-)

I think we should prefer prefs over build-time flags, since they always
have the chance of surprising us when we uplift something from Beta to
Release.

Cheers,
Ehsan

[Henri Sivonen]

On Tue, Nov 27, 2012 at 6:59 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> On 2012-11-27 3:49 AM, Henri Sivonen wrote:
>> So I adjust my policy proposal to:
>> Therefore, I propose that we adopt the following policy:
>> 1) APIs that are shipped on the release channel shall be shipped
>> without a prefix.
>> 2) If we ship APIs that don't have specs already, we'll write specs.
>
> Where do partial implementations of specs fall here?

It would be up to the implementor and reviewer to make the guess
whether the partial feature is unlikely to require later breaking
changes and unlikely to preclude later implementing the full feature.
If the guess is that the part already implemented is ready to be used
by Web developers and shipping only that part is unlikely to induce
Web content that would be broken by implementing the rest of the spec
later, then the partial feature can be shipped to the release channel
(without prefix).

If there is a reason to believe that implementing just a part would
result in Web content that would break with a later implementation of
the rest, it would be better to wait until the rest is ready, but the
policy I outlined above is silent, really.

Maybe we’d guess wrong some time, but that would be better than always
guessing wrong in the sense of always guessing that things will be
named mozFoo when they end up being named foo. :-)

> Can we ship something unprefixed without implementing the full spec?

Sure.

[Ehsan Akhgari]

Makes a lot of sense to me. Thanks for the explanation Henri. I'm in
full support of this proposal.

Ehsan

[Henri Sivonen]

On Tue, Nov 27, 2012 at 10:49 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
> Therefore, I propose that we adopt the following policy:
> 1) APIs that are shipped on the release channel shall be shipped
> without a prefix.
> 2) If we ship APIs that don't have specs already, we'll write specs.

In yesterday’s platform meeting, it turned out that I had
misunderstood Randell’s position on prefixing WebRTC.

Even though in general, it might be bad for a policy to have seemingly
ad hoc exceptions, I think making an exception for WebRTC is
reasonable, because:
* WebRTC is already in the implementation pipeline and the policy was
meant for new features and not for abruptly removing existing
prefixes, so it seems reasonable to stretch the notion of “existing
feature” to an in-the-pipeline feature in the case of a huge feature
like WebRTC where making changes right now might be too disruptive.
* It appears that there’s some kind of commitment made in the WG
involved as in the case of WebGL.
* WebRTC is a uniquely huge feature (or set of features) and it needs
special rollout (unusual iteration after release).
* Even if WebRTC and WebGL were excluded, I think it would be a big
win to stop prefixing other APIs that are introduced.

Also, a clarification was asked about whether the policy was proposed
to apply to new features only or also to existing features. (I
intended it to apply to new features.)

Therefore, I propose that we adopt the following policy:

1) Excluding WebGL and WebRTC APIs, new APIs that are shipped on the

release channel shall be shipped without a prefix.

2) If APIs that don’t already have specs are shipped, we’ll get specs written.

(For clarity, the above formulation does not require WebGL or WebRTC
to have prefixes.)

[Randell Jesup]

Henri wrote:
>It seems to me that we won't get agreement on policy about not
>shipping experimental features on the release channel. However, it
>seems to me that we could be able to agree not to ship moz-prefixed
>APIs on the release channel.
>
>So I adjust my policy proposal to:
>Therefore, I propose that we adopt the following policy:
> 1) APIs that are shipped on the release channel shall be shipped
>without a prefix.
> 2) If we ship APIs that don't have specs already, we'll write specs.
>
>I think a policy not to ship moz-prefixed APIs on the release channel
>would give enough flexibility to ship experimental features (without
>prefix) when market pressure so requires but would generally have
>positive consequences that would lead to less breakage for features
>that have reached the release channel.

>In the case of features where we don't know if the general design will
>be accepted as a cross-browser standard, shipping without prefix makes
>things better in the case our design gets accepted. With prefixes, we
>get breakage either way, so with prefixes we are always betting wrong.
>If our design doesn't get accepted, the standard can simply choose a
>differently-named API entry point. After all, the space of possible
>identifiers is countably infinite.

tl;dr - prefixing is bad. It's not good even before Release. API
version suffixing may be better.


Sure, if when standardized people add another parameter, you can change
the feature from Foo to Foo2 (or Bar, or Qwerty). But usually we've
chosen a "good" name for the feature (I hope), and people along the way
have learned that is the name of he feature, and so no one wants to
change it to Bar. If we use Foo2, then people get the "right" name, and
the API forevermore has the artifact that the API changed along the way.
(This may sound familiar from COM and other such APIs...)

Concrete example: Opera implemented an idea - navigator.getUserMedia().
This led to a standardization effort, which is standardizing
getUserMedia(). Great. But (no surprise) we all decided the API needed
to change (though I think for a time Opera resisted this; not for
long). So it's not compatible with Opera's getUserMedia() - but we
didn't change the name to Bar; everyone *knew* it was getUserMedia().
Everyone else implemented it with prefixes (even when still the same as
Opera's). webkitGetUserMedia() has changed API a couple of times and
likely will at least once more, because we're STILL arguing over whether
it should be fully asynchronous or partially async, or take a
placeholder input stream, etc. This is not a change we can really
avoid; we need it for important cases or we have to pevert an API
elsewhere. If this next iteration is adopted, then everyone will
unprefix to getUserMedia() - and clash with Opera's implementation.

A mess, to be sure. But Opera not prefixing didn't help things. I'll
note that vendor prefixing (moz/webkit) didn't help much either, except
that it avoided polluting the desired final symbol.

I'll note that Chrome did learn some from this, and for PeerConnection
they didn't vendor-prefix, they API-suffixed - PeerConnection01/02/etc.
When they un-prefixed they removed the API version (and changed to
RTCPeerConnection, because of arguments in the WG about namespacing in
JS - ask Anant).

One huge advantage to API versioning - they could change more than
once. Yes, conceptually there's nothing different about changing Foo to
Bar to Qwe compared to Foo01 to Foo02 to Foo - but people understand the
relationship of the second much better and more intuitively. (You *can*
remove the final change to Foo, and one can argue that ALL APIs should
have version suffixes, or after the first change - but at least for
simpler APIs one hopes they won't change again. Bigger ones like
PeerConnection may change, and then...)

Another advantage is that if during the process (including before
Release channel) two or more browsers implement the same proposed API
(closely enough) they can use the same version suffix. These wouldn't
be speced by the WG ("the Aug 3rd draft is Foo02"), but would be added
as needed by the browsers. If they don't, at least they won't clash and
people experimenting with the APIs will be able to use one or both, as
they prefer.

Coming back to prefixing - I dislike prefixing; but mostly because it
means only one change of API is allowed without people having to try to
sniff the version of the implementation. This *includes* prefixing
before going to Release channel! API suffixing seems a much better
solution, semantically equivalent to Foo to Bar to Final but easier to
understand (and to recognize when someone is using a pre-release API, if
we avoid shipping suffixed versions - though if we want to rev an API,
which will happen on occasion, suffixes are an option, though it may make
more sense in those cases to use some internal versioning or other way
to change/add functionality without breaking old users. Perhaps in some
case it will make sense to add a Foo2 and support both, either forever
or for a while. But that's really a separate, though related, question.

Also, when you un-suffix when the API is standardized, you can keep the
old Foo02 as an alias for Foo, so anyone building code on the
pre-release Foo02 continues to work. While semantically the same as
leaving a mozFoo, it has more sense to it - Foo is a shorthand for
Foo02. You don't have to leave it - there are arguments on both sides
(leaving it encourages people to use the "pre-release" version - but by
definition, it's the same API, so that's not really a problem.)

>In case of features like WebRTC where it's almost certain that
>breakage will occur, if we ship without prefix, we’ll be no worse off
>than shipping with prefix. Breakage occurs either way and experience
>shows that a prefix is worthless as a signal of API stability. So even
>in cases like WebRTC, it makes sense to bet for the case where
>breakage doesn't need to occur (i.e. the spec doesn’t end up changing
>after all).

--
Randell Jesup, Mozilla Corp

remove .news for personal responses

[Benoit Jacob]

2012/12/5 Henri Sivonen <hsiv...@iki.fi>

> Therefore, I propose that we adopt the following policy:

> 1) Excluding WebGL and WebRTC APIs, new APIs that are shipped on the

> release channel shall be shipped without a prefix.

> 2) If APIs that don’t already have specs are shipped, we’ll get specs
> written.
>
> (For clarity, the above formulation does not require WebGL or WebRTC
> to have prefixes.)
>

Thanks. To be clear and to conclude this on a positive note, the context of
our WG commitment in the case of WebGL is that WebGL prefixes are
reasonably kept under control:
- Only WebGL extensions can have suffixes, not core WebGL functionality;
- The WebGL API is designed so that you can't accidentally rely on an
extension (you have to explicitly call getExtension before you can use any
non-core functionality).
- There is a definite process to drop WebGL extension suffixes, so we can
drop suffixes on WebGL extensions that reach "community approved" status,
which actually happens in practice, typically after a few months or
real-world testing.

A couple draft WebGL extensions are overdue now for promoting to community
status, but other than that, the process is not too bad.

Benoit

>
> --
> Henri Sivonen
> hsiv...@iki.fi
> http://hsivonen.iki.fi/

[Henri Sivonen]

On Sat, Dec 8, 2012 at 5:24 PM, Randell Jesup <rjesu...@jesup.org> wrote:
> tl;dr - prefixing is bad. It's not good even before Release. API
> version suffixing may be better.

Are you OK with the latest policy proposal I made or do you intend to
make a counter-proposal with suffixing?

Latest for reference:
1) Excluding WebGL and WebRTC APIs, new APIs that are shipped on the

release channel shall be shipped without a prefix.

2) If APIs that don’t already have specs are shipped, we’ll get specs written.

(This policy implies nothing about what exactly WebRTC or WebGL do.
They are simply outside the scope of the proposed policy.)

> Sure, if when standardized people add another parameter, you can change
> the feature from Foo to Foo2 (or Bar, or Qwerty).

Better yet, adding more arguments to a method does not require
changing its name at all.

> one can argue that ALL APIs should
> have version suffixes

Even if WebRTC ends up using version suffixes, let’s not do that for
APIs in general. Experience suggests that it has been possible to
introduce APIs (e.g. APIs introduced by IE of old, canvas 2D or APIs
introduced by “HTML5”) without either prefixing or suffixing, so
making suffixing a rule seems like an overkill. I think in the usual
case (i.e. the non-WebRTC, non-WebGL case), it would make sense to see
how well we’ll do without either prefixes or suffixes. If we end up
doing fine, there is no need to add complexity.

Also, version suffixes can re-introduce the problem that, like vendor
prefixes, they might make us think it’s more OK to still bikeshed
things and introduce just one more version.

> Perhaps in some
> case it will make sense to add a Foo2 and support both, either forever
> or for a while. But that's really a separate, though related, question.

I don’t think it’s a separate question. With version suffixing, there
is a very real risk that removing old versions will break too much
content and so old versions stick around forever. In that case, the
same kind of considerations as those stated in
http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html and
http://robert.ocallahan.org/2008/01/http-equiv_22.html apply.

[Randell Jesup]

>On Sat, Dec 8, 2012 at 5:24 PM, Randell Jesup <rjesu...@jesup.org> wrote:
>> tl;dr - prefixing is bad. It's not good even before Release. API
>> version suffixing may be better.
>
>Are you OK with the latest policy proposal I made or do you intend to
>make a counter-proposal with suffixing?
>
>Latest for reference:
> 1) Excluding WebGL and WebRTC APIs, new APIs that are shipped on the
>release channel shall be shipped without a prefix.
> 2) If APIs that don’t already have specs are shipped, we’ll get specs written.
>
>(This policy implies nothing about what exactly WebRTC or WebGL do.
>They are simply outside the scope of the proposed policy.)

I'm ok with it, but I think it may be insufficient to avoid problems.
One could argue if we're going to try to push everyone to move off the
current prefixing, let's do it once. We're not likely to try again
soon, let alone succeed. Is it better than today? Yes, arguably. Does
it solve the fundamental problems? Only partly, and really only if
everyone follows suit. Are Google, MS and Apple (and Opera) on-board
with this?

>> Sure, if when standardized people add another parameter, you can change
>> the feature from Foo to Foo2 (or Bar, or Qwerty).
>
>Better yet, adding more arguments to a method does not require
>changing its name at all.

Quite true (and I mentioned elsewhere); I was writing quickly. Please
re-read as "some API change that's not backwards compatible".

>> one can argue that ALL APIs should
>> have version suffixes
>
>Even if WebRTC ends up using version suffixes, let’s not do that for
>APIs in general. Experience suggests that it has been possible to
>introduce APIs (e.g. APIs introduced by IE of old, canvas 2D or APIs
>introduced by “HTML5”) without either prefixing or suffixing, so
>making suffixing a rule seems like an overkill. I think in the usual
>case (i.e. the non-WebRTC, non-WebGL case), it would make sense to see
>how well we’ll do without either prefixes or suffixes. If we end up
>doing fine, there is no need to add complexity.
>
>Also, version suffixes can re-introduce the problem that, like vendor
>prefixes, they might make us think it’s more OK to still bikeshed
>things and introduce just one more version.

Both reasonable arguments. Versioning might be best reserved for
more-complex-than-average APIs and ones where people want to do
cross-browser experimentation (pre-release).

The second argument might be minimized or avoided by not shipping
suffixed APIs for the simpler ones. Though I'm unsure how large a
problem this would be, compared to the current issues with prefixing.

>> Perhaps in some
>> case it will make sense to add a Foo2 and support both, either forever
>> or for a while. But that's really a separate, though related, question.
>
>I don’t think it’s a separate question. With version suffixing, there
>is a very real risk that removing old versions will break too much
>content and so old versions stick around forever. In that case, the
>same kind of considerations as those stated in
>http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html and
>http://robert.ocallahan.org/2008/01/http-equiv_22.html apply.

Yes. It's a classic "stick with something forever" or "support the old
thing (virtually) forever" or "break the old thing (now or sometime
'soon')". This certainly has minuses, but never improving does too.
And introducing it under a totally different name (instead of
Foo2) doesn't change anything.

--
Randell Jesup, Mozilla Corp

remove ".news" for personal email

[Henri Sivonen]

On Tue, Dec 11, 2012 at 9:44 AM, Randell Jesup <rjesu...@jesup.org> wrote:
> I'm ok with it,

Great!

> but I think it may be insufficient to avoid problems.

It turned out to be harder to get agreement on the part whose purpose
was to avoid problems: the part about not shipping experimental stuff
on the release channel.

> One could argue if we're going to try to push everyone to move off the
> current prefixing, let's do it once.

If WebGL and WebRTC don’t want to be pushed now, I’d rather stop
vendor prefixing for everything else and let WebGL and WebRTC to come
round at their own pace than see this proposal sink because of WebGL
or WebRTC concerns. (WebGL and WebRTC living in their own worlds isn’t
quite safe, though, because they can leak. For example, we have WebGL
to blame for making the Web platform dependent on little-endian
hardware. Or maybe the real blame should go to TC39 for not giving
WebGL something better in a timely fashion.)

> Are Google, MS and Apple (and Opera) on-board
> with this?

If we require everyone to move in unison, we’ll never make progress.
Someone needs to make the first move and others will follow if the CSS
situation is any indicator. Previous discussions make me expect Opera
and Google to be the most likely vendors to follow us soon if we stop
shipping vendor prefixes.

> Versioning might be best reserved for
> more-complex-than-average APIs and ones where people want to do
> cross-browser experimentation (pre-release).

Considering that versioning has been an anti-pattern on the Web in
general[1], I think we should wait and see how versioning works for
WebRTC before doing it more broadly. (My general expectation is that
it’s bad to introduce APIs in such more-complex-than-average chunks
that the need for versioning arises.)

[1] HTML tried to version itself but browsers ingest all versions
using the same code. Likewise for SVG. On the other hand, XML tried to
version itself but coupled versioning with such a disastrous error
handling policy that their 1.1 launch flopped. JS versioning is
virtually unused on the Web (as opposed to Firefox-internal code). CSS
has been wisely designed as versionless from the processing point of
view.

[Anthony Jones]

On 11/12/12 06:40, Henri Sivonen wrote:

> On Sat, Dec 8, 2012 at 5:24 PM, Randell Jesup <rjesu...@jesup.org> wrote:
>> tl;dr - prefixing is bad. It's not good even before Release. API
>> version suffixing may be better.
>

> Are you OK with the latest policy proposal I made or do you intend to
> make a counter-proposal with suffixing?
>
> Latest for reference:

> 1) Excluding WebGL and WebRTC APIs, new APIs that are shipped on the

> release channel shall be shipped without a prefix.

> 2) If APIs that don’t already have specs are shipped, we’ll get specs written.

Name mangling is a poor solution. Perhaps we could come up with an API
for exposing experimental features?

enableExperimentalFeature(feature, version)

Anthony

[Henri Sivonen]

On Thu, Dec 13, 2012 at 10:11 PM, Anthony Jones <ajo...@mozilla.com> wrote:
> Perhaps we could come up with an API
> for exposing experimental features?

To go back to an earlier part of this thread: If you expose something
on the release channel to Web authors, you are de facto releasing the
feature for Web authors to bake into their sites/apps and risking it
getting stuck in the sense that breaking changes cause a bad end user
experience of sites/apps breaking. A moz prefix does not change that.
Having to call enableExperimentalFeature() won’t change that. Writing
documentation that says the feature is experimental won’t change that.

> enableExperimentalFeature(feature, version)

As with version suffixing, there is a very real risk that removing old

versions will break too much content and so old versions stick around
forever. In that case, the
same kind of considerations as those stated in
http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html and
http://robert.ocallahan.org/2008/01/http-equiv_22.html apply.