On Thu, Dec 13, 2012 at 10:11 PM, Anthony Jones 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 t
On 11/12/12 06:40, Henri Sivonen wrote:
> On Sat, Dec 8, 2012 at 5:24 PM, Randell Jesup 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-propo
On Tue, Dec 11, 2012 at 9:44 AM, Randell Jesup 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 chann
>On Sat, Dec 8, 2012 at 5:24 PM, Randell Jesup 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:
On Sat, Dec 8, 2012 at 5:24 PM, Randell Jesup 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) Exc
2012/12/5 Henri Sivonen
> 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.
>
> (
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 pro
On Tue, Nov 27, 2012 at 10:49 AM, Henri Sivonen 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
On 2012-11-30 12:16 PM, Henri Sivonen wrote:
On Tue, Nov 27, 2012 at 6:59 PM, Ehsan Akhgari 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
On Tue, Nov 27, 2012 at 6:59 PM, Ehsan Akhgari 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) I
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
On Tue, Nov 13, 2012 at 8:05 PM, Ehsan Akhgari wrote:
> On 2012-11-12 6:01 AM, Henri Sivonen wrote:
>>
>> On Fri, Nov 9, 2012 at 10:32 PM, Ehsan Akhgari
>> 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 availabl
On Wed, Nov 14, 2012 at 2:23 PM, Mounir Lamouri 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
On 14/11/12 19:27, Gavin Sharp wrote:
> On Wed, Nov 14, 2012 at 10:53 AM, Mounir Lamouri 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 wh
On Wed, Nov 14, 2012 at 10:53 AM, Mounir Lamouri 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 defa
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
(a
Henri Sivonen writes:
> On Tue, Nov 13, 2012 at 9:59 AM, Randell Jesup 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 beca
On 2012-11-12 6:01 AM, Henri Sivonen wrote:
On Fri, Nov 9, 2012 at 10:32 PM, Ehsan Akhgari 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
On Tue, Nov 13, 2012 at 9:59 AM, Randell Jesup 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 so
On Tue, Nov 13, 2012 at 12:14 PM, Neil wrote:
> Henri Sivonen wrote:
>
>> On Fri, Nov 9, 2012 at 7:38 PM, Neil 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 wou
Henri Sivonen wrote:
On Fri, Nov 9, 2012 at 7:38 PM, Neil 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 pref
Henri Sivonen writes:
> On Fri, Nov 9, 2012 at 10:32 PM, Ehsan Akhgari
> wrote:
>> 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
On Fri, Nov 9, 2012 at 10:32 PM, Ehsan Akhgari 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 wo
On Fri, Nov 9, 2012 at 7:38 PM, Neil 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
hsivo...@iki.fi
http://hs
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 ho
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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
h
2012/11/8 Benoit Jacob :
> 2012/11/8 Henri Sivonen :
>> On Wed, Nov 7, 2012 at 8:11 PM, Benoit Jacob
>> 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.
>>
>>
2012/11/9 Robert Kaiser :
> 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)
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
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 wrote:
>
> > On 2012-11-08 1:44 AM, Henri Sivonen
On Thu, Nov 8, 2012 at 6:56 PM, Ehsan Akhgari 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 cons
On Thu, Nov 8, 2012 at 5:47 PM, Benoit Jacob 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
On 2012-11-08 1:44 AM, Henri Sivonen wrote:
On Thu, Nov 8, 2012 at 12:03 AM, Ehsan Akhgari 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 rele
2012/11/8 Henri Sivonen :
> On Wed, Nov 7, 2012 at 8:11 PM, Benoit Jacob 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 exte
On Thu, Nov 8, 2012 at 8:41 AM, Henri Sivonen 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…
--
Henri Sivonen
hsi
On Thu, Nov 8, 2012 at 12:03 AM, Ehsan Akhgari 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
On Wed, Nov 7, 2012 at 8:11 PM, Benoit Jacob 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 cha
On Wed, Nov 7, 2012 at 7:24 PM, Joe Drew 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 t
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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
http
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
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
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 understan
42 matches
Mail list logo
