🥇 🙉 ❇️ Sprachen, die fast zu CSS wurden ✊🏿 👨‍🏭 🧒

Hallo Habr! Ich mache Sie auf die Übersetzung des Artikels " Die Sprachen, die fast zu CSS wurden " von Zack Bloom über Sprachen aufmerksam, die zu CSS hätten werden können, wenn die Geschichte etwas anders gewesen wäre.

, ( ) , ( ) , TeX, Microsoft Word . : ", ".

— , 1994

Als Tim Berners-Lee 1991 die Erstellung von HTML ankündigte, gab es keine Möglichkeit, Seiten zu formatieren. Die Art und Weise, wie HTML-Tags gerendert wurden, wurde vom Browser festgelegt und maßgeblich von den Benutzereinstellungen beeinflusst. Es schien jedoch eine gute Idee zu sein, ein Standardwerkzeug zu erstellen, mit dem Seiten auf ihre bevorzugte stilistische Darstellung "hinweisen" können.

Vor dem Aufkommen von CSS dauerte es jedoch noch fünf Jahre und weitere zehn Jahre, bis es vollständig implementiert war. Es war eine Zeit harter Arbeit und Innovation, die zur Schaffung vieler konkurrierender Stilisierungen führte, die durchaus zum Standard hätten werden können.

Obwohl diese Sprachen heute offensichtlich nicht weit verbreitet sind, ist es für mich interessant, darüber nachzudenken, wie die Welt aussehen könnte. Noch überraschender ist, dass viele dieser Sprachen Funktionen haben, die Entwickler auch heute noch gerne in CSS verwenden würden.

Erster Kandidat

Anfang 1993 erreichte der Mosaic-Browser nicht einmal die Version 1.0, und alle vorhandenen Browser arbeiteten nur mit HTML. Es gab keine Möglichkeit, den HTML-Stil anzugeben. Sie haben das Tag also so gesehen, <h1>wie der Browser es angezeigt hat.

Im Juni desselben Jahres reichte Robert Reisch der www-talk-Mailingliste einen Vorschlag ein , ein "leicht zu analysierendes Format für die Übermittlung von Stilinformationen zusammen mit Webdokumenten" zu erstellen, das er RRP nannte.

@BODY fo(fa=he,si=18)

Es ist ziemlich verzeihlich, wenn Sie nicht verstehen, was dieser Code tut. In der Zeit vor gzip, als die Verbindungsgeschwindigkeit normalerweise weniger als 14,4 kbit / s betrug, war es logisch, den Inhalt dieses neuen Formats so kompakt wie möglich zu halten. Insbesondere wählt diese Regel faHelvetica ( he) als Schriftfamilie ( ) aus und legt die Schriftgröße ( si) auf 18 Punkte fest.

Seltsamerweise fehlten Reischs Vorschlag Einheiten, alle Zahlen wurden kontextbezogen interpretiert (zum Beispiel wurden alle Schriftgrößen in Punkten angegeben). Dies liegt daran, dass RRP eher als „Satz von Tipps und Tricks für den Renderer“ als als Spezifikation konzipiert wurde. Dies wurde als notwendig erachtet, da dasselbe Stylesheet in normalen Browsern im Textmodus (zLynx ) und in den immer beliebter werdenden grafischen Browsern.

Screenshot des Lynx-Browsers

Interessanterweise enthält RRP eine Möglichkeit, das Spaltenlayout festzulegen - dies war in CSS erst 2011 möglich. Beispielsweise würden drei Spalten mit einer Breite von jeweils 80 Einheiten folgendermaßen aussehen:

@P co(nu=3,wi=80)

Es ist etwas schwierig zu analysieren, aber wahrscheinlich nicht viel schwieriger als white-space: nowrap.

