No longer vendor-prefixing features (was: Re: Mobile Evangelism)

[Henri Sivonen]

On Wed, Dec 7, 2011 at 3:19 PM, Dao <d...@design-noir.de> wrote:
> On 07.12.2011 10:11, Henri Sivonen wrote:
>>
>> Can we change our ways so that whenever we add an API
>> that we feel is "ready" enough to ship, we ship it unprefixed even if
>> it has not been standardized *yet* and propose it for standardization?
>
> What makes you believe that feeling won't sometimes trick us (or Microsoft,
> Google, Apple)?

It probably would once in a while, but currently the feeling that
prefixing makes shipping not-properly-baked stuff is OK is tricking
vendors all the time.

On Thu, Dec 8, 2011 at 1:14 PM, Gervase Markham <ge...@mozilla.org> wrote:
> On 07/12/11 09:11, Henri Sivonen wrote:
>> The doc mention -webkit- prefixes and pooling effort with other
>> vendors (i.e. Microsoft and Opera). I think we should have a better
>> story than "Please add this -moz- thing in addition to the -webkit-
>> thing you already have and, BTW, remember to say -o- and -ms-, too."
>>
>> If we now perceive webkit prefixing as a problem, I think we should
>> apply the golden rule and stop being part of the problem with moz
>> prefixing so that we'd have unprefixed vendor-neutral identifiers to
>> evangelize. See http://hsivonen.iki.fi/vendor-prefixes/ .
>
> I hear what you are saying, but I think this is a debate to be had
> separately, and the evangelism effort will work with the result.

OK. Splitting the thread.

> I think we should start by presenting the problem to e.g. the CSS-WG,
> and asking them what they think we should do about it.

The problem has been presented to the CSS WG.

However, while WebKit has introduced numerous prefixed CSS features,
Mozilla has been introducing prefixed APIs. For APIs, there isn't (to
my knowledge) any WG policy. Since prefixing APIs is Mozilla's own
policy, we could stop prefixing APIs without presenting anything to
the CSS WG.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Boris Zbarsky]

On 12/9/11 9:23 AM, Henri Sivonen wrote:
> However, while WebKit has introduced numerous prefixed CSS features,
> Mozilla has been introducing prefixed APIs.

I believe for every single API we've prefixed and then unprefixed so far
we have in fact ended up making incompatible changes to it before
unprefixing.

We could stop prefixing APIs, but then we'd have to do a lot more
specwork and consensus building and whatnot before adding them in the
first place....

-Boris

[Gervase Markham]

If we were making a data-driven decision here :-), someone might want to
make a list of the finished APIs we've added in the past (say) 3 years,
the date (A) they went in prefixed, the date (C) they were unprefixed,
and then (and this is the trick) the date (B) we could have unprefixed
them if we had perfect vision of the future - i.e. when did the last
incompatible change go in?

Is B usually close to A, close to C, or does it range about from API to API?

Gerv

[Boris Zbarsky]

On 12/12/11 9:13 AM, Gervase Markham wrote:
> Is B usually close to A, close to C, or does it range about from API to API?

Good question. Data needed.

-Boris

[Henri Sivonen]

On Fri, Dec 9, 2011 at 9:09 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> On 12/9/11 9:23 AM, Henri Sivonen wrote:
>>
>> However, while WebKit has introduced numerous prefixed CSS features,
>> Mozilla has been introducing prefixed APIs.
>
>
> I believe for every single API we've prefixed and then unprefixed so far we
> have in fact ended up making incompatible changes to it before unprefixing.

Doesn't that mean that in practice, we have been willing to make
incompatible changes to APIs that we've shipped?

Why would the willingness to make incompatible changes to APIs be
different if prefixes were absent? One possible answer is that the
prefix signals to Web authors that they are using a subject-to-change
API. However, the way authors use WebKit's prefixed CSS suggests that
authors (by and large) don't really know or care about such
distinctions and use whatever works at the time they are writing code.
Also, from the user point of view, site breakage is site breakage
regardless of reason. That is, the people who end up suffering from
breakage aren't the people who are supposed to be aware of the risk,
so arguments about authors knowing what they are getting into don't
seem particularly convincing.

