CSS履歴及び動的CSSに関する123
1. Preface
もしプログラムを書くだけなら、それは確かにそんなに面倒ではありません.直接Syntaxを見て、少なくとも300行のコードを書いて、3つのアプリケーションを作って、この言語はあなたもあまり使いません.次はモード、特殊な場所、いくつかの関数を覚えているだけです.しかし、この言語がなぜこのように設計されているのか、根底を知りたいときは、歴史を振り返るのが最善の選択です.そして、何年も勉強自体の研究を経て、同じことに精通したいなら、研究が誕生を促した問題は、その欠点と長所をより正確に理解し、なぜこの論理なのか、どのように改善するのかなどを理解します.歴史を研究する時、時には発見することができて、その年のいくつかの制限条件が実現できないもっと良い解決策のため、今まさに実施する時です.
2. Style Sheets' History
昔は(もちろん、HTMLがあってから)、みんな学術をしていたので、ほとんどの人はHTMLでドキュメントを伝えるだけで、ブラウザもドキュメントを解析できるようにすればいいだけです.最初は、作者ではなく、読者自身がページの表示方法を調整しただけだった.ゆっくりと、作者も集中的にコントロールしたいと思っていますが、この時のブラウザメーカーは作者を喜ばせるために、JSSのような作者が自分のスタイルを定義できるように多くの属性を設定しています.まずコードを見てみましょう.
(define *heading-font* "Times New Roman")
(define *heading-weight* 'bold)
(define *heading-posture* 'italic)
(element H1
(make paragraph
font-family-name: *heading-font*
font-weight: *heading-weight*
font-posture: *heading-posture*
font-size: 20pt
quadding: 'center))
(element H2
(make paragraph
font-family-name: *heading-font*
font-weight: *heading-weight*
font-posture: *heading-posture*
font-size: 18pt
quadding: 'left))このコードはLisp形式ですが、CSSに詳しいと、「おい、お兄さん、これはスタイルを定義するために使われているように見えます」という感じがします.そうですね.CSSがまだ成形されていないときは、それと並んでDSSSLのスタイルです.LESSとSASSをもっとよく知っていれば、より強力な文法表現と変数定義があるので、もっと感じられます.当時CSSではなくDSSSLを受け入れていたと仮定すると、ハッカーとデザイナーを区別するのは難しい.しかしもちろん、歴史的にはDSSSLはXSLの先輩であり、CSSと比較すべきではない.
JSSは、Netscapeの提案で、死んでひっそりとしていますが、Netscape 4内部ではCSSをJSSに解析して実行しているという噂があります.JSを無効にすればCSSも現れないからです.
Cascading HTML style sheetsとStream-based StyleSheet Proposalの2つのStyle Sheet Proposalをもう一度よく見ると、CSSが2つの提案を統合した利点が大きいことがわかります.
最終的な勝利は、依然として使用者(デザイナー)の勝利であり、より簡単な言語実現を得たからだ.「Hopefully,future Web innovations will emulate the example set by the Web Consortium in its work on CSS.」
2.1関連資料
3. Why no "variables" in CSS ?
当時の他のStyle Sheet LanguageをCSSと比較する必要がある場合は、CSSの起源や言語の設計に役立つ当時の会議記録や議論をひっくり返さなければなりません.特に設計上、CSSは実質的に衆家の長さを吸収し、簡略化した非常に徹底した文法である.他のLispのようなStyle Sheet Languageの実装に気づくと、初期の皆さんが設計したときに変数が記述されていたことがわかりますが、draft 1では「CSS変数と計算」の記述について「very interesting,but potentially complex issue」と注釈されていますが、CSSは最終的に実装する際に式やパラメータの設計を捨てています.これもゲームの結果だと信じています.
もちろん、プログラマーは怠け者の代表として、mailをどんなプログラムにも入れたいという気持ちで、08年にWebkitがCSSワークグループの2人でCSS Variablesのドキュメントを提出し続け(98年に開発界で動的変数を定義したいことが言及された)、変数を増やす方法はAt-rule方式である.変更上はそれほど大きくなく、その後PHPでバージョン(variables in css via php)を実現した人もいれば、現在のLESSやSASSまで、既存の開発者がCSSの組織やアーキテクチャを作るのに役立ちます.しかし、Bert Bos(published Stream-based Stylesheet Proposal,W 3 C Style Sheets Activity Lead)は、ダイナミックなコンテンツを増やすことは余計なことではなく、CSSを複雑にし、Varibleを直接CSSに導入することは適切ではなく、CSSに有害であると考えている.その全文を詳しく見た後、私は彼の言い方を認めた.
Bert Bosの思考は非常に慎重で、さすがにWhat is a good standardを書いたのだろうか.私たちの世代がHTML+CSS+JSをどのように勉強しているかから見ると、確かに彼が考えているのと同じです.また、私が書いたコードをチェックしました.各Selectorに対応する宣言を1行化すると、500行を超えません.importを使えば、ほとんどのコードが簡単になり、実際の状況と変わらないように修正できます.さすがStyle Sheet混戦時代から来た人だけあって、やはり複雑さに敏感.そして、Jakob NielsenがCSSを標準的なベンチマークだと思っているのも無理はない.
しかし、これはあなたがLESSとSassの使用を完全に放棄したという意味ではありません.あなたは彼らを使って作成してからCSSに変換し、ページに引用することができます.しかし、Bert Bosの観点から言えば、Sassは明らかに入選の資格を失い、複雑で柔軟ではない.LESSは簡単な傾向がありますが、どのようにdebugするかは依然として大きな問題です.同時に文法のネストは基本的にCSS重み計算が作成時に体現できないため、多重性が悪い可能性があり、Twitterの開放を学ぶともっと良いかもしれません.このことをどのように解決すべきかは、あなたのプロジェクトがどのように計画されているかにかかっていると思います.