Es ist erwähnenswert, dass RRP keine der "Kaskadierungen" unterstützt hat, mit denen wir heute Stylesheets verknüpfen. Jedes Dokument kann nicht mehr als ein aktives Stylesheet gleichzeitig haben, was bei der Gestaltung von Dokumenten durchaus logisch ist, obwohl dies für uns heute ungewöhnlich ist.

Marc Andreessen (Schöpfer von Mosaic, der schließlich zum beliebtesten Browser wurde) wusste von dem UVP-Vorschlag, implementierte ihn jedoch nie in Mosaic. Stattdessen ging Mosaic fast sofort den Weg der Verwendung von HTML-Tags für das Styling (was ziemlich tragisch ist) und fügte Tags wie <FONT>und hinzu <CENTER>.

Viola und die Proto Browser Wars

„Dann implementieren Sie doch einfach einen der vielen Stylesheet-Vorschläge. Mit der richtigen Struktur würde dies das Problem fast vollständig lösen. "

Dann müsste ich den Leuten sagen: "Okay, Sie müssen diese Sprache lernen , um ein Dokument zu schreiben, und dann eine andere Sprache lernen , damit das Dokument so aussieht, wie Sie es möchten." Oh, sie würden es einfach lieben.

- Mark Andreessen, 1994

Entgegen der landläufigen Meinung war Mosaic nicht der erste grafische Browser. Es wurde von voran Violawww , einem grafischen Browser ursprünglich geschrieben von Pei-Yuan Wei in nur vier Tagen.

Screenshot des Viola-Browsers

Pei-Yuan hat eine Stylesheet-Sprache erstellt , die die heutige hierarchische Struktur von CSS unterstützt:

(BODY fontSize=normal
      BGColor=white
      FGColor=black
  (H1   fontSize=largest
        BGColor=red
        FGColor=white)
)

In diesem Fall wenden wir Farben auf den Hauptteil des Dokuments (Hauptteils) an und gestalten insbesondere Stile H1, die sich innerhalb des Hauptteils befinden. Anstatt Selektoren zu wiederholen, um diese Verschachtelung zu steuern, verwendete PWP das Klammersystem, was uns an die Einrückungssysteme erinnert, die in Sprachen wie Stylus und SASS verwendet werden und die einige Entwickler heute noch gegenüber CSS bevorzugen. Dies macht die PWP-Syntax möglicherweise in mindestens einer Hinsicht besser als CSS, das sich im Laufe der Zeit zur universellen Sprache des Webs entwickelt hat.

PWP zeichnet sich auch dadurch aus, dass es eine Möglichkeit eingeführt hat, auf externe Stylesheets zu verweisen, die wir heute noch verwenden:

<LINK REL="STYLE" HREF="URL_to_a_stylesheet">

Leider wurde ViolaWWW hauptsächlich für die Arbeit mit dem X Window System geschrieben , das nur auf Unix-Systemen beliebt war. Als Mosaic auf Windows portiert wurde, brachte es Viola schnell zu Staub.

Stylesheets vor dem Web

HTML ist etwas, in das sich nur ein Informatiker verlieben kann. Ja, es drückt die interne Struktur eines Dokuments aus, aber Dokumente sind nicht nur strukturierte Textdatenbanken. Sie haben eine visuelle Wirkung. HTML zerstört jegliche grafische Kreativität eines Dokumententwicklers vollständig.

- Roy Smith, 1993

Die Notwendigkeit einer Sprache, die den Stil von Dokumenten ausdrücken kann, ist viel älter als das Internet selbst.

Wie Sie wahrscheinlich wissen, basierte der uns bekannte HTML-Code ursprünglich auf einer Vor-Internet-Sprache namens SGML. 1987 beschloss das US-Verteidigungsministerium zu testen, ob SGML verwendet werden kann, um die Speicherung und Übertragung seiner riesigen Dokumentationsmengen zu vereinfachen. Wie bei jedem guten Regierungsprojekt haben sie sich als erstes einen Namen ausgedacht. Das Team wurde ursprünglich als Computer-Aided Logistics Support-Team, dann als Computer-Aided Acquisition- und Logistics Support-Team und schließlich als Continuous Acquisition and Life-Cycle Support-Initiative bezeichnet. In jedem Fall waren die Initialen CALS.

