メイン

HTML アーカイブ

2003年10月01日

テーブルレイアウトの最大の欠点



テーブルレイアウトは、さまざまな弊害を伴った過去のテクニックである。



  • 概ね文章構造が明示されていない

  • ユーザスタイルシートで弄りにくい

  • 高度な環境が必要

  • 誤った要素の使い方


等々、理由は沢山あるけれど、テーブルレイアウトの最大の欠点はソースが汚くなるということではないかと思う。


つまりは、多くのWYSIWYG型エディタが挿入する、蛇のようなテーブルタグの数々。2重、3重、4重にも入れ子されて、何処から何処までが曾孫テーブルなのかもさっぱり解らない。あれを手書きで修正しようとすると、本気で萎える。たった一行の注釈を加えるだけなのに、ファイル全体の多重テーブル構造を理解しなければならないのだから。


しかも、テーブルがあまりに有名となったために、何でもかんでもテーブルで解決しようとする人も多いようで。



<table border=0>
<tr><td bgcolor="#99ccff">背景色を付けたい段落</td></tr>
</table>

こんな面倒なソースも



<p>背景色を付けたい段落</p>

として適当にCSSを付けてやればすむ話。


ある意味fontやらcenterやらよりよっぽど害のある「タグ」なのではないかと思う。レイアウトテーブルは、何ら役に立たない「ゴミ」情報(タグ)ばかりを増やす、排除すべき存在である。大体、tableが多いページに限って、<colgroup>やら<thead>やら<th>やらは一つも出てこない。


一テーブル好きとしては、こういう使い方はどうしても許せない。折角構造を明示できる要素が沢山あるというのに、勿体無い。


*[link]無断リンクを禁止するっ!


古いリソースなのですけれども。



何故「神」である管理人が、


一訪問者の気持ちなどを考えなければならないのですか?


「訪問者が」管理人の気持ちを考えるべきなのです。


「リンクしたい気持ち」など、「リンクされたくない気持ち」に比べれば取るに足らないものです。



ここまで言い切られると、逆に笑いが。この方がなぜリソースをWebに公開しようとされたのかが、全く理解できない。―「神」として崇められたいからだろうか。


「批判されたくないリソースは、大切にHDに保管しておけば良いのでは」、という意見に私は反論できません。


2003年10月05日

笑えない本



本屋でC言語関連の書籍を探していたところ、ふと目に入った「HTML4クイックスタートガイド」という本を手にとって開いてみました。題名からして、「HTML4」と名乗っているのだから、それなりにまともに解説してくれていると期待したのですが。


DOCTYPE宣言が無い


HTML4のリファレンスならば、これは欠かせない筈。DOCTYPE宣言無しに、何を根拠にHTML4と名乗っているのだろう。最も、<spacer>だの<marquee>だの<multicol>だのを平気で紹介しているあたり、もはやHTML4でも何でも無いのですが。むしろDOCTYPE宣言が無いのは懸命かもしれない。


リストはインデント?


「インデントの作成」という項を見て。



<ul>
ulタグでどんなブラウザでも簡単にインデントを作成できます。
リスト項目のタグを入れると黒丸が付いてしまうので、
そのままulタグで括ってください。
</ul>


いくらなんでもこれはあんまりだ。<blockquote>でインデントという本は良く見かけるけれど、わざわざ<li>を記述しないという文法違反を推奨するあたり、その意図がさっぱり理解できない。「どんなブラウザでも」って、作者はLynxやAmayaを使った事は無いのでしょうかね。


奇妙な用語


CSSのセレクタの事を「タグ名」と呼び、その上でこんな注釈を付けている。



タグ名の事を、W3Cはセレクタという奇妙な用語で呼んでいる。


奇妙って何ですか。少なくとも私には、「タグ名」などというわけのわからない独自の用語でセレクタ呼んでいるほうが「奇妙」に見えますが。


改行を含む?



<h1>や<hr>などの全てのブロック型タグは改行を含んでいるので、後ろに<p>タグをつける必要が無い。


定番の「お尻<p>」を教えた後でこれ。なんだか根本的に間違っています。むしろそれを言うならば、全く逆でしょうが。他のブロックレベル要素がすぐに来ないのであれば、後ろの段落は<p>で括るべき。少なくとも、HTML4を語(騙)る本であればそのぐらいは抑えておいてほしい。


物理マークアップは簡単?



ページ内のスタイルを全てスタイルシートで指定するのは大げさである。


難しいスタイルシートを使うよりも、HTMLタグで指定したほうがずっと簡単だ。


私は一つ一つスタイル定義タグで指定していくよりも、CSSで簡潔にスタイルをあてるほうがずっと簡単な気がしますが。勿論CSSの基本獲得の為にちょっとした時間は要するだろうけれど、テーブルやフレームを覚えるよりはずっと簡単なはず。単純な時間的価値観から言うならば、物理スタイル指定は慨して遅い。


その他


他にもいくつかツッコミはあるのだけれど、わりと目新しいものでも無いので割愛。


この手のネタは



辺りが詳しいです。


裏表紙を見たら、「全米で25万冊売れた」とあった。


真偽の程はともかくとして、単純計算で米国には最低25万のトンデモサイトがあるという事になる。



追記:(2003/10/6)



現実はこのテキストを読んでもらってもわかるように、段落もろくにそろえる


事が出来ないのがいらだつ!!


原因がわからない、、、<笑い>


このサイトを作りながらHTMLでどこまで作れるか試してみたい


今日は参考書を読んだ!@はじめてのHTML奮闘記


貴方が悪いのではありません。参考書が悪いんです。



2003年10月06日

左右マージン




次に、その文書の概観を掴みたいときがあります。この時どうするかといえば、自分の環境で実現できる最大のウィンドウ幅を利用して、一度に視界に入ってくる段落の冒頭や見出しを可能な限り多くさせます。この場合、左右マージンは邪魔以外の何物でもありません。


何故左右マージンを小さくすべきなのか@agenda


この意見には、概ね賛成です。私は普段、解像度1280×1024のフルスクリーンで閲覧しているのですが、600px程度の横幅で固定されているテキストが非道く寂しく見えます。逆に低い解像度しか実現できない端末ならば、より問題となるかもしれません。わざわざ一度に多くの情報を得たいが為に高い解像度にしているというのに、このような横幅の固定はユーザの自由を著しく奪います。 ― そういう時の為のユーザスタイルシートなのでしょうけれど。


とはいえ、ある程度の左右マージンは時にはユーザに有利に働く場合があるのではないかと私は考えています。文書の概要を掴む時、本文に適度な左マージンが指定されていると見出しを視覚的に抽出し易くなります。見出しレベルに合わせてマージンを大きく取る事によって、文書構造が掴めます。「飛ばし読み」をする際、適切にマージンが置かれたテキストならば、左端を追っていくことでより見出しごとに文章を追いやすくなるのではないでしょうか。


ただし、最深のノードテキストでウィンドウサイズの3%程度が限界かもしれません。あまり広く取りすぎると貴重なウィンドウ領域を奪います。


2003年10月09日

HTML+ に関するメモ



既に「過去の遺物」ですが、あえて掘り起こして紹介します。英語のドラフトをさらっと流し読みしただけなので、正確性に全く保証はありません。面白そうな所だけを取り出しています。



  • ルート要素が<HTMLPLUS>~</HTMLPLUS>

  • 非空要素のインライン画像要素:<IMAGE>~</IMAGE>があった。

  • CPAPTIONとセットで使える画像要素の<FIG>~</FIG>。イメージマップもこれで。

  • A要素にEFFECT属性がある。(トランジション?)

  • 人名を表す PERSON要素、コマンドを表す CMD要素、引数を表す ARG要素。

  • FOOTNOTE要素、ABSTRACT要素、NOTE要素。

  • マージンを定めるMARGIN要素がある。(仕様は謎)

  • INS要素、DEL要素のかわりにADDED要素、REMOVE要素。

  • ONLINE要素とPRINT要素。(CSSの @media に近いのかと)

  • XHTML2にもある ライン要素(<L>) が定義されている。出所はここだったのか。

  • nowrap="nowrap"ではなく、wrap="off"。P要素でも使える。

  • H1~H6は、「Headers」?

  • BLOCKQUOTEに相当するのがQUOTE要素。

  • TR要素は行区切り!(BR要素に近い仕様)。

  • メールヘッダを付加する MH要素。

  • INPUT要素の入力データ型を定義できる。(INT、FLOAT等)

  • 整形テキストのタブ空白をピクセル指定できる。(<tab at="40">)

  • 数式要素MATHと、それに属する SUB,SUP,BOX,OVER,ARRAY,ITEM要素


謎な部分も結構あるけれども、参考に出来る点は幾つかある。例えば、image要素がもし普及していたならば、わざわざ「object要素を使うかimg要素を使うか」で迷う事は無かっただろう。L要素はXHTML 2.0で採用されている。


