CSSフレームワークについて考えてみた
2009年2月19日、CSS Nite in Ginza Vol.31に行ってきました。
CSS Nite自体は既知の復習だったので残念ながら「新しい何かを学ぶ」というものではありませんでした。しかしながらCSS Nite後の懇親会で、プレゼンテーターの小林さんに興味深いお話を聞かせて頂いたのでそれをまとめておきます。（なので、今回はイベント自体のレポートはナシです）
小林さんのセッション内容はIE6が持つCSS関連のバグを修正する方法でした。その中で小林さんは、自分で作成したフレームワークを利用してブラウザ毎の挙動の差違を吸収していました。
この点が、僕にとってはとても不思議でなりませんでした。
「何故オープンソースCSSフレームワークの類でブラウザ毎の差違を吸収しないんだろう？」
オープンソースCSSフレームワークがあるのに、敢えて自分フレームワークを利用するのは、「車輪の再発明」に思えてならなかったのです。
その時はお酒の場ということもあり、あまり込み入った話を聞く事ができなかったのですが、翌日以降メールで細かいフォローをしていただきました。小林さん、お忙しい中ありがとうございます。
以下、メールの内容を会話形式でお届けします。
S(瀬筒): 何故、CSS Niteの中で「Yahoo! UI Library」のようなオープンソースCSSフレームワークについて触れられなかったのでしょうか？
K(小林さん): オープンソースCSSフレームワークは「CSSありき」の考え方で作られているため、「HTMLありき」の考え方に反するからです。
S: 「CSSありき」の考え方とは？
K: 例えばYUIライブラリの「gird.css」を見てみますと、「#doc,#doc2,#doc3,#doc4,.yui-t1,.yui-t2,.yui-t3,.yui-t4,.yui-t5,.yui-t6,.yui-t7」のようなセレクタが記述されています。ですので「gird.css」を利用しようと思うと、おのずとそれにあわせたXHTMLを記述しなければならないということになります。
そもそもCSSのセレクタにあわせたid／class名をXHTMLに記述するというのは、XHTML+CSSの考え方にそっていないんですよね。「XHTMLあってのCSS」と考えている方が多いので、CSSフレームワークのように「CSSあってのXHTML」という流れに違和感を感じるんだと思います。
S: サーバーフレームワークでは、多くの人が様々なプラグインを作成・公開することで効率的な開発ができるようになっています。
CSSフレームワークも、多くの人の英知が詰まった、ある種のデファクトスタンダードが必要なのでは？
K: XHTML+CSSでの作業効率を挙げる工夫は必要でして、現在大きめの制作会社で採用されているのは、もともとbA（ビジネス・アーキテクツ社）がひろめた、コンポーネントベースのWEBサイト制作が一般的になっているようです。
S: Flashなどと同じ流れですね。尤も、HTMLやCSSの本質的には「まずHTMLありき」にすべきでしょうが、実際の制作効率はそれとは違うところにある場合もありますからね。お忙しい中、時間を割いて回答いただき、ありがとうございました。
というわけで、小林さんのお話をまとめると大体以下のような内容になるかと思います。
- オープンソースCSSフレームワークを使用するということは、開発チームの設計思想に従う事になる。（YUIのreset-fonts-grids.cssなどでは、予め「#doc,#doc*,.yui-t*」などのセレクタが定義されているため）
- これらの設計思想に従うという事は、すなわち「CSSありき」のコーディングを余儀なくされる。
- つまり、HTMLがあってのCSSという、HTMLとCSSの本来の在り方を否定してしまう。
- だから、「#doc,#doc*,.yui-t*」など、CSSありきの部分を持たない自分フレームワークを作る事で「HTML+CSS」という本来の在り方に則ったコーディングを行う。
なるほど、確かにその通りだと思います。
ですが、プログラマとして上記の話を聞いた時に、どうしても納得いかない部分があったのです。
CSSを、JavaScriptと同じ「HTMLにインタラクティブな要素を与えるもの」として考えた場合に、上記の話だと 「ライブラリの一部に使わない機能があって、それがどうしても我慢できないから自分で別途ライブラリを作り直す」 と主張されているように感じてしまいました。
懇切丁寧にご説明いただいた小林さんには申し訳ないのですが、説明を受けた後でも僕には「自分フレームワーク」が「車輪の再発明」に思えてなりません。
（もっとも、CSS Niteの後で小林さんの作ったフレームワークは公開されているため、「自分フレームワーク」の域を超えてしまっていますが……）
というわけで、出来る限り公平な視点で、オープンソースCSSフレームワークと自分フレームワークを対比してみました。
| オープンソースCSSフレームワーク | 自分フレームワーク |
|---|---|
| 開発チームが常に最新のブラウザに対応するために修正を加えている（メンテナンスコストがほぼゼロ） | 最新ブラウザへの対応には、自分でメンテナンスを行う必要がある（メンテナンスコストが大きい） |
| 開発チームの設計思想により、不必要な機能が追加されがち（ファイルサイズが大きくなりやすい） | 最低限必要な機能に絞り込んで作ることができる（ファイルサイズが小さくなる） |
| 対応ブラウザさえ理解しておけば、フレームワーク自身のテストはほとんど不要 | 多くのブラウザに対応しようとすると、様々なブラウザやPCが必要になる（時間とお金がかかる） |
| 開発チームの都合により、突然開発が中止される可能性がある | 自分自身でメンテナンスしているため、突然フレームワークが使えない事態に陥る可能性は少ない |
当然ですが、どちらの場合も一長一短あるため、必ずしもどちらがいい、とは言えないと思います。
さて、今年中にはIE8が登場しますし、来年頭にはWindows7も発売予定です。さらにIE自体のシェアもどんどん下がっています。もしかすると数年後には「全てのブラウザがAcidテスト満点」なんて事になっているかもしれませんね。
その時、CSSフレームワークは「不要なもの」になっているかもしれません。
小林さん、本当にありがとうございました。
WEB開発, フレームワーク, CSS Nite, コーディングスタイル, CSS |
comments(2) |
trackbacks(2)
2009.03.08 Sun 17:27
TRACKBACKS
- CSS Nite in Ginza, Vol.31が終了しました。 - CSS Nite公式サイト
- 2009年2月19日、アップルストア銀座にてCSS Nite in Ginza...
- CSS Nite in Ginza, Vol.31フォローアップ（3）小林さん - CSS Nite公式サイト
- 2009年2月19日に開催したCSS Nite in Ginza, Vol.3...
この記事へのトラックバックURL: http://www.red-mount.com/trackback/36_43e7aa3237e105384372da2187642248dd96fd9b
ABOUT ME
tak (Takahito Sezutsu)
コメント、トラックバックはお気軽に！
COMMENTS
-
Versions - Macで使えるGUIベースのSubversionクライアント
→TANIARollins23 (07.23) -
Rails勉強会@東京第38回 行ってきました
→TamikaTurner (07.04) -
MacのSkypeでログイン時プルダウンメニューに表示されるSkype名を消す方法
→tak (06.22) -
「オリジナルの項目が見つからなかったので、エイリアス“********”は開けません。」と出て、Finderで外付けHDDが開けない時は
→tak (06.22) -
「オリジナルの項目が見つからなかったので、エイリアス“********”は開けません。」と出て、Finderで外付けHDDが開けない時は
→ko (06.22) -
MacのSkypeでログイン時プルダウンメニューに表示されるSkype名を消す方法
→Mac (05.06) -
クックパッドの裏側を見てきました
→Taylor30CLEVELAND (03.23) -
MacのSkypeでログイン時プルダウンメニューに表示されるSkype名を消す方法
→tak (03.11) -
MacのSkypeでログイン時プルダウンメニューに表示されるSkype名を消す方法
→tama (03.11) -
Mac版ATOK定額制(体験版)を1週間使ってみた
→tak (09.19)
COMMENTS
この件について素人意見ですが発言させていただきます。
確かに車輪の再開発になっているような気がします。
自分で開発したフレームワークは自分にとって非常に使いやすいものだと思います。
ただ、仰るように時間とお金のコスト面では到底不利な部分が多いのも事実だと思います。
私は既存のCSSフレームワークから不必要な機能を削る方が現実的だと考えるのですがいかがでしょうか。
素人意見で申し訳ございませんが、参考にお聞かせくださいませ。
コメントへのレスが遅れてしまい、申し訳ありません。
私も既存のCSSフレームワークから不必要な機能を削る方が現実的だと思います。
ただ、不必要な機能を削るとファイルサイズは小さくなるのですが、フレームワークがバージョンアップした際に、再度不必要な部分を探し出し削除する、という手間が発生します。
フレームワークのバージョンアップによる、不要なスタイル指定が大幅に変わる事はないと思いますので、フレームワーク側はいじらず、別途外部CSSを作成し、その中で不要なスタイル指定を初期化してあげた方が良いかもしれません。（テキストファイルであるCSSがロード時間全体に占める割合は微々たるものだと思います）
なお、本文中にあるYUIフレームワークですが、現在は機能によってかなり細かくCSSファイルが分割されているため、必要なファイルのみ読み込ませてあげる事で、不要なクラスなどが読み込まれる機会はかなり減っています。
ですので、僕個人としては、上記のような対処も取らなくなってきています。
参考になれば幸いです。