Re: Enabled CRLite in Nightly

[J.C. Jones]

About 10 times a year, the update will be a new filter, which is going to
be about 5-6 MB, which might be more an issue.

Also, CRLite depends on the metadata for Intermediate Preloading, which is
several megabytes of certificates -- but those change very, very rarely, so
once populated they won't be downloaded again.

Perhaps we should go ahead and experiment with these two features in Fenix
Nightly.

J.C.

On Tue, Nov 17, 2020 at 12:19 AM Henri Sivonen  wrote:

> On Fri, Nov 13, 2020 at 6:19 AM J.C. Jones  wrote:
> > Not yet, no. Neither this nor Intermediate Preloading (which CRLite
> depends
> > on) are enabled in Fenix yet, as we have outstanding bugs about "only
> > download this stuff when on WiFi + Power" and "that, but configurable."
>
> If the delta updates are averaging 66 KB, do we really need to avoid
> the updates over cellular data even when that's assumed to be metered?
>
> --
> Henri Sivonen
> hsivo...@mozilla.com
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: :focus-visible pseudo-class

[Emilio Cobos Álvarez]

Summary: Implement the :focus-visible pseudo-class and effectively make 
:-moz-focusring an alias of it.


This is intended to simplify the way authors deal with outlines to 
improve accessibility. In particular, authors seem to hate outlines when 
users focus stuff with the mouse, generally and so a lot of them do 
:focus { outline: none }, which renders elements also inaccessible by 
keyboard.


We have always exposed :-moz-focusring to represent Gecko's opinion on 
whether something ought to have an outline, but that also didn't quite 
have the desired effect (plus it required Firefox-specific selectors).


:focus-visible is supposed to be the standard version of :-moz-focusring 
with a behavior that matches more author's expectations (but that users 
can also customize).


To summarize current and upcoming behavior:

The behavior we're shipping depends on the platform, but for Windows is:

 * If browser.display.show_focus_rings (default false), or a 
Windows-specific setting (also default off) to always show outlines is 
enabled, then all focused elements match :-moz-focusring.


 * Otherwise (the default behavior) it matches all focused elements 
only after the user has navigated once with the keyboard once in a given 
tab.


If enabling this goes well (it's been enabled for a long while on 
Nightly, with no known regressions, and it's early in the cycle so we 
still have a bunch of time to fix issues if they arise) this will be the 
new behavior (which is the current on Nightly):


 * The first bullet point remains the same (with :focus-visible rather 
than :-moz-focusring).


 * , contenteditable, and  elements that require 
keyboard input or such always match :focus-visible if focused.


 * For other elements, we follow the rules described in the spec (link 
below), which are roughly that focus-visible matches for keyboard focus 
but not mouse focus, and that whether programmatic focus matches depends 
on whether the previously-focused element matched it.


 * Additionally, if browser.display.always_show_rings_after_key_focus 
is true (default false), then we keep the existing behavior of matching 
all elements once keyboard navigation has occurred.


This should hopefully make developers happy and less prone to remove all 
outlines on focus.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1445482

Standard: https://drafts.csswg.org/selectors-4/#the-focus-visible-pseudo

Platform coverage: All

Preference: layout.css.focus-visible.enabled

DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1617608

Other browsers:

 * Chrome: Shipped (M86)
 * WebKit: N/A (https://bugs.webkit.org/show_bug.cgi?id=185859)

web-platform-tests: 
https://wpt.fyi/results/css/selectors?label=master=experimental=focus-visible


Cheers,

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