ほぼCSSになった言語

こんにちは、Habr！歴史が少し違っていれば、CSSになる可能性のある言語について、ザックブルームがCSSになった言語の翻訳に注目します。

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



— , 1994

Tim Berners-Leeが1991年にHTMLの作成を発表したとき、ページのスタイルを設定する方法はありませんでした。 HTMLタグのレンダリング方法はブラウザによって決定され、ユーザーの好みに大きく影響されました。ただし、ページが好みのスタイルのレンダリングについて「ヒント」を与えることができる標準ツールを作成することは良い考えのように思われました。



しかし、CSSが登場する前は、まだ5年であり、完全に実装されるまでにはさらに10年かかりました。それは、標準になる可能性のある多くの競合する様式の作成につながった、ハードワークと革新の期間でした。



これらの言語は明らかに今日広く使用されていませんが、世界がどのようなものであるかを考えることは私にとって興味深いことです。さらに驚くべきことに、これらの言語の多くには、開発者が今日でもCSSで喜んで使用する機能があります。

最初の候補者

1993年の初めには、モザイクブラウザはバージョン1.0にさえ到達せず、既存のすべてのブラウザはHTMLでのみ機能していました。HTMLスタイルを指定する方法がなかったので<h1>、ブラウザーがタグを表示することを決定した方法でタグが表示されました。



同年6月、Robert Reischはwww-talkメーリングリストに、「Webドキュメントとともにスタイル情報を伝達するための簡単に解析できる形式」を作成する提案を提出しました。これをRRPと呼びました。

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

このコードが何をするのか理解していなければ、それは非常に許されます。 gzip以前の時代、接続速度が通常14.4 kbps未満であったとき、この新しいフォーマットのコンテンツを可能な限りコンパクトに保つ​​ことは論理的でした。具体的には、このルールは、フォントファミリfa（he）としてHelvetica（）を選択し、フォントサイズ（si）を18ポイントに設定します。



不思議なことに、Reischの提案には単位がなく、すべての数値はコンテキストに基づいて解釈されていました（たとえば、すべてのフォントサイズはポイント単位でした）。これは、RRPが仕様ではなく、「レンダラー向けのヒントとコツのセット」として設計されているためです。同じスタイルシートが通常のテキストモードブラウザで機能するはずだったため、これが必要であると考えられました（Lynx）、そしてますます人気のあるグラフィカルブラウザで。





Lynxブラウザのスクリーンショット



興味深いことに、RRPには列レイアウトを指定する方法が含まれています。これは2011年までCSSでは不可能でした。たとえば、それぞれ幅80ユニットの3つの列は、次のようになります。

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

解析するのは少し難しいですが、おそらくwhite-space: nowrap。よりもそれほど難しいことではありません。



RRPは、スタイルシートを今日関連付ける「カスケード」のいずれもサポートしていなかったことは注目に値します。今日の私たちにとっては珍しいことですが、どのドキュメントにも一度に1つのアクティブなスタイルシートしか含めることができません。これは、ドキュメントのスタイル設定の場合には非常に論理的です。



Mark Andreessen（Mosaicの作成者であり、最終的に最も人気のあるブラウザーになりました）は、RRPの提案について知っていましたが、Mosaicに実装したことはありませんでした。代わりに、MosaicはほとんどすぐにスタイリングにHTMLタグを使用するという道を歩み（これはかなり悲劇的です）、<FONT>やのようなタグを追加しました<CENTER>。

ビオラとプロトブラウザウォーズ

「それなら、そこにある多くのスタイルシート提案の1つを実装しないのはなぜですか。適切な構造があれば、これで問題はほぼ完全に解決されます。」

次に、「ドキュメントを作成するにはこの言語を学習してから、ドキュメントを希望どおりに表示するために別の言語を学習する必要があります」と人々に伝える必要があります。ああ、彼らはそれを好きになるでしょう。



-マーク・アンドリーセン、1994年

一般に信じられていることとは反対に、Mosaicは最初のグラフィカルブラウザではありませんでした。その前に、Pei- YuanWeiがわずか4日で作成したグラフィカルブラウザであるViolaWWWがありました。





Viola Browser



Pei-Yuanのスクリーンショットは、今日のCSSで使用されている種類の階層構造をサポートするスタイルシート言語を作成しました。

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

この場合、ドキュメントの本文（本文）に色を適用し、特にH1本文内のスタイリングを行います。このネストを制御するためにセレクターを繰り返す代わりに、PWPは括弧システムを使用しました。これにより、スタイラスやSASSなどの言語で使用されているインデントシステムを思い浮かべることができます。これにより、PWP構文は、Webのユニバーサル言語に時間とともに進化してきたCSSよりも少なくとも1つの点で優れている可能性があります。