[Gervase Markham]

Who can gather it? It would need to be someone familiar with Gecko
development, although they could probably be seriously helped by 5
minutes on the phone with you, dbaron, and roc, where you brainstormed
ideas and rough dates.

Gerv

[Boris Zbarsky]

On 12/13/11 2:35 AM, Henri Sivonen wrote:
> Doesn't that mean that in practice, we have been willing to make
> incompatible changes to APIs that we've shipped?

Often combined with removing the old name entirely, yes.

And in many cases this happened before we shipped in a final release, by
the way.

Of course adoption for those APIs was low at the time, not least because
they used different names in different browsers.

> Why would the willingness to make incompatible changes to APIs be
> different if prefixes were absent? One possible answer is that the
> prefix signals to Web authors that they are using a subject-to-change
> API.

For one thing, because making an API not work at all (renaming) is a lot
more noticeable for web developers than just silently changing its
behavior, so they're more likely to fix.

But yes, also the reason you mention.

> However, the way authors use WebKit's prefixed CSS suggests that
> authors (by and large) don't really know or care about such
> distinctions

For APIs that have been around for a long time.

-Boris

[Boris Zbarsky]

On 12/13/11 8:01 AM, Gervase Markham wrote:
> Who can gather it?

Probably anyone who can use Bugzilla. The combination of our "for
developers" release documentation and bug queries should be able to
answer these questions.

-Boris

[Jonas Sicking]

On Mon, Dec 12, 2011 at 11:35 PM, Henri Sivonen <hsiv...@iki.fi> wrote:
> On Fri, Dec 9, 2011 at 9:09 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

>> On 12/9/11 9:23 AM, Henri Sivonen wrote:
>>>
>>> However, while WebKit has introduced numerous prefixed CSS features,
>>> Mozilla has been introducing prefixed APIs.
>>
>>
>> I believe for every single API we've prefixed and then unprefixed so far we
>> have in fact ended up making incompatible changes to it before unprefixing.
>

> Doesn't that mean that in practice, we have been willing to make
> incompatible changes to APIs that we've shipped?
>

> Why would the willingness to make incompatible changes to APIs be
> different if prefixes were absent? One possible answer is that the
> prefix signals to Web authors that they are using a subject-to-change
> API.

Indeed, this is exactly the theory.

> However, the way authors use WebKit's prefixed CSS suggests that
> authors (by and large) don't really know or care about such

> distinctions and use whatever works at the time they are writing code.

Indeed, it's not a perfect theory.

I suspect that in part this is due to the fact that it hasn't been
clearly communicated that they might change in the future. I.e. you'll
often see blog posts like "webkit now supports feature X, here's the
syntax that you should use" rather than "We've introduce this
experimental feature, here's the syntax that works right now, but be
aware that it might change in the future."

Another problem is that have remained "stable" for a long time with no
clear direction for them getting standardized an unprefixed. I.e.
standardization has been slow and not tracked by the prefixed
implementation.

> Also, from the user point of view, site breakage is site breakage
> regardless of reason. That is, the people who end up suffering from
> breakage aren't the people who are supposed to be aware of the risk,
> so arguments about authors knowing what they are getting into don't
> seem particularly convincing.

I don't think this is true. I think setting expectations is really
important. Whenever we make breaking changes there are people that
step up and say that we broke them. In the cases when we can point to
that we're doing the change in order to align with the spec this has
more often than not made people accept the change and go update their
website.

I think setting expectations is a huge part of this. First off, if
people know that we're not just willy-nilly changing things on a whim,
but rather after careful consideration, then there is a bigger
understanding. Also, if they see that we are making the change to
align with the spec, that means that it's unlikely that we'll change
it again and so it's worth their time investment to fix up the code
now. I.e. they don't have to worry about it changing back or changing
again 5 days later.

Another reason that I think people are more ok with changes that align
us with the spec is that everyone sees and understands the value of
having consistently implemented specs.

To put it another way: No, I don't think "site breakage is site
breakage regardless of reason" is an accurate statement for how
developers feel. Making the investment to update a site is much easier
if you know that you'll get return on that investment in the form of
code that will work better going forward, and code that will work
across more browsers.

