CSS3の現状と今後の課題

グルーソフトウェア株式会社
代表取締役 石井 宏治 氏

EPUB3とW3C

私は、W3CのCSSワーキンググループで活動している。まず、W3CとEPUB関係について話したい。EPUB3の全体については、先ほど村田さんから話があったが、私はEPUB3の中核はWeb技術と融合したことが非常に大きいと思っている。

Web技術と融合したことで、同じツールが使え、同じ知識が使える。場合によってはWebと同じコンテンツが使える。これらによって、幾つもある電子書籍フォーマットの中からEPUBが注目されているのではないかと思っている。

EPUB3はIDPF（International Digital Publishing Forumと言う団体）が定めていて、2011年11月10日に勧告に至った。ここでは、EPUB3のファイルの構成、書誌情報などを規定しているが、他に使用可能なメディアの種類、Core Media Typesを規定している。

Core Media Typesとは、XHTML5、それからCSSを取捨選択しているので、EPUB3 CSS Profileと呼んでいる。それから画像としてGIF、PNG、JPEG、SVG、フォント、映像の種類を規定している。

IDPFとW3C、Unicodeという団体がどう役割分担をしているかというと、IDPFは電子出版のニーズに応えるための団体である。こちらではEPUB3あるいはEPUBの次でEPUB AALなど、現在幾つかの仕様が進んでいるが、中で使えるメディアそのものについては、何が使えるかを規定し、どのように作っていくかをIDPFでは規定していない。

そこを規定しているのが、例えばHTMLやCSSに関してはW3Cである。この仕様の関係を、我々は参照関係と呼んでいる。例えば、EPUB３の仕様はW3Cの仕様を参照している。W3Cはブラウザの挙動やHTMLの仕様を定めるにあたって、今度は文字コードの仕様を参照するので、W3CではUnicodeの仕様を参照している。

こういった関係を、団体の中で持っている。参照することは、その中身の別の仕様で定義されることになるので、当然、その仕様を使って何かを作ったり利用するのも、リーダーを実装するにも、参照先の仕様が必要になる。したがって、私がW3Cの側で、村田さんがIDPFの側で、共同で仕様を作ってきたことになる。
CSS3はマーケティング用語として非常によくメディア等に載るが、CSS3は実際には存在しない。

CSS2.0、2.1という仕様を作ってきて、この仕様が策定に非常に大きくて時間がかかり、ブラウザにも制作者にも、Web業界に対してよくない影響があったので、この仕様を今後は分割しモジュールで進めようとしている。
当然、少しずつ機能が追加されていくので、各モジュールにレベルという数字を定める。バージョンのようなものである。例えばSelectorsという機能のレベル3の仕様が完成したら、今度はSelectorsのレベル4、あるいは全く別の機能でやる場合は別のモジュールを作っていき進めていく。

制作側の注意点だが、実装、即ちブラウザやリーダーによってどのモジュールやどのレベルを実装しているかが異なってくる。統一されたものがない。したがって、特定の機能を使うときに、対象がどういうモジュールのどのレベルをサポートしているかについて、少なくともWebの世界では意識しなければいけない。
モジュールだが、W3Cのサイトで、図4のURLに一覧がある。現在56個ある。モジュールがありすぎてわからない、ブラウザによってどれをサポートしているかわからないなどの問題が出ていて、プロセスを見直す話も出ているが、今のところまだ解決していない。

図4のサイトでは、Statusという欄があり、これが各モジュールの仕様としての安定度を示す。W3Cプロセスでは5段階のStatusを定めていて、段階が進めば安定していき、改編が少なくなっていくことを表している。

一番上のREC、勧告まで行くと、製品版と考えていい。その前だと製品候補、ほとんど最終版だが、まだ最後のチェックをしている。その前はCRで、だんだん安定しなくなってくる。仕様として出ているが、近い将来変わるかもしれない。実装が出なかったり、なくなってしまうかもしれない。その場合だんだん下に行きリスクが高くなる。
図6のEPUBで使えるCSSの一覧、EPUB3 CSS Profileを見ていくと、まず、CSS2.1はRECに至っている。一番最後まで行っているので、これは安全だろう。