Das CALS-Team hat eine Sprache für die Gestaltung von SGML-Dokumenten namens FOSI erstellt. Sie veröffentlichteeine Sprachspezifikation, die ebenso detailliert wie unverständlich ist. Es enthielt meinen Favoriten der bedeutungslosesten Infografiken , die jemals im Internet existiert haben.

Eine Regel des Internets, die keine Ausnahmen hat, ist, dass Sie immer mehr erledigen, wenn Sie beweisen können, dass jemand falsch liegt. Im Jahr 1993, nur vier Tage nach Pei-Yuans Vorschlag, schlug Stephen Heaney vor, dass die FOSI-Version besser geeignet sei, das Web zu gestalten, anstatt das Rad neu zu erfinden.

Das FOSI-Dokument selbst ist in SGML geschrieben, was angesichts der Vertrautheit der Webentwickler mit einer SGML-Version namens HTML ein ziemlich logischer Schritt ist. Ein Beispieldokument sieht folgendermaßen aus:

<outspec>
  <docdesc>
    <charlist>
      <font size="12pt" bckcol="white" fontcol="black">
    </charlist>
  </docdesc>
  <e-i-c gi="h1"><font size="24pt" bckcol="red", fontcol="white"></e-i-c>
  <e-i-c gi="h2"><font size="20pt" bckcol="red", fgcol="white"></e-i-c>
  <e-i-c gi="a"><font fgcol="red"></e-i-c>
  <e-i-c gi="cmd kbd screen listing example"><font style="monoser"></e-i-c>
</outspec>

Vielleicht verstehen Sie nicht, was es ist docdescoder charlist, genauso wie die Mitglieder es nicht verstanden haben www-talk. Die einzige Kontextinformation ist, was e-i-c"Element im Kontext" bedeutet. FOSI ist jedoch zum ersten Mal bemerkenswert, als es die Maßeinheit einführte em, die nun zur bevorzugten Methode zur Größenbestimmung in CSS geworden ist.

Der daraus resultierende Sprachkonflikt war tatsächlich so alt wie die Programmierung selbst. Es war ein Kampf zwischen funktionaler Lisp-Syntax und Syntax in deklarativeren Sprachen. Pei-Yuan selbst beschrieb seine Syntax als "LISP-ähnlich", aber es war nur eine Frage der Zeit, bis die wahre LISP-Version auf der Bühne erschien.

Turing-komplettes Stylesheet

Trotz seiner Komplexität wurde FOSI tatsächlich als Zwischenlösung für das Problem der Dokumentformatierung angesehen. Langfristig war geplant, eine Sprache zu erstellen, die auf dem funktionalen Programmiersprachenschema basiert und in der Lage ist, die leistungsfähigsten Dokumententransformationen zu implementieren, die man sich vorstellen kann. Diese Sprache wurde DSSSL genannt. Lassen Sie uns einem der Entwickler der Sprache, John Bosak, das Wort erteilen:

Verwechseln Sie DSSSL nicht als Skriptsprache. Ja, DSSSL ist vollständig. Ja, es ist eine Programmiersprache. Aber die Skriptsprache (zumindest in meiner Interpretation des Begriffs) ist prozedural; und DSSSL ist definitiv nicht. DSSSL ist voll funktionsfähig und völlig frei von Nebenwirkungen. Im DSSSL-Stylesheet passiert nie etwas. Ein Stylesheet ist eine große Funktion, deren Wert eine abstrakte, geräteunabhängige, nicht prozedurale Beschreibung eines formatierten Dokuments als Spezifikation (eine Deklaration, falls gewünscht) der zu rendernden Regionen ist, die an die zugrunde liegenden Renderer übergeben werden.

