Zusammenfassung

  • Das W3C genehmigte die neue Charta der Web Performance Working Group am 10. August 2026; sie gilt bis zum 1. August 2028.
  • Neue Funktionen sollen vor der Aufnahme in als Candidate Recommendation gepflegte Spezifikationen Interessenbekundungen von mindestens zwei Implementierern haben.
  • Fehlen diese, darf eine Funktion in einen Candidate Recommendation Draft gelangen, muss aber als at risk gekennzeichnet werden.
  • Für den Schritt über Candidate Recommendation hinaus werden zwei unabhängige interoperable Implementierungen je Funktion und offene Tests erwartet; der allgemeine W3C Process kennt daneben eine öffentlich begründete Ausnahme.
  • Ein funktionsbezogener Evidenzstatus sollte Interesse, WG-Übernahme, Risikohinweis, Implementierungsidentität, Teststand und Übergangsentscheidung getrennt halten.

Warum aus Support Interesse wurde

Ladezeit, Rendering, Interaktionslatenz und Ressourcennutzung sind technische Größen mit unmittelbarer Wirkung auf Nutzer. Die Web Performance Working Group entwickelt dafür Beobachtungs- und Verbesserungsmethoden. Am 10. August gab das W3C die Genehmigung der neuen Charta und den Aufruf zur Teilnahme bekannt. Das Mandat läuft bis zum 1. August 2028.

Zwischen dem Entwurf vom Juni und dem genehmigten Text wurde eine kleine, folgenreiche Formulierung geändert. Aus der Unterstützung von mindestens zwei Implementierern wurden Interessenbekundungen von mindestens zwei Implementierern. Damit beschreibt die Charta genauer, was eine frühe Erklärung tatsächlich belegt.

Ein Unternehmen kann einen Entwurf prüfen, ein Experiment erwägen oder eine technische Option offenhalten, ohne Produktbudget, Liefertermin oder dauerhafte Unterstützung zugesagt zu haben. Diese Haltung ist für die Arbeitsgruppe relevant. Sie zeigt, dass die Frage nicht nur einen Autor interessiert. Sie ist aber kein Testbericht.

Der spätere Maßstab ist ausdrücklich operativ. Jenseits von Candidate Recommendation werden für jede Funktion mindestens zwei unabhängige interoperable Implementierungen erwartet, deren Zusammenspiel sich mit offenen Tests nachweisen lässt. Zusätzlich muss jede Funktion eine offene Testsuite haben. Das erste Signal betrifft Aufmerksamkeit und mögliche Investition; das zweite beobachtbares Verhalten voneinander unabhängiger Systeme.

Ein einziges Support-Feld würde aus zwei Tatsachen eine unprüfbare Behauptung machen.

Inkubation, Übernahme, bedingte Aufnahme, Übergang

Eine Idee kann zunächst in der Web Platform Incubator Community Group reifen. Dort entstehen Anwendungsfälle und Code, ohne dass die Web Performance Working Group bereits die formale Verantwortung übernommen hat.

Die Übernahme durch die WG ist der nächste Zustand. Laut Charta kann ein im WICG inkubierter Vorschlag, der in mindestens einem großen Browser implementiert und verfügbar ist und zusätzliche Unterstützung erhält, von WebPerf übernommen werden. Die Entscheidung ordnet das Vorhaben institutionell zu. Sie beweist keine zweite unabhängige Implementierung.

Danach kann die Funktion in einem Candidate Recommendation Draft erscheinen. Selbst ohne zwei Interessenbekundungen ist dies zulässig, wenn der At-risk-Status vermerkt wird. Der Entwurf darf also weit fortgeschritten sein, während eine einzelne Funktion sichtbar unter Vorbehalt steht.

Erst der weitere Übergang verlangt Implementierungserfahrung. Der W3C Process beschreibt Candidate Recommendation als Phase zur Sammlung dieser Evidenz. Er unterscheidet außerdem CR Draft und CR Snapshot: Der Draft macht beabsichtigte Änderungen prüfbar, der Snapshot besitzt andere Übergangs- und Patentwirkungen. Die Kurzform „in CR“ verrät weder das Dokument noch den Stand der einzelnen Funktion.

Ein grünes Häkchen kann daher eine positive Stellungnahme, einen Prototyp hinter einer Option, einen WG-Beschluss, teilweise Tests oder vollständige Interoperabilität meinen. Ohne Quelle und Zeitpunkt ist es keine belastbare Aussage.

Mozillas öffentliche Antwort hat einen klaren Umfang

Mozilla unterstützte den Chartavorschlag auch für den Fall, dass die vorgeschlagenen Änderungen nicht übernommen würden. Die Organisation befürwortete die geänderte Formulierung zu zwei Implementierern. Sie erklärte außerdem die Absicht, Entwürfe zu prüfen, experimentelle Implementierungen und Erfahrungsberichte zu entwickeln sowie Produkte auf Grundlage der Arbeit zu bauen.

Im öffentlichen Feld für einen Implementierungszeitplan steht kein Datum.

Das ist keine Schwäche, sondern die Grenze der Erklärung. Sie belegt allgemeines Interesse an der Arbeit, nicht zwei funktionsbezogene Zusagen. Weder API noch Browserversion oder Freigabetermin werden genannt. Wer daraus eine fertige Implementierung macht, erweitert den Inhalt ohne Quelle.

Auch die Teilnehmerliste darf nicht als Ersatz dienen. Mitgliedschaft ermöglicht Mitarbeit und Kritik. Sie ist keine pauschale Zustimmung zu jeder Funktion und kein Einblick in interne Produktpläne.

At risk ist kein Todesurteil

Im Alltag klingt at risk nach Scheitern. Im W3C-Verfahren bezeichnet die Markierung enger, dass eine Funktion bei einem späteren Übergang nach dem vorgesehenen Weg entfallen kann. So bleibt Experimentieren möglich, ohne die Reife des Gesamtdokuments auf jede Zeile zu übertragen.

Die Markierung muss an eine konkrete Funktion und Fassung gebunden bleiben. Verschwindet sie später, sollte der Verlauf zeigen, ob weiteres Interesse, eine Implementierung, eine Verkleinerung, eine Entfernung oder nur eine redaktionelle Verschiebung die Ursache war.

Dasselbe gilt für Tests. „Zwei Browser bestehen“ ist ohne Produkt- und Engine-Version, Standardaktivierung, WPT-Revision, Abdeckung und Restfehler unvollständig. Zwei Marken können denselben Codepfad nutzen. Unabhängigkeit braucht eine technische Begründung und darf nicht aus Logos abgeleitet werden.

Eine Ausnahme ist ein eigener Beschluss

Die Charta formuliert die zwei Implementierungen als Erwartung. Der allgemeine W3C Process erlaubt dem Team in einem zwingenden Fall einen Übergang mit minimaler Implementierungserfahrung. Entscheidung und Begründung müssen veröffentlicht werden.

Die Ausnahme hebt den Regelfall nicht auf. Sie erzeugt einen gesonderten Datensatz: entscheidende Stelle, Process-Version, Anwendungsbereich, Evidenz und Grund. Eine offen begründete Ausnahme kann glaubwürdiger sein als zwei formal gezählte, aber kaum unabhängige Implementierungen.

Heng Lus Abgrenzung von Veröffentlichung und Adoption hilft gegen institutionelle Übertreibung: Eine Erklärung ersetzt Implementierung, Validierung und Nutzung nicht. Umgekehrt verleiht laufender Code sich nicht selbst den Status einer W3C Recommendation. Institutioneller Zustand und operative Realität brauchen unterschiedliche Quellen in derselben Übersicht.

Der funktionsbezogene Evidenzstatus

Charta, Spezifikationen, Issues, Tests, Beschlüsse und Veröffentlichungsseiten existieren bereits. Verbunden werden sollten:

  • stabile Funktionskennung und unveränderliche Spezifikationsrevision;
  • anwendbare Charta- und Process-Version;
  • jede öffentliche Interessenbekundung mit Implementierer, Datum, Umfang und Quelle;
  • experimenteller, geplanter, implementierter, zurückgezogener oder undatierter Charakter der Erklärung;
  • WG-Übernahmebeschluss und übernommene Vorschlagsfassung;
  • URI und Historie der At-risk-Markierung;
  • Produkt, Engine und Version jeder Implementierung sowie Begründung ihrer Unabhängigkeit;
  • Revision der offenen Testsuite, Abdeckung und datierte Ergebnisse;
  • Übergang, Einwände und veröffentlichte Ausnahme;
  • nächste Prüfung, Korrektur und Ablösung.

Vertrauliche Roadmaps oder proprietärer Code müssen nicht offengelegt werden. Eine Interessenbekundung ohne Termin soll genau das bleiben und nicht auf dem Weg durch mehrere Webseiten zu einem Liefervertrag werden.

Die Charta bietet bereits die richtige Unterscheidung. Nun müssen Kompatibilitätslisten, Beschaffung und öffentliche Kommunikation sie bewahren.

Quellen

  1. W3C — Genehmigung der Charta und Aufruf zur Teilnahme
  2. W3C — genehmigte Charta der Web Performance Working Group
  3. W3C — Vergleich von Entwurf und genehmigtem Text
  4. W3C — öffentliche Ankündigung der Chartaprüfung
  5. Öffentliches W3C-Archiv — Mozillas Antwort
  6. W3C — Process Document
  7. W3C — Veröffentlichungen der Web Performance Working Group
  8. W3C — Web Performance Working Group
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption