Wöchentliche Plattform-Nachrichten: Fokusringe, Donut-Scope, mehr em-Einheiten und globale Datenschutzkontrolle

In den Nachrichten dieser Woche befasst sich Chrome mit Fokusringen, wir erfahren, wie wir den "Donut"-Scope erhalten, die globale Datenschutzkontrolle erhält die Unterstützung großer Namen, es ist an der Zeit, Pixel in Media Queries abzuschaffen, und ein Schnipsel, der störende Formularvalidierungsstile verhindert.

Chrome wird beim Klicken auf Schaltflächen keine Fokusringe mehr anzeigen

Chrome, Edge und andere Chromium-basierte Browser zeigen eine Fokusanzeige (auch Fokusring genannt) an, wenn der Benutzer auf eine ( gestylte) Schaltfläche klickt oder tippt. Zum Vergleich: Safari und Firefox zeigen beim Klicken oder Tippen auf eine Schaltfläche keinen Fokusring an, sondern nur, wenn die Schaltfläche per Tastatur fokussiert wird.

Einige Entwickler empfinden dieses Verhalten als störend und verwenden verschiedene Workarounds, um zu verhindern, dass der Fokusring beim Klicken oder Tippen auf eine Schaltfläche erscheint. Zum Beispiel verfolgt die beliebte what-input-Bibliothek kontinuierlich die Eingabemethode des Benutzers (Maus, Tastatur oder Berührung) und ermöglicht es der Seite, Fokusringe speziell für Mausklicks zu unterdrücken.

[data-whatintent="mouse"] :focus {
  outline: none;
}

Ein neuerer Workaround wurde durch die vor einigen Monaten erfolgte Hinzufügung der CSS-Pseudoklasse :focus-visible zu Chromium ermöglicht. In der aktuellen Version von Chrome ruft das Klicken oder Tippen auf eine Schaltfläche den :focus-Zustand der Schaltfläche, aber nicht ihren :focus-visible-Zustand auf. Auf diese Weise kann die Seite einen geeigneten Selektor verwenden, um Fokusringe für Klicks und Taps zu unterdrücken, ohne Tastaturbenutzer zu beeinträchtigen.

:focus:not(:focus-visible) {
  outline: none;
}

Glücklicherweise werden diese Workarounds bald überflüssig. Das User-Agent-Stylesheet von Chromium hat kürzlich von :focus zu :focus-visible gewechselt. Infolge dieser Änderung rufen Schaltflächenklicks und -taps keine Fokusringe mehr auf. Das neue Verhalten wird nächsten Monat erstmals in Chrome 90 veröffentlicht.

Der erweiterte CSS-:not()-Selektor ermöglicht "Donut-Scope"

Ich habe kürzlich über das Selektormuster A:not(B *) geschrieben, das es Autoren ermöglicht, alle A-Elemente auszuwählen, die keine Nachkommen eines B-Elements sind. Dieses Muster kann auf A B:not(C *) erweitert werden, um einen "Donut-Scope" zu erstellen.

Zum Beispiel wählt der Selektor article p:not(blockquote *) alle <p>-Elemente aus, die Nachkommen eines <article>-Elements sind, aber keine Nachkommen eines <blockquote>-Elements. Mit anderen Worten, er wählt alle Absätze in einem Artikel aus, außer denen, die sich in einem Blockzitat befinden.

*The New York Times* berücksichtigt jetzt die globale Datenschutzkontrolle

Im vergangenen Oktober angekündigt, ist die globale Datenschutzkontrolle (GPC) ein neues Datenschutzsignal für das Web, das rechtlich durchsetzbar ist. Im Wesentlichen handelt es sich um einen HTTP-Sec-GPC: 1-Anforderungsheader, der Websites mitteilt, dass der Benutzer nicht möchte, dass seine persönlichen Daten weitergegeben oder verkauft werden.

*The New York Times* ist der erste große Verleger, der GPC berücksichtigt. Eine Reihe anderer Verleger, darunter *The Washington Post* und Automattic (WordPress.com), haben sich verpflichtet, dies " im kommenden Quartal" zu tun.