On a related note, this is why I don't think that the statement "the
spec doesn't matter, implementations is the only thing that matters"
is accurate.

/ Jonas

[Gervase Markham]

On 13/12/11 16:12, Boris Zbarsky wrote:
> Probably anyone who can use Bugzilla. The combination of our "for
> developers" release documentation and bug queries should be able to
> answer these questions.

http://blog.gerv.net/2011/12/api-prefixing-making-a-data-driven-decision-help-wanted/

Gerv

[Henri Sivonen]

On Wed, Dec 14, 2011 at 1:15 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Mon, Dec 12, 2011 at 11:35 PM, Henri Sivonen <hsiv...@iki.fi> wrote:
>> On Fri, Dec 9, 2011 at 9:09 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

>>> On 12/9/11 9:23 AM, Henri Sivonen wrote:
>>>>
>>>> However, while WebKit has introduced numerous prefixed CSS features,
>>>> Mozilla has been introducing prefixed APIs.
>>>
>>>
>>> I believe for every single API we've prefixed and then unprefixed so far we
>>> have in fact ended up making incompatible changes to it before unprefixing.
>>

>> Doesn't that mean that in practice, we have been willing to make
>> incompatible changes to APIs that we've shipped?
>>
>> Why would the willingness to make incompatible changes to APIs be
>> different if prefixes were absent? One possible answer is that the
>> prefix signals to Web authors that they are using a subject-to-change
>> API.
>
> Indeed, this is exactly the theory.

I did a quick spot check of the first three Hacks articles that I
found under the "Feature" tag talking about a moz-prefixed feature:
http://hacks.mozilla.org/2009/10/orientation-for-firefox/
http://hacks.mozilla.org/2011/10/css-3d-transformations-in-firefox-nightly/
http://hacks.mozilla.org/2010/07/firefox4-beta2/

None of these warn the reader that this is subject-to-change stuff.
Instead, these features are advertised as something that Firefox now
has. (Also note how the CSS articles defeat the whole point of
prefixes by including the unprefixed property in advance and how the
article about Transitions and Transforms excludes the -ms- prefix (and
obviously any non-incumbent prefixes).)

>> However, the way authors use WebKit's prefixed CSS suggests that
>> authors (by and large) don't really know or care about such
>> distinctions and use whatever works at the time they are writing code.
>
> Indeed, it's not a perfect theory.
>
> I suspect that in part this is due to the fact that it hasn't been
> clearly communicated that they might change in the future.

Is there any reason to believe that Mozilla's communication to Web
developers will change in the future on this point? It seems to me
that all incentives go against publishing outreach messages that
effectively say "hey, we added this thing to our product for you to
use so that we can get feedback about broader deployment than we could
get with nightlies but we may break it so don't use it yet for
anything important".

>> Also, from the user point of view, site breakage is site breakage
>> regardless of reason. That is, the people who end up suffering from
>> breakage aren't the people who are supposed to be aware of the risk,
>> so arguments about authors knowing what they are getting into don't
>> seem particularly convincing.
>
> I don't think this is true. I think setting expectations is really
> important. Whenever we make breaking changes there are people that
> step up and say that we broke them. In the cases when we can point to
> that we're doing the change in order to align with the spec this has
> more often than not made people accept the change and go update their
> website.

Changes to unprefixed stuff would align us better with specs.
(Prefixed stuff is unaligned with specs by definition!)

> I think setting expectations is a huge part of this. First off, if
> people know that we're not just willy-nilly changing things on a whim,
> but rather after careful consideration, then there is a bigger
> understanding. Also, if they see that we are making the change to
> align with the spec, that means that it's unlikely that we'll change
> it again and so it's worth their time investment to fix up the code
> now. I.e. they don't have to worry about it changing back or changing
> again 5 days later.

Of course changes to unprefixed stuff should only happen after careful
consideration and to align with the spec and we should say so when
communicating changes.

> To put it another way: No, I don't think "site breakage is site
> breakage regardless of reason" is an accurate statement for how
> developers feel.

