見出し画像

HTMLの「デザイン手法」の推移とWebタイポグラフィ

前回、いくつかのWebによるタイポグラフィの初歩的手法を書きました。
文字表現を含め、現在のWebデザインの手法に落ち着くまでに、実は幾度かの技術の刷新と、それに伴う手法の変化がありました。まずは現在の手法をざっとおさらいしてみます。

現在:CSS3によるレイアウトとスタイル

主に、文書の意味をあらわす構造を持たせたHTMLと、デザインやスタイルといったレイアウト情報をコントロールするCSSは、完全に分離して書くことができます。CSSはあらゆる要素に対して適用でき、スタイルを記述することによって、デザインを記述することが可能です。
これはCSSが進化してきたことにより、我々が獲得できた自由といえるでしょう。文字周りのプロパティの実装が進んだことにより、レンダリング結果がまだユルユルな感じとはいえ、ある程度の制御ができるようになっています。スタイルを挟み込むには、主に文書の構造に影響を与えないとされてきた<span>を使うことになります。今のところ、複雑に書いたCSSの中にスポット的にスタイルを挟み込む要素は、これ以外に見当たりません。

過去:テーブルレイアウト

90年代後半、ヨゼフ・ミューラー=ブロックマンのデザイン手法の再評価とWebデザインへの投入が試行錯誤される過程で生まれ、90年代に主流となったのがテーブルレイアウトです。
ミューラー=ブロックマンをはじめ、国際様式のデザイナーが提唱した「グリッドシステム」をWebのUIデザインに持ち込むため、<TABLE>をグリッドのように構成し、文字や画像のレイアウトを実現しようという試みでした。これは、CSSの進化とともに消えていきます。
この頃、タイポグラフィの知識は主に画像を使った見出し部分にのみ投入されました。本文はテーブルのセルで幅を決めたり、2段組にしたり、といった程度のコントロールしかできませんでした。書体もデバイスに依存するしかありませんでした。

テーブルレイアウトの「罪」

先に書いたように、HTMLはタグによってテキストの「意味の構造」を記述していくのが正しい構造です。これは過去も今も変わりません。
<TABLE>はもともと「表組」のためのタグで、幅やセルの数などを細かく記述することができました。その仕組みをグリッドシステムの枠と捉え、レイアウトのために確信犯的に「誤用」したものです。
この誤用によって、それまでにほぼできなかったレイアウトのコントロールには一定の成功を収めるのですが、文書の構造を著しく損なうものでした。例えば本文がすべて「表組」として扱われると書けば、「なんだかおかしい」と分かっていただけるでしょうか。見た目はOKだとしても、検索の際にテキストが違った解釈をされるなど、SEO的見地など、いくつかの観点から問題があり、構造的にはかなりBadなテクニックとして糾弾されることとなりました。

<div>と<span>

テーブルレイアウトによって汚れるHTMLコードをの問題を解決し、柔軟なレイアウトを実現したのがボックスエレメント<div>です。初期はNetscapeの独自拡張<LAYER>と実装時期が重なり、混迷を極めましたが、多くのレイアウト関連CSSが実装され、すぐに<div>に統一されました。この<div>をはじめとするボックスエレメントが、レイアウトの単位として重宝されていきます。
また、部分的にスタイルを適用するために、スポット的に使う目的で現れたのが<span>です。文書の構造に影響を与えないとされ、SEO的にも推奨されました。
Webフォントの出現と、文字周りのCSSの実装が進むにつれ、2010年あたりは冗談としか思えなかったWebタイポグラフィという言葉が、最近ようやく現実味を帯びてきました。font-feature-setteingsプロパティの実装により、ついにオートカーニングをブラウザでも利用できるようになり、ブラウザの文字表現は紙媒体の文字表現にまた一歩大きく近づいたと言えます。現在、プラットフォームの違いによる表示フォントの問題や、大いに不満があった文字組まわりも、根気さえあれば制御がある程度可能となっています。
タイポグラフィを実践するにあたって、テキストにスタイルを挟み込むためにまず使えるのではないか、と考えたのが<span>です。現在、細かい制御を行うスタイルを記述するためだけに用意された要素は、仕様書を洗い出しても、どうやら<span>ぐらいしか見当たりません。SEO的にも推奨されてきました。

しかし