Netscape社が考案しただけあって、MH要素やTAB要素、MARGIN要素などブラウザ・サイドから見た仕様がかなり多い。それはそれで便利だったかもしれないが、HTMLの本質ではないので仕方が無い。


この独自仕様はHTML3.0のドラフトにかなり反映されている。3.0はHTML+以上に謎の拡張が多い仕様なので面白い。今度暇な時にでも仕様書をじっくり読んでみたい。ひょっとしたら、(X)HTMLも今とは全然違う代物になっていたのかもしれないのだ。


2003年10月10日

MSIE拡張イベント



IE独自拡張のイベントハンドラがちょっと気になったので調べてみました。―これが以外と多いんですよね。詳しいタイミングについては説明が面倒なので、名前から各自ご想像下さい。



  • onabort

  • onafterupdate

  • onbeforeunload

  • onbeforeupdate

  • onbounce

  • ondataavaliable

  • ondatasetchanged

  • ondatasetcomplate

  • ondragstart

  • onerror

  • onerrorupdata

  • onfilterchange

  • onfinish

  • onhelp

  • onreadystatechange

  • onresize

  • onrowenter

  • onrowexit

  • onscroll

  • onselectstart

  • onstart


もう何が何だか。


一番知りたかった oncontextmenu が何故か見当たらないのだけれど、参考にしたのが1997年のMSDNだからかもしれない。最近はもっと増えているんだろうか。


予想通り、MSIE6.0ではさらに増えている模様。全部書き写すのも面倒なので、DHTML Events@MSDN Libraryを参照してください。



preに対する不満



便利で重宝するpre要素だけれど、これには唯一不満な点がある。「自動的な語の折り返しを不可能にしてよい。整形済テキスト: PRE要素@HTML4.01仕様書」 との項である。


普通にHTMLを記述する分には画面解像度やブラウザウィンドウの幅を気にする必要は全く無いのだけれども、pre要素では結果的にそれが求められてしまう。本質から言うならば、横スクロールが出ようが出まいが、マークアップ前のテキストの改行がそのように記述されているならばそれを尊重すべきだが、現実の話そんな事は言っていられない。横スクロールは出きうる限り避けたいところである。


HTML3.2時代にはwidth属性が存在したが、まともに実装してくれるUAは少なかった。NetscapeNavigatorは独自にwrap属性を拡張して、自動改行を促す事が出来た。流れからすればそれらはCSSに受け継がれるはずである。


私が知っている限り、第2水準のCSSでは「空白は尊重するものの、自動改行は禁止しない」というスタイルには整形できない。pre要素を使うときには現在一般的な画面解像度を意識しなければならず、結果的に「ソースを新たに改行する」という行為に陥ることもある。プラットフォームを問わない言語としては、非常に残念な話だ。もちろん「してもよい(may)」であるから、必ずしも仕様書が悪いわけではない。


今さらwrap属性を定義しろとは言わないけれど、CSS3には是非とも期待したいものである。


2003年10月20日

フレームのあるべき姿



XFramesのワーキングドラフトをさらっと読んだのだが、期待外れだった。ブラウザが独自実装した既存のフレーム機構を、幾らか仕様変更したものに過ぎなかったのだ。


ぱっと見ではタグ名や使い方など大きく変化しているようにも読める。どちらかというならば、テーブルに近づいたとも言えるだろう。現状の、判りにくい仕様からは遥かに進歩している。フレーム内のURIを、ユーザは自由に変更できるようにもなった。だが、肝心な所が何も解決していない事に気付いた。


相変わらずフレーム定義ページが親なのである。つまりは、別個にフレーム定義ページを用意しておき、それで複数のページをドッキングさせるという事だ。framesetの最大の欠点であり、それゆえにフレームは嫌われるのだ。フレーム定義ページはコンテンツの子でなければならない。


現在の仕様では、フレームによって形成された特定の状況を保存する事が出来ない。つまりはサイトの深い位置にあるページのURLを保存しようとしても、直接開いて保存すればメニュー用フレームが付いてこないし、フレームページのURLは開いているページまでは考慮してくれない(XFramesではこの問題点が解決されている)。あるいは検索エンジンからフレームの断片に辿り着いた時、適切に位置関係を把握できる確率は稀だ。


フレームという、単なるインタフェース部品に過ぎないものがサイトの最上位に位置しているという事自体が根本的に間違っているのだ。繰り返すが、フレーム定義ページはメイン・コンテンツより下位に位置するべきだ。


フレームが生き残る道筋は一つしかない。フレームの最大のメリットは、「ナビゲーションとコンテンツを分離できる」という点にある。これを最大限に活かし、それ以外を一切排除しなければならない。フレームは、サイトマップを常時待機させることが出来るという意味においてのみ、生き残れるのだ。


具体例を提示しておこう。恐らく最も良い選択肢が、link要素によってサイトマップ定義ページと関連付けるという方法だ。


<link rel="framemenu" href="./sitemap.frm" type="text/x-frames" />


考え方としては、外部スタイルシートや外部スクリプトと同じだ。ユーザエージェントはサイト構造を記したファイルを読み込みに行き、右側なり上側なり、ユーザの好きな所にサイトマップ・フレームを表示させる。注意すべき点は二つある。



  • ユーザは自由に、好きな時にフレーム・メニュの 表示/非表示 の切り替えが出来ること

  • サイトマップのデザインはサイト作者ではなく、ユーザ又はユーザエージェントが決定すること


フレームはあくまでユーザのものでなければならない。丁度IEの『エクスプローラバー』やOperaの『ホットリスト』と同じ感覚である必要がある。即ち好きな時に出し入れでき、カスタマイズでき、ユーザの言う事を聞く良い道具であるべきだ。


同様の理由から、フレームはサイト作者が細かく指定できるものにしてはならない。作者はサイトマップとURLを記したシンプルなファイルを一つ用意するだけで良いのだ。フレーム定義ページは、HTMLである必然性は無いだろう。単なるサイトマップ「情報」として与えてやれば充分だ。


真実を言うと、既存のHTMLにもその機能はあるのだ。link要素である。本来ならば、サイトナビゲーションはすべてlink要素で行なうのが望ましいのだ。悲しい事にlink要素は長い間主要ブラウザに無視され続け、いつの間にか多様化するサイト構造を表現するのに必ずしも充分なものでは無くなっていた。


ユーザ側だけでなく、サイト作成者側の見地から考察してみよう。サイト内全てのページにナビゲーション・リンクを設置する作業は、大変な重荷だ。何故ならば一つコンテンツが変化したならば全てのナビゲーションを修正しなければならないのだ。無駄にファイルサイズは大きくなるし、それをより利用しやすいようにデザインしなければならない。一言で述べるならば、「ナビゲーションリンクは面倒」だ。


それに対し、上記の方法ではサイトマップ定義ファイルを一つ用意すれば良い。何時でも変更が可能だし、手間は限りなく少ない。ユーザビリティの改善も容易だろう。ユーザエージェントが「現在位置」を適切にナビゲーションするようになるならば、あたかも自分のHDDを渡り歩いている感覚でWebを利用できるかもしれない。


一つ欠点を挙げるならば、



  • この新しいインタフェースにユーザが慣れるまで、時間が必要


という点である。我々が想像する以上に、ユーザは新しい事に対して消極的だ。見覚えの無い機能であれば尚更だ。例え70%のブラウザがこのフレーム機能を採用したとしても、大半のユーザは見慣れたコンテンツページ内のリンクを辿ろうとするだろう。


Operaのホットリストにある『リンク』の項目を私は愛用しているが、一度ページ内の対応するリンクを確認するまで不安になる事がある。便利なホットリストのリンクよりも、見慣れたページ内のリンクの方が何と無く信頼できるのだ。


しかしこの点さえ解決できれば、つまり新しい方式が早い内にユーザに浸透するならば、フレームは全てのWebユーザの心強い味方と成り得るだろう。


2003年10月27日

divとparagraphに関する考察



ブロックレベル要素のdivとpは、暫し同時に取り上げられる。pが段落なのは一目瞭然なのだけれども、divもその一部ではないかと言う説だ。理由は2つほど挙げられる。


1つの理由としては、


<p>一般的なOSには、</p>
<ul>
<li>Microsoft Windows</li>
<li>Mac OS</li>
<li>UNIX(Linux)</li>
</ul>
<p>などがあります。</p>


このマークアップに違和感を感じるからだろう。


「一般的な~などがあります」の間は、どう考えても一つの段落だ。内部に箇条書きリストを含むばかりに、HTMLのDTDの規定により段落を2つに分けなければならないという事態が生じてしまう。結果的に、本来一つのブロックであった筈の文章が、3つのブロック構造に分割されてしまう。p要素は、同様にちょっとしたテーブルやブロックレベルの引用も含む事が出来ない。実際に書籍や雑誌などの文章を見ると、段落中にこれらを含んでいる文章は決して珍しい例ではない。


中には、この問題を以下のように解決する人もいる。


