Die CSS-Arbeitsgruppe bei TPAC: Was ist neu in CSS?

Letzte Woche habe ich sowohl am W3C TPAC als auch am dortigen Treffen der CSS-Arbeitsgruppe teilgenommen. Es wurden verschiedene Änderungen an den Spezifikationen vorgenommen und Diskussionen geführt, die meines Erachtens für Webdesigner und Entwickler von Interesse sind. In diesem Artikel erkläre ich ein wenig, was bei TPAC passiert, und zeige einige Beispiele und Demos der Dinge, die wir bei TPAC insbesondere für CSS besprochen haben.

Was ist TPAC?

TPAC ist die Sitzungswoche des Technischen Plenums/Beratungsausschusses des W3C. Eine Chance für all die verschiedenen Arbeitsgruppen, die Teil des W3C sind, unter einem Dach zusammenzukommen. Die Veranstaltung findet jedes Jahr in einem anderen Teil der Welt statt, dieses Jahr fand sie in Lyon, Frankreich, statt. Bei TPAC haben Arbeitsgruppen wie die CSS-Arbeitsgruppe ihre eigenen Treffen, genau wie wir es zu anderen Zeiten des Jahres tun. Da wir uns aber alle in einem Gebäude befinden, können Leute aus anderen Gruppen leichter als Beobachter kommen und arbeitsgruppenübergreifende Interessen diskutiert werden.

Teilnehmer des TPAC sind in der Regel Mitglieder einer oder mehrerer Arbeitsgruppen, die an W3C-Technologien arbeiten. Sie sind entweder Vertreter einer Mitgliedsorganisation oder eingeladene Experten. Wie bei allen anderen Treffen von W3C-Arbeitsgruppen werden die Protokolle aller Diskussionen, die bei TPAC abgehalten werden, offen verfügbar sein, normalerweise als IRC-Protokolle, die während der Treffen geschrieben werden.

Die CSS-Arbeitsgruppe

Die CSS-Arbeitsgruppe trifft sich persönlich bei TPAC und bei mindestens zwei weiteren Gelegenheiten im Jahr; Dies ist zusätzlich zu unseren wöchentlichen Telefonaten. Bei allen unseren Sitzungen werden die verschiedenen Fragen zu den Spezifikationen diskutiert und Entscheidungen getroffen. Einige Themen werden für persönliche Diskussionen aufbewahrt, da es vorteilhaft ist, sie mit der gesamten Gruppe zu besprechen oder einfach alle um ein Whiteboard herumzukommen oder eine Demo auf dem Bildschirm zu sehen.

Wenn ein Problem in einem Meeting besprochen wird (ob persönlich oder per Telefonkonferenz), wird das relevante GitHub-Problem mit dem Diskussionsprotokoll aktualisiert. Das bedeutet, wenn Sie ein Problem haben, das Sie verfolgen möchten, können Sie es markieren und sehen, wann es aktualisiert wird. Die vollständigen IRC-Protokolle werden auch auf der Mailingliste im Stil von www veröffentlicht.

Hier ist eine Auswahl der Dinge, die wir besprochen haben und die meiner Meinung nach für Sie am interessantesten sein werden.

CSS-Bildlaufleisten

Die CSS Scrollbars-Spezifikation versucht, eine Standardmethode zum Gestalten der Größe und Farbe von Bildlaufleisten bereitzustellen. Wenn Sie Firefox Nightly haben, können Sie es ausprobieren. Um die folgenden Beispiele anzuzeigen, verwenden Sie Firefox Nightly und aktivieren Sie die Flags layout.css.scrollbar-width.enabled und layout.css.scrollbar-color.enabled , indem Sie https://about:config in Firefox Nightly aufrufen.

