target 属性 (HTML)

`target` 属性 (HTML)

[4] HTML の target 属性は、文書を開くフレームの名前を指定します。

[16] a、 area、 base、 button (submit)、 form、 input (image、submit)、 link

属性名: target (target (対象) より)
属性値: %FrameTarget; (>>6)
既定値: (>>7)

[5] 仕様書:

HTML 4
- 16.3 Specifying target frame information IW:HTML4:"present/frames.html#target-info"
Web Forms 2.0
- 2.17. Extensions to the submit buttons IW:WF2:"#extensions3"

代替

[10] この属性は非推奨です HTML 4。代わりに、スタイル・シートで指定できます。

[11] CSS3 では、 target 特性を使って指定できます。

属性値

[156] form 要素の target 内容属性やフォーム制御子の formtarget 内容属性の値は、妥当な閲覧文脈名またはキーワードでなければなりません >>155。

[6] この属性の値は %FrameTarget です。大文字・小文字は区別しません HTML 4 16.3。 SGML 的には CDATA です。

[7] この属性は省略可能です。

UA による利用

[12] リンクを辿る時に、リンク先資源を開くべきフレームは、次のように決定するべきです。 HTML 4 16.3.1

まず、 target 属性を調べます。指定されていれば、そのフレームで開きます。
自分に target 属性が無ければ、 base 要素の target 属性を調べます。指定されていれば、そのフレームで開きます。
自分にも base 要素にも target 属性がなければ、自分と同じフレームで開きます。

なお、指定された名前のフレームがなければ、新しい窓とフレームを作り、そこで開きます。そのフレームの名前は指定された名前とします。
UA は、利用者が target を上書きする仕組みを用意しても構いません。

他との関係

[8] この属性に指定するフレームの名前は、 (予約名以外は) frame 要素や iframe 要素の name 属性で定義します。

安全性

[14] これまでの実装の中には、 target 属性で指定されたフレーム名に素直に従い、たとえ他の文書・他の鯖の文書であっても該当する名前のフレームがあればそこにリンク先文書を開くものがありました。

このような実装方法は、閲覧者を不可解に思わせるだけでなく、悪意を持つ人が他のウェブ・サイトのフレームに、あたかもその一部であるかのように自分の文書を含めることが可能であり、問題があると現在では考えられています。 (多くのブラウザはフレーム内の文書の URI を常時表示してはいませんから、普通の閲覧者は気付きにくいのです。)

[15] フレーム内の文書から他者の資源にリンクする際に、 target を使って、あるいは使わないで、自分のフレームの中にその資源を表示させるのは良くないことだと考える人もいます。

特に他者の資源であると明記しない場合には >>14 と同じような問題となり得ますし、意図的に他者の資源を自分のものと見せかけると法的な責任を問われる虞もあります。

閲覧文脈の選択

[144] 次の場面では、 navigate のための閲覧文脈の選択が行われます。

[131] ハイパーリンクをたどる処理 >>130
- a 要素、area 要素
[166] フォームの提出 >>165
[172] window.open (やそれに相当する document.open)

[188] プラグインからの navigate の指示を行う API が提供されている場合、それも同様の選択を行うかもしれません。

SVG、MathML

入出力

[149] これらの処理では、著者の指定、利用者の個別の指定、利用者の事前の設定や利用者エージェントの実装方針と現在の利用者エージェントの状態に基づき、 navigate が行われるべき適当な閲覧文脈を決定します。

[150] その結果、閲覧文脈を1つ選択するか、どの閲覧文脈も選択しないかのどちらかに決まります。閲覧文脈は、既存のものかもしれませんし、新たに作成するものかもしれません。また付随して navigate の引数の

置換有効フラグ
利用者が閲覧文脈を明示したフラグ

... を設定することがあります。

[208] 閲覧文脈の選択で置換有効フラグが真に設定されるのは、新しい閲覧文脈が作られた場合です。仕様書では、ハイパーリンクをたどるの定義ではそれを使って分岐しています (が不完全です (>>173))。フォームの提出や document.open では新しい閲覧文脈が開かれた場合、というような分岐になっていて、一貫していません。

[196] 判断の起点となる「現在の閲覧文脈」とは、 window.open (相当) では入口設定群オブジェクトの有責閲覧文脈 >>231、それ以外では要素の閲覧文脈です。

著者の指示

[197] 著者は、 target 属性、 formtarget 属性、 window.open メソッド (相当) の第2引数によってどの閲覧文脈を選択するべきかを記述できます。

[198] 歴史的には、 HTTP Window-Target: ヘッダーも存在していました。

[121] 砂箱化~~や seamless~~ であるか否かも影響を与えます。

[205] ハイパーリンクの場合、~~リンク型 sidebar が指定されているかどうかや、~~ リンク型 noreferrer や noopener が指定されているかどうか (noopener) も、挙動に影響を与えます。

[206] window.open (相当) の場合、その第3引数を字句化して得られる字句化済機能群が新たに開かれる閲覧文脈の表示方法に影響を与えます。

利用者の指示