<div class="paragraph">一般的なOSには、
<ul>
<li>Microsoft Windows</li>
<li>Mac OS</li>
<li>UNIX(Linux)</li>
</ul>
などがあります。</div>


また、もう1つの理由として、以下のマークアップ例を見て頂きたい。



<p class="sitelogo"><img src="logo.png" alt="サイトロゴ" /></p>
<p class="navigation">
[<a href="./index.html">TopPage</a>] >gt;>gt;[ThisPage]
</p>


単なる画像やナビゲーションリンクをbody直下にそのまま置いてしまうとDTD検証に引っ掛かるので、単純に段落で括ってみた例だ。だけれどもp要素はあくまで『段落』。本文と何ら関係の無いこれらの要素を段落としてマークアップしてしまうのには、少なからず違和感が生ずる。故に、これらのp要素を全てdiv要素に置き換えてしまうという選択肢を選ぶ人もいる。適切にclass名を与えたならば、それなりに妥当に見えるし、もしXMLならばこういう名前のタグでマークアップしていたんだと納得できる。


しかし、私はこのようなdivの使い方は望ましくないと考える。例えどんなクラス名を付けた所でdivは意味を持たない要素。作成者やCSSを解析するパーサには判ったとしても、閲覧者や一般的なユーザエージェントはその意味を知り得ない。例え見出しや段落を全てdivで置き換えたり、bodyの直下に大きなdivを置いたとしてもDTD的には妥当だけれども、それらは何ら意味を成していない。divは汎用的に使える便利にブロックレベルの要素と考えるのは間違いだ。最小のブロックレベル要素は、headingとparagraphのみであるべきだ


私はこれらの理由から、div要素は直接インライン要素を子要素に持てないと考えている(自戒のためで、人に奨めているわけではない)。blockquoteなどと同様に、ブロックレベルしか子要素に含められない要素である。div要素の使い道はただ一つ、『複数のブロック構造をグループ化するため』にしか使うべきではない。


では上記のようなナビゲーションは、どのようにマークアップすべきか。私はとりあえずリストという一つの答えを出している。



<ul>
<li>[<a href="./index.html">TopPage</a>]</li>
<li>[ThisPage]</li>
</ul>


これに関しては興味深い説もある(パン屑ナビはパラグラフかも@agenda)。


p要素がリストを含めないという問題点だが、XHTML 2.0で遂にリストやテーブル、ブロックレベルでの引用、整形テキストなどを含められるようになった。XHTML 2.0が大々的に普及するまでは、暫定的にp要素を分割するマークアップで我慢するしかないと考えている。またXHTML 2.0ではブロック構造を明示的にグループ化するためのsection要素が考案されているため、div要素の出番はますます少なくなるだろう。


もちろんこれらは仕様書を通り越した過度な解釈の仕方なので、必ずしもdivが悪いというわけではないだろう。だけれども<div>というなんら意味を持たない要素でマークアップすることの「不気味」さを、少しだけ注意しておきたい。あるいは、divはスタイルシートを適用するための“レイヤ”であるという間違った認識が、わずかでも減少してくれると有り難い。


不思議マークアップ世代



今でこそ、やれ「より妥当なマークアップ」だとか、やれ「テーブルレイアウトは異端」とか偉そうな事を日記に書いているけれども、1年ほど前には私も誰にも負けない自信があるほど不思議マークアップの使い手でした。


例えばちょうど一年前に、堂々とwwwに公開したリソース。(ママ)



<html><body>
<body bgcolor=000000>
<body text=#ffffff>
<center><font color=red size=6>
マニュアル
</font>
<br<<font color=red size=6>
<table border=1 bordercolor=ffffff>
以下略...


どうやら一つ目の<body>で本文である事を宣言して、次の<body>で背景色を付けて、3つ目の<body>で文字色を指定しようとしたんでしょう。NN4で見えないってば。headどころか、titleすら無いし。


headの無い理由は、原因は一年半ほど前のリソースを見て判明しました。



<html>
<head><tytle><font size=7 color=blue>
<center><i><b>~~特集</b></i></center></font>
<tytle></head>
<body>
<body background="img/name.gif">
<center><h5><font size=6>~~リスト</h>
以下略...


<tytle>という謎タグでマークアップした上に、思いっきり書式を指定してるし。「資料にはheadの中身は表示されないと書いてあったのに、なんで表示されてしまうんだろう。それなら見出しとして使ってしまえ。」というのが当時の私の考えだったはず。そのうちheadの存在意義すら判らなくなったので、書かなくなりました。


ちなみに、私は杜甫々さんが恩師です。


結果的に、それが本格的にHTML勉強するきっかけになったわけですが。


2003年11月05日

定義リストと見出し



定義リストは使いどころが難しい。被定義部と定義部の組み合わせというのは、大抵の場合見出しと段落で置きかえる事が可能だからだ。判断が微妙なケースが出てきたとき、dlを使うべきかh?を使うべきか多いに迷う。


定義リストの使い方には色々な説があるが、「見出し部を隠しても意味が通じる場合は見出しと段落、意味が通じなくなる場合は定義リスト」という考え方が一番妥当だと思う。つまりは定義リストは被定義部(dt)がで定義部(dd)が、見出しと段落では逆に見出し(h?)がで段落(p)がにあたるというものだ。見出しは段落の内容を要約して後から書くもので、見出しがメインなのではない。定義リストは明らか被定義部が先だ。


しかし、だからといって見出し部が主な場合は全て定義リストでマークアップすべきだろうか。実は定義リストには致命的な欠点が存在する。以下の例を見てみよう。


<dl>
<dt>被定義部A</dt>
<dd>定義部A</dd>
<dt>被定義部B</dt>
<dd>定義部B</dd>
</dl>


人間の目で見るならば、前半の組(A)と後半の組(B)がそれぞれ対になっているのは明らかだ。しかしHTMLでは必ずしもそうは解釈は出来ないし、パーサはそれを知り得ない。必ず対に存在しなければならないとか、それらがセットであるという規定はどこにも書かれていない。実際問題、CSSをあてた時にこの点で問題が発生する事がある。


チャットシステムを作成した時にこの問題に突き当たった。チャットの発言者の名前をdt要素で、発言内容をddでマークアップしてみたのだ。「DL要素の応用として、例えば対話のマーク付けがある。 DT要素が話者を示し、DD要素が話の内容を示す、というものである。」という1文がHTML4.01の仕様書に存在したためだ。


<dl>
<dt>人物A</dt>
<dd>発言内容</dd>
<dt>人物B</dt>
<dd>発言内容</dd>
</dl>


この発言ログに対して、文字色などの個人設定を定めたスタイルをあてる。個人の識別はclassを用いて判断する。


<dl>
<dt class="A">人物A</dt>
<dd class="A">発言内容</dd>
<dt class="B">人物B</dt>
<dd class="B">発言内容</dd>
</dl>


それぞれのdt,ddが対である事がDTD的に自明でないために、このように双方にわざわざclassを割り当てなければならないという自体が発生する。一つ二つならあまり気にはならないのだけれども、どうにも見ていて見苦しい。


<dl class="A">
<dt>人物A</dt>
<dd>発言内容</dd>
</dl>
<dl class="B">
<dt>人物A</dt>
<dd>発言内容</dd>
</dl>


というのも考えられるが、既にリストとは呼べない。いささか過大解釈が過ぎるだろう。こうなってくると、既にリストを使う必要性はあまり無いような気がしてくる。つまりは、以下のマークアップで充分だからだ。


<div class="A">
<h2>人物A</h2>
<p>発言内容</p>
</div>
<div class="B">
<h2>人物A</h2>
<p>発言内容</p>
</div>


div要素は、特定のブロック要素をグループ化する存在として満足だ。下手に定義リストにこだわるよりも、ずっと綺麗なマークアップになり得る。


理想を述べるならば、dtとddを適切にグループ化できる要素があるととても便利だ。例えばそれをdg要素(※注:私の独自拡張)と仮定してみる。


<dl>
<dg class="A">
<dt>人物A</dt>
<dd>発言内容</dd>
</dg>
<dg class="B">
<dt>人物B</dt>
<dd>発言内容</dd>
</dg>
</dl>


このように定義リスト内でグループか出来るならば、それぞれがセットである事は自明だし、いささか以前より“リストらしい”形になっているような気がする。ただし少々複雑化しすぎているような気もしなくはないが。


<ul>
<li class="A">
<dfn>人物A</dfn>
<span>発言内容</span>
</li>
<li class="B">
<dfn>人物B</dfn>
<span>発言内容</span>
</li>
</ul>


...これでも充分だ。


結論を言うならば、『定義』と謂う言葉にあまりこだわる必要はないと思う。リストは文章を簡潔にわかりやすく記述するための表現技法だから、そのほうが理解しやすいと判断したならば定義リストを使えばいいし、それ以外なら普通に見出しと段落だけで充分だ。全体の見出しレベル云々を色々考えるから面倒になるのであって、XHTML 2.0でレベルの無いh要素が使えるようになれば問題はだいたい解決する。dtとddの対が自明でないという点は、今のところXHTML 2.0でも解決しなさそうですけれども。


