Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Daniel Holbert]

On 05/13/2016 10:49 AM, Jet Villegas wrote:
> If I'm reading the dependency list correctly, we still plan to uplift to
> 48 if we can get bug 1264905 fixed in time. Is that correct?

bug 1264905's fix (a pref-unguarding) was just landed, as well.

We could uplift both, if we *also* uplift bug 1269971 (which was just
fixed yesterday, and which bug 1264905 depends on).

I'm instinctively uneasy about that, since that bug (bug 1269971) is
basically a reimplementation of the feature in question.
(background-clip:text)

~Daniel
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Jet Villegas]

If I'm reading the dependency list correctly, we still plan to uplift to 48
if we can get bug 1264905 fixed in time. Is that correct?

--Jet

On Fri, May 13, 2016 at 10:15 AM, Daniel Holbert 
wrote:

> On 12/30/2015 10:40 PM, Daniel Holbert wrote:
> > Estimated or target release:
> >   Firefox 46 (current Nightly), or 47 if we need to hold it back a
> > release to fix things.
> >
> > Preference behind which this will be implemented:
> >   layout.css.prefixes.webkit
>
> Following up on this -- this feature will be default-enabled in Firefox
> 49, as of the pref-unguarding-patch that I just landed on this bug:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1259345
>
> (This feature has been enabled & getting very useful testing & having
> bugs filed in Nightly/Aurora ever since Firefox 46. At this point, we've
> fixed all known regressions that are triggered by this feature, so we're
> calling it safe to ship in Firefox 49, and we'll be watching for any
> more bugs that are reported.)
>
> Thanks,
> ~Daniel
> ___
> 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: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Daniel Holbert]

On 12/30/2015 10:40 PM, Daniel Holbert wrote:
> Estimated or target release:
>   Firefox 46 (current Nightly), or 47 if we need to hold it back a
> release to fix things.
> 
> Preference behind which this will be implemented:
>   layout.css.prefixes.webkit

Following up on this -- this feature will be default-enabled in Firefox
49, as of the pref-unguarding-patch that I just landed on this bug:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1259345

(This feature has been enabled & getting very useful testing & having
bugs filed in Nightly/Aurora ever since Firefox 46. At this point, we've
fixed all known regressions that are triggered by this feature, so we're
calling it safe to ship in Firefox 49, and we'll be watching for any
more bugs that are reported.)

Thanks,
~Daniel
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Jonas Sicking]

Yay!

(I agree that it's sad that we need to do this, but still "yay" for
being more compatible with the web).

/ Jonas

On Wed, Dec 30, 2015 at 10:40 PM, Daniel Holbert  wrote:
> Summary:
>   A good chunk of the web today (and particularly the mobile web)
> effectively relies on -webkit prefixed CSS properties & features. We
> wish we lived in a world where web content always included
> standards-based fallback (or at least multiple-vendor-prefixed
> fallback), but alas, we do not live in that world.  To be successful at
> rendering the web as it exists, we need to add support for a list of
> frequently-used -webkit prefixed CSS properties & features.
>   Every other major modern browser engine implements support for these
> aliases -- Blink & WebKit obviously have them, & Edge includes them for
> compatibility.  (I'm not sure about IE's support, but it's not a
> particularly important data point, given that Microsoft is focused on
> Edge going forward.)
>
> Bug tracking implementation:
>  https://bugzilla.mozilla.org/show_bug.cgi?id=1170789
>
> Bug to enable pref:
>  https://bugzilla.mozilla.org/show_bug.cgi?id=1143147
>  (Will likely land in the next few days.)
>
> Link to standard:
>   Mike Taylor is working on a WHATWG spec describing the -webkit
> prefixed features that we believe are needed for web compatibility.
> That spec lives here: http://compat.spec.whatwg.org/
>   There's also been some discussion on the CSSWG mailing list about
> updating official CSS specs to mention legacy -webkit aliases (and
> discourage authors from using them), as discussed in this thread:
> https://lists.w3.org/Archives/Public/www-style/2015Dec/0132.html
>
> Platform coverage:
>   All platforms.
>
> Estimated or target release:
>   Firefox 46 (current Nightly), or 47 if we need to hold it back a
> release to fix things.
>
> Preference behind which this will be implemented:
>   layout.css.prefixes.webkit
>
> Side note on earlier work:
>   Earlier this year, in bug 1107378, we shipped an experimental JS-based
> version of this feature, which was only active for a whitelist of sites
> (all of which strongly depend on webkit prefixes for usability). This
> experiment proved successful at making the whitelisted sites usable in
> Firefox.  The new implementation (behind "layout.css.prefixes.webkit")
> will supersede the older experimental JS-based implementation and will
> not be whitelisted.
> ___
> 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: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Martin Thomson]