[23] 利用者が利用者エージェントにどのように指示したり、設定したりする (できる) のかは、利用者インターフェイスやプラットフォームの慣習に属する領域なので、仕様書では明確には規定されていません。

[125] 一般的には、個別の navigate の指示では次のような選択肢が利用者に提示されます。

[152] 特に方法を指定しない
[153] 現在の閲覧文脈を選択する
[185] 他の閲覧文脈を選択する
[164] 新しい閲覧文脈を選択する
- [170] 新しい窓を開く
- [183] 新しいタブを開く

[184] 通常のクリック (相当) では方法を指定しなかったものとみなし、それ以外は文脈メニューとして表示可能としたり、 Ctrl や Shift などの修飾キーとの併用で適用したりするのが普通です。リンク等を他の閲覧文脈に DnD することで、その閲覧文脈を選択できるのも一般的です。

[186] 異なる動作モード (private browsing や利用者プロファイルなど) で開く選択肢を提供する Webブラウザーもあります。閲覧文脈同士が相互にアクセスできない、異なる利用者エージェントと考えるべきものですから (private browsing 参照)、本項の閲覧文脈の選択や navigate とも異なる処理と考えるべきでしょう。

[240] こうした指示の手段は、通常のハイパーリンクだけでなく、フォームの提出でも提供されるかもしれません。 window.open (相当) の実行時にも提供できます >>231。

[234] 例えば Ctrl + クリックで新しいタブでリンクを開く利用者エージェントは、 onclick 時に Ctrl が押されていれば、そこから呼び出された window.open において新しいタブの閲覧文脈が指示されたとみなすことができます >>231。

[187] スクリプトからの window.open やハイパーリンクの click など、修飾キーによる指示は適用できてもメニューからの選択は原理的に行えない場合もあります。

[190] ポップアップ (スクリプトによる新しい最上位閲覧文脈を開く操作) は、濫用された歴史から、厳しく制限されるのが普通になっています。スクリプトによらず著者の指定に従い利用者の操作を経て新たな最上位閲覧文脈を開くものも、必要以上に使われている (と感じる利用者が少なくない) ため、 Webブラウザーやブラウザー拡張が無効化する機能を提供する場合があります。

[118] ポップアップを有効にするか、無効にするか設定できるのが一般的です。既定の状態では有効となるのが普通です。ポップアップ抑制

この設定は、 allowed to show a popup な場合に適用されるものです。つまり利用者の動作があった上でのポップアップに関するものです。 allowed to show a popup でない (利用者の動作によらない) 場合はそもそもポップアップに至りません。

[98] (利用者の明示的な指示によらずに) 新しい閲覧文脈を開く場合、次のいずれの動作とするか、利用者が設定できることがあります。

[99] 新しい閲覧文脈を開く (通常はこれが既定値となっています)
- [100] 新しい窓を開く
- [115] 新しいタブを開く
[110] 現在の閲覧文脈で開く (この選択肢を提供することが推奨 (encourage) されています >>20)
[116] 何も開かない

[117] ただし砂箱化のために基本的に何も開かないべき場合 (>>96) もあります。その場合であっても新しい閲覧文脈や現在の閲覧文脈を使う選択肢を提示できます (それが既定値であってはなりません >>20)。

[119] ポップアップが拒否された旨の表示 (>>95) がある場合、そこから利用者が有効に設定変更したり、手動で navigate したりできるかもしれません。 (その navigate は元の処理の続きではなく、新たに実行することとなります。)

[191] >>117 のような他の閲覧文脈の利用や >>119 のような手動の navigate は、元の著者が想定していた砂箱化の指定を無視することになるかもしれず、注意が必要です。 (砂箱化も参照。)

[192] ポップアップの挙動の設定は、利用者エージェント全体のものだけでなく、 >>119 などにより閲覧文脈ごと、文書ごとなどの単位で指定できるかもしれません。

選択処理

[179] 閲覧文脈の選択は、次のようにして行われます。

[132] 利用者が新しい閲覧文脈を作ることを指示した場合、
1. [133] noopener について閲覧文脈の作成を行い、選択します >>130, >>231。 (>>200 も参照。)
2. [134] one permitted sandboxed navigator を、現在の閲覧文脈に設定します >>130, >>231。
3. [176] 置換有効フラグを、真に設定します >>231。
[135] それ以外で、利用者が特定の閲覧文脈を使うよう指示した場合、
1. [136] その閲覧文脈を選択します >>130, >>165, >>231。
2. [122] 利用者が閲覧文脈を明示したフラグを、真に設定します。
[181] それ以外で、要素やメソッドの指示があれば、それにより選択します (>>168)。
[182] それ以外の場合、文書の指示により選択します (>>147)。

[167] フォームの提出に関して、仕様書は利用者に新しい閲覧文脈を作成することを指示された場合について明記していません。

[173] 仕様上、ハイパーリンクをたどる場合で利用者が新しい閲覧文脈を作らせた場合に置換有効フラグ (>>176) は設定されないようですが、意図的にそうしているのかは不明です。不具合のようにも思われます。