2003年11月11日

テーブルの読み上げ方



現存する音声ブラウザによるテーブル読み上げは、必ずしも完璧なものではない。しかしそれはブラウザメーカが全面的に悪いのではないだろう。現状を取り巻くWebサイトを見る限り、このような仕様が限界かもしれない。良質なブラウザを期待する前に、テーブルを無茶苦茶に使い始めた我々の方が歩み寄るべきだ。そうすればブラウザメーカも安心してテーブルをより良く読み上げる事が出来る。


ここに、理想的なテーブルの“読み上げ方”を提示する。



  1. summary属性(無ければcaption要素)を読み上げ、ユーザにテーブル全体を読み上げるかどうか選択させる。

  2. caption要素 を読み上げる。

  3. thead要素 内の th要素 はこの時点では読み上げない

  4. tbody要素 の tr要素 に差しかかった時点で、その列に存在する scope="col"scope="row" の指定された th要素を 探す。

  5. th要素 を、見出しであることを分かりやすく読み上げる。

  6. td要素 を読み上げる前に、thead要素内の scope="row"scope="col" が指定された該当する th要素 が存在した場合、そのabbr属性を読み上げる。

  7. abbr属性が存在しない場合は、見出しセルの内容を読み上げる。

  8. データセルにheaders属性が指定されている場合は、そちらの見出しセルのみを読み上げる。

  9. td要素を読み上げる。

  10. 次のセルに移動する。

  11. 最後にtfoot要素内を読み上げる。


言葉での説明だけでは分かりにくいので、簡単な表を基に読み上げ方の例を記す。


<table summary="当店メニューの価格をまとめた一覧表">
<caption>価格一覧</caption>
<thead>
<tr>
<th scope="col">商品名</th>
<th scope="col">標準価格</th>
<th scope="col" abbr="割引価格">特別割引価格</th>
</tr>
</thead>
<tfoot>
<tr>
<th id="biko">備考</th>
<td colspan="2" headers="biko">割引価格は会員のみ</td>
</tr>
</tfoot>
<tbody>
<tr>
<th scope="row">Aコース</th>
<td>3000円</td><td>2500円</td>
</tr>
<tr>
<th scope="row">Bコース</th>
<td>2000円</td><td>1800円</td>
</tr>
</tbody>
</table>



  • 「当店メニューの価格をまとめた一覧表」このテーブルを読み上げますか?

  • 価格一覧

  • Aコース(やや強めで休止を取って)

  • 標準価格、3000円、割引価格、2500円

  • Bコース(やや強めで休止を取って)

  • 標準価格、2000円、割引価格、1800円

  • 備考(やや強めで休止を取って)

  • 割引価格は会員のみ


このように親切に読み上げられるようにするには、以下の幾つかの条件が守られていなければならない。



  • 必ず表全体の概要(summary)を提供すること

  • 見出しセルとデータセルを厳密に分けること

  • 見出しセルは scope属性 で方向付けること

  • 適切に行要素をグループ化すること

  • 列要素にフィールド名、行要素にをレコード名を配置すること

  • セル内容が長い時、abbr属性で要約を与えること


今回の考察で少々残念だったのは、colgroup要素 及び col要素 を何ら活用する事が出来なかった点だ。特に colgroup要素 は列要素をグループ化するという大変有用な要素にも関わらず、存在するのは視覚的な情報ばかりで何らアクセシビリティの向上に寄与しない。いくらclass名を与えて見出し的であるかのように見せかけたとしても、ブラウザはそれを知り得ないのだ。


summary属性は難しい。ついつい私も適当な言葉を入れてしまいがちだが、もしこの読み上げ方が適用されるならばユーザが読み上げるべきかどうかの判断材料となる非常に重要な情報となるだろう。XHTML 2.0でsummary属性がsummary要素に仕様変更される事からも、可能性としては充分に有り得ることだ。summary=" " はこの場合、不許可だ。


2003年11月13日

文書型の作成



いっそのこと自分でDTDを書いてみようか、と思い立った。


Modularization of XHTML の規格に基づきつつ、XHTML2.0へとすんなり移行できるような仕様にしてみようかと。


仮称は「XHTML Structural」。


div要素による構造ブロックのグループ化を強制し、見出しに関する厳格なルールを築き上げる。(hn要素の絶対数字を取り除いても、なお見だしレベルが自明なような)。一般的なwwwブラウザの表示に限らず、例えばツリー上にレンダリングすることも想定した、極めて構造的なものにできれば、と思う。


まあ、私はXMLすらまともに書けない未熟者ですが。


2003年11月17日

idを振る要素



私は今まで fragment としての id属性 は、専ら見出し要素に付けていたのだけれども、div要素のほうが良いような気がしてきた。よく考えればその部分識別子を参照する人は別に“見出し”にリンクを張りたいわけではなく、“(意味)段落全体”を対象としているはずだ。見出しにidを振るだけでは、段落全体は参照できない。勿論、見出しが暗示的に下部の段落のハンドルとして存在していると考えるならばそうとは言い切れないが。


折角階層構造を明示しているのだから、DOM用や単なるスタイル適用のために保持しておくのは勿体無い。今度暇な時にでも一括変換しておこう。


2003年11月30日

見出しレベルに関する疑問



この度私は、「最上級見出しはh1要素でなければらならい」というルールを個人的に撤廃するかどうか悩んでいる。つまりは突然 h2 から始まろうがh4 から始まろうが、別に問題は無いのではないか、という話である。実際、多くの正しいHTMLを教えるサイトで、h1要素から始めるべきだと強く奨められている。しかしその考え方に、幾つか矛盾があるような気がしてならないのである。それに至った経緯を御紹介する。


印刷メディアにおける問題提起


近頃私は、印刷を意識した文書を作成している。とりあえずHTMLで書いておき、紙メディアとしても、Webリソースとしても活用できるようにしたものだ。最終的には1冊の簡潔なテキストに収めるつもりである。


細かく章区切りにし、各章ごとに一つのファイルとしてまとめている。この際、h1要素によってマーク付けされているのは『第n章 ~』という章題だった。結果として各ファイルにおけるそれぞれの最上級見出しがh1でマーク付けされており、あたかも妥当のようにも見える。


しかし私は章が増えてきたために、『第n部』というより大きな区切りで複数の章をまとめる事にした。ところが各部のはじめにその旨を挿入しようと考えても、既にh1要素が使われているためにそれをを挿入する事ができない。h0要素などというものは存在しなし、別ファイルにでかでかと一行『第n部 ~』と書くのも馬鹿らしい。結果的に、全てのhn要素の絶対数字を一つづつ減らしていかなければいけないという事態が発生した。


Webの表現


理想的なWebのモデルを表現するならば、全てのリソースを一意に独立したものと考えるニューラルな視点がより妥当、とは以前の記事で書いた。


もしそうならば、相互のリソース間の階層関係などどうでも良く、全てのリソース毎に最大級の見出しは h1要素 でマークアップすべきではないかという意見も理解できる。サイトタイトルが何であろうが、何処のカテゴリに属そうが、例えば「自己紹介」は「自己紹介」なのであって、その最大級見出しにはh1要素を用いるのが妥当だという話だ。


トップページを介する事無く突然そのページにアクセスしたUAが、h1要素を発見できずに「自己紹介」をマークアップしているh2要素を先に見つけてしまったら、見出し構造をどう解釈すれば良いのだろうか。


この考え方により、全てのそのファイルの中の最大見出しにh1要素を割り当てるのは“より良い”と言えるかもしれない。


URIと識別子


リソースを一意的に識別するために用いられるのがURIである。しかしURIには部分識別子(id属性やname属性)も含まれることに注意したい。もしリソースごとの最大見出しが h1要素 でなければならないのであれば、全ての部分識別子を持つ要素の最大見出しも h1要素 でなければなるまい。


たしかにその“ファイル”から見ればそれは第3レベルの見出しかもしれないが、その部分識別子を含むURIからリソースを見れば第1レベルの見出しであるに違いない。通常閲覧者はサーバ名やディレクトリ名を意識せずともリソースにアクセスできることと同様に、“ファイル”という単位もまた作成者側の都合に過ぎない。もしかすると、部分識別子の指し示す領域のみを表示するユーザエージェントが存在したとしても不思議ではない。そう考えると、一つのファイル上での最大見出しは h1 でなければならないというのは随分と可笑しな話だ。


絶対数字という矛盾


一冊の本を例に取ってみよう。先ほどは『章』の上に『部』という階層レベルが存在し得ると述べた。しかしそれならば、『本のタイトル』というさらに大きな見出しが存在することにも気付くだろう。もしかしたらその本はシリーズもので、『第何巻』という階層が存在するかもしれないし、『その作者の作品』『出版社』『同じジャンル』『書籍』『情報媒体』といくらでもその階層を遡ることができる。


