Webデザインで今も昔も非常に重要な要素である、tableのレイアウトについて気になる点があったので調査しました。 #outline ---- * 目的 table用のスタイルシートである「table-layout」プロパティを調査し、カラムの幅を固定できるようにする。カラムの幅はem, ex, pt, pxのいずれかで決定できるようにする。 Webデザイン系、業務アプリケーション系を問わず、tableのカラム幅の設定は頭痛のタネである。中に表示するデータの文字数や文字種によって様々に変動してしまうtableに対して、どうやって列幅を固定するか。そのための具体的な手法を調査することで、今後の開発時におけるHTMLレイアウト修正作業を軽減する。 * 基礎知識 ** table関連のスタイルシートプロパティ http://www.htmq.com/style/index.shtml#tab 今回調査対象としたもののみを挙げる。 ** table-layout : auto : テーブル（表）全体を読み込んでから、各縦列の幅を決定して表示する。デフォルト。 : fixed : 最初の横一行を読み込んだ時点で、各縦列の幅を決定して表示を開始する。 ** border-collapse : collapse : 隣接するセルのボーダーを重ねて表示する。 : separate : 隣接するセルのボーダーを間隔をあけて表示する。デフォルト。 他に以下のプロパティがあるが、IEに対応していなかったり使用頻度が著しく低かったりするため今回の調査では対象外とした。 : caption-side : テーブル（表）のキャプションの位置を指定する : border-spacing : セルのボーダーの間隔を指定する : empty-cells : 空白セルのボーダーの表示・非表示を指定する ** スタイルシートにおけるサイズ指定の単位 今回調査対象とした四つの単位についてまとめる。 : em : ブラウザデフォルトにおける、文字"M"の '' 高さ '' を基準とする。 : ex : ブラウザデフォルトにおける、文字"x"(小文字のエックス)の '' 高さ '' を基準とする。 : px : PCの画面を構成する要素、"ドット"を基準とする。画面の論理サイズで"1024ピクセル"といえば、すなわち1024ドット。 : pt : 実世界上の単位で、 '' 72pt(ポイント) = 1 inch '' となる長さ。PCが画面上で扱うためには、 '' DPI(dots per inch) '' を通して変換する。 *** em, ex 指定に関する誤認識について em, ex指定は文字Mあるいはxの '' 高さ '' を基準にしているのであって、幅を基準にしているのではない点に十分注意する必要がある。 通常、サイズ指定を考えるときは「このセルの幅は何文字か」という具合に桁数ベースで考える。もしもこのとき、em/exを幅の単位と考えて使用してしまうと、想定していた幅通りにならない。 '' 桁数ベースで幅を決定するなら、高さと幅が同一の（ように見える）全角文字の等幅フォントを使用するほかない。（文字種も全角文字のみとなる） '' *** pt <> px 変換 pt <> px 変換の中心となるのが、DPIである。 '' DPIはOSによって異なり、例えばWindowsであれば72DPI, Macであれば96DPIとなっている。 '' これより、以下の計算式が成立する。((macというのはOS9までのmacを指す。MacOS X 以降のmacや、その他のUNIX, Linux系OSについては未調査)) 1pt = 1/72 inch 1px(dot) = 1/72 (win) 1/96 (mac) inch -> (win) 1px = 1/72 inch * 72 px = 1 pt (mac) 1px = 1/96 inch * 72 px = 3/4 pt win : mac = 1 : 3/4 = 4 : 3 よって、 '' macでの1ptはwinでの4/3ptになる。 '' ちなみにこれをpx単位で考えると、逆にwinでの1pxはmacでの3/4pxに相当する。 実はこれまでの計算はOS内部における論理的な扱いである。これを実世界のデバイスであるディスプレイに表示する場合は、 '' PPI(pixels per inch) '' が関わってくる。これはディスプレイにより変わってくる。 以上見てきたように '' ユーザーのOSやディスプレイのより、1ピクセルの現実世界における表示サイズが変わってしまう '' 点に十分留意する必要がある。 * 実験 ** 実験内容 数種類のバリエーションのtableを作成し、Firefox 1.5 と IE6 とで表示を比較する。実際に作成したファイルを次のリンクに示す。 http://www.glamenv-septzen.net/medias/reports_2006052101_01.html 作成するテーブルのバリエーションの観点を以下に示す。 + "border-collapse: collapse;" バリエーション ++ cellspacing属性× + cellpadding属性× ++ cellspacing属性○ + cellpadding属性○ + "border-collapse: separate;" バリエーション ++ cellspacing属性× + cellpadding属性× ++ cellspacing属性○ + cellpadding属性○ + "table-layout: fixed;" バリエーション ++ (table)width属性× + (td)width属性○ ++ (table)width属性○ + (td)width属性○ +++ tableのwidth属性 > tdのwidth属性の合計値 +++ tableのwidth属性 < tdのwidth属性の合計値 ++ table/tdの幅をstyle="width: **em;"によりem単位で指定するバリエーション +++ 半角のみ +++ 全角のみ +++ 想定文字数を超えた場合(widthプロパティでem指定時) +++ 想定文字数を超えた場合(width属性指定時) +++ 想定文字数を超えた場合 + tdタグにoverflowプロパティ ** 実験結果 幾つか注目に値するバリエーションについて、FF1.5およびIE6での結果を載せる。 - "border-collapse: collapse;" -- FF1.5 : &image(97) -- IE6 : &image(96) FF1.5ではtdタグのborderがtableタグのborderを上書きしているように見える。一方のIE6ではその逆のように見える。枠線と、その中のセルを区切る罫線についてはデザイン上重要な要素であるが、ここまで挙動に違いがあると、border-collapseだけでFF1.5/IE6で同じ見栄えにするのは難しい。 - "border-collapse: collapse;" + cellspacing属性○ + cellpadding属性○ -- FF1.5 : &image(99) -- IE6 : &image(98) これもFF1.5とIE6では全く挙動が異なる。 - "table-layout: fixed;" + 想定文字数を超えた場合(widthプロパティでem指定時) -- FF1.5 : &image(101) -- IE6 : &image(100) tdの幅を超えた部分の文字列をどうするかで、中身の文字列の種類に応じ、FF1.5/IE6でそれぞれ挙動が異なる。まとめると、次のようになる。 | 文字列種類 | FF1.5 | IE6 |H | 連続文字列 | はみ出して表示 | 切り捨て | | 全角英語・日本語混在の連続文字列 | 文字種の切れ目を適当に折り返し表示 | 文字種にかかわらず折り返し表示 | | 空白混じり | 折り返して表示 | 折り返して表示 | 特に注意が必要なのが連続文字列で、FF1.5だとデフォルトでははみ出して表示してしまう。他の周りのTRやTABLEの属性指定やスタイル指定の影響がどう出るのかは不明だが、いずれにせよこの差異を認識していないと、頭痛のタネになることは間違いない。 * 結論 - 列幅を固定するには、"table-layout: fixed;"が有効である。 - W3Cの仕様上、文字の"幅"を基準として各種のwidthを決定することはできない。 - 文字の"幅"を基準としたい場合、テーブルの各セルに表示する文字種を全角を基本とすることで、文字の高さ=幅((見た目上の話。実際には異なる))と見なし、CSSでemを単位にすることである程度は指定可能である。 - FF1.5とIE6とでは、border-collapse周りの枠線表示および連続文字列表示における挙動がまるで異なるので、注意と対策を要する。 * 雑感 MS-DOS/Windowsクライアント系の画面と、HTMLの画面はそもそも制御方法がまるで異なると言うことを理解して欲しい。 その上で、真実、 '' 文字の幅・桁数を基準にして幅を「精密に」指定することは、HTMLでは「技術的に不可能」 '' のようである。 ただし、emやexというのは恐らく、どんな文字でもこの幅を超えることはないという基準点なのではあるまいか？であれば、ぴったり○○文字の幅という制御はできなくとも、"最大"○○文字まで入る、という使い方は十分に出来るはずである。精密に幅を指定するのが不可能であっても、最大文字数幅で合わせておけば、少なくとも途中で情報が切れてしまうことは避けられる。恐らく対応を迫られた場合、その辺りが妥協点となるのではないだろうか。 * 参考リンク - http://www.tohoho-web.com/www.htm - http://www.htmq.com/index.htm - http://www.aboutfont.com/manual/fontsyurui.html - http://msugai.fc2web.com/web/app/font.html - http://wisdom.sakura.ne.jp/system/winapi/win32/win133.html - http://www.styletype.jp/2004/10/post_2.html - http://neta.ywcafe.net/000349.html - http://www.fromdfj.net/html/fontsize.html - http://blog.asura.co.jp/takehara/5219ac5dcee34422a506ab9f3df120df/entry.aspx