PWPには、現在でも使用されている外部スタイルシートを参照する方法があることも注目に値します。

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

残念ながら、ViolaWWWは、主にXウィンドウシステムで動作するように作成されました。Xウィンドウシステムは、Unixシステムでのみ一般的でした。MosaicがWindowsに移植されたとき、それはすぐにViolaを粉々にしました。

ウェブの前のスタイルシート

HTMLは、コンピューター科学者だけが恋に落ちるようなものです。はい、それはドキュメントの内部構造を表しますが、ドキュメントは構造化されたテキストデータベースだけではありません。それらは視覚的な影響を及ぼします。HTMLは、ドキュメント開発者が持つ可能性のあるグラフィックの創造性を完全に破壊します。



-ロイ・スミス、1993年

ドキュメントのスタイルを表現できる言語の必要性は、インターネット自体よりもはるかに古いものです。



ご存知かもしれませんが、私たちが知っているHTMLは、もともとSGMLと呼ばれるインターネット以前の言語に基づいていました。 1987年、米国国防総省は、SGMLを使用して膨大な量のドキュメントの保存と転送を簡素化できるかどうかをテストすることを決定しました。他の優れた政府プロジェクトと同様に、彼らが最初にしたことは名前を思いつくことでした。このチームは当初、コンピューター支援ロジスティクスサポートチーム、次にコンピューター支援取得およびロジスティクスサポートチーム、そして最後に継続的取得およびライフサイクルサポートイニシアチブと呼ばれていました。いずれにせよ、イニシャルはCALSでした。



CALSチームは、FOSIと呼ばれるSGMLドキュメントのスタイルを設定するための言語を作成しました。彼女は出版した理解できないほど詳細な言語仕様。これには、これまでWeb上に存在した中で最も意味のないインフォグラフィックの私のお気に入りが含まれていました。



例外のないインターネットのルールの1つは、プロセスで誰かが間違っていることを証明できれば、常により多くのことを成し遂げることです。 Pei-Yuanの提案からわずか4日後の1993年、Stephen Heaneyは、ホイールを再発明する代わりに、FOSIバージョンの方がWebのスタイリングに適していると提案しました。



FOSIドキュメント自体はSGMLで記述されています。これは、Web開発者がHTMLと呼ばれるSGMLのバージョンに精通していることを考えると、かなり論理的な動きです。サンプルドキュメントは次のようになります。

<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>

おそらく、あなたはそれが何であるかを理解していないdocdescか、charlistメンバーがそれを理解していなかったのと同様に、www-talk。唯一のコンテキスト情報は、e-i-c「コンテキスト内の要素」の意味です。ただし、FOSIが初めて測定単位を導入したことは注目に値しemます。これは、CSSでのサイズ設定の推奨される方法になりました。



結果として生じる言語の競合は、実際にはプログラミング自体と同じくらい古いものでした。それは、機能的なlispスタイルの構文とより宣言的な言語の構文との間の戦いでした。Pei-Yuan自身が彼の構文を「LISPのような」と表現しましたが、真のLISPバージョンが登場するのは時間の問題でした。

チューリング-完全なスタイルシート

その複雑さにもかかわらず、FOSIは実際にはドキュメントのフォーマットの問題に対する中間的な解決策として認識されていました。長期計画は、機能的なプログラミング言語スキームに基づいて、考えられる最も強力なドキュメント変換を実装できる言語を作成することでした。この言語はDSSSLと名付けられました。言語の開発者の1人であるJohnBosakに発言権を与えましょう。

DSSSLをスクリプト言語と間違えないでください。はい、DSSSLはTuringが完了しています。はい、それはプログラミング言語です。しかし、スクリプト言語（少なくとも私の用語の解釈では）は手続き型です。DSSSLは間違いなくそうではありません。DSSSLは完全に機能し、副作用はまったくありません。DSSSLスタイルシートでは何も起こりません。スタイルシートは1つの巨大な関数であり、その値は、レンダリングされる領域の仕様（必要に応じて宣言）として、基になるレンダラーに渡される、フォーマットされたドキュメントの抽象的な、デバイスに依存しない、非手続き的な説明です。

最も単純な形式では、DSSSLは確かにかなり論理的なスタイリング言語です。

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

それはプログラミング言語だったので、その中で関数を定義することさえできました：

(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))

また、スタイリング時に数学的な構成を使用して、たとえば、テーブルの行をストライプにします。

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

さらに嫉妬させるために、DSSSLが継承された値を変数として扱い、それらに対して数学的な操作を実行できるとしましょう：

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

残念ながら、DSSSLには、すべてのスキームスタイルの言語に共通する致命的な欠陥がありました。括弧が多すぎます。さらに、その仕様は最終リリースの時点で過度に完全であり、ブラウザ開発者を脅かしていました。DSSSL仕様には、210を超える個別のスタイル付きプロパティが含まれていました。