それからCSS2.0の一部もRECに至っているので、建前では安全だが、そもそも2.0から2.1に移るとき一部落ちた理由は、仕様が曖昧だったからである。ブラウザによって挙動が違い、ブラウザベンダが実装してくれなかったものが、2.1では落としてある。2.0の仕様で、「仕様に書いてあるのに使えない」というクレームがたくさん来たので、使えないものは落とそうというのが2.1のポリシーであった。

そこで落ちたものをEPUBでもう一度拾い上げているので、若干危ない。それでもEPUBのほうで議論して、安全そうなものをピックアップしているので、ピックアップしたのは箇条書きだけである。アイウエオやイロハなど日本で使う箇条書きの番号が削除されたので戻した。漢数字もたぶん入っていて、99くらいまでは安全だと思う。100を超えると危ない。100を超えると中国語になったりする。

CSS 3.0 Speechの一部。アクセシビリティ関係である。文章を読みながらしゃべらせる、これはワーキングドラフトである。ワーキングドラフトは一番下のレベルで開発中である。

CSS Fonts Level 3の一部。これは外字などの埋め込みフォントに使う機能を持っている。

CSS Text Level 3の一部。ここには禁則、行揃え、圏点などが入っている。先ほど、WebKitの行揃えがまだ怪しいとのことだったが、それはこの辺の影響である。

CSS Writing Modes Level 3は縦書きに関するもので、Media Queriesは、CRで第3段階まで行っているので、安定している。これはデバイスの画面の大きさや向きによって表示を変えるものである。

CSS Namespacesは、ほとんど関係ないので説明しない。

CSS Multi-Column Layoutは多段組だが、CRまで行っているので、よほど使いこなさない限り大丈夫である。細かい挙動がまだ少し変わっている。

それから、Rubyやdisplayなど、一部に関しては、EPUBのニーズはあったが、W3Cは全く追いつかないので、ここはEPUBの独自拡張になっている。

次に、EPUB3でWDという開発中の仕様を参照する意味について話したい。これにはメリット、デメリットがあって、いろいろ議論されてきた。メリットは、最新の機能を使える。
日本人としては別に最新ではないかもしれないが、W3Cの仕様の中にインターナショナルな部分がほとんど入っていないので、基本的な日本語を表示するのにも最新の機能を使わざるを得ない状況がある。

デメリットは、将来参照先の仕様が変わるかもしれない。あるいは、ブラウザがこれから実装するにあたって、ブラウザによって違う動きをするかもしれない。この辺の担保がまだWDだとされていない状況なので、互換性に問題が出たり、過去に見えていたものがあるバージョンから変わってしまったり、リーダーによって違う表示をしたりするリスクがある。

これを受けて、EPUB3ではVersioning Strategyを定めている。改編には文法の改編と意味の改編の二通りあるという分析をして、少なくとも文法はEPUBの互換性を守ろうとし、それぞれのWDの日付を使って指定して、文法を固定している。
これも実はメリット、デメリットがある。EPUBとしては互換が保てるが、Webとは違うプロパティになるかもしれない。EPUBの一番のメリットは、ブラウザで使っていたツールや知識がそのまま使える、テストするのに、ブラウザで見れば正しく見えるというメリットだったはずだが、ここに関しては若干目をつぶっている。