極端な話だが、カテゴリ分けという意味での階層レベルは、上も下も無限大である。それを絶対数字として定義する事自体に無理がある。あたかもそれが最大見出しのように見えたとしても、井の中の蛙、一歩後ろに下がってみればもっと大きな見出しがある。


もっとも、あるレベルを仮に1と定めることによって、あたかも絶対的であるかのようにそのレベルを表現する仕方もある。


相対的なレベル


見出しとは常に相対的に存在するべきものである。つまりはそこにある規則によって纏められたテキスト群があり、それを代表するかたちで見出しが存在する。ここでは、一対一の純粋な相互関係によるアプローチとする。


より上位の見出しとより下位の見出しによる上下関係は確かに存在するが、そこに明らかな基点は存在しない。「章」を基準とするか、「節」を基準とするか、「部」をベースとするかは状況によって異なるので、それは自由に作成者が割り当てられるべきだ。HTML4.01にはレベル1から6までしか用意されていない為、便宜上、その中に収めなければならない。つまり、h0要素 や h7要素 が存在する事が無いように、適切に相対的な見出しレベルを調整する必要がある。


そのファイル内においての最大級見出しをh1要素でマークアップすることに不具合があるならば、h2で始まっても問題無いはずである。数字は確かにレベルの高さを表しているが、1だから最大、2だから準レベル、と決めつけるのは汎用性が低い。HTMLは自然言語をマークアップするために用いられるべきだから、そのような不便性は解消されるべきだ。


過渡的な手段


対象をWebに絞るならば、“ファイル”上の最大見出しをh2でマーク付けするのはあまり得策とは言えない。一般的な慣習とは異なっているし、潜在的な見出しを得るための手段が貧弱(link要素の解釈等)なため、ユーザやUAを混乱させる恐れがある。それを解消する術として、例えばはてなダイアリーのように全てのページにヘッダ部分を表示するという方法もある。


XHTML 2.0が勧告されてしまえば、このような奇妙な思いをしなくても済むようになるかもしれない。何故ならば、h要素とsection要素による極めて単純な見出し構造が実現できるからだ。


2003年12月03日

典型的な属性



とある初心者向けのローカル資料を作成していたのだけれども、一つの難題に付き当たってしまった。


「HTMLで初めて“属性”という概念を説明する時、何を例に取り上げたら良いだろう。」


ぱっと思いついたのがa要素のhref属性だ。だが、URIも何も説明していない時に、参照に関するルールを教えるのは難しい。リンクするためのサンプル・ページをもう一つ用意しなければならないというのも難点の一つである。もう一つはimg要素のsrc属性だが、これも同様にURIの解説が必要だし、空要素という特殊な例だから出来れば避けておきたい。


もっと簡単で、分かりやすい典型的なタイプの属性は無いものか。


ある意味では、font要素はこういう時に便利である。color属性だのsize属性だのをちょちょいと弄れば、面白いほど見た目が変化するのである。point-size属性あたりも良い。さぞかし、読者はHTMLというものを“素晴らしく”理解してくれるに違いない。


title属性あたりが一番無難かとも思ったのだけれども、いまいちtitle属性を上手く言い表す表現が思いつかなかった。「小さいツールチップの中にテキストを表示する」では駄目だろうな。仕様書を引いたら、「この属性は、当該要素に関する助言的情報を提供する。」とあった。分からなくも無いが、aかabbrでも組み合わせないと具体的な例文がさっぱり出てこない。―単に私の表現力不足か。


よく考えてみたら、strictなDTDでは直感的な属性があまり存在しない事に気付く。それこそ、MSIEには無視される類のものばかりだ。XHTML 2.0になると、属性がごっそりAttribute Collectionsに纏められてしまって、要素毎の固有属性は数えるほどしかない。独自拡張の謎な属性が乱発しすぎて無駄にHTMLを難しくしていたのだから、そういう統合は当然の結果なのかもしれない。CSSというものを全く知らなかった頃、p要素やdiv要素にbgcolor属性を付けても色が変わらないのがとても不思議だった。


結局思いつかないので、色々なサイトを見て回ることに。



HTML 4.01 Specification

h1要素にid属性

はじめてのWebドキュメントづくり

a要素のhref属性

ごく簡単なHTMLの説明 30分HTML講座

a要素のhref属性

簡単で正しいHTMLの書き方

img要素のsrc属性

Personnel 初心者のためのホームページ作成講座

div要素のclass属性

PCTips HTMLの定義のための覚書

blockquote要素のcite属性

とほほのWWW入門

font要素のsize属性

Web for beginner 作成支援

p要素にstyle属性

以外とバラバラで面白い。面白がってる場合でも無いのだけれど。折角だから、title属性で頑張ってみようか。


2003年12月07日

var要素



HP : 25 / 30


このようなRPGによくある残りHitPointを表す表示があったとして、25の部分(現在値)がスクリプトによって動的に変化する場合、


<dfn>HP</dfn> : <var id="foo">25</var> / 30


とvar要素でマークアップするのは“あり”だろうか。


要素に直接アクセスするためにはidを振るのは良いのだが、そのためにspanを使うのも何だと思ったので。“変数”というよりは“変化する数字”ですが。




VAR

変数またはプログラム引数のインスタンスを示す。

HTML 4.01 Specification


少なくとも、インスタンスではない事は確かである。


2003年12月08日

ホームページ入門



理想と現実



ブラウザで表示させてみましょう、HTMLタグを書いたら表示確認をしてみましょう、と書いてゐるサイトは駄目。


こんな「ホームページ入門」は駄目!


確かにその通りだ。理想論を述べればそうなのである。既存のWebブラウザは必ずしもその間違いを指摘しないし、「HTMLはレイアウトのためのもの」という余計な誤解を与えてしまう。文書のチェックはやはりそれ相応のツールを使うのが一番だ。


しかし、残念ながらこの理論は現実的ではない


いくら正しい薀蓄を述べたとしても、生徒がまずそれに興味を抱かないうちには何も始まらないのである。それぞれの意味を正しく説明し、段階を追って解説するのが正道なのだろうが、まず実際にこの目で確かめてみなければ何時まで経っても知識は自分のものにはならない。やはり視覚というものは偉大なもので、とりわけ初心者はブラウザにその変更が反映されて初めてそれがどのような効果をもたらしたかを知るようになる。h1タグで括って整形式を作り上げた“事実”ではなく、その“結果”ブラウザ上で太字の大きなフォントで表示されたことに依ってのみ、やっと「自分は見出しをマーク付けしたのだ」と理解するのだ。


文法と厳格さ


AHLを初めから使うなど色々検討してみたが、残念ながらその選択肢は残らなかった。AHLのまずい所は、“間違いばかりを指摘する事”である。チェッカなのだから至極当たり前の話だが、しかし「間違いばかりを悉く突き付ける教師は愚か」である。


まず自分の行なった行為の結果を見て、それから間違いを直していく方がより利口な手段だ。自らの意志でチェッカを使うのは一向に構わないが、「ほら、お前の書いているHTMLはこんなに駄目なんだ」と初めから言われて生徒はやる気を出すだろうか。それよりも、視覚的に自分の辿った道筋を眺めてから、行く末を正してやるのが道理である。


実際的な手段


一つの教え方として、こんな事を考えてみた。まず初めに簡単なCSSサンプルを与えてやり、それを早速HTMLに適用する。それから初めて要素云々タグ云々の解説をする。h1はボーダー付きのセンタリングで表示されるし、pには1文字分インデントが入る。中途半端に視覚的な教え方をするから勘違いするのである。初めからがちがちな視覚的効果に訴えれば良い


もちろんfontやbの類は教えない。それをやってしまったら御仕舞いである、見出し要素を使って様々なレイアウトを作り出す事を覚えさせ、自然と適切な見出し構造が組めるように誘導する。時期がくれば別のスタイルシートを与えてやり、CSS次第で全く異なる見栄えになり得る事を覚えさせる。テーブルには自動的に枠線が入り、色がつく。段落からはみ出たテキストは、不自然に左端に寄る。グルーピングすれば、周囲にぐるりと罫線を引く。一通り基本的な要素を覚えさせた後で、初めてCSSの書き方を教授するのだ。生徒たちの頭の中には、既に色々なレイアウトを試してみたいという欲求が起きている事だろう。


賢明な人は、「それではHTMLがまるでWebレイアウトのための言語みたいじゃないか」と思われるかもしれない。実の所私はそれでも良いと思っている。正確に言い直せば、「CSSで整形したHTMLが」だが。彼らの望んでいるのはWebサイトの構築である。欲求と直接関係無い“(彼らにとっての)例外”についてあえて序盤で触れる必要は無いだろう。そういった薀蓄は、XMLに入る辺りからでも充分遅くない。


教え方の壷