Die Spezifikation gibt uns zwei neue Eigenschaften: scrollbar-width und scrollbar-color . Die Eigenschaft scrollbar-width kann einen Wert von auto , thin , none oder length annehmen (z. B. 1em ). Es sieht so aus, als ob der length aus der Spezifikation entfernt werden könnte. Wie Sie sich vorstellen können, wäre es für einen Webentwickler möglich, eine sehr unbrauchbare Bildlaufleiste zu erstellen, indem er mit der Breite spielt. Daher ist es möglicherweise besser, dem Browser die Entscheidung über die genaue Breite zu überlassen, die sinnvoll ist, und stattdessen entweder dünn oder dick anzuzeigen Bildlaufleisten. Firefox hat die Längenoption nicht implementiert.

Wenn Sie auto als Wert verwenden, verwendet der Browser die Standard-Bildlaufleisten: thin gibt Ihnen eine dünne Bildlaufleiste und none zeigt keine sichtbare Bildlaufleiste (aber das Element ist immer noch scrollbar).

In einem Browser mit Unterstützung für CSS-Bildlaufleisten können Sie dies in der Demo in Aktion sehen:

Die Eigenschaft scrollbar-color behandelt – wie zu erwarten – die Farben der Scrollbars. Eine Bildlaufleiste besteht aus zwei Teilen, die Sie möglicherweise unabhängig voneinander einfärben möchten:

• Daumen
  Der Schieberegler, der sich beim Scrollen nach oben und unten bewegt.
• Spur
  Der Hintergrund der Bildlaufleiste.

Die Werte für die Eigenschaft scrollbar-color sind auto , dark , light und <color> <color> .

Wenn Sie auto als Schlüsselwortwert verwenden, erhalten Sie die Standardfarben der Bildlaufleiste für diesen Browser, dark stellt eine dunkle Bildlaufleiste bereit, entweder im dunklen Modus dieser Plattform oder in einem benutzerdefinierten dunklen Modus, light im hellen Modus der Plattform oder in einem benutzerdefinierten hellen Modus .

Um Ihre eigenen Farben festzulegen, fügen Sie zwei Farben als Wert hinzu, die durch ein Leerzeichen getrennt sind. Die erste Farbe wird für den Daumen und die zweite für die Spur verwendet . Es sollte darauf geachtet werden, dass genügend Kontrast zwischen den Farben vorhanden ist, da sonst die Bildlaufleiste für manchen schwer zu bedienen ist.

In einem Browser mit Unterstützung für CSS Scrollbars können Sie dies in der Demo sehen:

Seitenverhältniseinheiten

Wir verwenden den Padding-Hack in CSS seit einiger Zeit, um Seitenverhältnis-Boxen zu erreichen, aber mit dem Aufkommen des Grid-Layouts und besseren Möglichkeiten zur Größenanpassung von Inhalten ist es zu einem dringenderen Bedürfnis geworden, eine echte Möglichkeit zu haben, Seitenverhältnisse in CSS zu erstellen .

Auf GitHub wurden zwei Probleme gemeldet, die sich auf diese Anforderung beziehen:

• Seitenverhältniseinheiten erforderlich
• Seitenverhältnis.

Es gibt jetzt einen Entwurf einer Spezifikation in Level 4 von CSS Sizing, und die Entscheidung des Treffens war, dass dies eine weitere Diskussion auf GitHub benötigt, bevor Entscheidungen getroffen werden können. Wenn Sie also daran interessiert sind oder weitere Anwendungsfälle haben, wäre die CSS-Arbeitsgruppe an Ihren Kommentaren zu diesen Themen interessiert.

Die :where() Functional Pseudo-Klasse

Letztes Jahr beschloss die CSSWG, eine Pseudo-Klasse hinzuzufügen, die sich wie :matches() verhält, aber keine Spezifität aufweist, wodurch es einfach zu überschreiben ist, ohne die Spezifität späterer Elemente künstlich aufzublähen, um etwas in einem Standard-Stylesheet zu überschreiben.

Die :matches() ist vielleicht neu für Sie, da es sich um einen Level-4-Selektor handelt, Sie können jedoch eine Gruppe von Selektoren angeben, auf die CSS angewendet werden soll. Du könntest zum Beispiel schreiben:

 .foo a:hover, pa:hover { color: green; }

Oder mit :matches()

 :matches(.foo, p) a:hover { color: green; }

