On Fri, Jun 21, 2013 at 11:45 PM, Andrew Overholt <overh...@mozilla.com> wrote: > https://wiki.mozilla.org/User:Overholt/APIExposurePolicy > > I'd appreciate your review feedback. Thanks.
Thank you for putting this together. In general, I'd like the point "no prefixing" to be made more forcefully/clearly. Further quotes from the doc. > Standardization It's a bit unclear if this section is trying to establish criteria for shipping a feature on the release channel or criteria for starting an implementation in Gecko without shipping it right away. > the relevant standards body declares it ready for implementation Since the next two points talk about implementations but this one doesn't, I'm reading this as a standards body declaration happening without other implementations in place. For the purpose of shipping a feature on the release channel, I think a declaration by a standards body isn't good enough. If no one else wants to ship, which still end up with a single-vendor feature even if we somehow managed to get a standards body to bless it. (And the W3C blesses all sorts of things as evidenced by enterprise XML stuff and capital-S Semantic Web stuff.) For the purpose of starting an implementation in Gecko, the point in time where the W3C declares a spec ready for implementation is woefully late from the point of view of when you should have started implementing. I think for the purpose of starting implementation we should have a less precise criterion about when a spec at a standards body seems stable enough to start implementation. > at least two other browser vendors ship a compatible implementation of this > API This formulation has two problems: First, it talks about browser vendors instead of talking about browser engines. Google and Opera shipping the same code from the Blink repo should not count as to independent implementations. Second, it talks about shipping. If everyone adopted these rules, we'd be deadlocked for shipping. Instead of shipping, I think we should talk about a compatible implementation in the nightly builds (or higher) of at least two other browser engines when there is a reasonable assumption that the feature is genuinely on track to graduating from nightly builds to release eventually. > at least one other browser vendor ships -- or publicly states their intention > to ship -- a compatible implementation of this API and there is a > specification that is no longer at risk of significant changes, on track to > become a standard with an relevant standards body, and acceptable to a number > of applicable parties I think this point should be similarly tightened to talk about browser engines instead of vendors and relaxed to allow other engines' nightly builds to be considered when considering whether we can move a feature to release. > Exceptions Is the intention that APIs shipped under the exceptions to the rules still be unprefixed? (I think it's better to squat namespace and not prefix than to risk unprefixed feature getting popular enough that we need to consider unprefixing later.) > Shipping It seems to me that it should be clarified that "shipping" means pressing on by default on the release channel and it's okay to have code in m-c and even enabled in nightlies before that. > Cleanup window.navigator seems like a poor example of something to be cleaned up. Surely it is now such a part of the platform that it mustn't be changed. -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.iki.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