ここで重要なのは、スタイルが全てCSSによって制御できる事を自然に理解させる事である。そして見出し要素の重要性をもだ。HTMLの要素=スタイルという方程式を崩し、文書構造の大切さを学ばせる。もし初めから完成したスタイルを与えていなかったならば、h1は文字サイズを大きくするもの、pは改行2つと覚えるだろう。そして何時まで経ってもさっぱり“ほ~むぺーじらしく”ならない事に苛立ちを覚え、どこぞのほ~むぺーじ入門から引っ張ってきたfontやらmarqueeやらを使い出すかもしれない。


正しい事ばかりをただひたすらに教えるばかりでは、学者としては良いかもしれないが、教師としては失格だ。学ぶ事に意欲を与え、自主的に答えを見出させるのが教育である。ただ単純に引っ張っていくだけなら誰にだって出来る。生徒が大いなる間違いを犯した時にだけ、暖かくその背中を押してやれば良い。


現時点では、少なくとも私には他人に教えられるような資格は無い。相変わらず自身のエゴを押し付けようとしているからだ。下らない主義主張を捨て、教わるものの立場に立って初めてその気持ちが理解出来るのかもしれない。


2003年12月22日

kbd,samp,var



比較的出番が少ないと思われる論理要素 kbd , samp , var がどれだけ使われているかちょっと気になったので、ローカルに保存しているリソースたちにgrepしてみた。



  • <kbd>:606個

  • <samp>:5325個

  • <var>:5234個


皆さん結構使っているらしい。特にkbdあたりはいまいち使いこなせていなかったので、大変参考になった。


とはいえ、これは“限られた範囲内”での話。一歩外世界を出歩けば、<var> どころか <code> も <em> も何処にも無い。むしろ<strong>のほうが微妙に多いというのも面白い話だ。やはりデフォルトスタイルが<b>と同じという点が要因だろうか。


さすがに例示と実験以外で bdo要素 を使っているページは見当たらなかった。


2003年12月26日

q要素の謎




趣味をQタグで囲むことで間をあけます。HTMLは次のようになります。

<Q>パチンコ</Q>
<Q>競馬</Q>
<Q>ゴルフ</Q>


XML&Javascriptシステム開発 @ 秀和システム


知らなかった、qタグ って空白を空けるためのタグだったんだ。画面写真を見る限りでは、確かに半角空白が間に入っている。― 気になったので早速実験。


パチンコ競馬ゴルフ


著者が使ってるらしいIE6.0でも空白も何も入らないし、MozやOperaでは引用符が付いてしまうのですけど。もしかしてその空白ってCRが置き換えられたことによる半角空白のことだったのだろうか。謎。


2004年01月05日

HTML Formの問題点とXForms



既存のHTMLのフォームコントロール要素は、お世辞にも論理的とは呼べない。後から後から機能だけを取ってつけたというかたちで、仕様にも全く一貫性というものが無い。新しく提案されているXFromsと比較しながら、問題点を考察していく。


多機能過ぎる <input>


最もよく使われるinput要素は



  • 一行プロンプト

  • ボタン

  • チェックボックス

  • ラジオボタン

  • 隠しコントロール


という、機能も外見も全く異なる様々な形式を取る事が出来る。これらは全て type属性 の値によって決定される。実際的な問題として、例えば属性セレクタの対応していないIEでは、クラス名の助けを借りない限りはコントロールのスタイルを変更するのが困難である。機能面においても、「入力」「選択」「送信」「保持」と全く一貫性が無い。


HTML4.0においてボタン形式は button要素 に分離されたが、NN4.x等の古いブラウザが対応していないという問題もあり、あまり使用されていない。


XFormsにおいてはinput要素の役割は大幅に削減されており(多少追加もされたが)概ね文字通り"input" の機能のみを果たすようだ。


一貫性の無い選択用コントロール



  • <input type="radio" /><select>

  • <input type="checkbox" /><select multiple="multiple">


これらは機能的には全く同等のものである。単にレンダリング方法の違いだけで、大幅に仕様の異なる2つを使い分けなくてはならなくなっている。これらは統合され、スタイルシート或いは何らかの属性によってのみ、それらの表示形式を変えられるべきだ。この場合においては、一貫性の無いinput要素よりもリスト形式に近いselect要素が採択されるべきであろう。


XForms においては、 重複選択が select要素 、単一選択が select1要素に纏められており、その表示方法は appearance属性 によってラジオボタンやプルダウンメニュ等に変化する。


一貫性の無い入力フォーム



  • <input type="text" value="hoge" />

  • <textarea>hoge</textarea>


これらの入力フォームは、改行が有効かどうかが異なるだけで、あとは全く同等のものである。それだけの違いなのに、初期値の書き方やサイズ指定、取り得る属性など全く異なる仕様になっている。これらは統合され、改行できるかどうかは何らかの属性によって決定されるべきだ。


XForms でも、未だにinput要素とtextarea要素は分かれている。加えて、<input type="password" /> が secret要素 として別定義されている。まあ、全く不要だとは言わないが。


labelとquery


HTML4.0からlabel要素を用いて明示的にコントロールの説明を貼り付ける事が出来るようになった。しかし既存の仕様とも被る部分が多く、やはり一貫性が無い。

































各コントロールのクエリ値とラベル
コントロールKeyValueLabel
<input type="test"> name属性value属性(label要素)
<textarea> name属性内容テキスト(label要素)
<input type="radio"> name属性(重複可)"on" | value属性label要素
<input type="checkbox"> name属性"on" | value属性label要素
<select> + <option> select要素のname属性option要素の value属性 | 内容テキストoption要素の内容テキスト
<optgroup> --label属性
input type="submit" name属性value属性value属性
<button type="submit"> name属性内容テキスト内容テキスト


解りやすくするためには、これらに一貫性を持たせる必要がある。


XFormsにおいて、ラベルは殆どのコントロールの子要素として存在できる。また、新たなテキスト情報付加機能として hint要素 も加わった。


form要素の内容モデル


form要素 の Minimal Content Model は (%block;|SCRIPT)+ -(FORM) となっている。つまり行内要素である %formctrl; を直接子要素として含むことができない。これは確かに適切に構造化するための制約として充分なものなのだが、もともと構造的とは言えないコントロール群にそれを強制するのはいささか難がある。


例えば、隠しコントロール(<input type="hidden" />)は何によってグループ化すれば良いのだろうか。これは何かのグループというよりも、form要素の直接の初期値とでも考えたほうが妥当である。また、適切なグループ化要素であるはずのselect要素も何故か行内要素として扱われている。これらを段落(<p>)でマーク付けするのはいささか気分が悪いし、formの直下をdivで括るのも本末転倒だ。具体的な解決策としては、リストや fieldset でグループ化するという手もあるが、全てのケースに当てはまるとは言えない。


XFormsのスキーマをまだじっくり見ていないので詳しくは知らないが、現在ほどの混乱は無さそうだ。


XForms


断片的な部分しか見ていないので詳細なコメントは避けておくが、XForms1.0は概ね期待できるフォーマットと言っても良いだろう。最も、早々に多くのブラウザが対応してくれるとは考えられないので、専らXSL変換しながら使っていくしか無さそうだけれども。


2004年01月07日

HTML+TIME2.0



VML関連を調べているうちに HTML+TIME2.0 というのを見かけたので色々調べてみた。


というか使えませんね、これ。全く使いどころが分からない。Webページに時間の概念を与えて様々な画面効果を展開するというのだけれど、この手の“テクニック”はユーザに嫌われるだけだと思うのだが。



  • トランジション(遅い)

  • マーキー(読み難い)

  • metaによるリダイレクトもどき(勝手に飛ばされる)


の悪い所をいっしょくたにして纏めたという感じ。


それこそ、それ自体を一つの作品として捉えでもしない限りは使用価値はないだろう。HTML+TIME2.0のみでShockwave並のプロモーション動画を作ってみるとか。


2004年01月19日

AccessKey



accesskeytabindex(navindex) は今までどうにも使う気になれなくて敬遠していたのだけれども、WAIで奨められている事なので(優先度3だが)導入を検討してみる事にした。


しかしただ付けただけでは、全くその存在にすら気が付かない事が判明。メニュバーのように括弧付きでキーが明示されると助かるのだが。というわけで作ってみる。

if(document.getElementById){
var objAnc = document.getElementsByTagName("a");
for(i=0;i<objAnc.length;i++){
if(objAnc.item(i).accessKey){
objKey = document.createElement("kbd");
txtKey = document.createTextNode(objAnc.item(i).accessKey.toUpperCase());
objKey.appendChild(txtKey)
objAnc.item(i).appendChild(document.createTextNode("("));
objAnc.item(i).appendChild(objKey);
objAnc.item(i).appendChild(document.createTextNode(")"));
}
}
document.styleSheets.item(0).addRule('a kbd','text-decoration: underline');
}

label やら input やらは面倒なので今回は省略。と言うか単純に a[accesskey]:after{ content: "(" attr(accesskey) ")"; } で済む話だな、これは。IEには無視されるけど。