Von der Datenschutzseite der NYT

Unterstützt *The Times* die globale Datenschutzkontrolle (GPC)?

Ja. Wenn wir ein GPC-Signal vom Browser eines Lesers erkennen, auf den die DSGVO, CCPA oder ein ähnliches Datenschutzgesetz zutrifft, hören wir auf, die persönlichen Daten des Lesers online an andere Unternehmen weiterzugeben (mit Ausnahme unserer Dienstleister).

Der Fall für em-basierte Media Queries

Einige Browser erlauben dem Benutzer, die Standard-Schriftgröße zu erhöhen in den Browsereinstellungen. Leider hat diese Benutzereinstellung keine Auswirkungen auf Websites, die ihre Schriftgrößen in Pixeln festlegen (z. B. font-size: 20px). Teilweise aus diesem Grund verwenden einige Websites (einschließlich CSS-Tricks) stattdessen schriftsrelative Einheiten wie em und rem, die auf die bevorzugte Schriftgröße des Benutzers *reagieren*.

Idealerweise sollte eine Website, die schriftsrelative Einheiten für font-size verwendet, auch em-Werte in Media Queries verwenden (z. B. min-width: 80em anstelle von min-width: 1280px). Andernfalls funktioniert das responsive Layout der Seite möglicherweise nicht immer wie erwartet.

Zum Beispiel wechselt CSS-Tricks von einem Zwei-Spalten- zu einem Ein-Spalten-Layout bei schmalen Ansichtsfenstern, um zu verhindern, dass die Zeilen des Artikels zu kurz werden. Wenn der Benutzer jedoch die Standard-Schriftgröße im Browser auf 24px erhöht, wird der Text auf der Seite größer (wie er sollte), aber das Seitenlayout ändert sich nicht, was zu extrem kurzen Zeilen bei bestimmten Ansichtsfensterbreiten führt.

Wenn Sie em-basierte Media Queries auf Ihrer Website ausprobieren möchten, gibt es ein PostCSS-Plugin, das min-width-, max-width-, min-height- und max-height-Media-Queries automatisch von px in em umwandelt.

(via Nick Gard)

Ein neuer Vorstoß, um CSS :user-invalid in Browser zu bringen

Im Jahr 2017 veröffentlichte Peter-Paul Koch eine Reihe von drei Artikeln über native Formularvalidierung im Web. Teil 1 weist auf die Probleme mit der weit verbreiteten CSS-Pseudoklasse :invalid hin.

• Die Gültigkeit von <input>-Elementen wird bei jedem Tastaturanschlag neu bewertet, sodass ein Formularfeld :invalid werden kann, während der Benutzer noch den Wert eingibt.
• Wenn ein Formularfeld erforderlich ist (<input required>), wird es beim Laden der Seite sofort :invalid.

Beide Verhaltensweisen sind potenziell verwirrend (und störend), sodass sich Websites nicht ausschließlich auf den :invalid-Selektor verlassen können, um anzuzeigen, dass ein vom Benutzer eingegebener Wert ungültig ist. Es besteht jedoch die Möglichkeit, :invalid mit :not(:focus) und sogar :not(:placeholder-shown) zu kombinieren, um sicherzustellen, dass die "ungültigen" Stile der Seite nicht auf das <input> angewendet werden, bis der Benutzer die Eingabe abgeschlossen und den Fokus auf ein anderes Element verschoben hat.

Das CSS Selectors-Modul definiert eine :user-invalid-Pseudoklasse, die die Probleme von :invalid vermeidet, indem sie ein <input> nur "nachdem der Benutzer signifikant mit ihm interagiert hat" abgleicht.

Firefox unterstützt diese Funktionalität bereits über die Pseudoklasse :-moz-ui-invalid (hier in Aktion sehen). Mozilla hat nun die Absicht, diese Pseudoklasse zu entpräfixen und unter dem Standardnamen :user-invalid zu veröffentlichen (siehe hier). Es gibt noch keine Signale von anderen Browseranbietern, aber die Fehler für diese Funktion bei Chromium und WebKit wurden eingereicht.