In seiner einfachsten Form ist DSSSL in der Tat eine ziemlich logische Stilsprache:

(element H1
  (make paragraph
    font-size: 14pt
    font-weight: 'bold))

Da es sich um eine Programmiersprache handelte, konnten Sie sogar Funktionen darin definieren:

(define (create-heading heading-font-size)
  (make paragraph
    font-size: heading-font-size
    font-weight: 'bold))

(element h1 (create-heading 24pt))
(element h2 (create-heading 18pt))

Verwenden Sie beim Stylen beispielsweise mathematische Konstrukte, um Tabellenzeilenstreifen zu erstellen:

(element TR
  (if (= (modulo (child-number) 2)
        0)
    ...   ;even-row
    ...)) ;odd-row

Um Sie noch eifersüchtiger zu machen, nehmen wir an, DSSSL könnte geerbte Werte als Variablen behandeln und mathematische Operationen an ihnen ausführen:

(element H1
  (make paragraph
    font-size: (+ 4pt (inherited-font-size))))

Leider hatte DSSSL einen schwerwiegenden Fehler, der allen Sprachen im Schema-Stil gemeinsam war: zu viele Klammern. Darüber hinaus war die Spezifikation zum Zeitpunkt der endgültigen Veröffentlichung zu vollständig , was die Browserentwickler einschüchterte. Die DSSSL-Spezifikation umfasste über 210 individuell gestaltete Eigenschaften.

Weitere Entwicklungsarbeiten führten zur Schaffung von XSL - nicht weniger verwirrend, aber viel populärer als die Sprache für die Dokumententransformation.

Warum Stylesheet gewonnen hat

CSS hat keine übergeordneten Selektoren (eine Möglichkeit, ein übergeordnetes Element basierend auf dem darin enthaltenen untergeordneten Element zu formatieren). Diese Tatsache hat Stack Overflow- Benutzer schon lange geplagt , aber es stellt sich heraus, dass es einen ziemlich guten Grund für ihre Abwesenheit gibt. In den frühen Tagen des Internets wurde es als kritisch angesehen, dass eine Seite gerendert werden konnte, bevor das Dokument vollständig geladen wurde. Mit anderen Worten, es war notwendig, den HTML-Code am oberen Seitenrand rendern zu können, noch bevor der HTML-Code am Ende der Seite vollständig geladen war.

Ein übergeordneter Selektor würde bedeuten, dass die Stile beim Laden des HTML-Dokuments aktualisiert werden müssen. Sprachen wie DSSSL wurden vollständig ausgeschlossen, da sie Vorgänge für das Dokument selbst ausführen konnten, das zum Zeitpunkt des Renderns nicht vollständig verfügbar war. Bert Bose war der

erste, der dieses Problem im März 1995 ansprach und eine Arbeitssprache vorschlug , um es zu lösen. Sein Vorschlag enthält auch eine frühe Version des Emoticon "Smiley" :-).

Die Sprache selbst war in der Syntax eher "objektorientiert":

*LI.prebreak: 0.5
*LI.postbreak: 0.5
*OL.LI.label: 1
*OL*OL.LI.label: A

Das Symbol .kennzeichnet die nächsten Kinder und die *Vorfahren.

Boses Sprache hatte eine weitere interessante Eigenschaft: Es war möglich anzugeben, wie Elemente wie Links im Stylesheet selbst funktionieren:

*A.anchor: !HREF

Im obigen Beispiel haben wir angegeben, dass der Verweis für das Verknüpfungselement der Wert in seinem Attribut ist HREF. Diese Idee, dass das Verhalten von Elementen wie Links kontrolliert werden sollte, war in vielen anderen Vorschlägen beliebt. In der Zeit vor JavaScript gab es keine Möglichkeit, solche Aspekte zu kontrollieren, daher schien es logisch, sie in diese Vorschläge aufzunehmen.

In einem Entwurf einer funktionalen Sprache, der 1994 von einem Herrn namens S.M. Sperberg-McQueen, das gleiche Verhalten wird funktional implementiert:

(style a
  (block #f)     ; format as inline phrase
  (color blue)   ; in blue if you’ve got it
  (click (follow (attval 'href)))  ; and on click, follow url

In seiner Sprache wurde das Schlüsselwort auch eingeführt content, um den Inhalt eines HTML-Elements aus einem Stylesheet heraus zu bearbeiten. Dieses Konzept wurde später in CSS 2.1 hinzugefügt.

Was das Web sein könnte

Bevor wir über die Sprache sprechen, aus der tatsächlich CSS wurde, sollten wir noch einen weiteren Sprachvorschlag erwähnen, schon allein deshalb, weil es gewissermaßen der Traum der ersten Webentwickler war.

PSL96 war, wie der Name schon sagt, die 1996er Version der Presentation Specification Language. PSL sieht im Kern wie CSS aus:

H1 {
  fontSize: 20;
}

Die Dinge werden jedoch schnell viel interessanter. Zum Beispiel war es möglich, die Position eines Elements nicht nur abhängig von der Größe ( Width) auszudrücken, die ihm gegeben wurde , sondern auch von der Actual WidthGröße true ( ), in der es im Browser gerendert wird:

LI {
  VertPos: Top = LeftSib . Actual Bottom;
}

Sie können dem Beispiel entnehmen, dass Sie auch das linke Geschwister als Einschränkung verwenden können.

Boolesche Ausdrücke können auch zu Stilen hinzugefügt werden. Hier ist ein Beispiel für das Stylen nur von Ankerelementen mit href:

A {
  if (getAttribute(self, "href") != "") then
    fgColor = "blue";
    underlineNumber = 1;
  endif
}

Dieses Styling könnte auf alle möglichen Aspekte ausgedehnt werden, für die wir heute Klassen verwenden:

LI {
  if (ChildNum(Self) == round(NumChildren(Parent) / 2 + 1)) then
    VertPos: Top = Parent.Top;
    HorizPos: Left = LeftSib.Left + Self.Width;
  else
    VertPos: Top = LeftSib.Actual Bottom;
    HorizPos: Left = LeftSib.Left;
  endif
}

Die Unterstützung dieser Funktionalität würde es wahrscheinlich ermöglichen, endlich den Traum von der Trennung von Inhalt und Stil zu verwirklichen. Leider ist diese Sprache zu erweiterbar, dh es bestand eine hohe Wahrscheinlichkeit, dass ihre Implementierung in verschiedenen Browsern sehr unterschiedlich ist. Darüber hinaus wurde es in einer Reihe von Artikeln in der wissenschaftlichen Welt veröffentlicht und nicht auf der www-talk-Mailingliste, auf der der Großteil der konstruktiven Arbeit stattfand. Es wurde noch nie in einen gängigen Browser integriert.

Geist der Vergangenheit CSS

Die Sprache, die direkt zur Erstellung von CSS führen konnte (zumindest wie der Name schon sagt), war CHSS (Cascading HTML Style Sheets). Es wurde vorgeschlagen , im Jahr 1994 von Håkon W Lie.

Wie die meisten guten Ideen war der ursprüngliche Vorschlag ziemlich verrückt.

h1.font.size = 24pt 100%
h2.font.size = 20pt 40%

Achten Sie auf die Prozentsätze am Ende der Regeln. Dieser Prozentsatz gibt an, wie viel "Eigentum" das aktuelle Stylesheet über diesen Wert hat. Wenn für das vorherige Stylesheet h2beispielsweise eine Schriftgröße 30ptfür 60%"Besitz" und für das h2Stylesheet ein Stil für "Besitz" angegeben wurde 20px 40%, können die beiden Werte basierend auf ihrem Eigentumsanteil kombiniert werden, um einen Wert von etwa zu erhalten 26pt.

Es ist durchaus verständlich, warum ein solcher Vorschlag im Zeitalter dokumentarischer HTML-Seiten gemacht wurde: Ein solches Design, das auf Kompromissen basiert, würde in unserer anwendungsorientierten Welt nicht verstanden werden. Wie dem auch sei, es entstand die Grundidee der Notwendigkeit einer kaskadierenden Stylesheet-Struktur. Mit anderen Worten, die Idee, dass mehrere Stylesheets auf derselben Seite benötigt werden.

In der ursprünglichen Formulierung wurde diese Idee allgemein als wichtig anerkannt, da sie dem Endbenutzer die Kontrolle über das gab, was er sah. Die Originalseite könnte ein Stylesheet haben, und der Webbenutzer könnte ein eigenes Stylesheet haben, und sie könnten kombiniert werden, um die Seite zu rendern. Die Unterstützung mehrerer Stylesheets wurde als eine Möglichkeit zur Wahrung der persönlichen Freiheit im Web angesehen, nicht als eine Möglichkeit zur Unterstützung von Entwicklern (die immer noch jede einzelne HTML-Seite von Hand codiert haben).

Der Benutzer kann möglicherweise sogar den Grad der Kontrolle steuern, den er den Empfehlungen des Seitenautors gegeben hat. Eine solche Kontrolle im Sprachsatz wurde durch das ASCII-Schema beschrieben:

       User                   Author
Font   o-----x--------------o 64%
Color  o-x------------------o 90%
Margin o-------------x------o 37%
Volume o---------x----------o 50%

Wie viele dieser Annahmen enthielt dieses Projekt Funktionen, die erst Jahrzehnte später, wenn überhaupt, in CSS auftauchten. Zum Beispiel war es möglich, logische Ausdrücke basierend auf der Benutzerumgebung zu schreiben:

AGE > 3d ? background.color = pale_yellow : background.color = white
DISPLAY_HEIGHT > 30cm ? http://NYT.com/style : http://LeMonde.fr/style

In einer eher optimistischen Science-Fiction-Vision der Zukunft wurde angenommen, dass der Browser wissen würde, wie relevant jeder Inhalt für den Benutzer ist, sodass er in einer größeren Größe angezeigt werden kann:

RELEVANCE > 80 ? h1.font.size *= 1.5

Wir alle wissen, was als nächstes passiert ist

Microsoft setzt sich voll und ganz für offene Standards ein, insbesondere im Internet.

- John Ludeman, 1994

Haakon Lee arbeitete weiter an der Vereinfachung seines Vorschlags und veröffentlichte gemeinsam mit Bert Bose im Dezember 1996 die erste Version der CSS-Spezifikation. Am Ende schrieb er seine Doktorarbeit über das Erstellen von CSS, und dieses Dokument half mir enorm beim Schreiben des Artikels.

Im Vergleich zu vielen anderen Vorschlägen war der bemerkenswerte Aspekt von CSS seine Einfachheit. Es ist leicht zu analysieren, leicht zu schreiben und leicht zu lesen. Wie so oft in der Geschichte des Internets ist der Gewinner die Technologie, die für Anfänger am einfachsten zu beherrschen ist, und nicht die, die sich für Spezialisten als die leistungsstärkste herausstellt.

Dies an sich ist eine Erinnerung daran, wie zufällig Innovation sein kann. Zum Beispiel Unterstützung für Kontext-Selektoren (body ol li) wurde nur hinzugefügt, weil Netscape bereits die Möglichkeit hatte, Rahmen von Bildern zu entfernen, bei denen es sich um Hyperlinks handelte, und es schien notwendig, alles zu tun, was der beliebte Browser tun konnte. Die Funktionalität selbst verursachte eine erhebliche Verzögerung bei der Implementierung von CSS, da zu der Zeit die meisten Browser beim Parsen von HTML keinen "Stapel" von Tags speicherten. Dies bedeutete, dass die Parser neu gestaltet werden mussten, um CSS vollständig zu unterstützen.

Aufgrund dieser Probleme (und der weit verbreiteten Verwendung von nicht standardmäßigen HTML-Tags für das Styling) war CSS erst 1997 verwendbar und wurde bis März 2000 von keinem Browser vollständig unterstützt. Wie jeder Entwickler Ihnen sagen wird, war die Browserunterstützung weit davon entfernt, standardkonform zu sein, und dies änderte sich erst vor wenigen Jahren, fünfzehn Jahre nach der Veröffentlichung von CSS.

Netscape 4 CSS, <body>, , IE4 <body> , , CSS ? CSS. , IE4 , Netscape 4.

—

Internet Explorer 3 ist dafür bekannt, mit (ziemlich schrecklicher) CSS-Unterstützung veröffentlicht zu werden. Es wurde beschlossen, dass diese Sprache auch unterstützt werden muss, um in Netscape 4 mithalten zu können. Anstatt die Anstrengungen zur Implementierung dieser dritten Sprache (nach HTML und JavaScript) zu verdoppeln, wurde beschlossen, sie zu implementieren, indem CSS in JavaScript umgewandelt und anschließend ausgeführt wird. Schlimmer noch, es wurde entschieden, dass dieses JavaScript-Stylesheet für Webentwickler verfügbar sein sollte .

Die Syntax war einfaches JavaScript mit der hinzugefügten Styling-API:

tags.H1.color = "blue";
tags.p.fontSize = "14pt";
with (tags.H3) {
  color = "green";
}

classes.punk.all.color = "#00FF00"
ids.z098y.letterSpacing = "0.3em"

Es war sogar möglich, Funktionen zu definieren, deren Werte bei jedem Auftreten eines Tags berechnet wurden :

evaluate_style() {
  if (color == "red"){
    fontStyle = "italic";
  } else {
    fontWeight = "bold";
  }
}

tag.UL.apply = evaluate_style();

Die Idee, die Trennlinie zwischen Stilen und Skripten zu vereinfachen, ist durchaus vernünftig und wird heute sogar in der React-Community wiedergeboren .

JavaScript selbst war zu dieser Zeit eine sehr junge Sprache, aber dank Reverse Engineering wurde die Unterstützung in IE3 (in Form von JScript) hinzugefügt. Ein viel größeres Problem war, dass sich die Community zu diesem Zeitpunkt bereits um CSS versammelte und Netscape von den meisten Standard-Communitys zu dieser Zeit als Täter angesehen wurde . Als Netscape dem Normungsausschuss JSSS vorschlug , war es taub. Drei Jahre später stellte Netscape 6 die Unterstützung für JSSS ein und es starb allmählich.

Was könnte uns erwarten?

Dank der öffentlichen Kritik des W3C wurde Internet Explorer 5.5 im Jahr 2000 mit fast vollständiger CSS1-Unterstützung veröffentlicht. Wie wir jetzt wissen, waren Browser-Implementierungen von CSS seit mindestens einem weiteren Jahrzehnt furchtbar fehlerhaft und schwierig zu handhaben. Glücklicherweise hat sich die Situation heute erheblich verbessert, was es endlich möglich machte, den Traum von Entwicklern zu verwirklichen, dass man Code einmal schreiben kann und er in verschiedenen Browsern (fast) gleich funktioniert.

Persönlich habe ich aus all dem gezogen, wie willkürlich und kontextbezogen die Entscheidungen waren, die unsere modernen Werkzeuge bestimmen. Wenn CSS so konzipiert wurde, dass es mit den Einschränkungen von 1996 kompatibel ist, dann vielleicht zwanzig Jahre später, was uns die Erlaubnis gibt, die Dinge ein wenig anders zu machen.

Sprachen, die fast zu CSS wurden