しかしいざ設定してみると、面白いほどブラウザ側のメニュバーと競合してしまう。[alt]キー以外にアクセスキー用のキーを割り当てる事は出来ないのだろうか。手持ちのブラウザを片っ端から開いてみると、メニュバーと確実に競合しないのは



  • J

  • K

  • Q

  • X

  • Y

  • Z


のたったの6種類だけだった。これでは当分使う気になれない予感。


2004年01月26日

targetに関する考察



HTMLにおける target 属性が概ね有害である事はよく知られている。HTML4.01 及び XHTML1.0 では非推奨(Deprecated)、XHTML1.1、XHTMLBasic、ISO/IEM15445:2000 ではそれぞれ廃止済みだ。特にウィンドウを新しく開いてそこにリンク先の文書を表示する、target="_blank" は特に嫌われている。WAIのチェックポイントでは、[優先度2] だ。ユーザビリティのNielsen博士曰く、

新しいブラウザ・ウィンドウを開くというのは、訪問するやいなや、お客様宅 のカーペットに灰皿の中身をぶちまけて歩く、真空掃除機のセールスマンにひとしい。勝手にウィンドウを開いて、私のモニタを汚染するのはやめてもらえないかね、頼むから。新しいウィンドウが必要だと思ったら、自分で開くよ!


新・ウェブデザインの間違いトップ10 @Jakob Nielsen博士のAlertbox

しかし target は全く本当に使い物にならない、排除すべき過去の遺物なのだろうか。実際に時折出会うケースとして、次のような例を考えてみる。



  1. ユーザはサービスへの登録のために、入力フォームにパスワードや他の情報を入力する

  2. [送信] ボタンを押すべきか迷っている時に、すぐ近くに「プライバシー・ポりシー」と書かれたリンクを発見する

  3. ユーザがそのリンクをクリックすると、現在開いているウィンドウが「プライバシー・ポリシー」ページに置き換わる

  4. 内容を一通り確認した後、「登録画面に戻る」というリンクをクリックする

  5. 先ほどフォームに入力した内容が全て消えている


このような事態が発生した場合、ユーザはしばしば登録することを諦める。これは明らかに製作者側の設計ミスだが、target 属性が非推奨だからといって単純に排除しただけでは、思わぬ顧客の不満を煽ることにもなりかねない。ちなみにブラウザの「戻る」ボタンを押した場合でも、type="password" であるコントロールは内容が保存されない。


考慮すべき点には、次のようなものがある。



  • ユーザが自分から新しいウィンドウを開いてくれる事を期待すべきではない。多くのユーザはその方法を知らないか、あるいはその習慣がない。

  • ユーザが戻るボタンを押す事を期待すべきではない。知らないかもしれないし、検索エンジンから来たかもしれない。

  • フォームに入力したページが一度別のものに置き換わると、内容が一時保存されるという保証は無い。


「プライバシー・ポリシー」や「ヘルプ」といった類のリンクに target="_blank" を設定すれば、あたかも全て解決したかのように見える。Transitional DTD が一向に減らないわけだ。確かにそれは一つの解決策かもしれない。


しかしそれでは納得できない人も多いだろう。target属性の根本的な問題点は、ユーザの行動をHTMLの内部に含めてしまっているという点にある。「"_blank"に開くアンカー」があったらブラウザはそれに従わざるを得ないのであって、それ以外の解釈はできない。丁度「強調」ではなく「赤くて文字サイズ6」と同じようなものだ。インタフェース部分はスクリプトやスタイルシートによって提供するのがベストだろう。それに関して言えば、確かに解決策はある。

解決策

<a href="./privacy.html" rel="Help">プライバシー・ポリシー</a>

これだけで充分である。ただ「Help」という関係のみを表すのがアンカー要素の役割だ。しかし残念ながらrel属性の値によって挙動を変化させられるブラウザは今のところ存在しない。スクリプトを用いてユーザインタフェースを補う必要があるかもしれない。

function mClick(e){
var objEvt = (document.all) ? window.event.srcElement : e.target.parentNode;
if(objEvt.nodeName == "A" && objEvt.getAttribute("rel").toUpperCase() == "HELP"){
window.open(objEvt.getAttribute("href"),"help");
return false;
}
}
function addEvent(){
if(document.all) return;
var links = document.getElementsByTagName("A");
for(var i=0; i<links.length; i++){
links.item(i).addEventListener('click', mClick, true);
}
}
if(document.all){document.onclick = mClick;}
window.onload = addEvent;

JavaScriptが有効になっている場合、Help なリンクは新しくウィンドウを開いてそこに展開される。無効な場合はもちろんただのハイパーリンクだ。欠点を挙げるとすれば、window.open など特定の関数のみを無効化されているときの挙動か。


さて、ヘルプ・リンクを新しいウィンドウで開くという挙動が良いのかというと、実はごく一般的な挙動なのではないかと思う。殆どのアプリケーションにはオンラインヘルプが用意されているが、ヘルプを開いた時、現在編集・閲覧しているウィンドウを上書きしてそこにヘルプが展開される設計になっているものは非常に少ない(あえて言うならばOperaしか知らない)。目の前の画面に対して疑問を抱いたのだからヘルプを開くのであって、その疑問対象が消えてしまうとユーザは戸惑うかもしれない。“慣習”という観点から見るならば、「ヘルプ=別窓」はひどく一般的だ。


しかしユーザアクションの先読みは、時としておせっかいに繋がる事は否定しない。あらかじめ別ウィンドウで開く事を通知しておくか、或いは選択できるようにしておくほうが Better だろう。先ほどのスクリプトに幾らか改良を加えて「別窓」リンクを作ったり(アンカー文字列の妥当性は皆無だが)、cursor: help という規則を適用しても良いかもしれない。

結論

新しいウィンドウを開くというのは、アクセシビリティ問題も絡んでくるので一概には言及しきれない。しかし完全に Web から抹消してしまうことだけは避けるべきかもしれない。また、スクリプトというのは環境に依存するので、必ずしも万全な解決策とは言いきれない。


そういえば、XHTML 2.0のドラフト5版では Target Module がまだ存在していたけれど、6版ではすっぱり切り捨てられてますね(今頃気付いた)。XLink や XFrames に頼るということなのだろうか。XLink の role 属性や arcrole 属性をいまいち理解していないので、なんとも言えない。show属性やactuate属性はどうかと思うけれど。せめてもう少し意味論的な指定は出来ないものか。


追記:




2004年02月04日

フレームとサイト規模



全く根拠性の無い法則であるが、ページ総数が100に満たないWebサイトにフレームは不要である。逆に言えばそれを越えるサイトは、或いは導入を検討しても良いかもしれない。


というのも、今日の中/大規模なサイトにはグローバルナビゲーション(全コンテンツに対するリンク)が多すぎる。新たなページを開くたびに左側の領域を我が物顔で占拠するそれらは、ユーザにとって邪魔にしかならない。そんなものを全てのページにわざわざ埋め込むくらいなら、フレームを使ったほうが遥かに良いだろう。そう、フレームは自由に切り離せるが、テーブルで固定したそれらは執拗に付きまとう。メンテナンス面においても、表示速度においてもフレームのほうが圧倒的に有利である。


そもそも、そのようなグローバルナビゲーションは必要なのだろうか。Nielsen の言葉を借りるなら、「ヘアドライヤーを探しているユーザが、グランジ・ミュージックのページに行きたくなる可能性がどれほどある?もっとはっきり言おう。人類史上で、こんなリンクが必要になる日がやってくる可能性がどれほどあるというのだろう?ナビゲーションは役に立つのか@Alertbox」。最低限必要なナビゲーション項目は、



  • ホーム

  • 目次(或いは一つ上の階層)

  • 前のページ

  • 次のページ


だけであると思う。つまりはHTML4.01で定義されている %LinkTypes; の範囲内だけで充分だ。


しかし企業サイトともなると、クライアントの要求によりグローバルナビゲーションを用意せざるを得なくなるのであろう。そんな時、テーブル段組によるナビゲーション領域を確保しようとするのは賢い選択とは言えない。フレームのデメリットを深く検討した後、そのサイト設計を行なうべきだ。代替手段を用意し、コンテンツ領域にも最低限のナビゲーションを配置し。無論、グローバルナビゲーション自体を廃止するのが一番良い選択肢だとは思うが。


一つだけ言える事は、10ページにも満たないサイトにフレームも大規模なナビゲーションも不要である。ただホームに戻るリンクさえあればそれで満足だ。


2004年03月12日

リセットボタン



「フォームにリセットボタン(type="reset"のコントロール)を設けないのは、意に反して契約の申込みをさせようとする行為に相当するとして、違法になる」という類の記述を、書店でWebデザイン関連の書籍を読んでいて見つけた。


しかしリセットボタンを間違って押した時のリスクは大きく、ユーザビリティとしては寧ろ低下するのではないかと思う。送信のつもりでリセットを押した時の悲劇といったら、かなりものだ。一般的な登録フォームであれば、入力内容全体を修正するケースなど稀だろう。私は基本的に type="reset" のリセットボタンは設置しない方針だ。


