Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features
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
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
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
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
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
Re: Intent to implement & ship: support for a subset of -webkit prefixed CSS properties & features
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
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
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
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