On Thu, Dec 31, 2015 at 5:40 PM, Daniel Holbert  wrote:
> Summary:
>   A good chunk of the web today (and particularly the mobile web)
> effectively relies on -webkit prefixed CSS properties & features. We
> wish we lived in a world where web content always included
> standards-based fallback (or at least multiple-vendor-prefixed
> fallback), but alas, we do not live in that world.  To be successful at
> rendering the web as it exists, we need to add support for a list of
> frequently-used -webkit prefixed CSS properties & features.

This is definitely worth doing.

If we intend to continue to support these, and particularly if we
anticipate more prefixed rules in future, I think that it would be
worthwhile providing developers with a more visible notice regarding
their status.  Something like the deprecation warning we use for DOM
APIs [1] could be useful.  Otherwise, I worry that the warnings will
go unnoticed.

[1] 
https://dxr.mozilla.org/mozilla-central/rev/22f51211915bf7daff076180847a7140d35aa353/dom/base/nsDocument.cpp#10354
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Tantek Çelik]

Daniel, Mike, and the whole compat team, thank you for diligently
figuring out all the nasty details here and pushing this contentious
"feature" forward.

This is a tough balance for the good of our users, and I'm grateful
for all the thought and careful consideration you have put into it.

We noted a high level intent to consider doing this at the CSSWG f2f
nearly two years ago, and as this lands I'm sure it will come up again
at the next f2f. dbaron and I will be there to support your work.

Tantek


On Thu, Dec 31, 2015 at 12:40 AM, Jonas Sicking  wrote:
> Yay!
>
> (I agree that it's sad that we need to do this, but still "yay" for
> being more compatible with the web).
>
> / Jonas
>
> On Wed, Dec 30, 2015 at 10:40 PM, Daniel Holbert  wrote:
>> Summary:
>>   A good chunk of the web today (and particularly the mobile web)
>> effectively relies on -webkit prefixed CSS properties & features. We
>> wish we lived in a world where web content always included
>> standards-based fallback (or at least multiple-vendor-prefixed
>> fallback), but alas, we do not live in that world.  To be successful at
>> rendering the web as it exists, we need to add support for a list of
>> frequently-used -webkit prefixed CSS properties & features.
>>   Every other major modern browser engine implements support for these
>> aliases -- Blink & WebKit obviously have them, & Edge includes them for
>> compatibility.  (I'm not sure about IE's support, but it's not a
>> particularly important data point, given that Microsoft is focused on
>> Edge going forward.)
>>
>> Bug tracking implementation:
>>  https://bugzilla.mozilla.org/show_bug.cgi?id=1170789
>>
>> Bug to enable pref:
>>  https://bugzilla.mozilla.org/show_bug.cgi?id=1143147
>>  (Will likely land in the next few days.)
>>
>> Link to standard:
>>   Mike Taylor is working on a WHATWG spec describing the -webkit
>> prefixed features that we believe are needed for web compatibility.
>> That spec lives here: http://compat.spec.whatwg.org/
>>   There's also been some discussion on the CSSWG mailing list about
>> updating official CSS specs to mention legacy -webkit aliases (and
>> discourage authors from using them), as discussed in this thread:
>> https://lists.w3.org/Archives/Public/www-style/2015Dec/0132.html
>>
>> Platform coverage:
>>   All platforms.
>>
>> Estimated or target release:
>>   Firefox 46 (current Nightly), or 47 if we need to hold it back a
>> release to fix things.
>>
>> Preference behind which this will be implemented:
>>   layout.css.prefixes.webkit
>>
>> Side note on earlier work:
>>   Earlier this year, in bug 1107378, we shipped an experimental JS-based
>> version of this feature, which was only active for a whitelist of sites
>> (all of which strongly depend on webkit prefixes for usability). This
>> experiment proved successful at making the whitelisted sites usable in
>> Firefox.  The new implementation (behind "layout.css.prefixes.webkit")
>> will supersede the older experimental JS-based implementation and will
>> not be whitelisted.
>> ___
>> 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Martin Thomson]

