The real-world out there always tries to address the potential standard and
use these prefixed methods as fallbacks, not vice versa.

It would be very unwise to rely prefixed methods only in production and I
am not sure who does it but yes, the "dropping" might be gradual notifying
in console that has been deprecated.

Having the same unstable, not standard yet, global native constructor is a
problem in these fields:

   1. documentation ... MDN has been promoted as "the place to document
   JavaScript" ... MDN has many Mozilla and Gecko only methods and properties
   ... does MDN want to include every possible quirk for every possible method
   that every browser might or might not have implemented in a slightly
   different, since not standard yet, way? If the answer is NO, it's
   fragmentation of the documentation ... which I believe is not useful for
   anyone
   2. User Agent sniffing will be promoted instead of "impossible" features
   detections
   3. signatures implemented too early will lead to shenanigans
   4. every early implementation either will break the web the day it will
   change or will create an absurd mess of extra code to understand if it's
   the one that works as expected or not (again, leads to UA sniffing)

A very concrete example about prefixes, and since you work on this daily,
is the CSS gradient background syntax:
http://css-tricks.com/css3-gradients/

Now imagine that scenario with JavaScript ... a constructor that has
different signatures and no way to tell if it was an early adoption or the
standard version if not through User Agent sniffing ... and since the race
to early adopt any sort of thing is the biggest part of "the modern
Browsers war", who do you honestly think will benefit from such decision?

I understand that at the time Chromium decided to branch out from WebKit,
going to the press saying "yeah, another blok prefix is coming" would have
been bad ... press speaking, but at the same time almost nobody uses
anymore pure CSS and prefixes there are handled automatically plus many use
utilities such lo-dash or others so that behavior are ensured behind the
scene and nobody really care if that function was prefixed or not.

What do we have as pros avoiding prefixes instead? Does that overcome all
these cons?

Best Regards















On Tue, Dec 17, 2013 at 10:00 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Mon, Dec 16, 2013 at 6:06 PM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
> > last thought would be an answer to th epossible question:
> >
> > do we need to support mozMatchSelector forever ?
> >
> > NO
> >
> > since matches() will do once it works as standards say
>
> No, that's not how it works.  You support something as long as
> significant amounts of content depend on it, so you don't break pages.
>  The existence of a replacement doesn't mean that everyone immediately
> updates their pages to the new method.
>
> ~TJ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131217/2209b273/attachment.html>

The real-world out there always tries to address the potential standard and
use these prefixed methods as fallbacks, not vice versa.

It would be very unwise to rely prefixed methods only in production and I
am not sure who does it but yes, the "dropping" might be gradual notifying
in console that has been deprecated.

Having the same unstable, not standard yet, global native constructor is a
problem in these fields:

   1. documentation ... MDN has been promoted as "the place to document
   JavaScript" ... MDN has many Mozilla and Gecko only methods and properties
   ... does MDN want to include every possible quirk for every possible method
   that every browser might or might not have implemented in a slightly
   different, since not standard yet, way? If the answer is NO, it's
   fragmentation of the documentation ... which I believe is not useful for
   anyone
   2. User Agent sniffing will be promoted instead of "impossible" features
   detections
   3. signatures implemented too early will lead to shenanigans
   4. every early implementation either will break the web the day it will
   change or will create an absurd mess of extra code to understand if it's
   the one that works as expected or not (again, leads to UA sniffing)

A very concrete example about prefixes, and since you work on this daily,
is the CSS gradient background syntax:
http://css-tricks.com/css3-gradients/

Now imagine that scenario with JavaScript ... a constructor that has
different signatures and no way to tell if it was an early adoption or the
standard version if not through User Agent sniffing ... and since the race
to early adopt any sort of thing is the biggest part of "the modern
Browsers war", who do you honestly think will benefit from such decision?

I understand that at the time Chromium decided to branch out from WebKit,
going to the press saying "yeah, another blok prefix is coming" would have
been bad ... press speaking, but at the same time almost nobody uses
anymore pure CSS and prefixes there are handled automatically plus many use
utilities such lo-dash or others so that behavior are ensured behind the
scene and nobody really care if that function was prefixed or not.

What do we have as pros avoiding prefixes instead? Does that overcome all
these cons?