さらなる開発作業により、XSLが作成されました。これは、同様に複雑ですが、はるかに人気のあるドキュメント変換言語です。

スタイルシートが勝った理由

CSSには親セレクター（含まれている子に基づいて親のスタイルを設定する方法）がありません。この事実はいられ 苦しめる スタックオーバーフローユーザーの ために長い時間が、それは彼らの不在のためにかなり良い理由がある判明します。インターネットの初期には、ドキュメントが完全に読み込まれる前にページをレンダリングできることが重要であると考えられていました。つまり、ページの終わりのHTMLが完全に読み込まれる前に、ページの先頭のHTMLをレンダリングできる必要がありました。



親セレクターがあるということは、HTMLドキュメントがロードされるときにスタイルを更新する必要があることを意味します。DSSSLのような言語は、レンダリング時に完全には利用できなかったドキュメント自体に対して操作を実行できるため、完全に除外されました。Bert Boseは、



1995年3月にこの問題を最初に提起し、それを解決するための実用的な言語を提案しました。彼の提案には、エモティコン「スマイリー」の初期バージョンも含まれています:-)。



言語自体は、構文においてかなり「オブジェクト指向」でした。

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

記号.は、最も近い子と*祖先を示しています。



Boseの言語には、別の興味深い特性がありました。リンクなどの要素がスタイルシート自体でどのように機能するかを指定できます。

*A.anchor: !HREF

上記の例では、link要素の参照がその属性の値であることを指定しましたHREF。リンクなどの要素の動作を制御する必要があるというこの考えは、他の多くの提案で人気があります。JavaScript以前の時代には、そのような側面を制御する方法がなかったので、これらの提案にそれらを含めることは論理的であるように思われました。1994年にS.M.という名前の紳士によって提案された機能言語のドラフトの



1つ。Sperberg-McQueen、同じ動作が機能的に実装されています。

(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

彼の言語でcontentは、スタイルシートからHTML要素のコンテンツを操作する方法としてキーワードも導入されました。この概念は、後でCSS2.1で追加されました。

ウェブは何でしょうか

実際にCSSになった言語について話す前に、ある意味で最初のWeb開発者の夢だったという理由だけで、もう1つの言語提案について言及する価値があります。



PSL96は、その名前が示すように、1996年版のプレゼンテーション仕様言語でした。基本的に、PSLはCSSのように見えます。

H1 {
  fontSize: 20;
}

しかし、物事はすぐにはるかに興味深いものになります。たとえば、要素の位置は、与えられたサイズ（Width）だけでなくActual Width、ブラウザでレンダリングされる実際の（）サイズにも応じて表現することができます。

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

例から、左側の兄弟を制約として使用することもできることがわかります。



ブール式をスタイルに追加することもできます。次のようなアンカー要素のみをスタイリングする例を次に示しますhref。

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

このスタイリングは、今日私たちがクラスを使用しているあらゆる種類の側面に拡張できます。

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
}

この機能をサポートすることで、コンテンツをスタイルから分離するという夢をようやく実現できるようになるでしょう。残念ながら、この言語は拡張性が高すぎます。つまり、ブラウザによって実装が大きく異なる可能性が高くなりました。さらに、建設的な作業の大部分が行われたwww-talkメーリングリストではなく、科学界の一連の記事で公開されました。人気のあるブラウザに統合されたことはありません。

過去のCSSの幽霊

CSSの作成に直接つながる可能性のある言語（少なくとも名前が示すように）は、CHSS（Cascading HTML Style Sheets）でした。それはされた提案ホーコンWリーによって1994年に。



ほとんどの良いアイデアのように、最初の提案はかなりクレイジーでした。

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

ルールの最後にあるパーセンテージに注意してください。このパーセンテージは、現在のスタイルシートがその値に対してどれだけの「所有権」を持っているかを意味します。たとえば、前のスタイルシートh2が「所有権」30ptからのフォントサイズに設定されていて60%、そのスタイルシートh2がのスタイルを指定している場合20px 40%、所有権の割合に基づいて2つの値を組み合わせて、約の値を取得できます26pt。



ドキュメンタリーHTMLページの時代にそのような提案がなされた理由は非常に理解できます。トレードオフに基づくそのような設計は、アプリケーション指向の世界では理解されません。とはいえ、カスケードスタイルのシート構造の必要性という基本的なアイデアが思い浮かびました。言い換えれば、同じページに複数のスタイルシートが必要であるという考えです。