[207] 利用者が新しい閲覧文脈を作成することを指示した場合、著者の指示していた場合 (>>18) の細かな挙動の違いは生じないことになります。特に、 (著者の指示の有無に関わらず) 作成される閲覧文脈はただの最上位閲覧文脈で、補助閲覧文脈とはなりません (window.opener を持ちません)。

要素からの選択

[168] 要素やメソッドの指示による選択は、次の通り行います。

[137] ハイパーリンクをたどる処理では、ハイパーリンクの要素について、
1. [175]
  - [145] a 要素や area 要素の場合で、
  - [146] target 属性がある場合、
  1. [138] 属性値に閲覧文脈名から閲覧文脈を選ぶ規則を適用します。 >>130
[169] フォームの提出では、提出者の要素について、
1. [158] 要素が提出ボタンで、 formtarget 属性がある場合、
  1. [159] formtarget 属性値 >>155 に閲覧文脈名から閲覧文脈を選ぶ規則を適用します。 >>165
2. [160] フォーム所有子があり、それに target 属性がある場合、
  1. [161] target 属性値 >>155 に閲覧文脈名から閲覧文脈を選ぶ規則を適用します。 >>165
[174] window.open (相当) では、
1. [177] 第2引数 (省略時や空文字列時は _blank) に、閲覧文脈名から閲覧文脈を選ぶ規則を適用します。 >>231

[151] link 要素では、 target 属性があっても無視されます。

文書からの選択

[147] 文書の指示による選択は、次のようにしなければなりません。

[162] 節点文書の子孫で target 属性のある base 要素がある場合、
1. [163] 該当する最初の base 要素の target 属性 >>130, >>155 に閲覧文脈名から閲覧文脈を選ぶ規則を適用します。 >>130, >>165
[180] それ以外の場合、節点文書の閲覧文脈とします >>130, >>165, >>155, >>20。

[148] window.open (相当) の処理では、必ずメソッドの指定による処理が行われるので、こちらの選択方法が適用されることはありません。

[157] HTML Standard では、要素の対象 (target) >>155 を使って規定されています。対象とは、選択時に適用される target/formtarget 属性値 (なければ空文字列) のことです。

名前の解決

[18] 閲覧文脈名から閲覧文脈を選ぶ規則 (the rules for choosing a browsing context given a browsing context name) >>20 とは、次のようにすることです。

[46] 閲覧文脈名が空文字列なら、
1. [57] 現在の閲覧文脈を選択します >>20。
[55] 閲覧文脈名が ASCII大文字・小文字不区別で _self なら、
1. [58] 現在の閲覧文脈を選択します >>20。
[60] 閲覧文脈名が ASCII大文字・小文字不区別で _parent なら、
1. [62] 親閲覧文脈 (なければ現在の閲覧文脈) を選択します >>20。
[63] 閲覧文脈名が ASCII大文字・小文字不区別で _top なら、
1. [64] 最上位閲覧文脈 (なければ現在の閲覧文脈) を選択します >>20。
[84]
- [85] 閲覧文脈名が ASCII大文字・小文字不区別で _blank 以外で、
- [86] 同名の閲覧文脈が存在し、
- [87] 現在の閲覧文脈と familiar with 関係にあり、
- [88] 両者に十分関係性があると利用者エージェントが判断するなら、
1. [89] その閲覧文脈を選択します >>20。
  - [90] 複数候補があれば、何らかの一貫した方法 (開かれたのが最直近、焦点が当たったのが最直近、最も関係が深い、など) でいずれかを選ぶべきです。 >>20
[93] 現在の WindowProxy の Window の過渡活性化が偽で、ポップアップしないよう利用者エージェントが設定されている場合、
1. [94] どの閲覧文脈も選択しません >>20。
2. [95] ポップアップがブロックされたことを利用者に通知して構いません >>20。
[114] そうでない場合、利用者の設定に基づき、新しい閲覧文脈を選ぶか、現在の閲覧文脈を選ぶか、閲覧文脈を選ばないかを決めます >>20。
- [96] 現在の閲覧文脈の活性文書の活性砂箱化フラグ集合に sandboxed auxiliary navigation browsing context flag が設定されている場合は、原則として閲覧文脈を選ばないこととします。 >>20
- [126] その場合も他の選択肢を利用者が選べるようにしても構いません。しかしそれが既定値であってはなりません。 >>20
[101] 新しい閲覧文脈を作成する場合、
1. [123] noopener について閲覧文脈の作成を行い補助閲覧文脈を作成し、選択します >>20。 (>>200 も参照。) これを閲覧文脈とします。
2. [124] opener閲覧文脈を、現在の閲覧文脈に設定します >>20。
3. [103] 指定された閲覧文脈名が ASCII大文字・小文字不区別で _blank の場合や、現在の閲覧文脈の活性文書の活性砂箱化フラグ集合に sandboxed auxiliary navigation browsing context flag が設定されている場合は、
  1. [194] 閲覧文脈名を、空文字列に設定します >>20。
4. [97] それ以外の場合は、
  1. [195] 閲覧文脈名を、指定された値に設定します >>20。