On Fri, Jan 1, 2016 at 8:15 AM, Daniel Holbert  wrote:
>  (3) False positives: There are many "legitimate" ways that authors can
> use prefixed properties

Yep, you convinced me with this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Daniel Holbert]

On 12/31/2015 11:37 AM, Martin Thomson wrote:
> If we intend to continue to support these,

(We do.)

> and particularly if we
> anticipate more prefixed rules in future

(Happily, I don't anticipate too many more of these -- at least, the
space of -webkit-prefixed features is bounded, because implementors &
standards bodies have realized that vendor prefixes are bad for
web-compat, so they aren't being used for new features. The Chrome/Blink
team, at least, have committed to implementing new features behind their
equivalent of about:config prefs instead of vendor prefixes:
https://www.chromium.org/blink#vendor-prefixes )

> I think that it would be
> worthwhile providing developers with a more visible notice regarding
> their status.  Something like the deprecation warning we use for DOM
> APIs [1] could be useful.  Otherwise, I worry that the warnings will
> go unnoticed.

I'm not sure I agree. We discussed this a bit during a web-compat
session in MozLando, and there are several reasons not to bother with a
warning in this case (and note that these reasons do not apply to the
deprecated DOM API scenario that you brought up):

 (1) Dubious effectiveness: The existing web content where these
warnings would be *most* warranted -- content with webkit-prefixed CSS &
no fallback -- is (by definition) *exactly* the web content whose
developers are not bothering to test Firefox. So, any warning that we
add would have little chance of reaching that intended audience of
developers; it'd just add background noise to our users' error consoles.

 (2) Dubious usefulness: Given that these prefixed features will now
Just Work in Firefox, and given that we're saying they're de-facto part
of the web & committing to supporting them (and so are all other modern
browsers), then there's no clear benefit/motivation for web developers
to remove these from their sites. So, for web developers that *do* see
these warnings, it's not clear why they should care & address them (and
take time away from fixing other things).

 (3) False positives: There are many "legitimate" ways that authors can
use prefixed properties, and if we added a warning, we'd probably need
to exclude those cases. Some examples of "legitimate" use cases, which
would require some careful extra instrumentation to detect:

CSS with standards-based fallback after it:
.box {
   display: -webkit-box;
   -webkit-box-orient: horizontal;
   /* lots more -webkit-box stuff */
   display: flex;
   flex-direction: row;
   /* lots more modern-flexbox stuff */
 }

CSS with standards-based fallback in a completely different CSS rule
(not sure how often this happens, but it's conceivable):
.legacyBox {
  display: -webkit-box;
}
.modernBox {
  display: flex;
}
...


"@supports"-guarded conditions (where the author is explicitly checking
for browser support before using the legacy feature):
@supports (display: -webkit-box) {
  .foo { display: -webkit-box }
}

JavaScript that sets the prefixed style and modern style in separate
statements (i.e. separate passes through the CSS parser, so we have no
way of knowing that a standards-based version is coming up):
   elem.style.display = "-webkit-box";
   elem.style.display = "flex"; // use modern flexbox, if supported

Each of these "legitimate" scenarios would require a different set of
heuristics to skip the warning (and I'm not sure we'd be able to skip
the warning at all, for the 2nd and 4th cases).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features

[Daniel Holbert]

On 12/31/2015 01:15 PM, Daniel Holbert wrote:
>  (1) Dubious effectiveness:
[...]
>  (2) Dubious usefulness: Given that these prefixed features will now
> Just Work in Firefox, and given that we're saying they're de-facto part
> of the web & committing to supporting them (and so are all other modern
> browsers), then there's no clear benefit/motivation for web developers
> to remove these from their sites. So, for web developers that *do* see
> these warnings, it's not clear why they should care & address them (and
> take time away from fixing other things).

(In retrospect, I should've titled (2) "Dubious benefits", instead of
"usefulness", to more clearly differentiate it from (1). Let's pretend I
did.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform