Daniel Glazman (Co-chairman of the W3C CSS Working Group): CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*


Hintergrund:

W3C CSS WG, www-style mailinglist (07.02.2006): [CSSWG] Minutes and Resolutions Paris F2F Monday Morning 2012-02-06: Administrivia, Vendor Prefixes, Property/Value Alias OM (Abschnitt Vendor Prefixes)

W3C CSS WG, www-style mailinglist (07.02.2006): Vendor Prefixes and Generic Prefixes: who shall use which when and why?

Daniel Glazmans Aufruf zieht weitere Kreise (was gut ist und von diesem beabsichtigt ist) -- nun hat auch heise online das Thema aufgegriffen:

heise (09.02.2012): WebKit-Dominanz bedroht das offene Web

In Zeiten von SOPA, PIPA, ACTA und NDAA muss ich zugeben, dass das für mich keine Bedrohung ist.

Schens:

Mag sein. Abgesehen davon: schon mal in diesem Zusammenhang zur Kenntnis genommen, wie die beiden Unternehmen Apple und Microsoft zum Thema SOPA und ACTA stehen? Auffälligerweise sind die nämlich nicht unter der eindrucksvoll großen Phalanx, einem Who-is-who der Internet-Branche und von Internet-Pionieren zu finden, die unter Protest aufgestanden und sich öffentlich und vor dem US Kongress -- mit vorläufigem Erfolg -- gegen ACTA und PIPA eingesetzt und dagegengestellt haben...

Natürlich nicht. Warum auch? Im Gegensatz zu Google und co. betreiben die keine CGM Portale (wie YouTube) die dadurch gefährdet wären, sondern verkaufen selber Inhalte. Sie würden also eher davon profitieren.

Und zum Thema: Ich seh da jetzt auch keinen Grund zur Panik. Und wenn überhaupt ist wohl eher das W3C schuld, da die so ewig lange brauchen um mal endlich neue Standards zu verabschieden. Und es geht da hauptsächlich um ein paar Eye-Candy CSS styles, wenn die nicht gehen wird da nicht direkt eine ganze Internetseite unbrauchbar von (Im Gegensatz zu den zitierten IE6 "optimierten" Seiten).

ChrisK

Dann schau Dir einmal an, WER dagegen alles aufgestanden ist. Und wer sitzengeblieben ist. Deine Vermutung geht in die falsche Richtung. Es geht ums Grundsätzliche, ums Eingemachte sozusagen. SOPA und ACTA berühren die grundsätzliche Freiheit im Internet.
Das sehen die Unterzeichner (darunter Amerikas führende Forscher- und Wissenschaftselite im Bereich Internet, darunter auch die Gründungsväter des Internets) und die, die sich teilweise persönlich aufgemacht haben und beim US-Kongress in personam vorstellig geworden sind, grundlegend anders als Du.
Und wie man feststellen kann, hat dieser Proteststurm wohl auch Wirkung gezeigt: ACTA und PIPA sind vorerst politisch auf Eis gelegt bzw. vorerst gescheitert.

Den von mir verlinkten Diskussions-Thread der CSS Arbeitsgruppe hast Du gelesen und Dich mit den dort vorgebrachten Argumenten der Diskutanten auseinandergesetzt bzw. die an Dich rangelassen?

Abgesehen davon, dass Du anscheinend, wie leider so viele, nicht weißt, wie und auf welche Weise die Mühlen innerhalb des W3C bezüglich der formalen Stati und Abläufe bei einem Standardisierungsprozess laufen und Du deshalb falsche und unzutreffende Schlüsse ziehst: damit hat das Ganze null und nichts zu tun.

Lies Dir mal, wenn Du schon die engl.-sprachige Diskussion der CSS-Arbeitsgruppe und den darauf basierenden Glazman-Aufruf nicht gelesen hast und nicht nachvollziehen kannst, die diesbzgl. deutschsprachige Berichterstattung unter Golem durch, die beschreibt's ebenfalls treffend und etwas ausführlicher als der heise-Artikel.

Es geht ausdrücklich darum, was da draußen geschrieben und praktiziert wird von Webautoren und -entwicklern! Mit dem W3C hat das nix zu tun.

Nein, geht es nicht.

Da Du falsch liegst und anscheinend nicht begriffen hast, worum es geht: wird es sehr wohl! Lies bitte wenigstens den Golem-Artikel. Vielleicht verstehst Du danach besser, worum es geht. Und wenn Du es danach immer noch nicht begriffen hast, dann erkläre ich es Dir gerne nochmal in meinen Worten. Mit Beispiel.

Es geht darum, dass es unwissende / faule / ignorante WebdesignerInnen gibt, die Features, die noch nicht vom W3C ratifiziert sind, ohne crossbrowser-code nutzen.

Dass die Prefixe keine soo gute Idee waren, sieht W3C jetzt.

Mit der Internet Explorer Problematik ist das nur insofern vergleichbar, als dass auch dort unwissende / faule / ignorante WebdesignerInnen statt fuer alle zugänglich zu sein, Sperren fuer bestimmte Browser eingebaut haben.

IMHO ist es schon ein grosser Unterschied, ob proprietaerere Features entwickelt werden (blink) oder ob noch nicht ratifizierte Standards schon umgesetzt werden (prefixes).

Insofern sind Headlines wie "WebKit-Dominanz bedroht das offene Web" zwar reisserisch, aber falsch. Es muesste heissen "Schlechte Webdesigner bedrohen das offene Web".

Das ist eine falsche Schlussfolgerung Deinerseits und gibt den Sachverhalt nicht richtig wieder. Dass es solche Prefixe gibt, die sogar in der CSS-Spezifikation ausdrücklich genannt und erlaubt sind, ist gut! Das ist gewollt und auch nach wie vor gewollt! Auch jetzt! Wenn Du Dir das von mir oben verlinkte Gesprächsprotokoll der CSS-Arbeitsgruppe durchliest, in dem die Verantwortlichen das Problem miteinander erörtern, wirst Du feststellen, dass auch niemand einen Zweifel daran lässt, dass es gut und wichtig ist, dass es diese Prefixe gibt und dass sie von den Browser-Herstellern genutzt werden, um Neues im freien feldversuch auszuprobieren. Das hat die CSS-Entwicklung insgesamt unglaublich beschleunigt und beflügelt und hat allen Beteiligten neue Möglichkeuten eröffnet.

Wichtig nur ist dabei, dass die stattfindenen Entwicklungen halt eben auch miteinander Schritt halten, und das geht nur, wenn die Browser-Hersteller frühzeitig ihre Prefixe der W3C CAA-Sarbeitsgruppe auch vorlegen, sodass darauf basierend dann ein allgemeingültiges Spezifikationspapier erarbeitet werden kann, wovon dann alle Browser-Hersteller und alle Inhalteanbieter dann profitieren können.
Und genau das hat Apple lange Zeit leider versäumt bzw. nicht gemacht. Das wird jetzt nachgeholt.
Und wichtig dabei ist, dass die Browser-Hersteller ihre Vendor Prefixes mit einem Verfallsdatum versehen und sie genau das den Webentwicklern, die diese nutzen, auch unmissverständlich klarmachen. Sodass deren Unterstützung irgendwann wieder aus dem Browser getilgt wird zugunsten der allgemeingültigen und in der betreffenden, von ihnen selber angestoßenen W3C CSS-Spezifikation niedergeschriebenen Präfix-freien Notation.
Auch hier ist Apple leider total im Rückstand: sämtliche alten und neue webkit-Präfixe gelten noch, können in WebKit noch genutzt werden, obwohl es teilweise bzw. größtenteils schon längst Präfix-lose W3C-Spezifikationskonforme Entsprechungen gibt und diese sogar von allen ! Browsern verstanden und umgesetzt werden können. Bei Mozilla macht man es diesbzgl. sehr vorbildhaft: sobald einer ihrer vendor-geprefixten CSS-Regeln für alle zugänglich im Spezifikationspapier drinsteht und die Mehrheit aller Browser diese standardkonforme Schreibweise unterstützt, tilgen sie ihre geprefixte Version und schmeißen sie zugunsten der offiziell für alle geltenden Notation aus Firefox raus. So ist es richtig, so soll es sein!

Der jetzige aufruf an die Webentwickler da draußen ist vor diesem Hintergrund wichtig, weil es eben eine ziemlich große Anzahl an Webanwendungen da draußen gibt, vor allem im mobilen Bereich (Android, iOS), wo ein WebKit-basierter Browser der vorinstallierte und meistgenutzte Browser ist, wo die Webentwickler, die diese Anwendungen geschrieben haben, anscheinend vergessen haben, dass es außer WebKit auch noch andere Browser gibt, die mit diesen Anwendungen was anfangen könnten oder sollen. Und weil sie anscheinend nur noch gewohnt sind, in WebKit-Kategorien zu denken und zu entwickeln inkl. ihrer Entwicklungstools. Und sie viel zu oft und wie selbstverständlich sich vieler -webkit-Präfixe bedient haben und es immer noch tun, ohne drüber nachzudenken, ob das eigentlich so sinnvoll und richtig ist was sie da machen, indem sie sich alleinig auf diese -webkit-Präfixe stützen und verlassen, nicht wissen oder ignorierend, dass diese Vendor-Präfixe eigentlich nur für den vorübergehenden oder lokal begrenzten Einsatz bestimmt sind und dass es in dem einen oder anderen Fall eine bessere Notation gibt, eine, die in der Spezifikation steht und die alle Browser verstehen.

Darum geht es. Um die Augen darauf zu richten bei den vielen Entwicklern und Content-Anbietern, dass sie nicht dem Fehler unterlaufen, den sie gerade im Begriff sind zu tun, einseitig nur eine einzige Plattform im Visier zu haben, völlig ausblendend oder vergessend, dass es sie in vielen Fällen nur einen Sekundenbruchteil kosten würde, ihre CSS-Notation so zu verfassen, dass alle derzeit auf dem Markt befindlichen maßgeblichen Browser-Engines damit zurechtkommen, weil es Entsprechungen im Standard oder wenigstens standardkonforme vorübergehende andere Vendor-Prefixes gibt und nicht nur und ausschließlich WebKit betreffend.

