targetに関する考察 - 猫式Webメモ

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

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

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

ユーザはサービスへの登録のために、入力フォームにパスワードや他の情報を入力する
[送信] ボタンを押すべきか迷っている時に、すぐ近くに「プライバシー・ポりシー」と書かれたリンクを発見する
ユーザがそのリンクをクリックすると、現在開いているウィンドウが「プライバシー・ポリシー」ページに置き換わる
内容を一通り確認した後、「登録画面に戻る」というリンクをクリックする
先ほどフォームに入力した内容が全て消えている

このような事態が発生した場合、ユーザはしばしば登録することを諦める。これは明らかに製作者側の設計ミスだが、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属性はどうかと思うけれど。せめてもう少し意味論的な指定は出来ないものか。
追記：