昔とは違う！今時のHTML・CSS設計方法2016
テーブルレイアウトの時代が終わり、正確なマークアップが求められるようになったのは2005年ぐらいからでしょうか？
そこから10年以上が経過したということでマークアップのルール・設計方法も大きく変わりました。今と昔どのくらい変わったのかをまとめてみました。
この記事の目次
2005年当時の「Web標準準拠」のマークアップ
2005年頃主流だったマークアップは今よりも厳格なものでした（それ以前のテーブルレイアウトの反動が大きかったと推測）。
中でもよく言われていたのが「文書構造とデザインの分離」です。
当時は、HTMLではなく、文書として厳格なルールを持つXHTMLが主流でした。よって「文書はあくまでも文書、XHTMLに視覚的な情報を含めてはならない」という考えが強かったんですよね。
もちろん、現在も視覚的情報はCSSに定義するというのがセオリーですが、当時は命名規則においても徹底されていました。
ID、クラス名にも視覚的情報を含めないのが常識だった
例えば、現在であれば赤いボタン、青いボタンのクラス名は「.red-button」、「.blue-button」とすることが多いかも知れません。
でも、Web標準時代ではこのネーミングはNGです。なぜなら、「red」、「blue」という視覚的情報が含まれていますし、それに「button」も視覚的な情報と考える事が出来るからです。
なぜそこまで厳格なルールだったのかと言うと、先ほども言ったように「文書構造とデザインの分離」の為なんです。
「文書構造とデザインの分離」を徹底することで、「デザインの修正が入ってもCSSの修正だけで済ませられる」と考えられていたんですよね。
もし、クラス名に「red」、「blue」といった視覚情報を含めてしまったら、緑のボタンに変更したい場合、XHTML側も「green」と書き換えなければなりませんし、「button」と名付けてしまったら、ボタンぽくないデザインに変えた場合、同様にXHTMLを修正する必要が出てきます。
IDを多用して文書に意味を持たせようとしていた
また、当時は意味を持たせたい要素にはID名を設定することが常識でした。
命名規則もとにかく厳格で、例えば会社概要のページでは「#conpany-profile」、「#company-photo」、「#company-map」といった具合に、とにかく分かりやすい名称を設定していたんですよね。
不要な情報はとにかく排除していた
また、「文書として徹底」する為に、本来の文書に関係のない情報は徹底的に排除されました。
例えば、「container」、「inner」、「wrapper」といったID、クラス名は当時から使われていたわけですが、これもデザインの都合上使っているだけなので、本来の文書には不要なわけです。ですから、こういったものも廃する動きが見られました。
さらには、「div」や「span」といった汎用要素も本来の文書には不要なものである為、「とにかくdivやspanは使わない！」というポリシーでコーディングをしていた人は少なくありませんでした。
これが2005年当時のマークアップの主流です。
当時はそれに価値を感じてやっていたわけですが、Googleの進化が凄まじく、良き様に文書を解釈してくれるようになって来たので、そこまで厳格である必要性が無くなってきてしまったんですよね。
2016年現在は「拡張性」、「汎用性」重視のマークアップがトレンド
現在はHTML5がスタンダードなマークアップ言語になり、文書というよりはアプリのインターフェイスを作る為の言語という意味合いが強くなりました。
もちろん今でも「文書構造とデザインの分離」という基本概念は踏襲されていますが、かなり緩くなった印象です。
文書としての厳格さよりも、拡張性や汎用性に重きを置くようになりました。
ガジェットのようにコピペで設置できるマークアップ設計
2005年当時のWeb標準準拠のマークアップは、文書として意味のあるIDやクラス名でガチガチに固めていた為、文書としては厳格でしたが、拡張性や汎用性は皆無だったんですよね。例えば、会社概要のスタイルを他のページでも使い回すにも、そのページ専用の名称が付いてしまっている為、他のページでは使い回せなかったのです。
その失敗を教訓にして誕生したのが今の概念です。
用途を限定してしまうIDは使用せず、どこでも使える汎用的なクラス名を設定することで、一度スタイルを作りさえすれば、HTMLをコピペしてガジェットのようにどこにでも配置・複製する事が可能なマークアップが出来る、というのが今の主流です。
しかし、コピペしても破綻しないマークアップを書くのは難しい
あなたも一度は経験があるはずです。
- とあるページのスタイルを修正したら、全く想定してないページのデザインが崩れてしまった。
- 他のページをソースコードを部分的にコピペしたら崩れてしまった。
サイト規模が大きくなったり、複数人で作業していると必ずと言っていいほどこういう問題が起きます。
以前はページ固有のガチガチな名称が主だったのでこういったトラブル回避は容易でしたが、今は拡張性や汎用性を重視した「ゆるふわ」な名称が主なので、意図せぬスタイルの適用が発生してしまうんですよね。
そうならない為はコーダー自身で厳格なルールを定義する必要があります。でも、穴のない強固なルールを作るのは至難の業です。熟練した設計技術が必要になります。
しかし、安心してください。あなたがルールを作らなくても、世界の実力者が既にルールを作ってくれています。あなたはそれを利用すれば良いのです。
HTML・CSS設計のルールは国際的に使われているモノを活用しよう
HTML・CSS設計の実用的で破綻しないルールは世界中の実力者が作ってくれています。その代表的なものを紹介します。
OOCSSは構造的な部分に着目した設計方法で、BEMは厳格な命名規則に着目した設計方法です。これらを活用することで、より安全に破綻しないように拡張性や汎用性を確保することが可能です。
これらの設計方法の基本的な解説はCodeGridさんの記事が分かりやすくてオススメです（第2回以降は有料ですが第1回だけでも基本は十分学べます）。
これらの設計方法は使わないにしても、「考え方」を学ぶだけでも大きな価値があります。ぜひ、参考にしてみてください。
自分やメンバーが制作・管理しやすい方法がベスト
色々書きましたが、必ずしも今のトレンドに乗る必要はありません。2005年に主流だったWeb標準準拠のマークアップ記法でも、完全オリジナルのルールでも良いのです。
なぜなら、案件やメンバー構成によって最適は設計は変わるからです。
自分やメンバーに合った手法で制作していきましょう。