Um genau die von Dir ins Auge gefasste Klientel an WebdesignerInnen geht es bei diesem jetzigen Aufruf! Und diese Klientel ist leider besorgniserregend groß. Und damit ist das Ganze sehr wohl mit der langjährigen IE6-Situation vergleichbar. Deshalb ja der so dringende Aufruf. Wenn das einmal eingerissen ist, sich der Schlendrian einmal eingenistet hat in den Köpfen, einmal Falsches in den Gehirnen einprogrammiert ist, dann ist es unglaublich schwer und ein möglicherweise sehr elender und langwieriger Prozess, das bis zum letzten Mann und bis zur letzten Frau wiedr aus den Köpfen und aus den Gewohnheiten der betreffenden Leute wieder rauszubekommen. Man sieht's am IE6, wie lange es gebraucht hat, den aus den Köpfen der Leute (und vor allem: der Verantwortlichen in Firmen und Entwickler) wieder rauszubekommen. Selbst Microsoft hat davor fast kapituliert und hat's nur durch zwei sehr mit Nachdruck versehehen und viel Geld und Aufwand und Überzeugungsarbeit kostenden Kampagnen unter kräftiger Mithilfe von Communities und Entwicklern aller Welt gegen den eigenen IE6 wieder in die Spur bekommen (in einigen Firmen und Gegenden und vor allem: China leider immer noch nicht).