Wenn Sie jemals einen großen Stapel von Selektoren hatten, nur um die gleichen Regeln festzulegen, werden Sie sehen, wie nützlich dies sein wird. Der folgende CodePen verwendet die vorangestellten Namen webkit-any und -moz-any , um die match matches() Funktionalität zu demonstrieren. Sie können auch mehr über matchs() auf MDN lesen.

Wo wir diese Art des Stapelns von Selektoren oft durchführen und wo :matches() daher am nützlichsten ist, ist in einer Art anfänglichem Standard-Stylesheet. Beim Überschreiben dieser Standardwerte müssen wir dann jedoch darauf achten, dass das Überschreiben so erfolgt, dass es spezifischer ist als die Standardwerte. Aus diesem Grund wurde eine Null-Spezifitäts-Version vorgeschlagen.

Das Problem, das in dem Meeting diskutiert wurde, betraf die Benennung dieser Pseudo-Klasse, Sie können die endgültige Lösung hier sehen, und wenn Sie sich fragen, warum verschiedene Namen ausgeschlossen wurden, sehen Sie sich den vollständigen Thread an. Dinge in CSS zu benennen ist sehr schwierig – weil wir alle ewig damit leben müssen! Nach vielen Diskussionen stimmte die Gruppe ab und entschied sich, diesen Selektor :where() zu nennen.

Seit dem Treffen und während ich diesen Beitrag verfasste, wurde vorgeschlagen, matchs matches() in is() umzubenennen. Schauen Sie sich das Problem an und kommentieren Sie, wenn Sie starke Gefühle haben!

Logische Abkürzungen für Ränder und Polsterung

Zum Thema Benennen von Dingen habe ich in der Vergangenheit hier im Smashing Magazine über logische Eigenschaften und Werte geschrieben, werfen Sie einen Blick auf „Logische Eigenschaften und Werte verstehen“. Diese Eigenschaften und Werte stellen flussrelative Zuordnungen bereit. Das bedeutet, dass, wenn Sie andere Schreibmodi als einen horizontalen Schreibmodus von oben nach unten verwenden, wie z. B. Englisch, Dinge wie Ränder und Auffüllung, Breite und Höhe der Textrichtung folgen und nicht mit den physischen Bildschirmabmessungen verknüpft sind.

Zum Beispiel haben wir für physische Margins:

• margin-top
• margin-right
• margin-bottom
• margin-left

Die logischen Zuordnungen für diese (unter der Annahme von horizontal-tb) sind:

• margin-block-start
• margin-inline-end
• margin-block-end
• margin-inline-start

Wir können zwei Wertkürzel haben. Um beispielsweise margin-block-start und margin-block-end als Kürzel festzulegen, können wir margin-block: 20px 1em . Der erste Wert stellt die Startkante in der Blockdimension dar, der zweite Wert die Endkante in der Blockdimension.

Wir stoßen jedoch auf ein Problem, wenn wir zu der Shorthand- margin mit vier Werten kommen. Dieser Eigenschaftsname wird für physische Ränder verwendet – wie bezeichnen wir die logische Version mit vier Werten? Es wurden verschiedene Dinge vorgeschlagen, einschließlich eines Schalters am Anfang der Datei:

 @mode "logical";

Oder um einen Block zu verwenden, der ein wenig wie eine Medienabfrage aussieht:

 @mode (flow-mode: relative) { }

Dann verschiedene Vorschläge für Keyword-Modifikatoren, die Verwendung einiger Satzzeichen oder die Erstellung eines brandneuen Eigenschaftsnamens:

 margin: relative 1em 2em 3em 4em; margin: 1em 2em 3em 4em !relative; margin-relative: 1em 2em 3em 4em; ~margin: 1em 2em 3em 4em;

Sie können die Ausgabe lesen, um die verschiedenen Dinge zu sehen, die in Betracht gezogen werden. Die diskutierten Probleme waren, dass, obwohl die logische Version im Allgemeinen die Standardversion sein kann, Sie manchmal möchten, dass sich die Dinge auf die Bildschirmgeometrie beziehen. Wir müssen in der Lage sein, beide Optionen in einem Stylesheet zu haben. Eine @mode Einstellung oben im CSS könnte verwirrend sein; Es würde fehlschlagen, wenn jemand einen Teil des Stylesheets kopieren und einfügen würde.