元の定式化では、このアイデアは、エンドユーザーが見たものを制御できるため、一般的に重要であると認識されていました。元のページに1つのスタイルシートを含めることができ、Webユーザーに独自のスタイルシートを作成し、それらを組み合わせてページをレンダリングすることができます。複数のスタイルシートをサポートすることは、開発者（すべてのHTMLページを手作業でコーディングしている）をサポートする方法ではなく、Web上で個人の自由を維持する方法と見なされていました。



ユーザーは、ページ作成者の推奨事項に与えた制御の程度を制御できる場合もあります。言語文におけるそのような制御は、ASCIIスキームによって記述されました。

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

これらの多くの仮定と同様に、このプロジェクトには、まったくないにしても、わずか数十年後にCSSに登場した機能が含まれていました。たとえば、ユーザーの環境に基づいて論理式を作成する機能がありました。

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

将来のかなり楽観的なSFビジョンでは、ブラウザは各コンテンツがユーザーにどの程度関連しているかを認識し、より大きなサイズで表示できるようになると考えられていました。

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

私たちは皆、次に何が起こったのか知っています

マイクロソフトは、特にインターネット上で、オープンスタンダードに全力で取り組んでいます。



-ジョン・ルードマン、1994年

Haakon Leeは引き続き提案の簡素化に取り組み、Bert Boseと共同で、1996年12月にCSS仕様の最初のバージョンを公開しました。彼はCSSの作成に関する博士論文を書くことになり、このドキュメントは私がこの記事を書くのに大いに役立ちました。



他の多くの提案と比較して、CSSの注目すべき側面はその単純さでした。解析、書き込み、読み取りが簡単です。インターネットの歴史でよくあることですが、勝者は初心者にとって最も習得しやすい技術であり、専門家にとって最も強力であることが判明した技術ではありません。



これ自体が、ランダムなイノベーションがいかにあり得るかを思い出させるものです。たとえば、コンテキストセレクターのサポート（body ol li）が追加されたのは、Netscapeにはすでにハイパーリンクである画像から境界線を削除する方法があり、一般的なブラウザで実行できるすべてのことを実行する必要があるように思われたためです。当時、ほとんどのブラウザはHTMLを解析するときにタグの「スタック」を保存していなかったため、機能自体がCSSの実装に大幅な遅延を引き起こしました。これは、CSSを完全にサポートするためにパーサーを再設計する必要があることを意味しました。



これらの問題（およびスタイリングに非標準のHTMLタグが広く使用されている）のため、CSSは1997年まで使用できず、2000年3月までどのブラウザーでも完全にはサポートされませんでした。開発者なら誰でも言うように、ブラウザのサポートは標準に準拠することにはほど遠いものであり、CSSがリリースされてから15年後の数年前に変更されました。

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



—

Internet Explorer 3は、（かなりひどい）CSSサポート付きでリリースされることで知られています。Netscape 4で競争できるようにするには、この言語のサポートも必要であることが決定されました。ただし、この3番目の言語（HTMLとJavaScriptの後）を実装するための努力を倍加する代わりに、CSSをJavaScriptに変換して実行することによって実装する必要があることが決定されました。さらに悪いことに、この中間JavaScriptスタイルシートをWeb開発者が利用できるようにすることが決定されました。



構文は、スタイリングAPIが追加されたプレーンJavaScriptでした。

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

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

タグが出現するたびに 値が計算される関数を定義することも可能でした：

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

tag.UL.apply = evaluate_style();

スタイルとスクリプトの境界線を単純化するというアイデアは非常に合理的であり、今日ではReactコミュニティで生まれ変わっています。



JavaScript自体は当時非常に若い言語でしたが、リバースエンジニアリングのおかげで、JavaScriptのサポートがIE3（JScriptの形式）で追加されました。はるかに大きな問題は、コミュニティがその時点ですでにCSSを中心に結集しており、Netscapeが当時のほとんどの標準コミュニティから犯罪者と見なされていたことでした。NetscapeがJSSSを標準化委員会に提案したとき、それは耳を貸さなかった。3年後、Netscape 6はJSSSのサポートを終了し、徐々に機能しなくなりました。

何が私たちを待っているのか

W3Cからの公的な非難の おかげで、Internet Explorer 5.5は、2000年にほぼ完全なCSS1サポートとともにリリースされました。もちろん、私たちが今知っているように、CSSのブラウザ実装はひどくバグがあり、少なくともあと10年間は​​操作が困難でした。幸いなことに、今日の状況は大幅に改善され、コードを1回記述すれば、さまざまなブラウザーで（ほぼ）同じように機能するという開発者の夢をようやく実現することができました。



個人的に、私はこれらすべてから、現代​​のツールを支配する決定がいかに恣意的で文脈的なものであったかを引き出しました。CSSが1996年の制約と互換性があるように設計されている場合、おそらく20年後、それによって少し異なる方法で作業を行うことが許可されます。