Re: Proposal: Not shipping prefixed APIs on the release channel
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: On Thu, Nov 8, 2012 at 6:56 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2012-11-08 1:44 AM, Henri Sivonen wrote: 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. 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. ? -- 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
Re: Proposal: Not shipping prefixed APIs on the release channel
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 (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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Not shipping prefixed APIs on the release channel
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Not shipping prefixed APIs on the release channel
2012/11/8 Benoit Jacob jacob.benoi...@gmail.com: 2012/11/8 Henri Sivonen hsivo...@iki.fi: On Wed, Nov 7, 2012 at 8:11 PM, Benoit Jacob jacob.benoi...@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 hsivo...@iki.fi http://hsivonen.iki.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: move content JS interpretation to a background thread
Honza Bambas schrieb: Few reasons: - I really don't believe we will soon/ever have a good OOP Firefox implementation AFAIK, the major reason why we did abandon doing that was because moving all our interaction with the content to be async was too much work for the moment. Isn't that same work required for what you propose? If so, I don't see why we should go for that instead of taking another shot at moving content to a separate process - after all, we're using that process separation code in B2G quite heavily as well, so it's not that code itself that is problematic, it's making Firefox work well with the parallelization it brings. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: move content JS interpretation to a background thread
On 11/9/2012 8:26 AM, Robert Kaiser wrote: AFAIK, the major reason why we did abandon doing that was because moving all our interaction with the content to be async was too much work for the moment. Isn't that same work required for what you propose?\ No. AIUI, the reason we abandoned electrolysis was because it meant that a huge percentage of add-ons would have to be rewritten to work in the new model. We could accept this as a one-time cost, but looking further into the future, if Servo is a viable project and we decide to ship it as Firefox we'd have to take that add-on compatibility hit again. Once we can probably survive. Twice is too much to ask. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changes to JS components/JSMs
On Sun, Nov 4, 2012 at 11:53 PM, Mook mook.moz+nntp.news.mozilla@gmail.com.please-avoid-direct-mail wrote: Ping - was this part ever answered? Did you see my email on November 1st? - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed style guide modification: using declarations and nested namespaces
I reviewed a patch today that had: using namespace mozilla; using namespace dom; The intent is to pull in the contents of both the mozilla and mozilla::dom namespaces, but this is only clear if you know that there is no top-level dom namespace. In the review comments I asked the author to write this with fully qualified namespaces. That is, as: using namespace mozilla; using namespace mozilla::dom; If nobody has objections I'd like to add this to the style guide. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
No Gfx meeting next Monday, November 12. Also probably no meeting the week after.
Hi, There won't be a Gfx meeting next week. We had one last Monday, and next week the Gfx team is gathering in Vancouver. For the same reason, by default I expect that we won't meet either on November 19. Let's say that meeting is cancelled by default, and if we end up deciding we want to meet on Nov. 19, I'll send another email. Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 11/9/12 10:28 AM, Kyle Huey wrote: I reviewed a patch today that had: using namespace mozilla; using namespace dom; The intent is to pull in the contents of both the mozilla and mozilla::dom namespaces, but this is only clear if you know that there is no top-level dom namespace. In the review comments I asked the author to write this with fully qualified namespaces. That is, as: using namespace mozilla; using namespace mozilla::dom; If nobody has objections I'd like to add this to the style guide. Why stop there? What about: using namespace ::mozilla; using namespace ::mozilla::dom; ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On Fri, Nov 9, 2012 at 10:46 AM, Gregory Szorc g...@mozilla.com wrote: On 11/9/12 10:28 AM, Kyle Huey wrote: I reviewed a patch today that had: using namespace mozilla; using namespace dom; The intent is to pull in the contents of both the mozilla and mozilla::dom namespaces, but this is only clear if you know that there is no top-level dom namespace. In the review comments I asked the author to write this with fully qualified namespaces. That is, as: using namespace mozilla; using namespace mozilla::dom; If nobody has objections I'd like to add this to the style guide. Why stop there? What about: using namespace ::mozilla; using namespace ::mozilla::dom; In the past people have complained when I've written code that prefixes symbols with '::'. I suspect my proposal will be easier to reach consensus on. ;-) I don't have any objections to :: though. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 2012-11-09 1:28 PM, Kyle Huey wrote: I reviewed a patch today that had: using namespace mozilla; using namespace dom; The intent is to pull in the contents of both the mozilla and mozilla::dom namespaces, but this is only clear if you know that there is no top-level dom namespace. In the review comments I asked the author to write this with fully qualified namespaces. That is, as: using namespace mozilla; using namespace mozilla::dom; The style guidelines recommend against using nested namespaces, so doing what you suggest would make them self-inconsistent. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Not shipping prefixed APIs on the release channel
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 11/9/12 11:53 AM, Ehsan Akhgari wrote: using namespace mozilla; using namespace mozilla::dom; The style guidelines recommend against using nested namespaces, so doing what you suggest would make them self-inconsistent. But we have some nested namespaces today, so `using` them like Kyle suggests lets people write code as if the nested namespace did not exist. That should make unnesting the namespaces easier in the future. :) chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 2012-11-09 3:40 PM, Chris Peterson wrote: On 11/9/12 11:53 AM, Ehsan Akhgari wrote: using namespace mozilla; using namespace mozilla::dom; The style guidelines recommend against using nested namespaces, so doing what you suggest would make them self-inconsistent. But we have some nested namespaces today, so `using` them like Kyle suggests lets people write code as if the nested namespace did not exist. That should make unnesting the namespaces easier in the future. :) I agree with what Kyle suggests. But I think that instead of making the style guidelines more friendly to nested namespaces, we should focus on doing less of that in our code. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 2012-11-09 1:28 PM, Kyle Huey wrote: I reviewed a patch today that had: using namespace mozilla; using namespace dom; The style guide should forbid `using namespace` altogether. Use only what you need. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On Fri, Nov 9, 2012 at 10:14 PM, Zack Weinberg za...@panix.com wrote: The style guide should forbid `using namespace` altogether. Use only what you need. I really don't think it should. I do not want to see source files full of difficult-to-maintain and unnecessary using boilerplate a la Java import. At least with Java imports, there are really good tools for managing the mess; we don't have those tools for C++. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 2012-11-09 10:49 PM, Robert O'Callahan wrote: On Fri, Nov 9, 2012 at 10:14 PM, Zack Weinberg za...@panix.com wrote: The style guide should forbid `using namespace` altogether. Use only what you need. I really don't think it should. I do not want to see source files full of difficult-to-maintain and unnecessary using boilerplate a la Java import. At least with Java imports, there are really good tools for managing the mess; we don't have those tools for C++. I challenge your presuppositions. The average file should need no more than one or two `using SYMBOL;` lines per header it includes. Maintaining this will not be significantly more difficult than maintaining the existing lists of header inclusions (which I admit is already too difficult). And I think that it is worth it in order not to lose one of the major benefits of namespaces, viz. that you don't have to worry about symbol conflicts with anything but what you actually use. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
2012/11/9 Zack Weinberg za...@panix.com: On 2012-11-09 1:28 PM, Kyle Huey wrote: I reviewed a patch today that had: using namespace mozilla; using namespace dom; The style guide should forbid `using namespace` altogether. Use only what you need. In a given cpp file (in a single TU), as long as it builds, I don't see the problem with using namespace. Of course I see the theoretical problem, it's never been a real issue IME. If it ever causes problems in a given cpp file it's easy enough to stop doing using namespace there. Likewise (even more so) at function scope I don't see an issue with using namespace. The only issue I see is using namespace at file scope in a _header file_. I would support a coding style rule against that. I filed bug 798033 about removing the occurences that we have of that, and a new contributor is making great progress there. Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 11/9/12 8:11 PM, Benoit Jacob wrote: The only issue I see is using namespace at file scope in a _header file_. I would support a coding style rule against that. https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style#Namespaces says: No using statements are allowed in header files, except inside class definitions or functions. So whoever is putting using in header files is already breaking the rules... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 11/9/12 8:03 PM, Zack Weinberg wrote: I challenge your presuppositions. The average file should need no more than one or two `using SYMBOL;` lines per header it includes. That depends on the structure of the code, no? For example, until we finish moving over all of the DOM to live inside the mozilla::dom namespace, something like nsDocument would need to have a using for every single interface type used in the Document interface in IDL... I assure you there are more than two of those. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changes to JS components/JSMs
On 11/9/2012 10:12 AM, Kyle Huey wrote: On Sun, Nov 4, 2012 at 11:53 PM, Mook mook.moz+nntp.news.mozilla@gmail.com.please-avoid-direct-mail wrote: Ping - was this part ever answered? Did you see my email on November 1st? - Kyle Argh; sorry, Thunderbird screwed up threading there and decided your message was a sibling. That, and I initially read it as it'll work until we decide to change it, and there's been a... history of prefs being flipped because it's easy to do so and explicitly not supporting external code that depended on the old behaviour :( -- Mook ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
On 11/9/12 12:52 AM, James Graham wrote: I know Mozilla use a system where all the tests in a file should pass, but I don't see how that will work well when you don't control the tests. If you are manually editing every file when you import it, I imagine that updating tests will be so time consuming that it will be tempting not to bother. How do you plan to address this? I believe right now we have a list of known failures alongside such tests, and our own test harness knows to compare what the tests are reporting to our list of known failures. As in, we're not using the pass/fail state of the tests directly; we're comparing it to should all pass, except this whitelist of things that we know fail. Constructing these whitelists of known failures is indeed a bit of a PITA, but they're pretty static until we fix stuff, usually. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