5. [111] フラグ集合を、現在の閲覧文脈の活性文書の活性砂箱化フラグ集合に設定します。 >>20
6. [142] フラグ集合の砂箱化navigate閲覧文脈フラグの sandboxed navigation browsing context flag が設定されている場合、
  1. [143] 閲覧文脈の one permitted sandboxed navigator を、現在の閲覧文脈に設定します。 >>20
7. [213] フラグ集合の sandbox propagates to auxiliary browsing contexts flag が設定されている場合、
  1. [112] フラグ集合で設定状態にある各フラグについて、
    1. [113] 閲覧文脈のポップアップ砂箱化フラグ集合のフラグを設定します。 >>20
8. [193] 置換有効フラグを、真に設定します。 >>130, >>165, >>231
9. [244] 補助閲覧文脈の場合、
  1. [224] 字句化済機能群について、 CSSOM View の規定を適用します >>231, >>243。これにより窓の大きさなどが決まります。
10. [220] 閲覧文脈の script-closable のスクリプトが作成したか利用者が作成したかの情報を保存します。
[106] 現在の閲覧文脈を再利用する場合、
1. [107] 現在の閲覧文脈を選択します >>20。
[108] 閲覧文脈を選ばない場合、
1. [109] どの閲覧文脈も選びません >>20。

[127] 関連性の決定 (>>88) をどのように行うのか、明記はされていません。

[91] Window オブジェクトの名前付き特性や配列風アクセスが可能なことを考えると、子供閲覧文脈を優先して選択するべきと思われます。

[129] 自身のopener閲覧文脈を除く、他の最上位閲覧文脈に属する入れ子閲覧文脈は、関連性が低いかもしれません。利用者の混乱を避けるため、そのような入れ子閲覧文脈の選択は認めるべきではないかもしれません。

[92] 自身またはその先祖や子孫の関係にある閲覧文脈がopener閲覧文脈となった補助閲覧文脈を除き、最上位閲覧文脈を選択するのも不適切かもしれません。

[128] sandbox からのポップアップ (>>96) では砂箱化フラグ集合が引き継がれることになっていますが、既存の閲覧文脈を再利用する場合適用されないことになります。危険かもしれないので、関連しないと判断するべきなのかもしれません。

次の処理

[154] a 要素や area 要素の活性化動作からハイパーリンクをたどる場合で、どの閲覧文脈も選ばれなかった場合には、ハイパーリンクをたどる手順はなにもしないで終了します。

それがスクリプト内からの呼び出しの場合には、 InvalidAccessError 例外が投げられます。

[171] フォームの提出の際に閲覧文脈が選択されなかった場合にどうなるのかは、定かではありません。

[178] window.open (相当) で閲覧文脈が選ばれなかった場合、 InvalidAccessError 例外が投げられます。

[189] seamless の扱いに関する処理は、本規則による選択ではなく、その後の navigate 内で行われます。本規則による選択の後新たなタスクで navigate を実行する場合もあるため、それまでに seamless に関する状況が変わっているかもしれません。
navigate 参照。

新しい閲覧文脈のレンダリング

[139] XXX

[217] 新しい閲覧文脈であれ、既存の閲覧文脈であれ、他の窓にリンク先を開いた場合、その窓に表示とフォーカスが移ることが期待されています。特にスマートフォンのような単一の窓しか同時に表示できないプラットフォームでは、裏側で閲覧文脈が開いていても利用者が気づきません。

[218] ただし、Webブラウザーによっては、利用者が明示的に新しい閲覧文脈にフォーカスを移動しないオプションを提供していることがあります。リンク集ページから多数のリンク先を順に開いていきたい時に便利です。

新しい閲覧文脈が閉じられる

[245] 閲覧文脈の選択によって新しい閲覧文脈が作成されたにも関わらず、それが閉じられることがあります。利用者から見ると、新しい窓やタブが一瞬開いて、すぐに閉じられるように見えることがあります。 (実装によってはその一瞬を表示しないこともあるかもしれません。)

[246] 具体的には、新しい閲覧文脈で navigate したにも関わらず、 navigate からダウンロードに切り替わると、何も表示するものがなくなってしまうので、その閲覧文脈は閉じられることがあります.

[247] Firefox は、 target 属性で新しいタブが開かれてダウンロードに移行すると、そのタブを閉じるようです。しかし利用者がリンクの文脈メニューから新しいタブを開き、そのリンク先がダウンロードに移行した場合には、そのタブを開いたままになります。開かれたままのタブは、アドレスバーにリンク先の URL が表示されるものの何も表示されない特殊な状態になります。

[248] その状態で開発ツールのコンソールによると location.href は about:blank なのですが、通常の about:blank とは違って viewport には何もレンダリングされていません。 (about:blank にnavigateしたときと背景色が違い、右クリックしても文脈メニューが開かず、何かをドラッグアンドドロロップしても何も反応しない。) 2022-11-11T03:52:01.700Z

歴史

誕生

[24] target 属性は、フレーム機能の一部として Netscape Navigator 2 で導入されました。

どの要素に? Windows 版以外では?

[40] New HTML 3.0 Proposals (2007-02-26 21:59:55 +09:00 版) http://wp.netscape.com/assist/net_sites/new_html3_prop.html#Target

