Erstellen eines Dialogs mit nativem HTML

Hier ist er nun, der letzte Adventskalender-Blogbeitrag für 2024. Das bedeutet auch, dass viele von euch heute oder morgen Weihnachten feiern. Warum lest ihr also an einem solchen Tag Blogbeiträge? 😁

Im letzten Thema dieser Ausgabe geht es um ein weiteres HTML-Element, das ihr vielleicht noch nicht kanntet. Aber alle von euch kennen und hassen Cookie-Popups, richtig? Außer natürlich, ihr seid an der Entwicklung solcher Tools beteiligt. 😅

Das dialog HTML-Element

Wenn wir ein Popup erstellen „wollen“, haben wir in der Vergangenheit oft eine „Modal-Library“ verwendet. Aber jetzt haben wir ein eigenes HTML-Element dafür: das <dialog> Element. Es hat einige Gemeinsamkeiten mit dem details Element, über das ich vor vier Tagen gebloggt habe. Und wenn ihr die weiteren Ressourcen besucht habt, die ich dort verlinkt hatte, dann habt ihr das Element vielleicht schon kennengelernt. So würdet ihr es verwenden:

<dialog>
	Some Text inside the dialog.
</dialog>

Wenn ihr diesen Code in eure Seite einfügt, dann seht ihr … absolut nichts. Das Element ist nicht standardmäßig sichtbar. Ihr könnt das open Attribut hinzufügen, genau wie bei dem details Element, dann solltet ihr das hier sehen:

Chrome with open dev tools showing the properties of the open dialog element, that is centered on the page.

Wie ihr hier sehen könnt, erhalten wir mehr als nur ein leeres Element mit etwas Text. Das Dialogfeld hat einen Rahmen, einen Innenabstand und ist auf der Seite zentriert, wobei eine absolute Position und ein automatischer Außenabstand verwendet werden. Das würde sogar bedeuten, dass er über jedem Inhalt angezeigt wird, der nach ihm kommt.

Öffnen und Schließen des Dialogs

Ein Dialog, der standardmäßig geöffnet ist, ist nicht wirklich nützlich. Zum Glück gibt es einige JavaScript-Funktionen, mit denen wir ihn interaktiv gestalten können. Fügen wir also einen Button zum Öffnen des Dialogs und einen Button zum Schließen des Dialogs hinzu:

Chrome showing an open dialog element. The dev tools are open and at the bottom of the HTML markup tree, a "#top-layer" is shown after the closing html tag. The dialog has a paragraph and an undordered list. The page behind the dialog has an "Open dialog" button and inside the dialog, there is a "Read it" button at the end.

Dieser Screenshot zeigt mehrere Dinge auf einmal. Zuerst einmal haben wir die Webseite mit einem Button „Open Dialog“. Wenn dieser angeklickt wird, öffnet sich der Dialog, der dieses Mal etwas mehr HTML-Inhalt hat. Vielleicht ist euch auch aufgefallen, dass der Hintergrund der Website grau ist. Er ist eigentlich weiß, aber wenn der Dialog geöffnet ist, wird die Seite mit einem transparenten Overlay überlagert. Dies ist auch links mit der ::backdrop Pseudoelement zu sehen. Eine letzte Besonderheit ist der #top-layer nach dem HTML-Baum auf der linken Seite. Dies ist eine spezielle Ebene, die die gesamte Seite überdeckt und die Barrierefreiheit verbessert.

Wenn ihr auf den Button „Read it“ klickt, wird der Dialog geschlossen. Für die beiden Buttons benötigen wir etwas JavaScript, um diese Funktionalität umzusetzen:

const dialog = document.querySelector('dialog');
const openButton = document.querySelector('button#open-dialog');
const closeButton = document.querySelector('button#close-dialog');
openButton.addEventListener('click', () => {
	dialog.showModal();
});
closeButton.addEventListener('click', () => {
	dialog.close();
})

Wenn ihr die Funktion showModal() verwendet, spielt es keine Rolle, wo das Element im HTML-Baum platziert ist. Es wird immer in der Mitte der Seite geöffnet. Passt der Inhalt nicht hinein, wird eine Scrollbar angezeigt.

Alternative Möglichkeit zum Öffnen des Dialogs

Es gibt eine zweite Funktion zum Öffnen eines Dialogs. Sie heißt einfach show() und würde den Dialog „inline“ öffnen und nicht als „Modal“. In diesem Fall macht es einen Unterschied, wo der Dialog platziert wird. Es wird immer noch mit „position: absolute“ über dem Inhalt angezeigt, aber nicht mehr vertikal zentriert. Er wird genau dort angezeigt, wo sein HTML-Code im DOM platziert ist. Es gibt auch kein Hintergrund-Overlay und keinen #top-layer mehr, womit das Verhalten einige wichtige Unterschiede hat.

Schließen des Modals ohne JavaScript

Um den Dialog zu öffnen, benötigen ihr etwas JavaScript mit einer der beiden Funktionen, um es „anzuzeigen“. Es sei denn, ihr fügen das open Attribut hinzu, damit es standardmäßig geöffnet ist – ich frage mich wirklich, warum die Funktionen nicht openModal() und open() heißen, wenn das Element auch das open Attribut verwendet.

Um den Dialog zu schließen, brauchen ihr aber kein JavaScript. Ihr könnt ihn auch selbst schließen lassen, wenn du ein Formular als Inhalt hast:

<dialog open>
	<form method="dialog">
		Some text in the dialog.
		<button>OK</button>
	</form>
</dialog>

Siehst du den besonderen Trick mit dem Formular? Es verwendet den Wert dialog für das Attribut method. Dadurch wird der Dialog geschlossen, wenn das Formular mit einem Button darin abgeschickt wird. Ihr könnt also auch einfach nur ein Eingabefeld haben, dann wird der Dialog mit ENTER geschlossen.

Wenn der Dialog mit showModal() geöffnet wurde, kann dieses Modal auch mit der ESC-Taste geschlossen werden. Es gibt also verschiedene Möglichkeiten, es ohne JavaScript zu schließen.

Styling des Elements

Der Dialog selbst kann wie jeder andere „Container“ gestylt werden. Wie bereits gezeigt, verfügt es standardmäßig über einen Rahmen und einen Innenabstand. Spannender ist aber wahrscheinlich die Gestaltung des „Backdrops“. Hier ist ein Beispiel, welches den Dialog und den „Backdrop“ anpasst:

dialog {
	border-radius: 5px;
	border: 3px solid red;
	top: 30px;

	&::backdrop {
		background: black;
		opacity: 0.7;
	}
}

Wir ändern den Rahmen des Dialogs und auch den Hintergrund des „Backdrops“. Ach, und übrigens, was ihr hier seht, ist keine Sass-Syntax. Es handelt sich um natives verschachteltes CSS. Wenn ihr das noch nicht gesehen habt, lesen einfach den vorherigen Blogbeitrag „Verschachteltes CSS ohne Präprozessoren“ im Adventskalender. So würde es dann aussehen:

An open

Anstelle des rgba() Wertes für den Hintergrund verwenden wir nun eine bcakground-color in Kombination mit einer opactiy.

Noch mehr aus dem Element herausholen

Auf der Dokumentationsseite findet ihr viele weitere Beispiele dafür, wie ihr Formulare innerhalb des Elements verwenden, es gestalten und mit ihm interagieren könnt, und vieles mehr. Das alles wäre aber zu viel für diesen Blogbeitrag. Der CSS-Tricks-Blogbeitrag, der sich mit dem details Element beschäftigt, enthält auch einige Beispiele für das dialog Element.

Fazit

Ich hoffe, ich habe mir das beste Thema für heute aufgehoben. Zumindest fand ich dieses Element wirklich faszinierend und habe es in einem Projekt verwendet. Vielleicht blogge ich demnächst über diesen Anwendungsfall. Aber das ist etwas für das nächste Jahr. Dies war mein letzter Adventskalender-Blogbeitrag und auch der letzte für dieses Jahr, wenn ich meine zweiwöchige Blog-Routine einhalte.

Ich hoffe, ihr habt in den Adventskalender-Blogbeiträgen oder in den anderen Beiträgen, die ich in diesem Jahr geschrieben habe, ein paar neue Dinge gelernt. Es hat Spaß gemacht, aber es war auch viel mehr Arbeit, als ich dachte. Ich wünsche euch ein paar tolle Tage und wir sehen uns alle 2025! 🎇

Ein einfacherer Dark-Mode

Vor vier Tagen habe ich über „Die prefers-color-scheme Media-Query“ geschrieben und darüber, wie man sie verwendet, um einen Dark-Mode für den Browser zu erstellen. Heute werde ich euch zeigen, dass ihr sie vielleicht gar nicht braucht. Hm, aber wie bekommen wir dann einen Dark-Mode, werdet ihr euch jetzt vermutlich fragen? Mit einer einzigen CSS-Eigenschaft anstelle einer Medienabfrage.

Die color-scheme Eigenschaft

Ihr müsst nur eine einzige Eigenschaft verwenden, um dem Browser mitzuteilen, welche Farbschemas ihr habt. Und so können Sie es verwenden:

:root {
  color-scheme: light dark;
}

Das war es auch schon! Mehr als das braucht ihr nicht. Kommt morgen für einen neuen Blogbeitrag wieder. 😁 Nee, natürlich gibt es noch mehr zu sagen. Aber schauen wir doch mal, was das schon alles kann. Ich habe eine Seite mit ein wenig HTML ganz ohne CSS erstellt, abgesehen von dieser einen Zeile. So sieht sie in meinem Chrome-Browser aus, wenn ich einen hellen Modus verwende:

Screenshot einiger Elemente im hellen Modus in Chrome: h1, p, fieldset, input, textarea, select und button.

Und jetzt verwenden wir den Umschalter, den ich euch im Blogbeitrag „Präferenzen im Browser simulieren“ gezeigt habe, um in den dunklen Modus zu wechseln. Das würde dann so aussehen:

Screenshot von einigen Elementen im Dark-Mode in Chrome: h1, p, fieldset, input, textarea, select und button. Formularfelder und Button haben jetzt eine Hintergrundfarbe.

Während im hellen Modus alle Elemente einen weißen Hintergrund hatten, haben die Formularelemente und der Button nun einen grauen Hintergrund. Der Platzhaltertext des Inputs hat nun aber einen zu geringen Kontrast.

All das haben wir „kostenlos“ bekommen. Mit nur einer einzigen Zeile CSS. Aber dieses Design gefällt euch vielleicht nicht, wie können wir es also ändern, ohne die Media-Query zu verwenden? Es gibt einige spezielle „Funktionen“, die ihr verwenden könnt.

Die light-dark() Funktion

Nehmen wir unseren Quellcode aus dem Blogbeitrag „Die prefers-color-scheme Media-Query„, um zu sehen, wie das color-scheme verwendet werden kann, um einen einfachen Dark-Mode zu erstellen. So sah unser alter Code aus:

button {
	padding: 10px 20px;
	font-size: 2rem;
	background-color: #eee;
	border: 3px solid #333;
	border-radius: 10px;
	color: #333;
}
@media (prefers-color-scheme: dark) {
	button {
		background: #333;
		border-color: #333;
		color: #eee;
	}
}

Jetzt nehmen wir diesen Code und verwenden jede Farbe in der neuen light-dark() Funktion, die bereits eine recht gute Basis-Unterstützung hat. Wir definieren zuerst die helle Farbe und dann die dunkle Farbe. Es sollte dann wie folgt aussehen:

button {
	padding: 10px 20px;
	font-size: 2rem;
	background-color: light-dark(#eee, #333);
	border: 3px solid light-dark(#333, #eee);
	border-radius: 10px;
	color: light-dark(#333, #eee);
}

Ist das nicht viel einfacher zu lesen? Wenn wir die Seite mit einem hellen Farbschema betrachten, würden wir dies sehen:

Chrome mit geöffneten Entwicklertools, fokussiert auf einen Button. In den „Styles“ visualisiert die Funktion „light-dark()“ die beiden Farben.

Wenn Sie die Schaltfläche untersuchen, können Sie die Funktion light-dark() in den „Styles“ sehen und dort die Farben sehen/ändern. Betrachten wir nun dieselbe Seite mit der Einstellung für ein dunkles Farbschema:

Chrome mit geöffneten Entwicklertools, fokussiert auf einen Button. In den „Styles“ visualisiert die Funktion „light-dark()“ die beiden Farben. Es wird der Dark-Mode simuliert.

Das ist die grundlegende Verwendung der Eigenschaft color-scheme und der Funktion light-dark(). Aber die Eigenschaft kann verschiedene Werte haben.

Standardmäßig zu einem dunklen Modus wechseln

Wenn ihr den Dark-Mode als Standard für eure Website verwenden und auf einen hellen Modus verzichten möchtet, setzt das color-scheme einfach wie folgt um:

:root {
	color-scheme: dark;
}

Falls ihr aber standardmäßig einen hellen Modus haben wollt, tut genau das Gegenteil und verwendet light als einzigen Wert. Sobald ihr die beiden Werte light und dark habt, die Reihenfolge spielt keine Rolle, werdet ihr das oben gezeigte Verhalten haben.

Den Dark-Mode verhindern

Wie ich im Blogbeitrag „Präferenzen im Browser simulieren“ beschrieben hatte, verfügt Chrome über eine Option für einen „automatischen dunklen Modus“. Dadurch wird ein dunkler Modus verwendet, auch wenn das color-scheme auf light eingestellt ist. Ihr könnt den Dark-Mode aber auch verhindern, indem ihr das Keyword only hinzufügt:

:root {
	color-scheme: only light;
}

Jetzt wird der Browser keinen Dark-Mode verwenden. Und natürlich könnt ihr auch „only dark“ verwenden, um das Gegenteil zu erreichen.

CSS-Eigenschaft nur für einige Elemente setzen

Einige Website-Designs verwenden „unterschiedliche Farbschemas“ für verschiedene Elemente. Zum Beispiel könnte eine Website eine dunkle Kopfzeile, aber eine helle Fußzeile hat. Vielleicht möchtet ihr diese Farben beibehalten, auch wenn der Modus umgeschaltet werden kann. Dann könnt ihr das color-scheme für einige Elemente einschränken, aber für andere Teile beide zulassen:

:root {
	color-scheme: light dark;
}
header {
	color-scheme: only dark;
}
.left {
	color-scheme: light;
}
.middle {
	color-scheme: light dark;
}
.right {
	color-scheme: dark;
}
footer {
	color-scheme: only light;
}

In diesem Codeschnipsel legen wir beide Farbschemas für das Root-Element fest, ändern sie aber dann für bestimmte Teile der Seite. Die Kopf- und Fußzeile sind auf nur ein Farbschema beschränkt. Im Inhaltsbereich gibt es drei Teile. Der linke und der rechte Teil nehmen nur ein Schema an, der mittlere nimmt zwei an (wir könnten die Angaben für den mittleren weglassen, da er das Schema vom Root-Element erben würde, aber der Vollständigkeit halber habe ich ihn hier gelassen).

Ich habe unseren Button in jedem dieser Abschnitte platziert. Schauen wir uns an, wie das in Chrome mit den verschiedenen Farbschema-Simulationen aussieht:

Mit „prefers-color-scheme: light“

Chrome mit „prefers-color-scheme: light“ zeigt dunkle Buttons in der Kopfzeile und auf der rechten Seite und helle Buttons auf der linken Seite, in der Mitte und in der Fußzeile an.

Wir können hier sehen, dass unser „color-scheme: dark“ im „.right“ Container den Button im dunklen Farbschema anzeigt.

Mit „prefers-color-scheme: dark“ (bevorzugtes Farbschema: dunkel)

Chrome mit „prefers-color-scheme: dark“ zeigt dunkle Buttons in der Kopfzeile, in der Mitte und auf der rechten Seite an und helle Buttons auf der linken Seite und in der Fußzeile.

Beim Umschalten auf das dunkle Farbschema hat sich der Button in der Mitte verändert, die anderen sind jedoch gleich geblieben. Auch der Inhaltsbereich hat jetzt einen schwarzen Hintergrund, aber die Hintergrundfarben von Kopf- und Fußzeile sind gleich geblieben.

Mit „Automatischer dunkler Modus“

Chrome mit „Automatischer dunkler Modus“ zeigt dunkle Buttons in der Kopfzeile, in der Mitte und rechts, und helle Buttons in der Fußzeile an. Der button auf der linken Seite hat einen Dark-Mode mit einer anderen Rahmenfarbe (dunkler).

Unsere Kopf- und Fußzeile sind immer gleich geblieben. Aber jetzt wird auch der linke Button in einem Dark-Mode angezeigt, da dieser Teil nicht das Schlüsselwort „only“ verwendet. Die Rahmenfarbe ist allerdings dunkler als in unserem definierten CSS-Design.

Den Dark-Mode weiter stylen

Da die Funktion light-dark() nur für Farben verwendet werden kann, müsst ihr möglicherweise auch weiterhin die Media-Query prefers-color-scheme verwenden, um andere Stile in eurem Dark-Mode zu ändern.

Wenn ihr noch kreativer werden wollt und euch noch mehr mit dem Dark-Mode beschäftigen möchtet, empfehle ich euch den Blogbeitrag „Dark Mode in CSS Guide“ von CSS-Trick sowie die beiden Seiten über die color-scheme Eigenschaft und die light-dark() Funktion.

Fazit

Das Hinzufügen eines Dark-Mode zu eurer Seite und das Testen des Modus war noch nie so einfach wie mit den in den letzten Blogbeiträgen beschriebenen Methoden. Vielleicht könnt ihr also in diesen dunklen Wintertagen auch das Design eurer Website anpassen und versuchen, ein schönes dunkles Farbschema zu erstellen.

CSS-Stile mit JavaScript auslesen

In der Regel sollten man jede der grundlegenden Webtechnologien für ihren Hauptzweck verwenden: HTML für das Markup, CSS für die Stile und JavaScript für zusätzliche Interaktivität. Aber manchmal überschneiden sich diese Dinge. Es kann Fälle geben, in denen ihr die aktuell gerenderten Stile eines Elements kennen müsst. Darum geht es im heutigen Thema.

Ermitteln der berechneten Stile eines Elements

Der Funktionsname dafür könnte nicht einfacher zu merken sein: getComputedStyle(). Sie ist eine Funktion des windows Objekts und bekommt das Element übergeben, für das wir die Stile haben wollen:

const body = document.querySelector('body');
const bodyStyles = window.getComputedStyle(body);
const bodyFontSize = bodyStyles.getPropertyValue('font-size');
console.log(bodyFontSize); // 16px

Um eine einzelne CSS-Eigenschaft abzurufen, verwenden wir die Funktion getPropertyValue() für das CSSStyleDeclaration Objekt (in unserem Fall bodyStyles) und teilen ihm mit, welche Eigenschaft wir abrufen möchten.

Wenn ihr diesen Code in einem völlig leeren HTML-Dokument ausführt, erhaltet ihr wahrscheinlich 16px als Schriftgröße für den Textkörper, was in den meisten Browsern die Standardeinstellung ist, es sei denn, die Größe wurde im Betriebssystem oder im Browser geändert.

Aber schauen wir mal, wie wird das Ganze noch interessanter machen können. Man hat nicht immer eine feste Schriftgröße für ein Element, denn manchmal ist sie relativ zu anderen Elementen:

body {
	font-size: 22px;
}
h1 {
	font-size: 1.6em;
}
h1 small {
	font-size: 75%;
}

Jetzt haben wir eine Website mit einer <h1> Überschrift und einem <small> Element darin. Wie groß wäre die resultierende Schriftgröße? Schnappen wir uns unsere Taschenrechner:

  • <body> font-size: 22px
  • <h1> font-size: 22px * 1,6 = 35,2px
  • <small> innerhalb von <h1> font-size: 35,2px * 0,75 = 26,4px

Wir sollten also eine Schriftgröße von 26,4px für den kleinen Text erhalten. Schauen wir uns an, ob das der Fall ist, indem wir es auch mit den Entwicklertools überprüfen:

Screenshot von Chrome mit den geöffneten Entwicklungswerkzeugen. Die Seite hat ein h1 Element mit einem darin enthaltenen small Element. Dieses Element ist ausgewählt und das Stile-Panel „Berechnet“ zeigt „font-size: 26.4px“.

Hier seht ihr ein vollständiges Beispiel, mit dem geänderten Selektor. Wir haben das <small> Element ausgewählt und Chrome zeigt uns die Schriftgröße von 26,4px im Abschnitt „Berechnet“ an. Wie ich nach dem Aufruf von console.log() geschrieben habe, erhalten wir diesen Wert auch von JavaScript. Ganz nett, nicht wahr?

Abrufen von Stilen aus einem Pseudo-Element

Wenn ein Element über ein Pseudo-Element verfügt, das entweder speziell festgelegt oder standardmäßig verfügbar ist, können wir auch Stile für dieses Element abfragen. Legen wir also einige Stile für das neue ::marker Pseudo-Element eines Listenelements fest:

ul li::marker {
	color: red;
}

Wir können nicht einfach ein Pseudo-Element mit der Methode document.querySelector() auswählen, aber wir können die berechneten Stile wie folgt erhalten:

const element = document.querySelector('ul li');
const color = window.getComputedStyle(element, '::marker').color;
console.log(color); // rgb(255, 0, 0)

Wenn ihr versucht, Stile für ein „älteres Pseudo-Element“ wie das ::before Pseudo-Element zu erhalten, können ihr auch :before schreiben, aber ihr könnt nicht :marker schreiben, da dies ein neueres Pseudo-Element ist, für das die Variante mit nur einem Doppelpunkt nicht existiert.

In diesem Codeschnipsel verwende ich nicht zusätzliche die Funktion getPropertyValue(), da sie nicht unbedingt erforderlich ist. Ihr könnt die meisten Eigenschaften direkt über ihren Namen abrufen. Ich empfehle, einen Blick in die Dokumentation des CSSStyleDeclaration Objekts zu werfen oder das Objekt auf der Konsole auszugeben, um die verfügbaren Eigenschaften zu sehen.

Was ihr in diesem Beispiel auch sehen könnt, ist, dass wir nicht den Wert red erhalten, den wir in unserem CSS verwendet haben. Stattdessen erhalten wir rgb(255, 0, 0) als berechneten Stil. Weitere Informationen hierzu findet ihr in den Notes auf der Dokumentationsseite.

Fazit

Vielleicht habt ihr einen JavaScript-Code, der die Stile eines Elements kennen muss. Sei es die Größe, die Farbe, die Position oder andere Eigenschaften, die eine Auswirkung auf euren Code haben würden. In diesen Fällen ist die Funktion getComputedStyle() sehr hilfreich. Der WordPress Core verwendet sie auch an verschiedenen Stellen, z.B. im Farbwähler, um vor einem zu geringen Farbkontrast zu warnen. Das ist ein sehr gutes Beispiel dafür, wie man die Funktion verwenden kann.

Aufzeichnen und Wiedergeben von Website-Interaktionen für Tests

Dies ist der letzte Blog-Beitrag zum Thema Debugging für diesen Adventskalender. Für den letzten Beitrag habe ich mir etwas Besonderes aufgehoben. Vielleicht gibt es Dinge, die ihr im Frontend (oder Backend) eurer Seite immer wieder testen müsst, nachdem ihr etwas geändert habt. Sei es das Ausfüllen eines Formulars, das Klicken auf einige Elemente oder die Navigation durch die Seite. Es kann sehr mühsam sein, das immer wieder manuell zu tun. Aber wenn ihr Chrome für eure Tests verwendet, gibt es ein nettes eingebautes Tool, das ich durch eine Kollegin kennengelernt habe.

Die Rekorder Funktion in Chrome

Um zu dieser Funktion zu gelangen, haben ihr zwei Möglichkeiten. Ihr können das Panel auf ähnliche Weise öffnen, wie wir das „Rendering“ Panel geöffnet haben. Öffnen dazu die Entwicklertools, klickt auf die drei vertikalen Punkte, wählt „Weitere Tools“ und dann „Rekorder“ aus:

Screenshot, wie man die "Weitere Tools > Rekorder" Einstellungen öffnet.

Die zweite Möglichkeit ist die Verwendung des Dialogs „Befehl ausführen“, den ihr mit „Strg+ Umschalt + P“ (oder „Cmd+ Umschalt + P“ auf einem Mac) öffnen könnt. Dort sucht ihr dann nach „Rekorder“. Sobald das Panel geöffnet ist, klickt auf die blaue Schaltfläche „Neue Aufzeichnung erstellen“:

Screenshot der geöffneten Chrome Rekorder-Funktion mit dem blauen Button „Neue Aufzeichnung erstellen“.

Auf der nächsten Seite erstellt Chrome automatisch einen „Name der Aufzeichnung“ mit dem aktuellen Datum und der Uhrzeit für eure Aufzeichnung, den ihr aber mit einem aussagekräftigeren Titel überschreiben könnt:

Chrome-Recorder-Funktion mit geändertem „Name der Aufzeichnung“, bevor die Aufzeichnung gestartet wird.

Wenn ihr fertig seid, klickt auf den roten Button am Ende der Seite oder drücken Sie „Strg + E“. Dann macht irgendetwas auf der Seite. In diesem Beispiel habe ich oben rechts auf die Suche geklickt, „Adventskalender“ in das Suchfeld eingegeben und auf ENTER gedrückt. Nachdem die Seite neu geladen wurde, habe ich wieder auf den Button unten geklickt, um die Aufzeichnung zu beenden. Ihr solltet dann in etwa so etwas sehen:

Chrome Rekorder nach der Aufzeichnung.

Wenn du nach oben scrollst, findest du oben links einen Button „Code anzeigen“. Wenn ihr dort darauf klickt, können ihr die technische Datei für die Aufzeichnung in verschiedenen Formaten sehen:

Chrome Rekorder mit geöffneter Code-Ansicht.

Der interessanteste Button ist aber der blaue Button „Noch einmal wiedergeben“. Links davon können ihr zuvor noch die Wiedergabegeschwindigkeit auswählen. Wenn ihr nun auf den Button klickt, zeigt Chrome die Meldung „Chrome wird automatisierter Testsoftware gesteuert“ an. Es werden dann alle Schritte abgespielt und einzeln überprüft. Wenn alles erfolgreich war, ist die vertikale Linie für einige Sekunden grün:

Chrome Rekorder direkt nach der erneuten Wiedergabe.

Oben links in der Leiste seht ihr ein Dropdown-Menü. Hier findet ihr alle Aufzeichnungen, die ihr jemals in diesem Chrome-Profil gemacht habt. Mit den Schaltflächen daneben können ihr sie importieren, exportieren und löschen. Wenn ihr eine solche JSON-Datei exportiert und an eine andere Person senden, könnt ihr die wiederholbaren Testschritte mit anderen teilen.

Ihr könnt auch jeden Schritt ausklappen und die Einstellungen des Schritts ändern. Auf der Seite Chrome for Developer findet ihr hierzu ein kurzes Video, in dem der Rekorder etwas genauer erklärt wird.

Fazit

Wenn ihr einen Test auf einer Seite wiederholen möchtet, aber nicht jeden Klick und jeden Tastendruck manuell wiederholen wollt, ist der Chrome Rekorder ein großartiges Tool, das ihr verwenden könnt. Es hat auch eine Exportoption, die ich wahrscheinlich in einem anderen Blog-Beitrag behandeln werde. Da dieses Thema aber nicht ganz in unsere vier Themen für den Adventskalender 2024 passt, müssen ihr bis 2025 warten.

Ich konnte keine ähnliche Funktion in Firefox finden, aber wenn ihr eine Erweiterung kennt, die etwas Ähnliches in anderen Browsern anbietet, hinterlasst bitte einen Kommentar.

Barrierefreie Akkordeons mit dem details HTML-Element erstellen

In meinem vorletzten Blog-Beitrag zum Thema HTML in dieser Adventskalender-Serie möchte ich ein Element vorstellen, das einige von euch vielleicht schon benutzt haben, ohne es zu kennen. Aber die Funktionalität, die es euch bietet, haben viele von euch vielleicht schon in einer Website verwendet.

Toggle- und Akkordeon-Elemente

Wenn wir nur ein Element haben, das beim Anklicken eines Buttons oder Textes zusätzlichen Text einblendet, sprechen wir oft von „Toggle-Elementen“. Gibt es mehrere, von denen immer nur eines gleichzeitig geöffnet sein kann, spricht man von „Akkordeons“.

In der Vergangenheit hätten wir für eine solche Funktionalität eine JavaScript-Bibliothek verwenden und den Inhalt in einigen Container-Elementen platziert, die dann über einen Button oder Link angezeigt werden. Aber jetzt haben wir ein Element für diese Funktion. Wenn wir einen einzelnen Toggle haben wollen, wäre dies unser Markup:

<details open>
	<summary>Erfahre mehr über das details Element</summary>
	Dies ist Text, der nur angezeigt wird, wenn das Element geöffnet wird.
	Ihr können hier auch beliebige andere HTML-Elemente verwenden, ihr müsst 
	also nicht nur einfachen Text verwenden.
</details>

In diesem Beispiel wird der „versteckte Text“ nicht in ein Element eingeschlossen. Wahrscheinlich würdet ihr hier ein <p> oder <div> verwenden, aber eigentlich wird jeder Inhalt, der nach dem <summary> Element kommt, ausgeblendet. Das Element wird standardmäßig „geschlossen“ angezeigt uns es würde so aussehen:

Ein nach rechts zeigendes Dreieck mit dem Text „Erfahre mehr über das details Element“ daneben.

Der nach rechts zeigende Pfeil wird standardmäßig angezeigt. Die Form wird in den verschiedenen Browsern etwas unterschiedlich aussehen. Wenn ihr auf den Pfeil oder den Text klickt, wird das Element geöffnet, und der Pfeil zeigt jetzt nach unten. Damit wird angezeigt, dass das Element geöffnet ist:

Ein nach unten zeigendes Dreieck, mit dem Text des details Elements rechts davon und dem restlichen Inhalt innerhalb des details Elements darunter.

Wie bereits erwähnt, ist das Element standardmäßig geschlossen, ihr können es aber auch öffnen, indem ihr ein leeres open Attribut zum Element hinzufügt:

<details open>
<!--... -->
</details>

Wenn ihr nun auf das <summary> Element klickt, wird das <details> Element geschlossen. Ich kann mir nicht wirklich einen Anwendungsfall vorstellen, in dem man dies für einen einzelnen Toggle verwenden würde. Warum sollte man mit einem Klick etwas ausblenden, das bereits sichtbar war?

Erstellen eines Akkordeons mit mehreren „gruppierten“ details Elementen

Das <details> Element hat nur zwei spezifische Attribute. Das Attribut open haben wir bereits kennengelernt, das zweite ist name. Wenn ihr mehreren <Details> Elementen dieses Attribut mit demselben Wert gebt, werden sie zu einem Akkordeon gruppiert, wobei immer nur eines zur gleichen Zeit geöffnet sein kann:

<h2>Gruppe eins</h2>
<details name="group-one">
	<summary>Erstes Element von Gruppe eins</summary>
	<p>Der Inhalt des ersten Elements von Gruppe eins.</p>
</details>
<details name="group-one">
	<summary>Zweites Element von Gruppe eins</summary>
	<p>Der Inhalt des zweiten Elements von Gruppe eins.</p>
</details>
<h2>Gruppe zwei</h2>
<details name="group-two">
	<summary>Erstes Element von Gruppe zwei</summary>
	<p>Der Inhalt des ersten Elements von Gruppe zwei.</p>
</details>
<blockquote>
	<q>Ein zufälliges Zitat dazwischen</q>
	<p>Eine berühmte Person</p>
</blockquote>
<details name="group-two" open>
	<summary>Zweites Element von Gruppe zwei</summary>
	<ul>
		<li>Punkt 1</li>
		<li>Punkt 2</li>
	</ul>
</details>

Ich habe hier ein etwas komplexeres Beispiel gewählt, um mehrere Dinge auf einmal zu zeigen. Zunächst einmal haben wir zwei Akkordeons, die jeweils die Werte group-one bzw. group-two für das name Attribut verwenden. Das HTML-Markup würde folgendermaßen dargestellt werden:

Zwei details Akkordeongruppen mit einem Zitat zwischen den Elementen der zweiten Gruppe, die eine ungeordnete Liste als Inhalt des zweiten details Elements hat.

In Gruppe eins hat kein Element das open Attribut, also sind beide standardmäßig geschlossen, während in Gruppe zwei das zweite Element das open Attribut hat und seinen Inhalt anzeigt. In diesem Fall ist der Inhalt eine ungeordnete Liste, was zeigt, dass das Element beliebigen HTML-Code und nicht nur statischen Text enthalten kann.

Zwischen dem ersten und dem zweiten Element der zweiten Gruppe befindet sich auch ein „Blockquote“ (Zitatblock). Dies soll verdeutlichen, dass nicht alle <details> Elemente direkt neben-/untereinander stehen müssen. Ihr könnt auch Inhalte dazwischen haben.

Wenn ihr eines der anderen Elemente in derselben Gruppe öffnet, wird automatisch das aktuell geöffnete Element geschlossen. Wenn ihr das geöffnete Element ebenfalls schließt, sind dann alle geschlossen. Es gibt keine (native) Möglichkeit, das Schließen aller Elemente zu verbieten.

Wenn ihr ermöglichen wollt, dass alle Elemente offen sind, verwenden einfach nicht das Attribut name für diese Elemente. Ihr könnt auch ein wenig JavaScript für zwei Buttons „Alle öffnen“ und „Alle schließen“ verwenden, die alle Elements öffnen oder schließen würden. Es gibt sogar ein toggle Event, für das ihr einen Event-Listener registrieren könnet. Mehr dazu finden ihr in der Dokumentation.

Styling des Elements

Die Dokumentation enthält auch einige grundlegende Beispiele für die Gestaltung. Wenn ihr noch kreativere Möglichkeiten zur Gestaltung des Elements sehen möchten, kann ich euch den CSS-Tricks-Blogbeitrag zu diesem Element sehr empfehlen..

Fazit

Wenn ihr wirklich ein Toggle-/Akkordeon-Element auf eurer Website benötigt, kann ich die Verwendung der nativen HTML-Elemente sehr empfehlen. Ich persönlich mag keine Toggles oder Akkordeons. Ich blättere lieber durch eine längere Seite, als auf all diese „Toggle-Buttons“ klicken zu müssen, die die Seite auch noch nach oben/unten verschieben, womit man das nächste Element erst einmal anvisieren muss. Das frustriert mich wirklich.

Wenn ihr WordPress verwendet, benutzt einfach den „Details“ Block, der euch genau dieses Element liefert. Ihr habt dann eine Zeile für die Zusammenfassung und dann einen „Absatz“ Block für den Inhalt. Ihr könnt hier aber jeden beliebigen Block verwenden, sogar mehrere oder Blöcke wie „Gruppe“, „Spalten“ usw., um wirklich kreativ zu werden.

Die prefers-color-scheme Media-Query

Heute möchte ich über etwas sprechen, das viele von euch wahrscheinlich sehr mögen: Dark-Modes! Oder genauer gesagt, wie man das Farbschema auf den dunklen Modus umstellt, diese Präferenz eingestellt ist. Ich verwende den Dark-Mode für meine IDE und für einige Online-Dienste, aber für viele bin ich immer noch auf der hellen Seite.

Erkennung des Dark-Modes und Anpassung der Styles

Die Aktivierung des Dark-Mode kann durch eine Einstellung im Betriebssystem oder Browser vorgenommen werden oder durch das Klicken auf einen Button passieren. Unabhängig davon, wie zum Dark-Mode gewechselt wird, sollte euer CSS-Code die Media-Query wie folgt verwenden:

button {
	padding: 10px 20px;
	font-size: 2rem;
	background-color: #eee;
	border: 3px solid #333;
	border-radius: 10px;
	color: #333;
}
@media (prefers-color-scheme: dark) {
	button {
		background: #333;
		border-color: #333;
		color: #eee;
	}
}

Dieses CSS geht davon aus, dass ihr standardmäßig ein helles Farbschema verwenden. Wenn nun die Präferenz auf dark gesetzt wird, werden alternative Farben für die Buttons verwendet. So würde ein Button in hellen oder dunklen Farben aussehen:

Ein Button mit dem Text „light colors“ auf der linken Seite, mit einer hellgrauen Hintergrundfarbe und einer dunkelgrauen Text- und Rahmenfarbe. Ein zweiter Button auf der rechten Seite mit dem Text „dark colors“, dem Text in hellgrau und dem Hintergrund und Rahmen in dunkelgrau für ein „ausgefülltes“ Design.

Durch die Verwendung der gleichen Farbe für Hintergrund und Rahmen haben wir die dunkle Version des Buttons „ausgefüllt“. Ihr müsst aber nicht immer alle Farben invertieren/vertauschen. Einige generische Plugins tun dies jedoch. Wie ich im Beitrag „Präferenzen im Browser simulieren“ erklärt habe, könnt ihr diese Dark-Mode-Styles einfach testen, ohne die Einstellungen in eurem Betriebssystem ändern zu müssen. Chrome verfügt noch über eine Option „Automatischer dunkler Modus“, aber diese würde nur versuchen zu „erraten“, welche Farben verwendet werden könnten. Wir hätten dann ein etwas helleres Grau für den Hintergrund und ein helleres Grau für den Rahmen:

Zwei Buttons, einer mit der Bezeichnung „light colors“ und einer mit der Bezeichnung „dark colors“. Beide haben die gleichen Farben, mit einem mittelgrauen Rand, einem dunkelgrauen Hintergrund und einer hellgrauen Textfarbe.

Wie ihr sehen könnt, würden sogar unsere definierten Farben für den Dark-Mode eines Buttons nicht mehr verwendet werden. Stattdessen zeigt Chrome jeden Button in diesem „automatischen dunklen Modus“ an. Ich bin mir aber auch nicht sicher, ob viele Leute das wirklich nutzen.

Verwendung des hellen Dark-Modes als Standard

Viele Leute entwerfen eine Website mit einem hellen Modus als Standard und verwenden dann die Medienabfrage wie oben gezeigt, um die Farben für einen dunklen Modus zu ändern. Wenn ihr allerdings eine Seite mit einem Dark-Mode als Standard gestalten möchtet, wäre das eine Menge CSS in dieser Media-Query. Was ihr hier stattdessen tun könnt: ändern die Farben, wenn jemand ausdrücklich einen hellen Modus bevorzugt. So in etwa macht ihr das:

button {
	padding: 10px 20px;
	font-size: 2rem;
	background-color: #333;
	border: 3px solid #333;
	border-radius: 10px;
	color: #eee;
}
@media (prefers-color-scheme: light) {
	button {
		background: #eee;
		border-color: #eee;
		color: #333;
	}
}

Dieser Code-Schnipsel ist im Grunde genommen wieder der Erste, es sind nur (fast) alle Farben vertauscht und wir haben den bedeutenden Unterschied, dass wir jetzt in der Media-Query prefers-color-scheme nach light abfragen. Der Button sieht nun im Standard-Dark-Mode und im hellen Modus wie folgt aus:

Zwei Buttons, der linke mit dem Text „dark colors“, einem dunkelgrauen Hintergrund und hellgrauen Text. Der rechte mit dem Text „dark colors“, einem hellgrauen Hintergrund und dunkelgrauem Text.

Je nach euren eigenen Vorlieben könnt ihr also entscheiden, welches Farbschema ihr als Standard für eure Website verwenden möchtet. Das Hinzufügen des anderen Farbschemas kann allerdings einen großen Unterschied in Bezug auf Lesbarkeit und Barrierefreiheit machen. Vor allem, wenn ihr einen Dark-Mode als Standardeinstellung haben wollte, sollten ihr unbedingt in Erwägung ziehen, auch ein helles Farbschema anzubieten.

Fazit

Das Hinzufügen eines Dark-Mode zu eurem CSS war noch nie so einfach wie mit dieser Media-Query. Wenn ihr die Möglichkeit zur Auswahl der Modus geben wollt, kann ein „Umschalt-Button“ oder eine Profileinstellung sinnvoll sein. Dafür ist eine weitere Eigenschaft sehr nützlich. Aber das wird das Thema unseres letzten Blogbeitrags im Adventskalender 2024 zu CSS sein.

Tagged Template Literals in JavaScript

Im Blogbeitrag vor 8 Tagen mit dem Titel „Dynamische Parameter in JavaScript“ habe ich euch gezeigt, wie Funktionen mit einer variablen Anzahl von Parametern funktionieren. Heute möchte ich über die Funktion „getaggte Template“ („Tagged Template Literals“) in JavaScript sprechen, als eine Art von Funktion, die variable Anzahl von Parametern hat.

Template-Literale

Bevor wir uns dem Thema zuwenden, sollten wir zunächst über „Template Literals“ sprechen. In alten Versionen von JavaScript hätte man Folgendes getan, wenn man eine Variable zwischen statischem Text einfügen möchte:

var name = "Bernhard";
var country = "Finland";
var greet = "Hi, my name is " + name + " and I'm currently in " + country + ".";
console.log(greet);
//Hi, my name is Bernhard and I'm currently in Finland.

Mit modernem JavaScript könnt ihr „Template Literals“ verwenden, um eine Variable (oder sogar Code) in euren Strings zu platzieren, die dann interpretiert werden:

const name = "Bernhard";
const country = "Finland";
const greet = `Hi, my name is ${name} and I'm currently in ${country}.`;
console.log(greet);
//Hi, my name is Bernhard and I'm currently in Finland.

Durch die Verwendung von „Backticks“ anstelle von Anführungszeichen verwandeln wir unseren einfachen String in ein Template Literal. Ist das nicht viel einfacher zu lesen? Ah, und ja, ich bin derzeit in Finnland und nicht in Berlin. Auf den Åland-Inseln, um genau zu sein.

Tagged Template Literals

Nach dieser kurzen Einführung kommen wir nun zu den „getaggten“ Template Literals. Wenn ihr sie zum ersten Mal seht, dann kommen sie euch vielleicht ein bisschen seltsam aus. So könnte ein Beispiel aussehen:

const name = "Bernhard";
const country = "Finland";
const greet = makeItBold`Hi, my name is ${name} and I'm currently in ${country}.`;

function makeItBold(strings, ...values) {
	// strings => ['Hello, my name is ', " and I'm currently in ", '.']
	// values => ['Bernhard', 'Finland']

	let result = "";

	// Loop through the strings and values
	for (let i = 0; i < values.length; i++) {
		result += strings[i] + `<b>${values[i]}</b>`;
	}

	// Append the last string (after the last variable)
	result += strings[values.length];

	return result;
}

console.log(greet);
// Hi, my name is <b>Bernhard</b> and I'm currently in <b>Finland</b>.

Wir definieren eine Funktion(makeItBold) und schreiben dann einfach den Funktionsnamen vor das Template Literal. In der Funktion erhalten wir das „statische Strings-Array“ als ersten strings Parameter und dann eine dynamische Anzahl von Parametern für jede „Variable“ (oder genauer gesagt jeden Ausdruck) im Template Literal als zweiten values Parameter. Wir könnten diese Funktion auch so schreiben:

function makeItBold(strings, name, country) {
	// ...
}

Aber das wäre nicht wirklich flexibel, wenn wir die Variablen vertauschen oder mehr/weniger Variablen in einem anderen String haben.

Eine Möglichkeit, die Funktion etwas kürzer zu machen, ist die Verwendung von modernem JavaScript-Code, der mit Arrays arbeitet (zur besseren Lesbarkeit in mehreren Zeilen geschrieben):

function makeItBold(strings, ...values) {
	return strings.reduce(
		(result, str, i) => result + str + (values[i] ? `<b>${values[i]}</b>` : ""),
		""
	);
}

Diejenigen unter euch, die mit modernem JavaScript vertraut sind, können dies wahrscheinlich leicht lesen. Ich muss immer noch zweimal hinschauen und es sorgfältig lesen.

Ich hatte Schwierigkeiten, ein gutes „Praxisbeispiel“ zu finden, aber nachdem ich das obige Beispiel gefunden hatte, ist mir sogar eines eingefallen, das wirklich nützlich sein könnte. Es arbeitet auch nicht mit skalaren Werten, sondern mit Objekten. Was haltet ihr von diesem Beispiel?

function schema(strings, ...values) {
	return strings.reduce((result, str, i) => {
		const value = values[i];
		if (value) {
			// Check for specific schema.org types and add relevant markup
			if (value.type === "Person") {
				return (
					result +
					str +
					`<span itemscope itemtype="https://schema.org/Person">
						<span itemprop="name">${value.name}</span>
					</span>`
				);
			} else if (value.type === "Place") {
				return (
					result +
					str +
					`<span itemscope itemtype="https://schema.org/Place">
						<span itemprop="name">${value.name}</span>
					</span>`
				);
			}
		}
		return result + str;
	}, "");
}

// Usage
const name = { type: "Person", name: "Bernhard" };
const country = { type: "Place", name: "Finland" };

const greet = schema`Hello, my name is ${name} and I'm currently in ${country}.`;

console.log(greet);
// Hello, my name is <span itemscope itemtype="https://schema.org/Person"><span itemprop="name">Bernhard</span></span> and I'm currently in <span itemscope itemtype="https://schema.org/Place"><span itemprop="name">Finland</span></span>.

Fazit

Wie bereits erwähnt, war es nicht einfach, ein gutes Beispiel zu finden. Man könnte argumentieren, dass man in vielen Fällen auch einfach ein Template Literal und etwas Inline-HTML-Markup verwenden könnte. Aber trotzdem gibt es diese Funktionalität und ihr sollten wissen, wie solcher Code funktioniert.

Wenn ihr ein Beispiel mit Tagged Template Literals aus einem eurer Projekte habt, hinterlasst bitte einen Kommentar.

JavaScript mit dem debugger Keyword pausieren lassen

Dieser Blogbeitrag soll keine grundlegende Einführung in das Debugging mit JavaScript sein. Wir könnten wahrscheinlich einen ganzen Adventskalender mit allen Aspekten füllen. Aber ich möchte ein kleines Schlüsselwort für eure Debugging-Toolbox vorstellen.

Einen Breakpoint im Browser setzen

Wenn ihr einen JavaScript-Code debuggen wollt, dann setzt ihr wahrscheinlich irgendwann einen Breakpoint in eurem Code. Wenn ihr eine kleine JavaScript-Datei habt, die schön formatiert ist, sieht sie in Chrome vielleicht so aus:

Chrome Entwicklertools mit einem manuellen gesetzten Breakpoint, der den Browser an dieser Zeile pausieren lässt.

Ihr öffnet dazu die Entwicklertools, navigieren auf der Registerkarte „Quellcode“ („Sources“) zur JavaScript-Datei, setzen einen Breakpoint und laden die Seite neu. Chrome hält dann an der Zeile an, und ihr könnt euren Code debuggen.

Das Problem mit kompiliertem JavaScript-Code

Diejenigen unter euch, die Code mit React, Vue usw. entwickeln und Webpack oder ähnliche Tools zum Kompilieren eures Codes verwenden, die erhalten keinen so schön formatierten Code, der auch noch leicht zu lesen ist. Fügen wir unseren Code von oben in den Kompilierungs-Workflow aus dem Paket @wordpress/scripts ein und kompilieren ihn:

npm run build

Jetzt erhalten wir eine kompilierte „Produktions-Datei“, und unser schön formatierter Code ist jetzt nur noch eine einzige Zeile in dieser kompilierten Datei:

Chrome Entwicklertools, die eine minifizierte Datei anzeigen.

Wie setzen wir jetzt einen Breakpoint? Wenn ihr einen Breakpoint in einer „einzeiligen JavaScript-Datei“ setzen wollt, gibt es eine kleine Funktion, die ihr verwenden können. Klickt dazu einfach auf das „{}“ Symbol („Quelltextformatierung“) unten links in der mittleren Spalte, und ihr erhaltet etwas wie im folgenden Screenshot. Hier könnt ihr nun einen Haltepunkt in der „virtuellen Zeile“ setzen:

Chrome dev tools "pretty printing" the one-line JavaScript file and a manual break point set on a prettified line.

Das funktioniert einigermaßen. Aber wenn ihr den Aufruf von console.log() am Ende der Datei debuggen wollt, dann stehen sie immer noch in einer Zeile und auch noch zusätzlich in einem ternären Operator.

Verwendung des debugger Keywords für einen „erzwungenen Breakpoint“

Nach dieser kurzen Einführung kommen wir nun zu dem Keyword, über das ich heute sprechen wollte. Während ihr euren Code entwickelt, können ihr das debugger Keyword an eine beliebige Zeile eures Codes einfügen, wodurch der Browser gezwungen wird, an dieser Stelle zu pausieren. Verwenden wir es also in der kompilierten Version, um den „if“-Teil des ternären Operators zu debuggen. Wir verwenden nun einen anderen Befehl, um die „Entwicklungsversion“ zu erhalten, der auch einen Watcher startet und den Code kompiliert, sobald wir etwas ändern:

npm run start

In unserem JavaScript-Code fügen wir außerdem das debugger Keyword wie folgt am Ende des if/else ein:

if (found) {
    debugger;
    console.log(`there is a 4 in array ${found}'`);
} else {
    console.log("There is no 4 in the array");
}

Wenn wir den Browser jetzt aktualisieren, wird er bei diesem Keyword in Zeile 17 anhalten. Wir müssen hier keinen Breakpoint setzen:

Chrome dev tool showing a JavaScript file stopped at the "debugger" keyword.

Oben rechts seht ihr „Debugger paused“ und das Skript ist angehalten, genau wie bei einem von uns manuell gesetzten Breakpoint in dieser Ansicht. Wir können nun mit unserem Debugging fortfahren.

Verwendung des debugger Keywords in minifizierten Dateien

Eine Anmerkung vorweg: ihr solltet das wahrscheinlich nicht tun. Wenn ihr das „build“-Skript verwendet, dann erstellt ihr normalerweise Dateien für den produktiven Einsatz und diese sollten kein debugger Keyaord enthalten. Aus diesem Grund entfernt das Webpack-Minifizierungs-Plugin dieses Keyword automatisch. Wenn ihr, aus welchen Gründen auch immer, das debugger Keyword in den kompilierten Dateien haben wollt, müsst ihr eine eigene webpack.config.js Webpack-Konfigurationsdatei schreiben:

const defaultConfig = require('@wordpress/scripts/config/webpack.config');
const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
    ...defaultConfig,
    optimization: {
        ...defaultConfig.optimization,
        minimize: true,
        minimizer: [
            new TerserPlugin({
                terserOptions: {
                    compress: {
                        drop_debugger: false,
                    },
                },
            }),
        ],
    },
};

Wenn wir jetzt npm run build ausführen und den Browser aktualisieren, sehen wir das Keyword und der Browser bleibt dort stehen:

Chrome dev tool showing a JavaScript file stopped at the "debugger" keyword in a "prettified" minified code.

Dies würde auch automatisch das „Quelltextformatierung“-Symbol unten links aktivieren und euren Code wie oben zeigen.

Fazit

Es kann manchmal schwierig sein, einen Breakpoint manuell zu setzen, besonders wenn eure JavaScript-Dateien kompiliert, kombiniert und sogar minifiziert wird und ihr keine Ahnung haben, wo eine Zeile, die ihr gerade geschrieben habt, am Ende zu finden ist. Ihr können das debugger Keyword auch nur vorübergehend setzen, und sobald das Skript angehalten wurde, einen regulären Haltepunkt setzen, um das Schlüsselwort dann sofort zu entfernen, damit ihr nicht versehentlich Code mit dem Keyword darin veröffentlicht.

Das HTML meter Element und wie es funktioniert

Dieser Blogbeitrag behandelt ein Element, das dem progress Element aus einem vorherigen Blogbeitrag sehr ähnlich ist. Es wird verwendet, um eine Art „Füllstand“ wie bei einer Batterie oder eine „Score“ (Punktzahl) wie bei einem Online-Test anzuzeigen. Diese Visualisierungen werden in der Regel durch einen Minimal- und Maximalwert definiert.

Ein einfaches Beispiel für das meter Element

Beginnen wir mit einem sehr einfachen Beispiel, mit nur den Attributen, die mindestens notwendig sind. Die folgenden müssen wir implementieren:

<label for="score">Score:</label>
<meter id="score" value="0.5">50%</meter>

OK, das zugehörige <label> ist optional. Aber vermutlich habe ihr mittlerweile bemerkt, dass ich immer versuche Beispiele zu geben, bei denen die Barrierefreiheit beachtet wird.

Das Element hat ein min Attribut, das standardmäßig auf 0 gesetzt wird, wenn es nicht definiert wurde, während max auf 1 gesetzt wird. Wenn wir sie also nicht definieren, würden wir einen Wertebereich zwischen 0 und 1 verwenden und damit würde unser Wert von 0,5 dann 50% auf dem Zähler darstellen. Das Ergebnis würde dann so aussehen:

A label "Score" followed by the meter element that is half "filled" with a green background.

Ähnlich wie beim <progress> Element sehen wir den „Textknoten“, auf dem „50%“ steht, nicht. Dieser wird nur angezeigt, wenn das Element vom Browser nicht unterstützt wird.

Verwendung der zusätzlichen Attribute, um das Element noch nützlicher zu machen

Beim <progress> Element gab es nur ein max und value Attribut. Das <meter> Element hat viel mehr Attribute und sie machen den großen Unterschied zwischen den beiden Elementen aus. Hier ist ein Beispiel mit allen Attributen, die wir verwenden können:

<meter min="-20" max="100" low="10" high="40" optimum="25" value="10">10°C</meter>

Wir können die Attribute min und max explizit angeben. Das min Attribut ist auch nicht auf 0 festgelegt, sondern kann jeden beliebigen Wert annehmen, auch einen negativen, z. B. für eine Temperaturskala mit Minusgraden. So würde das für verschiedene Temperaturwerte aussehen:

Seven meter elements ranging from -20°C to 100°C with the temperature 10°C, 25°C and 40°C with a green background, the other ones with a yellow background.

Wenn wir einen optimum Wert zwischen dem min und dem max Attributwert festlegen (der Wert kann zwischen 10 und 40 liegen), wird dieser Bereich mit einem grünen Hintergrund dargestellt. Jeder Bereich, der unter dem min Wert oder über dem max Wert liegt, wird gelb dargestellt.

Ein meter Element mit drei verschiedenen Farben

Nehmen wir ein weiteres Beispiel mit einem Test-Score. Wir würden den Test als „bestanden“ definieren, wenn wir 50 % oder mehr erreichen und er wäre „gut“, wenn wir 80 % oder mehr schaffen. Diese Elemente würden unterschiedliche Punktzahlen darstellen:

<meter min="0" max="100" low="50" high="80" optimum="100" value="0">    0%</meter>
<meter min="0" max="100" low="50" high="80" optimum="100" value="10">  10%</meter>
<meter min="0" max="100" low="50" high="80" optimum="100" value="20">  20%</meter>
<meter min="0" max="100" low="50" high="80" optimum="100" value="30">  30%</meter>
<meter min="0" max="100" low="50" high="80" optimum="100" value="40">  40%</meter>
<meter min="0" max="100" low="50" high="80" optimum="100" value="50">  50%</meter>
<meter min="0" max="100" low="50" high="80" optimum="100" value="60">  60%</meter>
<meter min="0" max="100" low="50" high="80" optimum="100" value="70">  70%</meter>
<meter min="0" max="100" low="50" high="80" optimum="100" value="80">  80%</meter>
<meter min="0" max="100" low="50" high="80" optimum="100" value="90">  90%</meter>
<meter min="0" max="100" low="50" high="80" optimum="100" value="100">100%</meter>

In diesem Codebeispiel liegt unser optimum Wert zwischen high und max. Wenn der Wert von optimum größer ist als der Wert von max (wir haben ihn einfach auf 100 gesetzt), erhalten wir drei verschiedene Hintergrundfarben:

Eleven meter elements ranging from 0% to 100%. The background at 0% is not visible and values 10% to 40% have a green red background. Values 50% to 70% have a yellow and values 80% to 100% have a green background.

Das spiegelt unsere Definition der Punktzahl perfekt wider, oder nicht? Wenn ihr euch sich nicht sicher seid, wie ihr die Werte für die Attribute festlegen müsst, schaut in der Dokumentation nach und testet verschiedene Werte in verschiedenen Browsern.

Styling des Elements

Es gibt nur wenige CSS-Eigenschaften, die wir in WebKit-Browsern verwenden können. Safari benötigen sogar einen JavaScript-Hack, damit sie funktionieren. Ihr findet sie im Abschnitt „See more“ der Dokumentation verlinkt.

In Chrome können wir sie mit einem Attributselektor kombinieren, um die Hintergrundfarbe des genauen „optimalen Werts“ für das Temperaturbeispiel wie folgt zu ändern:

meter[value="25"]::-webkit-meter-optimum-value {
	background-color: blue;
}

In Firefox hätte dies jedoch keine Auswirkung. Sobald ihr den Hintergrund des Elements ändern, sieht es völlig anders aus (genau als wenn ihr "appearance: none“ darauf anwendet). Ich euch empfehlen, einfach mal ein wenig mit dem Element zu experimentieren.

Fazit

Das <meter> Element ist wahrscheinlich eines der weniger bekannten Elemente, aber es kann eine nette Ergänzung für eure Benutzeroberfläche sein, um Zahlen besser zu visualisieren. Für das <progress> Element hatten wir die ProgressBar-Komponente für WordPress, aber für <meter> gibt es leider keine Komponente in WordPress.

Bessere Lesbarkeit mit reduzierter Transparenz

Heute möchte ich über eine CSS-Funktion schreiben, die noch experimentell ist. Aber sie kann einen Unterschied für alle machen, die Schwierigkeiten haben, Text auf transparenten Elementen zu lesen.

Auf vielen Websites finden wir Elemente, die Text auf einem Bild platzieren. Dies ist oft ein großes Problem für die Lesbarkeit des Textes.

Text auf einem Bild

Sehen wir uns hierzu ein kleines Beispiel an. WordPress bietet den „Cover“-Block an. Wenn wir ihn verwenden, wird das Bild zu einem Hintergrundbild. Der Block verfügt über ein Steuerelement für die „Overlay-Deckkraft“. Wenn die Deckkraft auf einen Wert von 21 oder weniger eingestellt ist, wird der Text standardmäßig schwarz angezeigt. Wenn der Wert auf 22 oder höher gesetzt ist, wird die Textfarbe auf Weiß umgestellt.

Cliffs in the archipelago of Åland with stones coverd in lichen in the front and the sea (blurred) in the back.

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Wie wir im obigen Beispiel sehen können, ist der Text im oberen Teil schwer zu lesen, selbst wenn man normalerweise keine Probleme mit dem Lesen von Text auf Bildern hat. Für mich als Legastheniker kann das extrem frustrierend sein, Text so zu lesen.

Verwendung einer Präferenz zur Verringerung der Transparenz

Die neue CSS-Eigenschaft, über die ich heute schreiben möchte, heißt prefers-reduced-transparency und verwendet genau wie die Präferenz für reduzierte Bewegungen den Wert reduce. Hier ist ein Beispiel für den Cover-Block:

@media (prefers-reduced-transparency: reduce) {
    .has-background-dim {
        opacity: .7;
    }
}

In einem früheren Blogbeitrag habe ich erklärt, wie man Präferenzen im Browser simulieren kann. Wenn ihr die Rendering-Einstellung bei euch simuliert, dann würde der Cover-Block nach der Änderung der Deckkraft so aussehen:

Cliffs in the archipelago of Åland with stones coverd in lichen in the front and the sea (blurred) in the back.

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Ist das nicht viel besser zu lesen? Die Deckkraft zu ändern, wenn jemand eine geringere Transparenz bevorzugt, ist ziemlich einleuchtend. Aber wie bei jeder anderen Media-Query könnt ihr auch hier beliebige CSS-Eigenschaften verwenden. Anstatt also die Deckkraft zu ändern, könntet ihr auch das Element ändern.

Wie wäre es z.B. damit, den Text unterhalb des Bildes ohne Transparenz und mit schwarzem Text auf weißem Hintergrund zu platzieren? Oder wir richten den Text neben dem Bild aus. Seid kreativ und macht eure Inhalte für Menschen mit unterschiedlichen Präferenzen und Bedürfnissen besser lesbar.

Fazit

Es gibt so viele CSS-Eigenschaften, die unbekannt oder noch nicht weit verbreitet sind. Diese spezielle Eigenschaft kann bereits in Chromium-Browsern verwendet werden und Firefox-Benutzer können ein Flag setzen, um sie zu verwenden. Wenn ihr Windows 10/11, macOS oder iOS verwenden, können ihr diese Präferenz ebenfalls bereits einstellen, wie in der Dokumentation erklärt wird. Angesichts der bereits guten Betriebssystem-Unterstützung würde es mich überraschen, wenn diese neue Media-Query noch lange experimentell bleiben würde.