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 hsivo...@iki.fi http://hsivonen.iki.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