Ich bevorzuge eine Art Keyword-Wert. Auf diese Weise können Sie, wenn Sie sich die Regel ansehen, genau sehen, welcher Modus verwendet wird, auch wenn es etwas unelegant erscheint. So etwas könnte ein Präprozessor für Sie erledigen; wenn Sie tatsächlich wollten, dass alle Ihre Eigenschaften und Werte die logischen Versionen verwenden.

Wir konnten das Problem nicht lösen. Wenn Sie also darüber nachdenken, welche davon am besten geeignet sind, oder Probleme mit ihnen sehen, die wir nicht beschrieben haben, kommentieren Sie das Problem bitte auf GitHub.

Diskussion über Webplattformtests

Beim Treffen der CSS-Arbeitsgruppe und dann während des technischen Plenartags im Stil einer Unconference war ich an der Diskussion beteiligt, wie man mehr Leute dazu bringen kann, Tests für CSS-Spezifikationen zu schreiben. Das Projekt Web Platform Tests zielt darauf ab, Tests für die gesamte Webplattform bereitzustellen. Diese Tests helfen dann Browserherstellern zu überprüfen, ob ihr Browser die Spezifikation erfüllt. In der CSS-Arbeitsgruppe ist es das Ziel, dass jede normative Änderung einer Spezifikation, die den Status einer Kandidatenempfehlung (CR) erreicht hat, von einem Test begleitet werden sollte. Dies ist sinnvoll, da wir, sobald eine Spezifikation in CR ist, die Browser bitten, diese Spezifikation zu implementieren und Feedback zu geben. Sie müssen wissen, ob sich etwas in der Spezifikation ändert, damit sie ihren Code aktualisieren können.

Das Problem ist, dass wir nur sehr wenige Leute haben, die Spezifikationen schreiben, also wird es den Fortschritt von CSS verlangsamen, wenn Spezifikationenschreiber alle Tests schreiben müssen. Wir würden gerne sehen, wie andere Leute Tests schreiben, da dies eine Möglichkeit ist, zur Webplattform beizutragen und tiefes Wissen darüber zu erlangen, wie Spezifikationen funktionieren. Also trafen wir uns, um darüber nachzudenken, wie wir Menschen ermutigen könnten, sich an den Bemühungen zu beteiligen. Ich habe in der Vergangenheit über dieses Thema geschrieben; Wenn Sie die Idee, Tests für die Plattform zu schreiben, interessiert, werfen Sie einen Blick auf meinen 24-Wege-Artikel zum Thema „Testen der Webplattform“.

Weiter mit der Arbeit!

TPAC hat meine persönliche To-Do-Liste erheblich erweitert. Ich konnte jedoch Tipps zum Bearbeiten von Spezifikationen und zum Schreiben von Tests sammeln und einen Plan entwickeln, um die Multi-Column-Layout-Spezifikation – deren Mitherausgeber ich bin – wieder in den CR-Status zu versetzen. Als jemand, der kein Fan von Meetings ist, habe ich festgestellt, wie wertvoll diese persönlichen Meetings für die Webplattform sind, da sie denen von uns, die dazu beitragen, die Möglichkeit geben, das Wissen zu teilen, das wir individuell entwickeln. Ich halte es jedoch für wichtig, dieses Wissen dann zu nutzen und es außerhalb der Gruppe zu teilen, um mehr Menschen zu helfen, sich an der Entwicklung und Nutzung der Plattform zu beteiligen.

Wenn Sie daran interessiert sind, wie die CSS-Arbeitsgruppe funktioniert und wie neues CSS erfunden wird und in Browsern landet, sehen Sie sich meine CSSConf.eu-Präsentation 2017 „Woher kommt CSS?“ an. und die Informationen von fantasai in ihren Beiträgen „An Inside View of the CSS Working Group at W3C“.