それから、意味が改編された場合には、もう仕方がない。互換性のリスクが生じた場合には、EPUBの仕様を更新して、マイナーバージョンを上げていく。EPUBとしては、仕様を決めている団体なので、できるのはここまでである。3.0.1のリーダーで3.0のEPUB3を読んだらどうなるかについては、メーカー任せになる。
そこに関してだが、メリット、デメリットを考えて、不安定で使えないなら簡単だが、その場合日本語の書籍は全く作れなくなってしまう。作る側が、これを使うとどれくらいのリスクやメリットがあるのかを考えながら、選べるようにし、EPUB3にはWDの機能をたくさん入れている。
作る側としては、自己防衛し、危険な部分を避けながら使っていくしか、当面は手段がないが、仕様策定側としては、WDをなるべく早期に安定化させていくことが、今は一番の課題となっている。
（図1）（図2）（図3）　（図4）（図5）（図6）（図7）
 

 
▲図1
 
▲図2
 
▲図3
 
▲図4
 
▲図5
 
▲図6
 
▲図7


 

EPUB3の日本語関連仕様群

EPUB3の日本語に関連する部分の仕様について説明したい。まず、CSSにおける国際化レイアウトだが、歴史は長くて、1999年、マイクロソフトからInternational Layoutが出されている。

これが2003年までにいろいろ議論を重ねて、元の仕様が広範すぎるので分けることになり、この3つに分けて、中核となるCSS3 Text Moduleは第3段階のCRまで一度進んだ。Internet Explorerが実装している縦書きは、2003年のCRを元に実装している。

ところが、第3段階まで進んだが、この後に問題が発覚して、このCRは却下されている。したがって、Internet Explorerの縦書きは、今の標準に沿っていないことになる。その後、その問題について議論をして、さらに進めて現段階では5つに分かれている。それぞれが全てまだWDの状態である。

この中の、まずCSS Text Level 3は、文字レイアウト全般に関わる機能群だが、元の仕様がInternational Layoutなので、国際化や言語によって異なる部分をたくさん含んでいる。

この仕様ももう8年くらいやっているが、なかなか進まない。まだ第1段階である。そこで、最近にすぐに決まらないものを全てLevel 4に送り、とりあえず固まっているもの、それから必要性の高いものを安定化させる努力が現段階で進んでいる。

機能を見ていくと、大体この辺がText Level 3の内容になる。大文字小文字、全角、大仮名変換。大仮名ととは、小仮名を大仮名に変換する機能である。ルビの中で、文章としては小仮名を使いたいが、ルビは大仮名で表示したい場合に、大仮名変換を想定している。

禁則は、出版の方からはもう少しという声もたくさんあるが、今のところは3段階のプリセット、どの文字で禁則するという仕様できちんと定めて、その3段階から選べるようにしている。

欧文泣き別れ、ハイフネーション。ハイフネーションも、今非常に細かい仕様が入っているので、オンオフスイッチくを3に残して、ほとんどLevel 4に送ろうとしている。

改行禁止、特定の場所の改行を手動で禁止する場合。それから行揃え、行ツメ、両端揃え、均等揃え。字下げ、ぶら下げ、下線、取り消し線、圏点、文字の影付け、これらをカバーをしている仕様になる。

実際仕様を見ると、かなり大きいが、エディターから、他の全部削ってをLevel 3に残そうと提案をしている状態である。それに対して、今議論中だが、赤字もLevel 4に送れという話が来ている。最初の、大文字小文字、全角文字は大丈夫だったが、大仮名変換もクレームというか、異論が出ている。

禁則は、メーリングリスト等で意見を集めている段階である。3段階のプリセットで入れたいと提案をしているが、他の意見は「プリセットではだめなのではないか、どの文字を禁則するかは1個1個定めたい」というニーズがもともとあり、我々エディターとして、「それはLevel 4で、まずはプリセットでやろう」と言っているのに対して、一部の人から、「プリセットはどっちみち使えないのだから、Level 4に先送りして、1文字1文字指定できるようにしたほうがいいのではないか」という意見が出ている。

行揃え、行ツメ、両端揃え。鎌田さんの質問に答えると、1つ、2つ、あるいは1ブロックくらいの言語の仕様を固めてコードを書くのはそれほど大変ではない。実際に、過去にやられてきて、おっしゃるように製品が出ている。ただ、どんな言語が来ても行揃えができるという仕様を作るのは非常に大変で、過去にどの製品もやってきていない。