[249] New HTML 3.0 Proposals, 2024-08-15T14:44:47.000Z, 1997-06-14T03:22:19.453Z http://web.archive.org/web/19970613222237/http://www82.netscape.com/assist/net_sites/new_html3_prop.html

[41] How to target a link to a window (2007-02-28 00:30:29 +09:00 版) http://web.archive.org/web/19970613222251/www82.netscape.com/eng/mozilla/2.0/relnotes/demo/target.html

[250] How to target a link to a window, 2024-08-16T05:43:33.000Z, 1997-06-13T22:27:49.549Z http://web.archive.org/web/19970613222251/http://www82.netscape.com/eng/mozilla/2.0/relnotes/demo/target.html

`Window-Target:` ヘッダー (HTTP)

[2] HTML で言うところの base 要素の target 属性的な HTTP 頭欄。 Netscape Navigator 2.0 以降の独自拡張。

[3]

Window-Target: _top

標準化

[25] HTML 4 で、非推奨ながら a, area, base, form, link に target が追加されました。

[19] HTML 4.0 仕様書本文の frame 要素と iframe 要素の定義には誤って target 属性の定義への参照が含まれていました。

A.1.2 Errors that were corrected IW:HTML4:"appendix/changes.html#h-A.1.2"

[26] XHTML m12n では、対象属性モジュールという独立したモジュールが定義されました。

[27] XHTML 1.1 1e は対象属性モジュールを組み込みませんでした。

暗黒時代

[28] target が非推奨となり、厳密DTD や XHTML 1.1 に含まれませんでしたが、既に下火になっていたフレームはともかく、 target=_blank への需要は高く、形式的な妥当性を得つつも target を使いたいという要求が少なくありませんでした。

[29] 妥当性と target の両方を求める人たちは、 JavaScript と DOM で、 target や open などを用いて target を実現しようとするなどの本末転倒な回避法 (ごまかし) に走り出しました。

[30] >>29 のような手法は、本来宣言的に記述できるものをあえてわかりにくくすることで、アクセス可能性や利用可能性に劣るといわれています。

[31] このような背景から、 target の復活を求める意見もあります。

再評価

[75] target は HTML に不適当との考えから90年代末に排除の方向へと進みましたが、代替がなかったために >>28 のように非本質的な書き換えが横行するなど、事態はむしろ悪化していました。意味的潔癖性を追求するよりはむしろ実利も含めて総合的に判断するべきとの考えが支持されるようになり、 2000年代の終わりには一部の原理主義者を除いて完全に容認する方向へ進んでいます。

XHTML2

[32] XHTML 2.0 では、 XFrames との関係もあって、 target が復活しました。

[73] XHTML2 の最初の作業原案で、ハイパーテキスト属性集成に属し、実質すべての XHTML2 要素で利用できるものとして規定されるようになりました。

- XHTML Attribute Collections (2002-08-06 00:20:43 +09:00 版) http://www.w3.org/TR/2002/WD-xhtml2-20020805/mod-attribute-collections.html#adef_attribute-collections_target

[71] target attribute (Shane McCarron 著, 2009-01-25 04:02:09 +09:00 版) http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0077.html

@target is defined in the hypertext attributes module. I believe this should be moved into a target attribute module so that it can be more easily omitted from languages that do not want to support it.

XHTML1

[34] XHTML 1.1 には元々 target 属性は含まれていませんでしたが、旧 HTML WG (後の XHTML2 WG) は XHTML 1.1 2e WD で対象属性モジュールを「復活」させました。

ただし、旧 HTML WG の仕様書は例によって杜撰で、追加されたのは DTD 実装だけで XML Schema 実装や文書型の定義には含まれていませんでした。

[35] 更に XHTML Basic 1.1 WD でも対象属性モジュールが「復活」させられました。

[36] しかし、 XHTML Basic の主要な適用対象である携帯電話の業界は、 target 属性は携帯電話の Webブラウザでは実装できない機能だとして >>35 に反発しました。

[74] 結局 XHTML2 WG (旧 HTML WG) は XHTML Basic 1.1 が勧告に至るまでに次のような注記が追加されることで反発を抑えました。

target 属性はフレーム、複数窓、タブなど外部環境 (external environment) に束縛するための一般的なフックとして設計されている
- 外部環境が利用できない利用者エージェントでは target 属性を無視してもよい
- 束縛された外部環境がある時は target 属性の適合性要件は各外部環境で定義される
著者は利用者エージェントの target 属性に注意する必要がある
- 外部環境の束縛の有無、利用可能な資源の制約、アプリケーションや利用者の設定、実装依存の設計方針などに依存する
- 外部環境適合性が存在しないときは target 属性に依存しないことを推奨する
実装依存の target 属性の用法は相互運用性の妨げとなりかねないことに注意されたい

XHTML™ Basic 1.1 (2008-07-27 02:02:25 +09:00 版) http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/#s_xhtmlmodules

[76] >>74 の注記は一見普通のことを言っているように見えますが、よくよく考えてみるとまったく無茶苦茶です。

そもそもこの記述は XHTML Basic にまったく依存していないのだから、 XHTML m12n あるいは HTML4 の改訂によって追加するべき注意なのではないか
- 実際、後に XHTML 1.2 ED にもコピペされている
「一般的なフックとして設計されている」という記述は事実なのかどうか
- 少なくても HTML4 にはそんなことは書かれていない
適合性に関する記述が「Note」として記述されているが、仕様書の作法としてありなのかどうか
- たしかに Note は informative との記述はどこにもないが、 normative とも明記されていないし、 Note は informative だといっている仕様書もあるから、少なくても confusing ではある
適合性が利用者エージェントに依存するなんて態度でいいのかどうか
著者にとっても実装者にとっても「注意しろ」としか書かれていない仕様書に一体なんの意味があるのか
そもそも XHTML1 シリーズはクライアントの環境に合わせたプロファイルを作ることによって device independence を実現するのが方針ではなかったのか
- そのためにわざわざ target 属性が単独の XHTMLモジュールとなっているのに、それを敢えて追加して「無視してもよい」などと注記する意味はどこにあるのか

HTML5

[17] Web Forms 2.0 で、 input (image、submit)、 button (submit) に追加されました。特に非推奨との記述はありません。

XHTMLモジュール定義 (参考) では、多窓やフレームに対応しているときに target 属性が定義されるとされています。

[33] Ian Hickson は、2007年2月、 Web Applications 1.0 への target の追加について、 iframe 対応のために必要との見解を #whatwg で示しています。

それによると、存在しないフレーム名を指定するのは不適合、存在するフレーム名を指定するのは適合とするつもりだそうです。

例

[9] 単純な例 HTML 4 16.3

フレーム文書:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
   "http://www.w3.org/TR/html4/frameset.dtd">
<HTML>
<HEAD>
<TITLE>A frameset document</TITLE>
</HEAD>
<FRAMESET rows="50%,50%">
   <FRAME name="fixed" src="init_fixed.html">
   <FRAME name="dynamic" src="init_dynamic.html">
</FRAMESET>
</HTML>

init_dynamic.html:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>A document with anchors with specific targets</TITLE>
</HEAD>
<BODY>
...beginning of the document...
<P>Now you may advance to 
    <A href="slide2.html" target="dynamic">slide 2.</A>
...more document...
<P>You're doing great. Now on to
    <A href="slide3.html" target="dynamic">slide 3.</A>
</BODY>
</HTML>

ここで、 init_dynamic.html 内の2つのリンクのいずれを辿っても、 fixed フレームは不変で、 dynamic フレームだけが変わります。

[13] base target の例 HTML 4 16.3.1

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>A document with BASE with a specific target</TITLE>
<BASE href="http://www.mycom.com/Slides" target="dynamic">
</HEAD>
<BODY>
...beginning of the document...
<P>Now you may advance to <A href="slide2.html">slide 2.</A>
...more document...
<P>You're doing great. Now on to 
       <A href="slide3.html">slide 3.</A>
</BODY>
</HTML>

>>9 ではそれぞれの a に target を指定しましたが、その文書のリンクの target がすべて同じなら、 base でまとめて指定しておくのが便利です。

メモ

[1]

::frame ("frame-name") a {
  target: "another-frame-name";
}

みたいな感じのことができると、 target 属性もいらないし、特定の frameset だけに依存せずに style sheet を書けるよね。最近の CSS3 draft はどうなっているのだろう?

[21] 携帯電話業界から XHTML Basic 1.1 に target を追加することへの反対が結構強いね。。。 (名無しさん 2006-08-12 15:04:21 +00:00)

[22] target属性の利便性 (kuruman.org > 駄的HTML改善計画) (2007-02-18 00:31:14 +09:00 版) http://kuruman.org/dateki/target

[37] 別窓指定の理想論 (kuruman.org > Kuruman Memo) (2007-02-23 02:50:28 +09:00 版) http://kuruman.org/diary/2007/02/23/target-blank (名無しさん 2007-02-23 16:03:46 +00:00)

[38] target="_blank"は多数派? (kuruman.org > Kuruman Memo) (2006-09-09 01:47:03 +09:00 版) http://kuruman.org/diary/2007/02/24/is-target-blank-popular (名無しさん 2007-02-25 02:10:35 +00:00)

[39] 別サイトへの target="_blank" は優しいか http://pc10.2ch.net/test/read.cgi/hp/1136738511/

おもしろい統計がでている http://pc10.2ch.net/test/read.cgi/hp/1136738511/834

(名無しさん 2007-02-25 02:11:46 +00:00)

[42] target="_blank"によるリスクの軽減:メモランダム (2007-02-22 23:32:51 +09:00 版) http://elastic965.80code.com/blog/2007/02/target_blank (名無しさん 2007-03-08 14:00:59 +00:00)

[43] まじかんと雑記: Re: target="_blank"によるリスクの軽減 (2007-03-08 23:00:43 +09:00 版) http://magicant.txt-nifty.com/main/2007/02/re_target_blank_e80b.html (名無しさん 2007-03-08 14:02:18 +00:00)