Do you have data indicating that Web developers are more OK with a
breaking change that goes from prefixed to unprefixed-and-spec-aligned
than with a breaking change that goes from
unprefixed-and-old-spec-aligned or unprefixed-and-accidentally-buggy
to unprefixed-and-new-spec-aligned?

It's worth noting that the Canvas API and the <video> element's API
have pretty successfully been evolved in place unprefixed.

Any ideas about how we might get data that shows if Web developers
really have a different perception of breaking changes to prefixed
features than of breaking changes of unprefixed features and that the
difference in perception matters? It's kinda silly if we are more
willing to break prefixed stuff because of *our* perceptions. (I have
a really hard time believing that prefixed vs. unprefixed behind the
scenes makes any difference as far as user perception of site breakage
goes.)

[Wes Garland]

You know -- something that hasn't been mentioned in this thread is
implementations conforming to draft specifications. I'm specifically
talking about CSS3 here. Why is it that we vendor-prefix implementations
that match a draft standard?

I gotta say, this kind of stuff is getting on my nerves as a developer:

.dfIconScaleUp
{
transform: scale( 2.2 );
-moz-transform: scale( 2.2 );
-webkit-transform: scale( 2.2 );
-ms-transform: scale( 2.2 );
-o-transform: scale( 2.2 );
}

If we're going to prefix draft standards, maybe allow a -draft prefix too,
and encourage the other vendors to do the same?

Wes

On 16 December 2011 09:03, Henri Sivonen <hsiv...@iki.fi> wrote:

> On Wed, Dec 14, 2011 at 1:15 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> > On Mon, Dec 12, 2011 at 11:35 PM, Henri Sivonen <hsiv...@iki.fi> wrote:
> >> On Fri, Dec 9, 2011 at 9:09 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> >>> On 12/9/11 9:23 AM, Henri Sivonen wrote:
> >>>>
> >>>> However, while WebKit has introduced numerous prefixed CSS features,
> >>>> Mozilla has been introducing prefixed APIs.
> >>>
> >>>
> >>> I believe for every single API we've prefixed and then unprefixed so
> far we
> >>> have in fact ended up making incompatible changes to it before
> unprefixing.
> >>

> --
> Henri Sivonen
> hsiv...@iki.fi
> http://hsivonen.iki.fi/

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>



--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Henri Sivonen]

On Fri, Dec 16, 2011 at 4:43 PM, Wes Garland <w...@page.ca> wrote:
> If we're going to prefix draft standards, maybe allow a -draft prefix too,
> and encourage the other vendors to do the same?

See http://hsivonen.iki.fi/vendor-prefixes/#draftprefix

[Jonas Sicking]

On Fri, Dec 16, 2011 at 6:03 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
> On Wed, Dec 14, 2011 at 1:15 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>> On Mon, Dec 12, 2011 at 11:35 PM, Henri Sivonen <hsiv...@iki.fi> wrote:
>>> On Fri, Dec 9, 2011 at 9:09 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

>>>> On 12/9/11 9:23 AM, Henri Sivonen wrote:
>>>>>
>>>>> However, while WebKit has introduced numerous prefixed CSS features,
>>>>> Mozilla has been introducing prefixed APIs.
>>>>
>>>>
>>>> I believe for every single API we've prefixed and then unprefixed so far we
>>>> have in fact ended up making incompatible changes to it before unprefixing.
>>>

>>> Doesn't that mean that in practice, we have been willing to make
>>> incompatible changes to APIs that we've shipped?
>>>
>>> Why would the willingness to make incompatible changes to APIs be
>>> different if prefixes were absent? One possible answer is that the
>>> prefix signals to Web authors that they are using a subject-to-change
>>> API.
>>
>> Indeed, this is exactly the theory.
>
> I did a quick spot check of the first three Hacks articles that I
> found under the "Feature" tag talking about a moz-prefixed feature:
> http://hacks.mozilla.org/2009/10/orientation-for-firefox/
> http://hacks.mozilla.org/2011/10/css-3d-transformations-in-firefox-nightly/
> http://hacks.mozilla.org/2010/07/firefox4-beta2/
>
> None of these warn the reader that this is subject-to-change stuff.
> Instead, these features are advertised as something that Firefox now
> has. (Also note how the CSS articles defeat the whole point of
> prefixes by including the unprefixed property in advance and how the
> article about Transitions and Transforms excludes the -ms- prefix (and
> obviously any non-incumbent prefixes).)