私はもともとマイクロソフトにいてWordの開発をしていたが、Wordでも基本のエンジンを3つに割っている。
英語圏、つまりラテン系のものと、東アジア系のものと、MSの分類で言うコンプレックススクリプト、アラビア語やタイ語や、文字が変形していく言語。それぞれで仕様やモジュールを書いて、エンジンを中できれいに切り替えることをやっている。

普通の製品だと、この国で発売、日本語版発売などをやるのでできるが、ブラウザはダウンロードしたら世界中の人が同じコードを使うので、W3C、ブラウザ、HTML、CSSとしては、100％は無理でも、ある程度のレベルをどの言語に対してでも動くものを作らなければいけない。ここが非常に難しい。

ここ数年の作業で、日本語はRECを出したりして作業してきたお陰で、東アジアはこのレベルまで来ている。アラビア語も大分来ている。残りが大分少なくなってきているので、何とかエディターとしては「このままLevel 3に残そう、大分できているじゃないか」と言っている。

反対している人たちは、「まだもう少しないとコードを書きたくない。今書いて、今度タイ語をサポートするときに全部書き直しになったらどうするのか」というのが大きな焦点になる。
（図8）（図9）（図10）（図11）（図12）（図13）
 

 
▲図8
 
▲図9
 
▲図10
 
▲図11

 
▲図12

 
▲図13

 
村田氏：これで落ちるとどうなるのか。

石井氏：落ちると、Level 3をこれでまとめられればEPUBの互換性も保てそうだし、W3Cのスペックとしては数年内に勧告に持っていけると思う。ここで終わってラストコールに持っていければ。Level 4は、それが終わってから。5年くらいではないか。どれくらい仕様を書く人が時間をかけるかにもよるが。
Elikaは、ちょっと状況が変わった。彼女はMozillaの社員になったので、逆にMozillaのゴールに合わない作業はできなくなっている。

MLでも質問を投げたが、ラインブレイク、禁則に関して何か、「こういったプロパティを使った」、あるいは「禁則したかったのにできなかった」とかいう経験をお持ちの方はいるか。WebあるいはHTMLで、禁則で困ったという経験。

「CSS、禁則」でググったら45,000件ヒットした。IEは緩い禁則、小仮名が行頭に来てもいいという禁則を実装しているので、逆に言えば記事を書いているということは、IEのデフォルトでは困ったという人たちが記事を書いていると思うので、小仮名が行頭に来たくないという人はやはりそこそこいるのだろう。

印刷会社やWeb制作会社として、クライアントが「なんで小仮名が行頭に来るのか」と言ったら、せざるを得ないと思うので、そのときに現在はプロパティがないというのは何とかしたいと思う。

日本語の間は基本的に改行可能なので、改行禁止文字を入れていけば作れる。一応、強制改行禁止は入りそうである。ただ、1個1個に対してそれをやっていくのは辛いだろう。

WebKitの現状で言うと、WebKitは1年くらい前までほぼ禁則を何も実装していない。句読点も先頭に来てしまうという状態である。今は大分改善されているはずだが、どの文字を禁則文字にするかというのは、はっきりした規定が今はない。それを規定しようというのがこのCSS3 Textの仕様である。

先ほどの村田さんのサンプルでも、閉じカギ括弧が行頭に来ていたので、私は気になっていた。ブラウザによって、IEでもときどき、特定の文字が、閉じ括弧なのに行頭に来てしまうことがある。規定がしっかりないので、ブラウザベンダがこれでよしと実装したものが、今は出てしまう。
それで、どの文字を行頭禁則文字で、どの文字を行末禁則文字かをきちんと定めて、どのブラウザで見ても同じ禁則になるようにし、かつ、1種類では厳しいので、3段階のプリセットを持とうというのが、今、我々エディターがCSSに提案している内容である。