[44] 無爲徒食日記二千七年二月 (眞名垣郁夫著, 2007-02-28 15:45:43 +09:00 版) http://lan.rgr.jp/diary/2007/02#Twentyfive-One (名無しさん 2007-03-08 14:03:53 +00:00)

[45] http://suika.fam.cx/~wakaba/-temp/test/dom/window/name/target-name-1.html

target で新しい窓の名前を (newwindow) 指定し、そのリンクをたどって新たな閲覧文脈を作成します。

新しい閲覧文脈の名前 (window.name) は newwindow となるのが自然な動作です。

WinIE 6 (Windows XP SP2)、Opera 9 は実際そのように動作します。 window.name は newwindow になりますし、その中の target が newwindow なリンクをたどると同じ窓で開かれます。

しかし、 Firefox 1.5 は、新しい窓を新しいタブとして開く設定になっていると、名前を持たない (window.name が空文字列の) 閲覧文脈が作られてしまいます。新しい窓として開く設定になっていれば WinIE や Opera と同じく window.name は newwindow になります。

(名無しさん)

[47] XHTML 1.1 Modularization Anchor Element Target Attribute - www.TexaStar.com (Texastar.com WebMaster@TexaStar.com 著, 2007-08-14 21:17:48 +09:00 版) http://www.texastar.com/tips/2004/target_blank.shtml (名無しさん)

[48] Sparanoid » Blog » XHTML 1.1 plus Target 1.0 and other modularizations (Sparanoid 著, 2007-08-14 21:24:36 +09:00 版) http://sparanoid.com/blog/xhtml-11-plus-target-10-and-other-modularizations/ (名無しさん)

[49] torresburriel.com » Blog Archive » Añadir el módulo target a XHTML 1.1 (2007-08-14 21:25:50 +09:00 版) http://www.torresburriel.com/weblog/2004/04/19/anadir-el-modulo-target-a-xhtml-11/ (名無しさん)

[50] Łukasz Aranowski - strona domowa (Aster, Astercity, MP3, stacje, Kolejarz, Microsoft, XHTML, zdjęcia i inne...) (Lukasz Aranowski 著, 2007-08-14 21:28:31 +09:00 版) http://www.mendel.pl/index.php?co=xhtml (名無しさん)

[51] Do podstrony - Odsyłacze - Kurs HTML (Sławomir Kokłowski 著, 2007-08-12 00:17:26 +09:00 版) http://www.kurshtml.boo.pl/html/do_podstrony,odsylacze.html (名無しさん)

[52] net2ftp forum / Doctype (2007-08-14 21:41:03 +09:00 版) http://www.net2ftp.org/forums/viewtopic.php?pid=6679 (名無しさん)