上記ガイドラインに抵触しないためには、送信ボタンを押した時に確認ページを一枚用意すれば充分だと思う。


2004年03月29日

インラインフレームについて



私はインラインフレーム中に表示するのは「参照」と捉えているけれども、相手がそう思わなければ、避けるほうが無難なのかもしれない。どちらの答えにしろ、現在は大多数が納得する状況にはなっていないので、参照先が拒絶したなら外したほうが良いだろう。


私の意見としては、フレーム内に表示するしないの問題ではなく、それが自分のコンテンツに見えるか否かのほうが重要なのではないかと思う。例えば『リンク集』と銘打ったページ中で他人のトップページを埋め込んだところで、それを勘違いする人は少ないだろう。Googleの画像検索にしてもそうだ。


自分のサイトのように見せ掛けるのだったら、アンカーによるリンクでも出来る。つまり、『手段』では無く『文脈』に依存するのではないかと思う。


どうしても気になるのだったら、訴訟でも何でも起こせばよいだろう。幼稚じみた方法で嫌がらせしたり煽ってみるよりは、きちんとした場所で定めてもらいたいものだ。


2004年04月09日

pre要素によるマーク付けについて



ちょっと気になる記述を見つけたのでメモ:ウェブの作り方・整形済みテキストについて。


要約すると、「pre 要素には欠点が多く正当な使い道も見出せないで、当サイトでは一切用いない」というもの。参照先のサイトでは、サンプル・ソースコードを pre 要素ではなく ol 要素によってマーク付けしている。例えば以下のようにである。


  1. <title>HTMLについて解説。</title>
  2. <h1>HTMLについて。</h1>
  3. <h2>HTMLとは。</h2>


*


<pre> でマーク付けされると、幅の面で問題が出てくるという点には大いに賛成できる。いくつかの Web ブラウザで pre 要素内で自動的な折り返しが行なわれないため、過度の横スクロールを出さないためにはある程度で改行しなければならず、その際どうしても“特定の解像度のPC”を意識しなければならなくなる。ブラウザ表示画面とにらめっこしながらソースコードに改行を加えていく作業は、ひどく苦痛である。さらに BASIC のインタプリタ(コンパイラ)では復帰文字を処理の区切り記号として解釈するので、そのまま改行しただけではコピー&ペーストした際にエラーが発生してしまう。そのような表示のためだけのコーディングの変更は、汎用性が無く本質的なものでは無い。


おそらくその解決策として準備されたと思われる非推奨要素の width や NN4 の wrap 属性は、どちらにしろ推奨されていないし IE 等では実装されていない。CSS の white-space プロパティの値にそれを実現できるものが出れば良いのだが、今のところ空白文字は尊重しつつ自動折り返しを有効にするための値は用意されていない。よって現状では妥協して適度に改行を加えるか、横スクロールを無視するか、pre{width:100%;overflow:scroll} という規則を加えるといった方法しか無い。


しかし、このような“欠点”(ここではあえて欠点と呼んでおこう)をもってしても尚、私は pre 要素を便利な要素だと思っている。私の pre 要素の捉え方は、再利用する可能性の高いコードのマーク付けのために用いるものというものである。ソースコードを他の要素(例えばol要素やl要素)によってマーク付けしようとすると、再利用する際の手間が多くなりやすい(例えばDOMでは一つ一つのノードを解析して結合する必要があるかもしれない)。整形済みテキストを用いればプログラムソースを“そのまま”持って来る事が出来るし、再利用する際も実体参照を解決してやるだけで良い。プログラムソースをそのまま例示として提供する要素としては、pre 要素が現状では一番良いのではないかと考えている(もちろん、例文を細かくマーク付けする行為が望ましくないという意味ではない)。


その点では、替わりにtextarea 要素を用いても構わないと思っている。寧ろ再利用のし易さではこちらのほうが上だ。ただ textarea 要素はフォームに値を渡すためのコントロールであるので本来の目的とは異なるし、マーク付けの自由度も低い。


ただ順序リストや行要素を用いることのメリットとして、行番号を振る事が出来るというものがある。たまにプログラムソースに“手動で”行番号を挿入しているケースを見かけるが、コピー&ペーストした際にそれらも一緒にくっ付いてくるため、再利用性に乏しい事この上ない。順序リストや行要素を用いれば、ソースに関係無く自動的に番号を割り振る事も可能である(悲しい事に一部のブラウザでは、これらも文字列選択の対象となってしまうが)。


私は pre 要素を用いる事を今のところさほど問題視していませんが、このサイトの積極的な姿勢には敬意を表させていただきます。


2004年06月01日

button 要素と IE のバグ



フォーム関連要素は使う機会が少ないので今まで気付かなかったが、IE の button 要素の実装にしてやられたという気がした。以下のコードを見て頂きたい。



<form>
<ul>
<li><button type="submit" name="btn1" value="1">Prev</button></li>
<li><button type="submit" name="btn2" value="1">Next</button></li>
</ul>
</form>

2 つの提出(submit)ボタンを持った、ごくありふれた小さなフォームである。これを Netscape(Mozilla)*1で開いて[Next]ボタンを押すと、以下のフォームデータが Web サーバに提出される。


btn2=1

サーバサイドスクリプトは、送られたキーを基準にユーザの要求を正しく判別することができる。しかし IE 6.0 で同様に [Next] ボタンを押してみると、

btn1=Prev&btn2=Next

と、押すか押さないかに関わらず全てのボタンに割り当てられたフォームデータを送信してしまう。これではどちらのボタンが押されたか全く判別できない。正しく判別させるにはクライアントサイドスクリプトを用いるか、提出ボタンを一つにして select 要素等で選択させるしかない。
HTML 4.01 の仕様書によると、


1つのフォームに複数の提出ボタンがある場合、アクティブにされた提出ボタンのみが満足となる。
フォームの提出:満足なコントロール -HTML4仕様書-

とあるので、IE の動作は明らかに間違った実装だ。実際、そんな事をやらかされると大いに困る。


もう一つ気が付く点として、IE は初期値として設定した value 属性の値を無視し、内容のみ送信した。悪い予感がしたので、このようなボタンを作って試してみた。



<button type="submit" name="btn" value="1" >
<img src="./btn.png" alt="Submit" />
</button>

この画像ボタンを含んだフォームデータの送信文字列は、IE では


btn=%3CIMG+alt%3DSubmit+src%3D%22.%2Fbtn.png%22%3E

となる。予感は的中、見事に img タグを丸々送信してくれている。そんな馬鹿な。ボタンに画像を用いることの有用性は別として、これでは全く使い物にならない。


BUTTON要素が生成するボタンとINPUT要素が生成するボタンは、機能的には同等だが、 BUTTON要素の方がレンダリング能力が高い。

BUTTON要素は内容を持てる。例えば、画像を内容に持つBUTTON要素の機能は、type属性が"image"のINPUT要素とそっくり同じだが、BUTTON要素型は内容を持てるのだ


17.5 BUTTON要素 -HTML 4.01仕様書-

とあるが、IE がある以上かえって button 要素の方が使い難くなっている。もちろん Moz や Opera はそんな馬鹿なことはしない。
これらの問題点は、伝統的な input 要素を用いれば解決する。しかし折角 button 要素があるのにわざわざそちらを用いるのは今ひとつ潔しとしない。


button 要素を用いる具体的なメリットとして、たとえば属性セレクタを用いなくても押しボタンに CSS の規則を与えることができるというものだある。input 要素ではテキストフィールドやラジオボタンにまで同じスタイルが指定されているため、属性セレクタに対応していない IE では別途 class を当てるなどして割り振らなければならない。


IE のために button 要素を使いたいのに、やっぱり IE にそれを阻まれるというのは皮肉な話だ。JScript の style プロパティから JSSS もどきなスタイル指定をしても良いが、内部的には style 属性によるインラインスタイルシートと同様な扱いをされているということに気付いて使う気が失せた。最も、送信ボタンのスタイルを無闇にデフォルトスタイルから変更するのは、ユーザビリティ的な観点からしてあまり好ましくないのだが。


比較的 MS 製品支持派の私でも、久しぶりに IE がかなり嫌いになった。これでは button 要素を他の人に勧めようがない*2。提出ボタンはユーザインタフェース上のかなりクリティカルな位置を占める要素なので、後方互換性は最大限に考慮しなければならないだろう。またしても我々は IE に足を引っ張られるのだろうか。




*1:Opera 7.23 や Lynxでも同様


*2:ちなみに Netscape 4.x ユーザを考慮に入れるなら、まず button 要素は使ってはいけない。


About HTML

ブログ「ねこトトラ」のカテゴリ「HTML」に投稿されたすべてのエントリーのアーカイブのページです。過去のものから新しいものへ順番に並んでいます。

前のカテゴリはDOMです。

次のカテゴリはLinkです。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。