Der folgende Beitrag ist ein Gastbeitrag von Sebastian Ekström (@seb_ekstrom), einem Webentwickler aus Schweden. Ich war daran interessiert, weil wir hier viel über CSS reden, aber nie darüber, wie CSS entsteht. CSS ist nur eine Syntax, die von Menschen wie Ihnen und mir erfunden wurde, um Probleme zu lösen. Es ist eine extrem komplizierte Sache, die beinhaltet: Benutzerfreundlichkeit, Abwärtskompatibilität, die Fähigkeit von Browsern, mit zufriedenstellender Geschwindigkeit zu implementieren, Abdeckung von Anwendungsfällen, Versuch, die Zukunft dessen, was benötigt wird, und wie Dinge verwendet werden könnten, vorherzusehen und mehr. Wie wir alle wissen, tun schlechte Entscheidungen weh und tun lange weh. Deshalb gibt es einen Prozess. Hier ist Sebastians Einführung in diesen Prozess. Ich hatte Tab Atkins, ihn vor der Veröffentlichung zu überprüfen und zu kommentieren.
Wie wird eine neue CSS-Eigenschaft standardisiert? Wer trifft die Entscheidungen? Warum sollte mich der Standardisierungsprozess interessieren? Was hat es mit dem Essen im Flugzeug auf sich? Das und noch mehr werde ich in diesem Beitrag behandeln.
Hintergrund
Die Standardisierung von CSS wird von der W3C Cascading Style Sheets Working Group (CSSWG) verwaltet, die heute aus 98 Mitgliedern von Browser-Anbietern, Universitäten, größeren Unternehmen und unabhängigen CSS-Experten besteht. Diese Gruppe wird von Peter Linss und Daniel Glazman organisiert, die die Treffen der CSSWG koordinieren und sicherstellen, dass die Diskussionen relevant sind und vorangetrieben werden.
Die Kommunikation und Entscheidungsfindung in der CSSWG erfolgt auf verschiedene Weise. Diskussionen über Spezifikationen laufen kontinuierlich per E-Mail und Telefonkonferenzen, und sie haben jährliche Treffen, bei denen sie sich persönlich sehen.
Die Entscheidungsfindung basiert auf Konsens. Diskussionen werden geführt, bis alle Mitglieder dem Thema zugestimmt haben, danach wird eine endgültige Entscheidung über die Erstellung einer neuen Spezifikation getroffen.
Der Standardisierungsprozess besteht im Allgemeinen aus sechs Phasen, von denen zwei Übergangsphasen sind.
1. Editor's Draft (ED)
Beispiel: Farben (Level 4)
Dies ist die Anfangsphase einer Spezifikation. Eine Idee für eine neue CSS-Eigenschaft oder einen neuen Selektor wird spezifiziert und intern von der CSSWG bearbeitet. Dies ist eine Phase, in der viel mit einer Spezifikation passieren kann. Und wenn die Gruppe zustimmt, dass dies offiziell veröffentlicht werden soll, geht es zum nächsten Schritt.
Editor's Note: CSS-Module kommen in verschiedenen Stufen. "CSS3" ist kaum etwas, es ist nur "alles nach 2.1". CSS4 ist kein Ding. Von nun an werden Module Level haben und diesen Prozess unabhängig von anderen Modulen durchlaufen.
2. Working Draft (WD)
Beispiel: Animationen
Nach dem Editor's Draft folgt der Working Draft, die Designphase einer Standardisierung. Die Gruppe arbeitet iterativ mit einer Spezifikation und erhält Feedback von internen und externen Stellen. Das Ergebnis dieser Phase ist entweder, dass die Spezifikation vollständig abgelehnt wird, aufgrund technischer Schwierigkeiten oder anderer aufgetretener Probleme. Wenn die Spezifikation andererseits diese Phase besteht, wird sie als First Public Working Draft (FPWD) veröffentlicht. Eine grobe Version der Spezifikation, die anzeigt, dass die CSSWG weiter daran arbeiten wird.
3. Übergang – Last Call Working Draft (LCWD)
Beispiel: Text
Dies ist die erste Übergangsphase. Wenn die Spezifikation als bereit erachtet wird, um vom Working Draft zur nächsten Phase zu gelangen, wird eine Frist für das letzte mögliche Feedback für kleinere Änderungen festgelegt.
Editor's Note: Tab sagt mir, dass diese Übergangsphasen (siehe auch #5) eher unbedeutend sind. Die wichtigsten Phasen sind ED, WD und CR.
4. Candidate Recommendation (CR)
Beispiel: Hintergründe und Rahmen und Flexbox
Hier wird die Spezifikation gründlich getestet, sowohl von der CSSWG als auch von Browser-Anbietern (Chrome, Safari, Firefox, Opera usw.), die sich entscheiden, diese Spezifikation zu implementieren. Was meistens passiert, wenn sie dieses Stadium erreicht. Um zum nächsten Stadium zu gelangen, muss die CSSWG zwei korrekte Implementierungen der Spezifikation nachweisen.
5. Übergang – Proposed Recommendations (PR)
Beispiel: Aktuell kein Modul in PR
Wenn dieses Stadium erreicht ist, entscheidet das W3C Advisory Committee, das als globale Beratungsgruppe des W3C fungiert, ob die Spezifikation fortgesetzt werden soll oder nicht, bis zum letzten Stadium.
6. Recommendation (REC)
Beispiel: Farbe.
Wenn eine Spezifikation diesen Schritt erreicht, gilt sie als abgeschlossen und ist bereit für die Implementierung durch Browser-Anbieter. Die W3C und die CSSWG arbeiten nicht mehr aktiv an der Spezifikation und führen nur noch geringfügige Wartungsarbeiten durch, falls erforderlich.
Editor's Note: Es stellt sich heraus, dass der Recommendation-Status eher ein Friedhof als ein Idealzustand ist. Browser implementieren im Candidate Recommendation-Stadium. Tab Atkins klärt auf.
Bis eine Spezifikation REC erreicht, ist sie eigentlich tot, nicht stabil. Wahrscheinlich haben sich Fehler angehäuft, die nicht behoben wurden, weil die Aktualisierung von RECs eine ziemliche Qual ist. Neue Versionen der Spezifikation könnten bereits in Entwicklung sein, das Feature selbst könnte gestorben sein, usw.
Warum sollte ich mich darum kümmern?
Warum sollte man sich für den Standardisierungsprozess interessieren? Ich denke, es ist wichtig zu wissen, wie sich eine Spezifikation in ihren verschiedenen Phasen verhalten kann und welche Konsequenzen es haben kann, wenn man sie zu früh verwendet.
Wir erinnern uns alle daran, wie die Gradient-Eigenschaft Dinge durcheinanderbrachte, als keine Einigung über die Syntax erzielt werden konnte. Dies war die alte Syntax vom Anfang 2011, als die Spezifikation im Working Draft war.
background-image: -webkit-gradient(linear, 0 100%, 0 0, from(fuchsia), to(yellow));Siehe den Pen iKmjh von sebastianekstrom (@sebastianekstrom) auf CodePen
Später, als die Spezifikation Candidate Recommendation erreichte, wurde die Syntax zu dieser geändert:
background-image: -webkit-linear-gradient(fuchsia, yellow);
background-image: linear-gradient(fuchsia, yellow);Was ein völlig anderes Ergebnis produzierte:
Siehe den Pen gJCzd von sebastianekstrom (@sebastianekstrom) auf CodePen
Editor's Note: Die Stabilität eines Features ist tatsächlich nicht so stark an die Stufe im Standardisierungsprozess gebunden, wie man denken könnte. Tab Atkins sagte dazu:
Stabilität hat im Grunde keine Beziehung zu den Prozessstufen, zumindest bis zum Candidate Recommendation. Ein Feature ist stabil, wenn es ausgeliefert wurde und aufgrund von Abwärtskompatibilität nicht mehr geändert werden kann. Das kann einem Feature in einem Editor's Draft einer Spezifikation passieren. Und einige Candidate Recommendations enthalten nicht implementierte (und damit instabile) Features. Das ist das richtige Maß für Stabilität, nicht die Stufe, auf der es sich im W3C-Prozess befindet.
Schlusswort
Wenn Sie also eine neue, topaktuelle Eigenschaft verwenden möchten, prüfen Sie, in welcher Phase sich diese Spezifikation befindet. Working Draft? Ich würde es mit Vorsicht angehen. Candidate Recommendation? Ich sage, legen Sie los, aber behalten Sie Änderungen im Auge.
Im Zweifelsfall empfehle ich Ihnen, sich diese Frage zu stellen: „Werden die Dinge auseinanderfallen, wenn das nicht funktioniert?“
Werden Funktionalität oder Verfügbarkeit beeinträchtigt, wenn ein implementiertes Feature aufgrund von Syntaxänderungen nicht mehr funktioniert? Es ist nicht das Ende der Welt, wenn Ihre Schaltflächen keine abgerundeten Ecken mehr haben. Aber wenn Ihre neue Website vollständig auf einem neuen Layoutsystem basiert und sich die Syntax ändert, dann haben Sie ein Problem.
Gibt es eine einfache Möglichkeit, Eigenschaften, ihren Übergangszustand und wichtige Änderungen an den verwendeten zu sehen?
Eine Tabelle wäre großartig, aber ich glaube nicht, dass es so einfach sein wird. (
Das ist so ziemlich das, wonach Sie suchen. Ansonsten müssen Sie in der Spezifikation der Eigenschaften nachsehen.
Ich finde diese Seite ziemlich nützlich.
Ihr Text zum Verlinken hier…
Zeigt den Status von CSS3, HTML5, SVG und mehr an. Listet auf, ob sie Release Candidates, Working Drafts sind und enthält auch Tabellen zur Unterstützung in den wichtigsten Desktop- und Mobilbrowsern.
Ich frage mich, warum der sogenannte „CSS Snapshot“, der als „Latest stable CSS“ gekennzeichnet ist und so etwas wie eine formale Definition von CSS enthält, nur den Status „Group Note“ hat (soweit ich weiß, bedeutet dies, dass das Dokument nicht nur eine tote Spezifikation, sondern gar keine Spezifikation ist) und seit fast 3 Jahren nicht mehr aktualisiert wurde. Ich nehme an, es wäre schön, wenn dieses Dokument den tatsächlichen Zustand von CSS jederzeit widerspiegeln würde, mit leicht zugänglichen Listen von implementierungsbereiten und produktionsbereiten Spezifikationen an einem Ort und kontinuierlich durch ein „Living Standard“-Modell aktualisiert würde.
Woher erfahren wir von neuen CSS-Eigenschaften, die sich im Working Draft befinden?
Hallo Chris, du hast uns zum Ursprung (Anfang der Dinge) gebracht. Es ist sehr wichtig, diese Fakten zu kennen, wie du gesagt hast: "Werden die Dinge auseinanderfallen, wenn das nicht funktioniert?" Ich bin nur neugierig, wie die ganze Webwelt in den nächsten 10 Jahren aussehen wird. Darf ich das auf meiner Blog-Beratungswebsite für meine Leser und Lernenden veröffentlichen, damit sie den Ursprung verstehen?
Kannst du das in voller Länge auf deiner eigenen Website wieder posten? Das kannst du, aber das ist irgendwie unhöflich. Kannst du von deinem Blog darauf verlinken? Klar, und dafür brauchst du nicht wirklich meine Erlaubnis. Ich habe auch die doppelten Links entfernt, die du in deinem Kommentar für „Blog-Beratungswebsite“ hattest. Das kommt auch irgendwie unhöflich und nach SEO-Spam rüber. Nur ein paar Tipps für dein Blog-Beratungsgeschäft.
Ich habe es nirgendwo im Artikel gesehen, aber es sollte erwähnt werden, dass die CCSWG eine öffentliche Mailingliste hat, die jeder abonnieren kann* (und teilnehmen kann, wenn er möchte).
* Es lohnt sich absolut, meiner Meinung nach; aber beachte, dass es in der Größenordnung von 600 – 1.000 E-Mails pro Monat liegt.
Tabs Aussage, dass eine Recommendation „tot“ ist, ist eine Perspektive. Es ist tatsächlich schwierig, eine Recommendation zu ändern, aber das ist auch der Sinn der Sache. Sie wird zu einer stabilen Referenz, im Gegensatz zu einer Candidate Recommendation, die sich für einen Entwickler unter den Füßen verschieben kann, wenn jemand zeigt, dass etwas daran in der Praxis nicht funktioniert.
Insbesondere müssen zusätzlich zur Arbeit der Identifizierung, was geändert werden muss, ein paar Entwürfe veröffentlicht werden, und die Vorbereitung eines Entwurfs kann mindestens eine Stunde dauern. Normalerweise muss die Gruppe auch den W3C-Direktor davon überzeugen, dass die Recommendation bearbeitet werden muss, was oft ein Treffen von 30-60 Minuten erfordert.
Aber die normale Praxis ist, eine nächste Version zu erstellen, die mehr Features enthält. Und wenn sie etwas auf eine Weise ändert, die eine bestehende Recommendation ungültig macht, ist es gute Praxis, gleichzeitig eine bearbeitete Version dieser Recommendation zu erstellen.
(Wenn Sie vom W3C-Prozess wirklich fasziniert sind, beachten Sie, dass sie die Details etwas ändern wollen und die Diskussion für die Öffentlichkeit offen ist, sowohl zum Lesen als auch zur aktiven Teilnahme, über die W3Process Community Group)
Danke, das ist ziemlich nützlich, es war ziemlich interessant zu sehen, wer die Entscheidungen trifft. Gute Idee, den Status neuer Features zu prüfen, bevor man sie implementiert. Das werde ich von nun an tun! :)