[53] Standards-Compliant New Windows | Accessify (Ian Lloyd, Accessify [http://www.accessify.com/] 著, 2007-08-17 23:17:09 +09:00 版) http://www.accessify.com/features/tutorials/new-windows/ (名無しさん)

[54] XHTML 1.1 plus Target 1.0 DTD — Information (2007-09-24 16:17:49 +09:00 版) http://suika.fam.cx/gate/2007/schema/schema/dd9db9d3e91e5444c7741e0d0e3943b2/prop.html (名無しさん)

[56] Thermaglaze Double Glazing (2008-03-01 12:20:27 +09:00 版) http://www.thermaglaze.com/ (text/html)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" 
 [ <!ATTLIST a target CDATA #IMPLIED> ]>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

(名無しさん)

[61] The target="" attribute (Ian Hickson <ian@...> 著, 2008-04-21 05:21:56 +09:00 版) http://permalink.gmane.org/gmane.org.w3c.whatwg.discuss/13793 (名無しさん)

[65] Lachy’s Log » Blog Archive » Conforming target Attribute (2008-07-26 22:40:57 +09:00 版) http://lachy.id.au/log/2008/04/target-attribute (名無しさん)

[66] 冬様もすなる☆日記というもの (2008年10月) (わかば著, 2008-10-17 18:50:52 +09:00 版) http://suika.fam.cx/~wakaba/d/d200810#d17-2

[67] 類似の属性に、 SMIL の show 属性や XLink の xlink:show 属性、 SVG の target 属性、 OpenDocument の meta:target-frame-name 属性があります。 HTTP には Window-Target: 頭欄があります。その他 API 等で同様の役割を果たす引数等もあります。詳しくは FrameTarget の項を参照してください。

[68] MAMA: Frames - Opera Developer Community (2008-11-25 20:37:51 +09:00 版) http://dev.opera.com/articles/view/mama-frames/#target

[69] The SMIL 3.0 Linking Modules (2008-12-02 00:45:09 +09:00 版) http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-extended-linking.html#adef-target

[70] Linking – SVG Tiny 1.2 (2008-12-20 02:31:29 +09:00 版) http://www.w3.org/TR/2008/REC-SVGTiny12-20081222/linking.html#AElementTargetAttribute

[72] target は (「戻る」や「進む」やハイパーリンクによる前後の方向への「水平」な移動に対して) 「垂直ナビゲーション」を記述するものだと理解する考え方もあります。

[77] Web Forms 2.0 (2009-01-05 20:07:15 +09:00 版) http://www.whatwg.org/specs/web-forms/current-work/#xhtml-module-def

[78] XFrames ( (2010-12-17 00:45:08 +09:00 版)) http://www.w3.org/TR/2010/NOTE-xframes-20101216/#s_links

[79] >>78 によると、 target が明示されていない場合、そのフレームに xml:id があればそのフレーム、なければ全体 (_top? その XFrames 文書の最上位?) が指定されたような動きになるようです。

[80] WICD Core 1.0 ( (2010-08-17 16:51:00 +09:00 版)) http://www.w3.org/TR/WICD/#child-documents

[81] Touch Events ( (2013-10-12 10:35:42 +09:00 版)) https://dvcs.w3.org/hg/webevents/raw-file/v1/touchevents.html#widl-Touch-target

[82] New HTML 3.0 Proposals ( (2014-04-07 08:07:57 +09:00 版)) http://web.archive.org/web/19970806103517/http://www31.netscape.com/assist/net_sites/new_html3_prop.html

[83] Welcome to Netscape Navigator Version 2.0 ( (2014-04-07 08:48:39 +09:00 版)) http://web.archive.org/web/20030202175634/http://wp.netscape.com/eng/mozilla/2.0/relnotes/windows-2.0.html#Images

[210] Add an 'allow-popups-to-escape-sandbox' sandboxing token · whatwg/html@955fbaa (2015-09-10 00:18:19 +09:00 版) https://github.com/whatwg/html/commit/955fbaa

[211] Add a 'noopener' link attribute by mikewest · Pull Request #290 · whatwg/html (2015-11-12 22:14:09 +09:00 版) https://github.com/whatwg/html/pull/290

[212] Add a 'noopener' <link rel> keyword and window feature · whatwg/html@2992ea9 (2015-11-12 22:14:24 +09:00 版) https://github.com/whatwg/html/commit/2992ea921bc75e44157451a37a807a8ce0b9a884

[120] Remove <iframe seamless> · whatwg/html@1490eba (2016-02-04 19:20:59 +09:00 版) https://github.com/whatwg/html/commit/1490eba4dba5ab476f0981443a86c01acae01311

[59] Editorial: clarify follow a hyperlink algorithm · whatwg/html@d22a9f1 (2016-03-26 12:47:36 +09:00 版) https://github.com/whatwg/html/commit/d22a9f12e1cc13a77504fa6482b7ded6ba790b54

[141] Set "one permitted sandbox navigator" for all sandbox-created popups (mikewest著, 2016-09-13 00:53:04 +09:00) https://github.com/whatwg/html/commit/ca6c42085dae650676ad90a0b852cc2e8c6feab7

[214] Allow <a>/<area> with download="" to not require user activation (domenic著, 2016-12-06 07:13:46 +09:00) https://github.com/whatwg/html/commit/5de03c7b38e7b33a49f0dcf2bcef29e8eb9a2205

[215] Revert part of "Allow <a>/<area> with download="" to not require user… (zcorpan著, 2016-12-07 17:47:38 +09:00) https://github.com/whatwg/html/commit/b359209579d79a713af88ecf24b9be8fb6168adf

[216] href が javascript: で void を返し、 target が新しい閲覧文脈の時、 Firefox は about:blank の新しい閲覧文脈を作り、 Chrome は作らないようです。 2016-12-19T09:46:24.600Z

[209] Should target=_blank and window.open('...', '_blank') be case sensitive? · Issue #2443 · whatwg/html (2017-04-01 14:58:30 +09:00) https://github.com/whatwg/html/issues/2443

[221] Intent to Deprecate and Remove: Cross-origin top navigation without a user gesture - Google グループ ( (2017-04-07 02:51:26 +09:00)) https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Xi8-y4ySjA4

[222] 640057 - Restrict the ability to navigate the top level context to content that is processing a user gesture, unless it is same-origin to the parent - chromium - Monorail ( (2017-04-07 02:52:07 +09:00)) https://bugs.chromium.org/p/chromium/issues/detail?id=640057

[223] Require a user gesture for a cross-origin frame to navigate the top-level page · Issue #16 · WICG/interventions ( (2017-04-07 02:53:01 +09:00)) https://github.com/WICG/interventions/issues/16

[200] 閲覧文脈の作成時は、

[201] 既存の閲覧文脈のスクリプトが作成する場合
[202] 既存の閲覧文脈のリンクを利用者がたどっている場合
[203] その他何らかの方法で特定の文書に関連する形の場合

... なら、 a new start for session storage となった場合を除き、 >>199 それをセッションストレージ領域の処理において関係する文書としなければなりません。つまり、 sessionStorage が新しい閲覧文脈に複製されることになります (共有ではありません)。

[204] 「その他」とは何なのか、具体的には示されていませんし、おそらくは本稿の閲覧文脈の選択の場合の一部が含まれていると思われます。 (>>201 と >>202 でカバーされないのは、利用者がフォーム提出する場合くらいでしょうか。) 理論上は、それ以外でも Webブラウザーの UI からの指示などで該当するものがあるかもしれません。