Indeed, we can and should do better with messaging here. I looked at
the docs we have for prefixed features and found that we do much
better there:

https://developer.mozilla.org/en/DOM/window.requestAnimationFrame
https://developer.mozilla.org/en/IndexedDB
https://developer.mozilla.org/en/WebSockets

I'm sure we miss many cases though, we should be better.

>> To put it another way: No, I don't think "site breakage is site
>> breakage regardless of reason" is an accurate statement for how
>> developers feel.
>
> Do you have data indicating that Web developers are more OK with a
> breaking change that goes from prefixed to unprefixed-and-spec-aligned
> than with a breaking change that goes from
> unprefixed-and-old-spec-aligned or unprefixed-and-accidentally-buggy
> to unprefixed-and-new-spec-aligned?

Only experience based on interacting with people that file bugs on us.
The majority of time when I've given the message "we did this to align
with spec" have people stopped arguing. A few times people have even
given positive feedback at that point, though that's more rare.

> It's worth noting that the Canvas API and the <video> element's API
> have pretty successfully been evolved in place unprefixed.
>
> Any ideas about how we might get data that shows if Web developers
> really have a different perception of breaking changes to prefixed
> features than of breaking changes of unprefixed features and that the
> difference in perception matters?

None other than the obvious one of asking them.

/ Jonas

[Henri Sivonen]

On Sat, Dec 17, 2011 at 7:09 AM, Jonas Sicking <jo...@sicking.cc> wrote:

> Indeed, we can and should do better with messaging here. I looked at
> the docs we have for prefixed features and found that we do much
> better there:
>
> https://developer.mozilla.org/en/DOM/window.requestAnimationFrame
> https://developer.mozilla.org/en/IndexedDB
> https://developer.mozilla.org/en/WebSockets
>
> I'm sure we miss many cases though, we should be better.

Those aren't much better, IMO. As far as I can tell with a quick scan,
none of those docs say that the APIs can still change or that the
prefixed flavors can go away. The Web Sockets doc does talk about
previous changes from which some readers might infer the possibility
of future changes. The requestAnimationFrame doc reminds the reader to
use prefixes but doesn't spell out the future risks.

>>> To put it another way: No, I don't think "site breakage is site
>>> breakage regardless of reason" is an accurate statement for how
>>> developers feel.
>>
>> Do you have data indicating that Web developers are more OK with a
>> breaking change that goes from prefixed to unprefixed-and-spec-aligned
>> than with a breaking change that goes from
>> unprefixed-and-old-spec-aligned or unprefixed-and-accidentally-buggy
>> to unprefixed-and-new-spec-aligned?
>
> Only experience based on interacting with people that file bugs on us.
> The majority of time when I've given the message "we did this to align
> with spec" have people stopped arguing. A few times people have even
> given positive feedback at that point, though that's more rare.

That also happens when changing non-prefixed features to align with
the spec. I don't think that experience says anything in favor of
prefixing. It does say something in favor of aligning with the spec.

>> It's worth noting that the Canvas API and the <video> element's API
>> have pretty successfully been evolved in place unprefixed.
>>
>> Any ideas about how we might get data that shows if Web developers
>> really have a different perception of breaking changes to prefixed
>> features than of breaking changes of unprefixed features and that the
>> difference in perception matters?
>
> None other than the obvious one of asking them.