Ich schrieb schon was dazu, was Apple und deren Prefixes und vor allem deren Umgang bzgl. Verfallsdatum derselben (bisher gibt's da nämlich leider keines im Gegensatz zu Mozilla bspw.) angeht.

Möglicherweise sind beide Überschriften richtig. Denn Apple tut nix gegen den Schlendrian bzw. fördert ihn insofern, weil sie nicht aufklären, keine Verfallszeit eingebaut haben, ihre Präfixe nur langsam oder teilweise auch gar nicht der W3C-Arbeitsgruppe vorlegen und den Entwicklern das Gefühl geben, sie handelten korrekt und richtig, wenn diese sich bzgl. gewisser Präfixe allein auf WebKit beschränken, obwohl sie genauso gut und viel besser eine existierende und gültige allgemeingültige Notation hätten nehmen können oder wenigstens, falls diese noch nicht in allen Browsern umgesetzt sein sollte, zusätzlich deren vendor-spezifische Notation. Sodass, egal, in welchem Anwendungsfall, immer mindestens eine der geschriebenen Notationen verfängt und Wirkung zeigen kann. Das ist ein Mehraufwand von wenigen Sekunden beim Schreiben von CSS. Und ist und bleibt standardkonform.

Wenn Du das diesbzgl. Gesprächsprotokoll der CSS-Arbeitsgruppe liest, dann liest Du auch, dass die Verantwortlichen von Apple an diesen Stellen Besserung gelobt haben und da Einiges nachreichen und verbessern werden (wenn auch nicht alles) in ihrem Umgang damit.

wir muessen erstmal 2 dinge bzgl. der prefixe unterscheiden:

1. prefixe, die fuer noch nicht ratifizierte spezifikationen genutzt werden, als (altes) beispiel
und

2. prefixe, die fuer nicht spezifizierte features genutzt werden, auf anhieb faellt mir da ein, was aber wohl ein schlechtes bsp. ist, da ms und apple dies fuer ein browserfeature, nicht fuer styling nutzen.


warum ich die prefixe fuer eine schlechte idee halte, ist genau die problematik mit dem verfallsdatum. da sehe ich apple auch nicht in der erziehungsrolle von schlendiranen. der ansatz von mozilla hingegen erfordert die aktualisierung des codes, verzoegert damit potentiell den einsatz von innovation, insofern kann ich das momentane, eher geschaeftsorientierte vorgehen von apple durch aus nachvollziehen. besserung zu geloben ist natuerlich die uebliche pr antwort


kurz: apple / google bashing ist zwar hip, aber hier imho nicht zielfuehren. die verantwortichen sind jede die es implementieren, bzw. den implementierungsauftrag geben. insofern waere es imho wichtiger fuer ein offenes web in den marketing abteilungen aufklaerungsarbeit zu leisten, damit diese nicht ipad user zugunsten ihrer app aussperren und bei consumern aufklaerungsarbeit leisten, damit diese nicht facebook nutzen

gona:

(insbesondere die Topics Vendor Prefixes und Aliasing Details) und von Anfang bis Ende gelesen und verstanden?

Anwesende/Diskutanten:

Rossen Atanassov (Microsoft), Rossen
Tab Atkins (Google), TabAtkins
David Baron (Mozilla), dbaron
Bert Bos (CSS Lead, W3C), Bert
Tantek Çelik (Mozilla, früher Microsoft), Tantek
John Daggett (Mozilla,), jdaggett
fantasai Etemad (Mozilla), fantasai
Simon Fraser (Apple), smfr
Sylvain Galineau (Microsoft), ylvaing
Daniel Glazman (Disruptive Innovations), glazou
Vincent Hardy (Adobe), Vincentv
Koji Ishii (Invited Expert)
Håkon Wium Lie (CTO Opera), howcome
Peter Linss (Hewlett-Packard), plinss
Luke Macpherson (Google), macpherson
Alex Mogilevsky (Microsoft), alexmog
Anton Prowse (Invited Expert), Anton
Florian Rivoal (Opera), Florian
Alan Stearns (Adobe), Alan
Steve Zilles (Adobe), Steve

Observers:
Jet Villegas (Mozilla Corporation)
Tavmjong Bah (Inkscape)


Vor DIESEM Hintergrund, DIESEM Round-Table-Gespräch, an dem die gerade genannten Vertreter/Verantwortlichen (einer davon Glazman) am Montagmorgen, den 06.02.2012 in Paris zusammengekommen und gemeinsam beratschlagt und nach nach Vorschlägen/Lösungen gesucht haben, solltest Du Glazmans zwei Tage später öffentlich formulierten Aufruf verstanden wissen, nur so -- mit dem inhaltlichen Wissen über diesen 2 Tage vorher gewesenen "Runden Tisch", an dem , versteht man den tieferen Sinn hinter Glazmans Aufruf.

Vergegenwärtige Dir bitte, dass angesichts dieses vorangegangenen Runden Tisches, an dem namhafte Vertreter und Verantwortliche ALLER Browser-Hersteller saßen (nebst Bert Bos vom W3C, seines Zeichens zusammen mit dem ebenfalls anwesenden Håkon Wium Lie von Opera, beide Co-Autor und Erfinder von CSS), dieser 2 Tage später von Glazman geschriebene öffentliche Aufruf keine Privatmeinung von Glazman ist (das vielleicht auch), sondern Quintessenz und Ergebnis DIESES vorangegangenen Runden Tisches. Und damit von ALLEN dort Anwesenden (inklusive der Vertreter von Apple und Google) unterstützt und mitgetragen wird. An diesem Runden Tisch saß nicht irgendwer zusammen! Die haben sich da getroffen, weil dringender Handlungsbedarf besteht!

Bzgl. Deines Beispiels text-size-adjust sagt Sylvain Galineau (Microsoft), sylvaing, Folgendes: "-webkit-text-size-adjust was implemented in IE. So we pulled it out and asked that it be submitted for standardization. But it wasn't. *looks at smfr* (Simon Fraser (Apple))". Soviel dazu.

Es lohnt sich wirklich, das Gesprächsprotokoll dieses Runden Tisches mal komplett durchzulesen und was die einzelnen Vertreter da gesagt haben.

Um Bashing in die eine oder andere Richtung geht's hier überhaupt nicht. Sondern um ein ganz handfestes, ernsthaftes Problem, das nur gemeinsam gelöst werden kann und von allen (von dem einen mehr, von dem anderen weniger) Mitarbeit erfordert.

@sierkb ja, und weiter?

was aus dem ganzen ja deutlich durchklingt, ist die (berechtigte) angst des w3c die normierierungs-hoheit durch geschaffene tatsachen innovativer browser-hersteller zu verlieren. und dies kann natuerlich ein offenes web behindern.

aendert aber nichts an meinen aussagen bzgl. bashing und verantwortlichkeiten

gona:

Du scheinst immer noch nicht zu verstehen. Wer bildet denn das W3C? Wer ist denn in diesen W3C-Arbeitsgruppen tätig und erarbeitet diese Standards? Nicht das W3C. Das W3C stellt nur den administrativen äußeren Rahmen, bildet das gemeinsame Dach. Schau Dir die Liste der an dem runden Tisch Anwesenden doch mal an! Wer hat denn da die Problematik erörtert und diskutiert? Das W3C? Nein! Die Browser- und Software-Hersteller selber sind es, die zusammen mit anderen Teilnehmern (Vertreter aus Firmen, Einzelpersonen wie mir z.B.) das alles gemeinsam erarbeiten, die diese Standards gemeinsam erarbeiten! Sie sind ganz wesentlicher Teil dessen, was Du da unterteilst in W3C versus Browser-Hersteller, diese von Dir vorgenommene Lagerbildung in "die einen links und die anderen rechts" existiert so in der Realität nicht! Diese Browser- und Software-Hersteller zahlen jährlich viel Geld dafür, dass sie da die Köpfe zusammenstecken und gemeinsam an einem Strang ziehend Standards aus der Taufe heben können/dürfen/sollen, und sie tun es gerne!
Will heißen: unter dem Dach des W3C gemeinsam erarbeitete Standards sind von einer breit aufgestelten Mehrheit auch getragen. Genau dafür entsenden Firmen ihre Vertreter in diese nach allen Seiten hin offenen Arbeitsgruppen, die diese Standards/Spezifikationen erschaffen und ihre Ideen einbringen.

Du scheinst ein völlig falsches Verständnis zu haben von dem, was das W3C ist, wie es arbeitet, welcher tiefere Sinn eigentlich hinter dieser Institution steckt.

@sierkb ist ja ok deine meinung zu wiederholen, um sie zu unterstreichen. mir dinge zu unterstellen ist allerdings unangebracht. das gespraech ist hiermit beendet. /ignore

Ich habe das deshalb unterstrichen und vielleicht auch etwas bewegt formuliert, weil Deine geäußerten Worte leider beispielhaft für vieles ist, wie das W3C und das Zustandekommen von Webstandards da draußen gesehen wird. Unterstellt habe ich Dir gar nichts. Ich sehe immer noch einen Unterschied in der Formulierung zwischen dem von mir gewählten "Du scheinst ein völlig falsches Verständnis zu haben..." und der Formulierung wie Du sie verstanden zu haben scheinst "Du hast ein völlig falsches Verständnis...". Von daher bitte nicht über etwas aufregen, das von mir so garantiert nicht gemeint gewesen ist. Ich will Dich weder angreifen noch Dich beleidigen noch Dir irgendwie zunahetreten. Sollte es mir dennoch passiert sein, so bitte ich um Verzeihung.

Deine getroffene Unterscheidung in W3C versus Browser-Hersteller/ Rest der Welt ist leider sehr verbreitet, und es ist sehr schwer, das aus den Köpfen vieler herauszubekommen und so geradezurücken, dass es der Realität entspricht.
Du kannst es so formulieren: wenn ein Standard unter dem Dach des W3C gemeinsam von vielen erarbeitet/diskutiert wird, dann ist das eine Gemeinschaftsarbeit und wird von allen Beteiligten getragen bzw. sollte möglichst von allen Beteiligten getragen werden, sonst hätte es gar keinen Sinn, Vertreter in so eine Arbeitsgruppe zu entsenden, wenn man sich von dem gemeinschaftlichen Ergebnis dann am Ende distanziert bzw. konträr dazu trotzdem sein Ding dann macht und diesen Gemeinschaftserfolg damit dann konterkariert/entwertet. Sehr verkürzt und plakativ gesagt: diese daran Beteiligten SIND das W3C, sie sind Mitglieder des W3C, eine gebildete Arbeitsgruppe, in der die Beteiligten zusammengefasst sind, bilden einen wichtigen Körper (eigentlich sogar den wichtigsten) des W3C, eine unter dem Dach des W3C in so einer Arbeitsgruppe (Working Group) gemeinsam erarbeitete Spezifikation ist IHR gemeinschaftliches Werk. So möchte ich mich da bitte verstanden wissen in der Äußerung von 22:11 Uhr.

"Deine getroffene Unterscheidung in W3C versus Browser-Hersteller" – @siebk

scheinbar hast du etwas falsch verstanden folgerst daher falsch, ich wisse nicht, wer das w3c (und die what-wg ) ist und macht.


aus dem aufruf:

"…other browsers will start supporting/implementing themselves the -webkit-* prefix" – @glazman

es besteht also imho die angst, seitens des w3c – genauer gesagt: seitens eines w3c mitglieds – die nominierungs-hoheit zu verlieren, weil andere browser-hersteller auf die geschaffene tatsachen - also auf features mit prefix, die von faulen / unwissenden webdesignern alternativlos genutzt werden - zurueckgreifen, anstatt auf die ratifizierten specs des w3c.


und am ende geht es imho wiedereinmal um geld. um das geld, dass sich webdesigner durch nicht-offene bzw. nicht cross-browser (2 unterschiedliche dinge) implementierungen sparen und um geld, dass browser-hersteller potentiell verlieren koennen, weil consumer an den bling von prefixed implementierungen gewohnt sind.


man koennte jetzt auch das blatt auch umdrehen und klagen: das w3c ist schuld weil es nicht schnell genug ratifiziert. oder: browserhersteller bedrohen das offene web, weil sie ggf. -webkit prefixe implementieren um eine groessere reichweite zu erlangen…


ich denke wir stimmen darueber ueberein, dass ein offenes web wichtig ist. insofern ist die initiative von @glazman gut. nur auf apple zu bashen finde ich allerdings etwas kurzsichtig

(ps.: dass ich mal apple verteidige haette ich mir auch nicht gedacht, aber wir sind hier ja auf einer fanboi seite, hehe)

Ich entschuldige mich vorab schon mal bzgl. der Länge/Menge.
Aber das Thema ist sehr umfassend, es gibt meinerseits viel zu erklären. Ich bitte also um das nötige Verständnis -- im Sinne der Sache:

Schon wieder trennst Du unzulässigerweise auf in "hier das W3C" und dort "die Browser-Hersteller und alle anderen". Das gibt aber die Sitiation nicht wieder und ist deshalb ein falsches Denken. So formuliert nur jemand, der, wie ich oben schon angedeutet habe, nicht weiß und nicht versteht, wie die internen Gesetzmäßigkeiten und Abläufe beim Zustandekommen solcher Standards sind. Ich mache Dir das nicht zum Vorwurf, stelle nur fest, dass es so ist und dass Du da eine leider weit verbreitete falsche Vorstellung hast von den Dingen.

Denn: ein Standardisierungsverfahren unter dem Dach des W3C folgt einem ganz bestimmten Prozedere, einem ganz bestimmten festgelegten und i.d.R. in allen Fällen gleichen Ablauf. Der ist hier, in diesem Dokument festgelegt inklusive aller Zwischenstufen, Voraussetzungen, die erfüllt sein müssen etc. pp.:

W3C Process Document: W3C Technical Report Development Process

Und ein ganz ganz wichtiger Teil des Ablaufes ist das Feedback und die Mitabeit der Implementatoren, also in diesem Fall maßgeblich der Browser-Hersteller. Feedback in jeglicher Form. Und vor allem und ganz dick unterstrichen: Tests. Tests, Tests und nochmal Tests. Und zwar erarbeitet und eingereicht vor allen von den Browser-Herstellern (aber jedes andere Mitglied einer Arbeitsgruppe bis hin zur Einzelperson ist dazu ebenfalls ermuntert), die dann aber der W3C-Arbeitsgruppenleitung übergeben bzw. von diesem gesammelt und für alle anderen bereitgestellt werden können! Denn nur so kann bewertet werden, ob das, was man da schriftlich erarbeitet hat, in der Praxis und Umsetzung auch funktioniert. Und das Fehlen solchen Feedbacks, das Fehlen oder nicht ausreichen solcher Tests oder auch das Nicht-Klären von evtl. IP (Patentansprüchen) in den eigenen Reihen seitens der Browser-Hersteller kann den ganzen festgelegten Standardisierungsprozess ins Stocken geraten lassen und aufhalten. Sind Unklarheiten bzgl. IP, sind Fragestellungen offen bzgl. irgendwelcher zu implementierenden Features, sind nicht ausreichend und von ALLEN relevanten Implementierern (Browser-Herstellern) Tests und Aussagen über diese Tests in der Arbeitsgruppe bzw. der W3C-Leitung dieser Arbeitsgruppe vorhanden bzw. liegen nicht vor, dann kann der Standardisierungsprozess aufgrund dessen nicht weitergeführt werden. Weil alle auf genau diese ausstehenden Ergebnisse warten, bevor weiterverfahren werden kann.

Und da, an dieser Stelle ist ein ganz neuralgischer Punkt, der schon so manchen Standardisierungsprozess verlangsamt/aufgehalten/verzögert hat. Weil die Browesr-Hersteller ihren diesbzgl. Verpflichtungen nicht schnell genug nachgekommen sind. Tests, Testsuiten schreibt NIEMAND gerne. Das ist eine Heidenarbeit, das ist eine sehr undankbare, aber eine leider unbedingt notwendige und höchstwichtige Aufgabe. Jeder der Implementoren versucht sich so elegenat wie möglich da herumzudrücken oder diese lästige Aufgabe hinauszuzögern. Und leider ist ausgerechnet Apple unter denjenigen, die da nicht richtig in Wallung kommen und den Standardisierungsprozess dadurch ausbremsen.

Positiv vorbildhaft in dieser Richtung sind hingegen Microsoft (ausgerechnet! ist man versucht zu sagen) und Mozilla und auch Opera (in personam vor allem Anne van Kesteren). Die reichen, wenn man das beobachtet, regelmäßiger ihre Tests und Ergebnisse beim W3C ein (bzgl. CSS hier: ), Microsofts eingereichte umfangreiche CSS-Testsuiten setzen da bislang Maßstäbe, was dem Umfang angeht, die klopfen da in letzter Zeit mit ganz dicken Paketen im Arm an die Tür der Arbeitsgruppen-Leitung. Das ist dann in Bezug auf Microsoft fast jedes Mal aufgrund des Umfangs sowohl Microsoft als auch die einschlägige IT-Fachpresse eine Meldung wert (z.B. ). Andere wie Mozilla und Opera tun das eher im Stillen und mit weniger öffentlicher Aufmerksamkeit.

Tests, Tests und nochmal Tests. Machen. Raushauen in Richtung W3C-Leitung. An Tests kann es nie genug geben! Egal, von wem geschrieben und eingereicht. Unangenehm ist es für jeden, der's macht, diese Aufgabe macht niemand gerne. Aber es muss sein! Und Apple? Könnten an dieser Front durchaus mehr tun.
Einfach mal die vorliegenden und bislang eingereichten Tests anschauen und in die Credits reinschauen. Der Name Apple oder der Name eines Apple-Mitarbeiters taucht da leider eher selten auf.

Und solche Situationen halten auf.
Die Browser-Hersteller und ihre Mit- und Zuarbeit sind ein ganz elementarer Bestandteil und Faktor im gesamten Standardisierungsprozess! Je zügiger und je besser sie mit und zuarbeiten, umso schneller kommt ein Standard in einem solchen Standardisierungsprozess voran!

Deshalb ist die Unterscheidung in "W3C hier" und "Browser-Hersteller dort" falsch! Die Browser-Hersteller sind Teil des Ganzen, Teil des Prozesses. Gibt es ein Problem, ist es das Problem aller. Ist jemand aus der Runde säumig oder behäbig, so ist er Teil oder gar Ursache des Problems, denn alle anderen warten auf ihn bzw. sind angehalten zu warten.

Vendor prefixes sind ausdrücklich gewollt. Seit Jahren schon. Sie stehen sowohl in CSS 2, Kapitel 4.1.2.1 Vendor-specific extensions (CSS 2.1 ist übrigens erst im August 2011 endgültig als Recommendation verabschiedet worden, zuvor hatte sie jahrelang diesen endgültigen Status NICHT, das nur mal am Rande bemerkt mit Seitenblick auf die diesbzgl. immer wieder kommenden Einwürfe bzgl. HTML5) als auch in CSS 3 ausdrücklich in der CSS-Spezifikation drin, allerdings mit der Zusatz-Information "Authors should avoid vendor-specific extensions".

Vendor extensions sind eigentlich dazu gedacht, Herstellern die Möglichkeit zu geben, Eigenschaften auszuprobieren bzw. Eigenschaften, die bei ihnen selber oder auch auf höherer Ebene im Rahmen einer W3C Spezifikation in der Diskussion sind, trozdem anzubieten und umzusetzen, damit man damit herumspielen kann und evtl. Schwachstellen und/oder Verbesserungen daran besser finden kann. Sie sind NICHT dazu gedacht, stabilen Entsprechungen in der Spezifikation den Rang abzulaufen.
Sobald in einer Spezifikation eine entsprechung ist, die so stabil spezifiziert ist, dass sich alle Browser-Hersteller darüber einig sind (sie wissen es ja am besten, denn sie haben diese Spezifikation ja gemeinsam erarbeitet), dann sollten wenigstens jene Präfix-Notationen aus den Browsern rausfliegen, die auf einer breiten Basis gefahrlos überall genutzt werden können. Und nicht still im Browser weiterbestehen und vor sich herschlummern. Und darüberhinaus sollten eigene ins Feld gebrachte Präfix-Erweiterungen vom betreffenden Browser-Hersteller dokumentiert und in einen Standardisierungsvorschlag gegossen werden, auf dass darauf aufbauend dann eine Spezifikation mit W3C-Stempel aus der Taufe gehoben werden bzw. angestoßen werden kann, auf den sich dann alle anderen ebenfalls berufen und ihn umsetzen können. Darum geht's! Und hier ist Apple (und in Teilen auch Google, doch was dem Umfang angeht, mehrheitlich Apple) angehalten, nachzuliefern (was ja jetzt auch zugesagt worden ist).

Bzgl. CSS Transitions und CSS Animations hat's doch auch geklappt, dass Apple hier dem W3C diese eigenen CSS-Erweiterungen als Spezifikationsvorschlag vorgelegt hat, welcher von den anderen Browser-Herstellern auch begrüßt und akzeptiert worden ist und daraus somit ein Standard für alle im Werden begriffen ist. Das war gut, vorbildhaft und richtig, wie Apple das gemacht hat! Und genau das soll/muss halt kontinuierlich geschehen. Und nicht nur einmal in 5 Jahren und abhängig von Lust und Laune und auf Zuruf bzw. aufgrund einer dringlichen Bitte im Rahmen einer solchen gewesenen Dringlichkeitssitzung. Sowas nicht schleifenlassen! Denn wenn da einmal der Schlendrian drin ist, dann verselbständigt sich dann irgendwann mal eine Situation, erzeugt eine bedenkliche Schieflage und triggert eine Fehlentwicklung, welche Anlass für diesen runden Tisch im Februar geworden ist.

Dass der eigentliche, ursprüngliche Sinn genau so gemeint ist, also im Sinne eines Experimentalstatus, im Sinne eines zeitlich begrenzten Testbettes, sieht man beispielhaft auch an dieser werdenden CSS3-Spezifikation CSS Template Layout Module Editor's Draft 15 February 2012, die ich mir jetzt mal wahllos rausgepickt habe und wo an mehreren Stellen in rosa Kästchen z.B. folgende Formuliereung drinsteht: One way to experiment safely with implementations before the specification reaches Candidate Recommendation status is to add an identifier with a vendor prefix somewhere in the value, e.g., ‘display: -my-product "aa" "bc"’ or ‘display: -my-product("aa" "bc")’..

Im Sinne eines solchen Experimentalstatus, im Sinne eines solches Testbettes von Vendor Extensions äußert sich u.a. im November 2011 auch Daniel Glazman in seinem Blog-Eintrag CSS vendor prefixes, again... .

Es hat zudem u.a. meinen Mitstreiter und Fachkollegen Jens Meiert und andere viel Mühe und mehrere über Jahre verteilte Anläufe gekostet, Vendor Extensions auch beim W3C CSS Validator als zulässig und nicht als Fehler anerkennen zu lassen wie das jahrelang der Fall gewesen war, eben weil sie in der Spezifikation ausdrücklich vorgesehen und erlaubt sind und deshalb nicht als Fehler anzusehen sind. Es hat sehr lange gedauert, mehrere Jahre, und immer wieder heiße Diskussionen erzeugt, bis die CSS-Validator-Entwickler hier dann am Ende doch ein Zugeständnis gemacht haben und sich der Lebenswirklichkeit angenähert haben, indem der CSS Validator dazu angehalten worden ist, an solchen Stellen nur noch lediglich eine Warnung auszuspucken statt einer Fehlermeldung.

Ähnlich habe ich in der Vergangenheit an anderer Front gekämpft (per email, per Mailinglist; und mich gegen die harten Verweigerer am Ende durchsetzen können) beim HTML Validator (an dem ich in bescheidenem Maße mitgewirkt habe), vom Server dynamisch geschriebenes "application/xhtml+xml" erkennen zu können, indem der Markup Validator endlich einen HTTP_ACCEPT Header sendet statt wie bislang keinen.

Ja und Ja.

Vielleicht verstehst Du ja nach meinen gerade gemachten Ausführungen etwas besser, was ich meine und wie ich es meine.

Bin gerade via RSS Feed drüber gestolpert -- weiterer direkter Nachhall obigen Runden Tisches bzw. des hernach erfolgten Glazman-Aufrufs:

Lea Verou (09.02.2012): Vendor prefixes, the CSS WG and me

Christian Heilmann (09.02.2012): Now vendor prefixes have become a problem, want to help fix it?

Remy Sharp (09.02.2012): Vendor Prefixes - about to go south

Remy Sharp benennt meiner Ansicht nach einige Ding genau richtig, auch wenn ich geneigt bin, ihm in einem Punkt (in Bezug auf das W3C) zu widersprechen (ich habe bereits oben länglich versucht, die Lage/Rolle/Mechanismen/Abläufe/Zusammenhänge zu verdeutlichen).



Und, zeitlich davor, bereits im November 2011:
Folgende Replik von Daniel Glazman in Bezug auf eine längere Äußerung seitens Henry Sivonen Vendor Prefixes Are Hurting the Web (Henri Sivonen ist unabhängiger Entwickler, der aber eng mit und für Mozilla arbeitet und u.a. den (HTML5-)Parser geschrieben, welcher in seinem HTML5-Validator validator.nu sowie inzwischen sowohl im W3C Markup Validator als auch in Firefox' Rendering-Engine Gecko zum Einsatz kommt, um HTML5 zu parsen):

Daniel Glazman (16.11.2011): CSS vendor prefixes, an answer to Henri Sivonen

@sierkb: da du allen realitaeten zu trotz verbissen darauf bestehst mir zu unterstellen, dass ich bestimmte dinge nicht weis und bestimmte dinge meine, die ich nie behauptet habe, lasse ich dir den spass und freue mich, dass es menschen wie dich gibt, die sich fuer die materie interessieren und einsetzen, wenn auch kommunikativ etwas ungeschickt.

gona:

Ich denke, eigentlich sind wir beide da wohl in der Sicht der Dinge nicht weit voneinander entfernt.

Um darauf nochmal zurückzukommen:

Da würde Dir mindestens Mozilla widersprechen.

Das sowieso! Und nicht nur und erst angesichts dieser Problemstellung hier. Aber/und: durch oben aufgezeigte und der Diskussion zugrundeliegende Problematik, dass WebKit mittlerweile voll ist von proprietären, leider nur zu einem geringen Teil in den Standard eingeflossenen proprietären CSS-Präfixen, sind viele Webentwickler/-Designer auch dazu verleitet, diese zu benutzen, zu bevorzugen, ausschließlich zu nutzen. Und genau da liegt die Verantwortlichkeit von Apple (und auch Google, da sie an WebKit ja mitschreiben), genau diese Einseitigkeit, diese Verlagerung nicht auch noch zu fördern und unterstützen bzw. den Dingen einfach ihren Lauf lassen und untätig danebenzustehen, sondern alles zu tun, dass deutlich gemacht wird, dass diese CSS-Präfixe mit äußerster Sorgfalt und mit Bedacht und sowieso möglichst nur zeitlich begrenzt eingesetzt werden sollen/dürfen. Und gleichzeitig ist Apple angehalten, sie insofern zu dezimieren, dass die meisten von ihnen endlich in einen allgemeingültigen Standard überführt werden können, den dann alle auch ohne Präfix verwenden können. Und gleichzeitig sollte Apple bemüht sein, solche dann entstehenden Standards in ihrer Umsetzung zu beschleunigen und ihrerseits alles dafür tun, dass diese nicht unnötig aufgehalten und ausgebremst werden durch ihr eigenes Tun/Nicht-Tun und Handeln/Nicht-Handeln (bspw. wie bei der W3C Widget-Spezifikation, die derzeit nicht weiterkommt, weil Apple bremst bzw. nicht mit Info/Entscheidungen rüberkommt, welche aber dringend benötigt werden, um im diesbzgl. Standardisierungsprozess weiterzukommen).

Und deshalb ist das Ganze kein einseitiges Bashing gegen Apple. Weil's eine sehr berechtigte Forderung, ein sehr berechtigter Aufruf, ein sehr ernstes Problem geworden ist, an dem Apple in Bezug auf WebKit nicht ganz unbeteiligt ist bzw. eine gewisse Verantwortlichkeit im Sinne des großen Ganzen an den Tag legen sollte/muss.

Und das Problem, welches zwar ein Grundsätzliches ist, hat aber nun mal in diesem Fall konkret mehrheitlich WebKit als Grundlage aufgrund dessen Verbreitung besonders im mobilen Bereich. Und hat halt gerade dort zahlenmäßig eine gewisse Dominanz erlangt, auch was Anwendungen und Entwickler angeht, welche diese Anwendungen schreibe, so sind halt die Fakten. Und es gilt zu verhindern, dass aus dieser Dominanz eine dauerhafte manifestierte Schieflage wird, welche am Ende nur schwer oder gar nicht mehr zu korrigieren ist. Es ist ja jetzt schon schwer das zu korrigieren, Du siehst es ja an den Statements, die da am Runden Tisch gemacht worden sind und an der Hilflosigkeit, der sich manche da ausgeliefert sehen, wenn schon ernsthaft darüber nachgedacht wird, letztendlich WebKit-Aliase in die Browser der Nicht-WebKit-Browser einzubauen oder -- noch weiter gedacht, gleich die komplette WebKit-Rendering-Engine neben die eigene zu stellen. Das kann/darf es doch nicht sein als Weg aus dieser Misere!