異論が出ているので、これはもう少し議論するが、そういう世界が欲しいことに賛同してくださるのであれば、是非ご意見を伺いたい。

CSSのプロパティにするにはあまりに複雑なので、最近CSSではアットルールというデザインパターンを採用している。細かい、例えば箇条書きの番号で、前に第を付けて後ろに章を付けたいいうと、それを全部CSSの中に定義可能にすると複雑になりすぎるので、「第何章というルールはこういうものだ」というのをアットルールとして定めておいて、CSSではそのアットの名前を参照するというやり方を定めている。おそらく、Level 4でこの文字をどうしても禁則に入れたいというニーズが高いのであれば、こういったやり方が考えられると思う。

現段階で、CSSワーキンググループの認識としては、印刷やWordではそこまでやっているのは知っているが、WebやEPUBで本当にそこまでのニーズがあるのかまでは合意に至っていない状況である。「やるならLevel 4で」とは言っているが、「Level 4でやる」とは言っていないというのが現状である。

鎌田氏：Unicodeと合わせると、文字はリベラルで、「これも、これも認めよう」という方向なのに対して、組版はかなり絞っているのではないか。どちらにしても、ある程度カスタマイズしないと商品にならないのが多いのではないか。

石井氏：結局そこがみんな予想である。今までの紙では、フォントもインクも紙質も全部含めて指定できた。電子では、画面も違えばバックライトのあり、なしも違う。フォントや大きさも字詰めも違う。その環境でこの1文字を指定することがどこまで大事かというのは、誰も経験としては持っていないと思う。

縦書きはCSS Writing Modes Level 3というスペックでカバーしている。これがカバーしているのはRight-to-Leftの右から左に読むアラビア語、ヘブライ語等の言語である。

それから縦書きについて2種類、日本、中国、台湾で使っている縦書きと、行が左から右に流れる古代モンゴル語の縦書きがある。この3つのパターンと、普通の横書きの切り替えをこの仕様で定義している。

それから、この仕様では縦書き字の文字の向きを定義している。これは、日本人的に考えると最初全く違和感がなかったが、現段階の製品はどの製品もアプリやOSによって文字の向きが微妙に違う。
例えば「℃」という記号は、Wordでは縦になるがパワーポイントでは横になるので、コピー＆ペーストすると変わる。W3Cは、「1個マークアップとCSSを書いたら、どのブラウザでもどのOSでも同じレイアウト」を目指しているので、「それはだめだろう」という話が5月くらいから出始めて、大きな問題に発展している。

少なくとも方向性としてはそれに関して1個定めようと。「XML、CSSで書いたら文字の向きがブラウザによって縦や横に変わってしまうのはやめよう」ということを目指している。

ボックスモデルはCSSの用語だが、たくさんのボックスがあるときにどういうレイアウトをするかという計算方法を示している。この場合は特に、横書きに関してはCSS2.1で定めているので、ここでは追加で縦横混在字にどういうボックスの計算をするかということを定めている。

縦中横が、この仕様のカバー範囲で、このほとんど全てがEPUB3で使用可能とされている。ただ、これはまだWDなので、現在の仕様の状況としては、まず文字の向きは改編予定である。今仕様に書いてあるのは、誰も実装する気がない。多分、全部確実に書き直す。

イーストや、現段階でEPUB3を作っているところからは、「なかなか機種によって文字の向きを固定できない」という話は既に伺っている。WebKitとAdobeで違う、あるいは同じWebKitでもMacとWindowsで違うという話は聞いているので、そこに関しては全面改訂していく。

ボックスモデルと縦中横は、まだ少し細かい修正があり得る。EPUB3の仕様を注意深く読むと、「縦横混在文書はあまりお薦めしない」と書いてある。縦横混在したときの計算が、まだテストが不十分だと我々は感じている。

先ほど、文字の向きは、各文字についての仕様は役割分担としてCSSワーキング、W3Cで定めるのはおかしいという話が出て、縦書きにしたとき、どういう文字が縦でどういう文字が横になるかは、漢字は正立するがアルファベットは横にする。こういった規則をUnicodeで定めることが、2011年5月ごろから始まった。

