Re: Intent to ship: Implement :-moz-any() as an alias of :is()
On 9/21/20 3:46 PM, Tom Ritter wrote: I imagine there's a good reason; but I'm curious: why do we want to keep this legacy, prefixed pseudo-class and not just use is()? Removing it is generally much more risky than aliasing to something that is more permissive. This is specially true when accounting for add-ons/userChrome.css users, but even without accounting for those, I suspect :-moz-any can be used in the wild much like @-moz-document to write Firefox-only CSS, which is a compat thing that we need to live with. That being said, I could certainly look into it as a follow-up. Once :-moz-any usage is removed from the codebase (there's a patch under review) I can add a use counter and see how often it's hit on content, to consider removing it eventually if feasible. -- Emilio -tom On Sat, Sep 19, 2020 at 3:36 PM Emilio Cobos Álvarez wrote: Summary: Implement the legacy :-moz-any selector as an alias of :is(). This means that it'll be more powerful, and also simpler to maintain for us. This has been enabled in 81 beta/nightly and for the whole 82 cycle with no regriessions so far, see bug 561154. This means that it will accept more selectors (like :is() does), which I don't expect to be problematic. It also means that specificity may change in some cases, because the specificity of :-moz-any doesn't account for the inner selectors. This was a long-standing issue that this change fixes (bug 561154), but that can technically change behavior (thus the pref, and having it enabled on Nightly / Early beta for a while). This last bit is pretty hard to use-count, because the specificity change in most cases won't end up resulting in an actual behavior change. I expect this to not be problematic either, because of the limited usage that this prefixed pseudo-class has, and because behavior is closer to what authors expect. As a data point, this change required no changes to the browser UI at all, which extensively used the :-moz-any() pseudo-class. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1666086 Standard: N/A, this is a legacy, prefixed pseudo-class, which we'll build on top of the standard alternative that we've shipped for a while. Platform coverage: All Preference: layout.css.moz-any-is-is.enabled DevTools bug: N/A, devtools will work the same as they work with :is(). Other browsers: N/A, this is a -moz- prefixed pseudo-class. web-platform-tests: There are tons of tests for :is(), but I don't plan to test the :-moz- prefixed pseudo-class in WPT. Cheers, -- Emilio ___ 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 ship: Implement :-moz-any() as an alias of :is()
I imagine there's a good reason; but I'm curious: why do we want to keep this legacy, prefixed pseudo-class and not just use is()? -tom On Sat, Sep 19, 2020 at 3:36 PM Emilio Cobos Álvarez wrote: > > Summary: Implement the legacy :-moz-any selector as an alias of :is(). > > This means that it'll be more powerful, and also simpler to maintain for us. > > This has been enabled in 81 beta/nightly and for the whole 82 cycle with > no regriessions so far, see bug 561154. > > This means that it will accept more selectors (like :is() does), which I > don't expect to be problematic. > > It also means that specificity may change in some cases, because the > specificity of :-moz-any doesn't account for the inner selectors. This > was a long-standing issue that this change fixes (bug 561154), but that > can technically change behavior (thus the pref, and having it enabled on > Nightly / Early beta for a while). > > This last bit is pretty hard to use-count, because the specificity > change in most cases won't end up resulting in an actual behavior > change. I expect this to not be problematic either, because of the > limited usage that this prefixed pseudo-class has, and because behavior > is closer to what authors expect. As a data point, this change required > no changes to the browser UI at all, which extensively used the > :-moz-any() pseudo-class. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1666086 > > Standard: N/A, this is a legacy, prefixed pseudo-class, which we'll > build on top of the standard alternative that we've shipped for a while. > > Platform coverage: All > > Preference: layout.css.moz-any-is-is.enabled > > DevTools bug: N/A, devtools will work the same as they work with :is(). > > Other browsers: N/A, this is a -moz- prefixed pseudo-class. > > web-platform-tests: There are tons of tests for :is(), but I don't plan > to test the :-moz- prefixed pseudo-class in WPT. > > Cheers, > > -- Emilio > ___ > 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
[action maybe required] Verify recent wpt changes are still on autoland
A bug in the wptsync when switching over to Python 3 caused it to drop some upstream changes when doing recent landings. In order to get things back on track I've made a patch which copies over the files from the current sync revision from GitHub to m-c and reapples changes made to mozilla-central which hadn't yet landed in that GitHub revision. The commit containing that patch is now on autoland [1] To verify I haven't missed anything it would be very helpful if anyone who's landed a change under testing/web-platform/tests in the last ~3 weeks would confirm that their changes are still on autoland. If they are not please let me know and I'll ensure they are relanded. Apologies for the inconvenience; the sync is getting some more sanity checks to ensure that this kind of thing doesn't happen again. [1] https://hg.mozilla.org/integration/autoland/rev/1bf583a361709eca05877399cd19ec1c5022d4d7 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soft code freeze for Firefox 82 starts September 17
Development is now open for 83, the last merge from autoland to mozilla-central before 82 merges to beta has happened. Cheers, Julien On Mon, Sep 14, 2020 at 10:36 AM Julien Cristau wrote: > Hi all, > > With Firefox 81 merging to mozilla-release later today, we are nearing the > end of the Nightly 82 cycle. > > In order to avoid invalidating the testing we get out of late Nightly > and to ensure that we can roll out 82 Betas to a wider audience with > confidence, we'd like to ask that any risky changes be avoided from > Thursday September 17 until after the version bump to 83 on September 21. > > Some reminders for the soft code freeze period: > > Do: > - Be ready to back out patches that cause crash spikes, new crashes, > severe regressions > - Monitor new regressions and escalate merge blockers > - Support release management by prioritizing fixing of merge blockers > > Do Not: > - Land a risky patch or a large patch > - Land new features (that affect the current Nightly version) — be mindful > that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to > unexpected CI results > - Flip prefs that enable new Features that were untested in the Nightly > cycle > - Plan to kick off new experiments that might impact a feature's merge > readiness > > Please let us know if you have any questions/concerns. > > Thanks, > Julien and the release management team > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
