On 26/06/13 17:08, Andrew Overholt wrote: > On 25/06/13 12:15 PM, Mounir Lamouri wrote: >> Also, I do not understand why we are excluding CSS, WebGL and WebRTC. We >> should definitely not make this policy retro-apply so existing features >> should not be affected but if someone wants to add a new CSS property, >> it is not clear why this shouldn't go trough this process. > > My hope was to get something in place for APIs and then build up to > other web-exposed "things" like CSS, etc.
In my opinion, CSS, HTML, DOM, WebGL, WebRTC and other Web APIs should follow that rules. I do not see why CSS, for example, should be an exception. >> "ship" is too restrictive. If a feature is implemented and available in >> some version (even behind a flag) with a clear intent to ship it at some >> point, this should be enough for us to follow. > > I changed it to "at least two other browser engines ship (regardless if > it's behind a flag or not in their equivalent of beta or release) -- a > compatible implementation of this API ". How's that? I don't want to > see us basing our decision to ship on another engine's use of their > nightly equivalent for experimentation (whether this happens right now > or not). Am I worried for no reason? As Henri said, we should make sure that there is a genuine intent to ship if a feature is implemented in a browser (even behind a flag). Reaching out to the other vendors in that case should be easy. >>> 2. ecosystem- and hardware-specific APIs that are not standard or of >>> interest to the broader web at that time (or ever) may be shipped in >>> a way to limit their harm of the broader web (ex. only on a device >>> or only in specific builds with clear disclaimers about applicability >>> of exposed APIs). An example of this is the FM Radio API for Firefox >>> OS. >> >> When I read this, I read "It is okay to have Mozilla ship a phone with >> proprietary APIs". That means that we are okay with Mozilla creating the >> situation Apple created on Mobile, a situation that Mozilla has been >> criticising a lot. Shipping proprietary APIs on a specific device is >> harming the broader Web if that device happens to be one of the most >> used device out there... > > The way you read it obviously not something we want to do. What if we > dropped the "ecosystem-"? I can't see how we can allow ourselves to > ship hardware-specific APIs that don't work everywhere without an > exception like this. If this exception is only about mobile or hardware-specific APIs, we might want as well remove it. If we do not standardise things like FM Radio API it is not really because it requires a FM Radio (a lot of phones have this feature) but mostly because no one else want this for the moment. > Are there situations where we would ship such an > API on desktop if there's very little chance of the required hardware > existing there? Indeed, we would not ship an API on desktop if it doesn't work on desktop but I am not following the logic here. If an API works only on Mobile, it should be standardised as well. An good example being the Screen Orientation API. >>> Declaring Intent >>> API review >>> Implementation >>> Shipping >> >> I think some clarifications are needed in those areas. > > I changed the section headers to: > > Declaring Intent to Implement > API review > Implementation > Intent to Ship and Shipping > > How's that? I didn't meant the names but the content of those sections ;) >> The issue with having "dev-platform" finding a consensus with intent >> emails is that we might end up in a infinite debate. In that case, we >> should use the module system and have the module owner(s) of the >> associated area of code make the decision. If the module owner(s) can't >> take this decision, we could go upward and ask Brendan to make it. > > I admit I didn't think much about "dev-platform" coming to a consensus. > I guess I'd like major disputes to be handled on a case-by-case basis > and not have to define what should be done in the infinite discussion > situations. Maybe we should just be more forthcoming as reviewers or > module owners about something we wouldn't want to ship and thus save > potential implementors' time. I would bet that consensus is going to be reached most of the time. We used to discuss a lot of things in dev-webapi and we never ended up in infinite discussions. -- Mounir _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