ガッツさえあればひと文字でのコントロールも<span>でできることがわかり、個人的に試行錯誤を続けてきました。また、2010年頃に深津さんが公開したFlAutoKerning.jsも、キャラクタごとにスタイルを持たせ、<span>を自動で生成することにより、オートカーニングを実現する構造になっていました。
しかし、文字のコントロールのために<span>を多用した時に、予期せぬ問題が起こります。検索エンジンで「本文が細切れになっている」と認識され、検索性が著しく落ちるという現象が起こります。これは画像の乱用やテーブルレイアウトで著しく損なわれた文書構造を取り戻す「Web標準」のあり方と、結果的に対立するようなしくみになってしまうという問題が起こりました。
SEO的に推奨されてきたはずの<span>ですが、おそらく、こうした使い方を想定していなかったようです。カーニングのために<span>を乱用することはBadなノウハウとなってしまったのです。

font-feature-settings

数年前に待望のfont-featuire-settingsがブラウザに実装され、ついにフォントが持っているカーニング情報にアクセスできるようになります。これにより、タイポグラフィと呼べる文字表現の下地は整ったと言えます。
ただし、プラットフォームやデバイス、解像度によってフォントレンダリングのばらつきが大きく、環境によってはWebフォント+font-feature-settingsでも、まだまだかなり貧弱な結果となることがあります。それと、少し挑戦的なレイアウトを試すと、まだ自動では見るに耐えない結果となることも多いです。Webタイポグラフィの実践において、信頼性と汎用性の高い、決定打はまだありません。

じゃあどうしよう

いかなる文字周りのプロパティを幾重にも投入しても、崩れるところは崩れます。デザイナーであれば、Web標準であることを守るために、見るに耐えない崩れを放置せざるを得ないこともあります。ただ、それらの法則はなんども失敗を重ねることにより、見えてきています。
そこで、できるだけ構造に影響を与えないCSSプロパティの適用の方法を試し、どうしても気になるところだけ<span>を注意深く使う、という手法を取っています。
それでも、Web標準の観点から見るとベストプラクティスとは言えないようです。エンジニアリングの観点から見ると、こうした努力は害でしかないと言われることもあります。
そこで、わたくしは「いま使えるプロパティはなんと言われようが最低限投入する」という基本姿勢を取ることにしました。例えば、テーブルレイアウトが主流だった時代に、その解決策としてCSSの策定が進んで、それを代替するテクノロジーが実現したように、<span>の弊害をクリアする技術の進化を促するようなことになりはしないか、と考えています。これはおそらくGoodとはされないと思うのですが、今できることは試しておきたいです。

一例をあげておきます。
明朝系フォントを使って縦書きをしたときのことなのですが、以下のようなことになってしまいました。


これはあんまりです。なぜこんなことになるのか説明します。
横書きのテキストを縦に流れるようにCSSを書くだけなのですが、ベースラインの位置が調整されず、左起点になったままなので、キャラクタ幅の違う文字の右側がガタガタになってしまっています。
これを解消するには、「vertical-align」を適用し、ベースラインからの位置を調整するしかありません。


日本語のDTPソフトやIllustratorで縦書きをやってみるとわかるのですが、日本語縦書きのベースラインは中央になっています。ですので、幅の違うキャラクタも、綺麗に揃っていますが、そもそも横書き欧文文化のものであるHTML/CSSには、「ベースラインが中央にある」といういう概念が存在しません。これはベースラインをコントロールするCSSプロパティがあれば、おそらくあっさり解消します。そうしたプロパティが勧告されるのを期待して待つか、それとも現状でなんとかするか。どうしましょうか。
ちなみに本文中もこうした崩れは顕著なのですが、どうしても気になるところだけ調整して、ある程度は諦めています。とにかく、<span>の乱用で本文が認識されなくなるのは避けたいところですが、上記のような崩れは、おそらくクライアントチェックでも「ここどうにかして」という戻しが来るレベルです。

難病を明らかにすることにより、新薬の開発を促すような、そんな気持ちでWebの文字表現を試行錯誤していくしかないと考えています。わたくし一人だけでやってても、仕方がないとも思えるのですが...

みなさんはどういう取り組みをしているのでしょうか。

Webフォントサービスを片っ端から試してみたいですし、オンスクリーン組版ももっと探求していきたいです。もしサポートいただけるのでしたら、主にそのための費用とさせていただくつもりです。