:-( Asking people is generally a bad way of getting information of
this sort, because what people say and what people do might not match.
Also, it's probably hard to reach the long tail of Web developers who
are busy developing sites instead of going to conferences or hanging
out where browser developers hang out.

[Jonas Sicking]

On Sun, Dec 18, 2011 at 11:18 PM, Henri Sivonen <hsiv...@iki.fi> wrote:
> On Sat, Dec 17, 2011 at 7:09 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>
>> Indeed, we can and should do better with messaging here. I looked at
>> the docs we have for prefixed features and found that we do much
>> better there:
>>
>> https://developer.mozilla.org/en/DOM/window.requestAnimationFrame
>> https://developer.mozilla.org/en/IndexedDB
>> https://developer.mozilla.org/en/WebSockets
>>
>> I'm sure we miss many cases though, we should be better.
>
> Those aren't much better, IMO. As far as I can tell with a quick scan,
> none of those docs say that the APIs can still change or that the
> prefixed flavors can go away. The Web Sockets doc does talk about
> previous changes from which some readers might infer the possibility
> of future changes. The requestAnimationFrame doc reminds the reader to
> use prefixes but doesn't spell out the future risks.

Yup. I can only agree that we can and should get better.

>>>> To put it another way: No, I don't think "site breakage is site
>>>> breakage regardless of reason" is an accurate statement for how
>>>> developers feel.
>>>
>>> Do you have data indicating that Web developers are more OK with a
>>> breaking change that goes from prefixed to unprefixed-and-spec-aligned
>>> than with a breaking change that goes from
>>> unprefixed-and-old-spec-aligned or unprefixed-and-accidentally-buggy
>>> to unprefixed-and-new-spec-aligned?
>>
>> Only experience based on interacting with people that file bugs on us.
>> The majority of time when I've given the message "we did this to align
>> with spec" have people stopped arguing. A few times people have even
>> given positive feedback at that point, though that's more rare.
>
> That also happens when changing non-prefixed features to align with
> the spec. I don't think that experience says anything in favor of
> prefixing. It does say something in favor of aligning with the spec.

Sorry, you are right. I lost track of context.

I don't actually recall ever getting anyone filing bugs on us for
changing prefixed APIs. This either means that our sample size is too
small, or that people for whatever reason choose not to file bugs
against us when we change prefixed APIs.

/ Jonas

[chris hofmann]

I had someone ask me about where we are with a vendor prefixing.

Can someone summarize the latest thinking, status of any proposals, and
any actions that we are taking
or point me to something that can?

Thanks

-chofmann

[Ed Morley]

A few of the proposals I've seen so far:
http://hsivonen.iki.fi/vendor-prefixes/
http://felipe.wordpress.com/2012/02/02/a-proposal-to-drop-browser-vendor-prefixes/

Best,
Ed

[Robert O'Callahan]

On Sun, Feb 5, 2012 at 6:49 AM, chris hofmann <chof...@meer.net> wrote:

> I had someone ask me about where we are with a vendor prefixing.
>
> Can someone summarize the latest thinking, status of any proposals, and
> any actions that we are taking
> or point me to something that can?
>

This question is a bit too vague...

Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]

[Henri Sivonen]

On Sat, Feb 4, 2012 at 7:49 PM, chris hofmann <chof...@meer.net> wrote:
> Can someone summarize the latest thinking,

I think it's fair to say that many people think that vendor prefixes
are problematic. As far as I can tell, there does not seem to be
consensus on whether they are more problematic than not having them.

> status of any proposals,

AFAICT, my proposal (http://hsivonen.iki.fi/vendor-prefixes/#whattodo)
has been unsuccessful so far.

Felipe's proposal
(http://felipe.wordpress.com/2012/02/02/a-proposal-to-drop-browser-vendor-prefixes/)
is so new that it's too soon to tell how it is succeeding. (I think
Felipe's proposal wouldn't solve the problem I want solved--the
adverse effects to browser competition.)

> and any actions that we are taking

On the CSS side, there was a proposal to advance certain features on
the REC track so that they could be unprefixed sooner without revising
the CSS WG policy. However, since then, there has also been a proposal
to revamp syntax related to some of those features, which I expect to
lead to delays. Viewed from outside of the CSS WG, it's unclear if
anything is actually happening differently from how things were
before.

The initiative to implement some -webkit-prefixed CSS features in
Gecko does not appear to have advanced.

On the DOM side, whether we prefix features in the first place or when
we unprefix features mostly depends on individual developers' outlook
on prefixes, since, unlike with CSS, there's no firm policy to violate
either way.

Gerv asked for data about what has happened with previously-launched
features. I don't know if anyone actually took the time to gather that
data.

So as far as I'm aware, there was an action (the proposal to advance
certain CSS features) within the framework of current vendor prefixing
policy. I'll leave it to someone who is actually in the CSS WG to say
whether that action is still going somewhere. As far as I'm aware,
there has been no organized action to systematically stop prefixing
stuff, to systematically unprefix previously prefixed stuff or to
implement WebKit's prefixed stuff. :-(

[Boris Zbarsky]

On 2/6/12 4:33 AM, Henri Sivonen wrote:
> Viewed from outside of the CSS WG, it's unclear if
> anything is actually happening differently from how things were
> before.

Apart from people actually trying to maybe edit animations/transforms,
things are no different as far as I can tell.

> The initiative to implement some -webkit-prefixed CSS features in
> Gecko does not appear to have advanced.

It's in the "gathering data to see which things we should consider
implementing" stage, I believe.

-Boris

[Teoli]

On 19/12/11 08:18, Henri Sivonen wrote:
> On Sat, Dec 17, 2011 at 7:09 AM, Jonas Sicking<jo...@sicking.cc> wrote:
>
>> Indeed, we can and should do better with messaging here. I looked at
>> the docs we have for prefixed features and found that we do much
>> better there:
>>
>> https://developer.mozilla.org/en/DOM/window.requestAnimationFrame
>> https://developer.mozilla.org/en/IndexedDB
>> https://developer.mozilla.org/en/WebSockets
>>
>> I'm sure we miss many cases though, we should be better.
>
> Those aren't much better, IMO. As far as I can tell with a quick scan,
> none of those docs say that the APIs can still change or that the
> prefixed flavors can go away.

On the MDN, we have a banner to indicate that something is experimental
and subject to change.

For those pages, the fact that it wasn't set is a MDN bug, and not a
deliberate decision : this banner is a recent (read a few months) idea
and is not set everywhere yet. Don't hesitate to add it yourself or to
report missing ones to me.

Banner for indicating the whole page is experimental:

{{SeeCompatTable()}}

and banner to denote that only a given value is experimental (for
extensions of a previous standard): {{experimental_inline()}}

A better wording for the banner can be discussed if needed

--
Jean-Yves Perrier
E-mail: teoli followed by the regular Mozilla domain

[Henri Sivonen]

On Mon, Feb 6, 2012 at 4:07 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> It's in the "gathering data to see which things we should consider
> implementing" stage, I believe.

Looks like this work just emerged in the WG:
"Why and How to Implement Other Vendors' Prefixes" in
http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html

[Christopher Blizzard]

Yeah, the original question is pretty vague.

If we're talking about mobile compatibility, then Boris is right, we're
doing data collection now. Tantek is driving here and has started to
expand the CSS compatibility page with information about goals & principals:

https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility

In addition it was a discussion point at the last WG meeting with other
vendors also chiming in to say that they were interested in working with
us on this issue, especially on mobile.

So progress is being made, for sure, both on the product front (what
should we do in Firefox) and the standards front (what defacto standards
exist that we be documenting.)

--Chris

[Henri Sivonen]

On Tue, Feb 7, 2012 at 9:52 PM, Christopher Blizzard
<bliz...@mozilla.com> wrote:
> If we're talking about mobile compatibility, then Boris is right, we're
> doing data collection now.  Tantek is driving here and has started to expand
> the CSS compatibility page with information about goals & principals:
>
> https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility

A huge thanks to everyone involved in making this happen!

The above is about dealing with the -webkit- situation with CSS, though.

Is there any active action to stop minting more moz-prefixed CSS or
API so that we'd stop being part of the problem?

- -

What are we gaining from shipping the Fullscreen API (for example)
with a prefix compared to shipping it unprefixed? It's not Mozilla
secret sauce: We helped spec it along the way and the drafts got
review form other interested parties. We are evangelizing it from day
one and we want YouTube to deploy it ASAP, so it's not really
experimental. So far, prefixing seems to be buying us the trouble of
evangelizing 3 syntaxes from day 1 and the W3C process having
bikeshedded a capital 'S' to lower case 's' and 'cancel' to 'exit'.