10月4日にAdobeから最初の提案があったが、あまりよくなかったので、いったん全面改訂することになり提案を取り下げて、もう一度作っている。順調にいけば、年明けにドラフトが出てきて、2月に決議する。
これが決まると、W3Cとしてはまずこれの開発に協力する。これを一緒に作っていって、CSS Writing Modesの仕様を全部これに合わせる。UnicodeとW3Cで違うと大変なので、まずUnicodeで定めて、それをそのまま使うことを基本方針として考えている。EPUBからすると、「W3Cの先のUnicodeまでか」という感じもするが、ここで決まる内容が、特に縦書きに関しては大きな影響を持つと思っている。

漢字とアルファベットは簡単だが、ギリシャ文字はどうするか、ローマ数字も厄介である。それから、約物の中で、Unicodeの細かい話になるが、大丈夫なものと危ないものとある。他のコード定義とユニファイされてしまったものは非常に厄介で、例えばダブルクオートや三点リーダーなどあの辺は非常に話がややこしくなる。
数学記号は、微分積分が出てきたらそれは横という話があるが、簡単に文章の中に1文字、2文字で表れると、結構みんな縦で使っている。その区分をどうするか。そもそも、ある文字が数学記号かどうか、「＝」は、分類上は数学記号だが、ほとんどダブルダッシュとして使っている人もたくさんいる。その辺の分類をどうするかを、1個1個やっていかなければいけない。

もちろん、我々エディターのほうで網羅的には見るが、是非、興味のある人がいたらドラフトを見ていただいて、自分が気になっている文字、あるいは自分の専門の範囲であれば、ご意見いただければと思う。

最後に、もう1つ現在HTML5 Rubyが問題になっていて、もう1年ほどやっているがまだ結論が出ない。<rb>タグ問題とComplex Ruby問題があり、どちらもHTMLワーキンググループとCSSワーキンググループで意見が分かれているので、1年間議論をしてまだ結論が出ていない問題である。HTML5もまだWDなので、この先細かい部分はどんどん変わる。その中で、「今の仕様のままではまずいのではないか」と言っている部分がこの2つである。

<rb>タグは、ルビの親文字を指定するタグである。これはもともと昔のルビタグでは必須としていたが、実はみんな結構省略している。そういうことで、HTMLワーキンググループは、「使わないタグなら禁止してしまえ」というので、利用してはいけない規定としたい。CSSのほうでは、「ルビの親文字だけ全部まとめてスタイルをかけたい。そうするにはタグが必要なので、タグをさせてくれ。せめてオプションとして使えるようにしてくれ」という議論をしている。

それから、Complex Ruby問題は非常に話がややこしい。簡単に言うと、例えばルビの同じ親文字に対して、上と下同時にルビを付けたい、一般の用途ではないが、もう少し複雑なルビをしたいときのための仕様が、昔のルビには入っていた。

「そんなものは誰も使わないので禁止してはどうか」というのが、HTMLワーキンググループの主張で、我々もまだユースケースをきちんと証明できていないので、消せとは言えない。「消せとは言えないが、禁止するのはやめてほしい」という、ちょっとぶれた状況である。

今のHTML5で、このままの仕様でいくと、「将来やっぱり必要だ」というときにもう足せなくなってしまう仕組みを今導入しようとしている。したがって、「足せなくなる仕組みはやめてほしい」というのを、今議論している。

大体、こういったことに関して今議論をしているが、エディターはみんなの声を集めて、「こういう状況だから」と議論をして、合意した内容を書くだけなので、「私の意見がどうだ」といくら言っても、仕様には反映できない。是非、本当に使っている人に、実際にこういう問題があることをお寄せいただければと思っている。

2011年11月28日TG研究会「EPUB3策定の経緯と電子書籍の今後」より（文責編集）