target

target 属性 (HTML)

仕様書

target 属性 (HTML)

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

[16] aareabasebutton (submit)、 forminput (imagesubmit)、 link

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

[5] 仕様書:

代替

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

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

属性値

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

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

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

UA による利用

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

  1. まず、 target 属性を調べます。 指定されていれば、そのフレームで開きます。
  2. 自分に target 属性が無ければ、 base 要素の target 属性を調べます。指定されていれば、そのフレームで開きます。
  3. 自分にも base 要素にも target 属性がなければ、自分と同じフレームで開きます。
  • なお、指定された名前のフレームがなければ、 新しい窓とフレームを作り、そこで開きます。 そのフレームの名前は指定された名前とします。
  • UA は、利用者が target を上書きする仕組みを用意しても構いません。

他との関係

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

安全性

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

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

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

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

閲覧文脈の選択

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

[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 が指定されているかどうかや、 リンク型 noreferrernoopener が指定されているかどうか (noopener) も、 挙動に影響を与えます。

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

利用者の指示

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

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

[184] 通常のクリック (相当) では方法を指定しなかったものとみなし、 それ以外は文脈メニューとして表示可能としたり、 CtrlShift などの修飾キーとの併用で適用したりするのが普通です。 リンク等を他の閲覧文脈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] (利用者の明示的な指示によらずに) 新しい閲覧文脈を開く場合、 次のいずれの動作とするか、利用者が設定できることがあります。

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

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

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

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

選択処理

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

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

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

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

要素からの選択

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

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

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

文書からの選択

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

  1. [162] 節点文書子孫target 属性のある base 要素がある場合、
    1. [163] 該当する最初の base 要素target 属性 >>130, >>155閲覧文脈名から閲覧文脈を選ぶ規則を適用します。 >>130, >>165
  2. [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 とは、次のようにすることです。

  1. [46] 閲覧文脈名空文字列なら、
    1. [57] 現在の閲覧文脈を選択します >>20
  2. [55] 閲覧文脈名ASCII大文字・小文字不区別_self なら、
    1. [58] 現在の閲覧文脈を選択します >>20
  3. [60] 閲覧文脈名ASCII大文字・小文字不区別_parent なら、
    1. [62] 親閲覧文脈 (なければ現在の閲覧文脈) を選択します >>20
  4. [63] 閲覧文脈名ASCII大文字・小文字不区別_top なら、
    1. [64] 最上位閲覧文脈 (なければ現在の閲覧文脈) を選択します >>20
  5. [84]
    1. [89] その閲覧文脈を選択します >>20
      • [90] 複数候補があれば、何らかの一貫した方法 (開かれたのが最直近、焦点が当たったのが最直近、最も関係が深い、など) でいずれかを選ぶべきです>>20
  6. [93] allowed to show a popupない場合で、 ポップアップしないよう利用者エージェントが設定されている場合、
    1. [94] どの閲覧文脈も選択しません >>20
    2. [95] ポップアップがブロックされたことを利用者に通知して構いません >>20
  7. [114] そうでない場合、利用者の設定に基づき、 新しい閲覧文脈を選ぶか、現在の閲覧文脈を選ぶか、閲覧文脈を選ばないかを決めます >>20
  8. [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スクリプトが作成したか利用者が作成したかの情報を保存します。
  9. [106] 現在の閲覧文脈を再利用する場合、
    1. [107] 現在の閲覧文脈を選択します >>20
  10. [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ブラウザーによっては、利用者が明示的に新しい閲覧文脈フォーカスを移動しないオプションを提供していることがあります。 リンク集ページから多数のリンク先を順に開いていきたい時に便利です。

関連

[219] 閲覧文脈の選択よりも後に、 navigate 内で allowed to navigate の検査があります。 sandbox=allow-top-navigation などの指定はそちらで反映されます。

歴史

誕生

[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> (名無しさん)

[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>

Window-Target: ヘッダー (HTTP)

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

[3]

Window-Target: _top

標準化

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

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

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

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

暗黒時代

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

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

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

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

再評価

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

XHTML2

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

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

[71] target attribute (Shane McCarron 著, 版) <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勧告に至るまでに次のような注記が追加されることで反発を抑えました。

[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 (imagesubmit)、 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 ではそれぞれの atarget を指定しましたが、その文書のリンクの target がすべて同じなら、 base でまとめて指定しておくのが便利です。

メモ

[1]

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

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

[21] 携帯電話業界から XHTML Basic 1.1target を追加することへの反対が結構強いね。。。 (名無しさん 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.namenewwindow になりますし、 その中の targetnewwindowリンクをたどると同じで開かれます。

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

(名無しさん)

[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 &#187; Blog &#187; 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 &#187; Blog Archive &#187; A&#241;adir el m&#243;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] &#321;ukasz Aranowski - strona domowa (Aster, Astercity, MP3, stacje, Kolejarz, Microsoft, XHTML, zdj&#281;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&#322;acze - Kurs HTML (S&#322;awomir Kok&#322;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 &#187; Blog Archive &#187; Conforming target Attribute (2008-07-26 22:40:57 +09:00 版) <http://lachy.id.au/log/2008/04/target-attribute> (名無しさん)

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

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

[68] MAMA: Frames - Opera Developer Community ( 版) <http://dev.opera.com/articles/view/mama-frames/#target>

[69] The SMIL 3.0 Linking Modules ( 版) <http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-extended-linking.html#adef-target>

[70] Linking – SVG Tiny 1.2 ( 版) <http://www.w3.org/TR/2008/REC-SVGTiny12-20081222/linking.html#AElementTargetAttribute>

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

[77] Web Forms 2.0 ( 版) <http://www.whatwg.org/specs/web-forms/current-work/#xhtml-module-def>

[78] XFrames ( ( 版)) <http://www.w3.org/TR/2010/NOTE-xframes-20101216/#s_links>

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

[80] WICD Core 1.0 ( ( 版)) <http://www.w3.org/TR/WICD/#child-documents>

[81] Touch Events ( ( 版)) <https://dvcs.w3.org/hg/webevents/raw-file/v1/touchevents.html#widl-Touch-target>

[82] New HTML 3.0 Proposals ( ( 版)) <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 ( ( 版)) <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 ( 版) <https://github.com/whatwg/html/commit/955fbaa>

[211] Add a 'noopener' link attribute by mikewest · Pull Request #290 · whatwg/html ( 版) <https://github.com/whatwg/html/pull/290>

[212] Add a 'noopener' <link rel> keyword and window feature · whatwg/html@2992ea9 ( 版) <https://github.com/whatwg/html/commit/2992ea921bc75e44157451a37a807a8ce0b9a884>

[120] Remove <iframe seamless> · whatwg/html@1490eba ( 版) <https://github.com/whatwg/html/commit/1490eba4dba5ab476f0981443a86c01acae01311>

[59] Editorial: clarify follow a hyperlink algorithm · whatwg/html@d22a9f1 ( 版) <https://github.com/whatwg/html/commit/d22a9f12e1cc13a77504fa6482b7ded6ba790b54>

[141] Set "one permitted sandbox navigator" for all sandbox-created popups (mikewest著, ) <https://github.com/whatwg/html/commit/ca6c42085dae650676ad90a0b852cc2e8c6feab7>

[214] Allow <a>/<area> with download="" to not require user activation (domenic著, ) <https://github.com/whatwg/html/commit/5de03c7b38e7b33a49f0dcf2bcef29e8eb9a2205>

[215] Revert part of "Allow <a>/<area> with download="" to not require user… (zcorpan著, ) <https://github.com/whatwg/html/commit/b359209579d79a713af88ecf24b9be8fb6168adf>

[216] hrefjavascript:void を返し、 target が新しい閲覧文脈の時、 Firefoxabout:blank の新しい閲覧文脈を作り、 Chrome は作らないようです。

[209] Should target=_blank and window.open('...', '_blank') be case sensitive? · Issue #2443 · whatwg/html () <https://github.com/whatwg/html/issues/2443>

[221] Intent to Deprecate and Remove: Cross-origin top navigation without a user gesture - Google グループ ( ()) <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 ( ()) <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 ( ()) <https://github.com/WICG/interventions/issues/16>

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

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

[204] 「その他」とは何なのか、具体的には示されていませんし、 おそらくは本稿の閲覧文脈の選択の場合の一部が含まれていると思われます。 (>>201>>202 でカバーされないのは、利用者フォーム提出する場合くらいでしょうか。) 理論上は、それ以外でも WebブラウザーUI からの指示などで該当するものがあるかもしれません。
[104] >>201>>202 の場合どの文書か定かではありませんが、 リンクの場合はその節点文書でしょうか。 スクリプトの場合は入口設定群オブジェクト有責文書でしょうか? (リンクスクリプトクリックしたら?)

[140] 新しく作成される閲覧文脈補助閲覧文脈となりますが、 既存の閲覧文脈を選択しても、それが補助閲覧文脈に変化することはありません。 つまり window.open で得られたwindow.close しても、閉じられない可能性があります。

[102] 以前は rel=noreferrer の時 a new start for session storage と定義されていましたが、現在はその定義がなくなっています >>212。意図的なのかは不明です。


[105] Make noopener stop the copying of session storage (mystor著, ) <https://github.com/whatwg/html/commit/a68a1f712b641981d7367d78758596b21a04521c>

[225] Mention `sessionStorage` copying in logic for creating auxiliary browsing contexts · Issue #2681 · whatwg/html () <https://github.com/whatwg/html/issues/2681>

[226] Mention sessionStorage copying in logic for creating a new browsing context by mystor · Pull Request #2832 · whatwg/html () <https://github.com/whatwg/html/pull/2832>

[227] Editorial: centralize target attribute processing (annevk著, ) <https://github.com/whatwg/html/commit/0b31844d6dcc7ef49b3815f4f709d4c0284378f1>

[228] Deduplicate finding the correct target attribute · Issue #2619 · whatwg/html () <https://github.com/whatwg/html/issues/2619>

[229] Editorial: centralize target attribute processing by annevk · Pull Request #3007 · whatwg/html () <https://github.com/whatwg/html/pull/3007>

[230] Regression fix: continue to defer to CSSOM for window.open()'s features (annevk著, ) <https://github.com/whatwg/html/commit/e1533f1dbb7405ffc0814bbc4eaf9e8b0442c035>

[232] Regression fix: tokenize features earlier in window.open() (annevk著, ) <https://github.com/whatwg/html/commit/0ce114d22c285dd52c64c5f00b2185e4ed8edf84>

[233] Window open steps use tokenizedFeatures before setting it · Issue #3107 · whatwg/html () <https://github.com/whatwg/html/issues/3107>

[235] Regression fix: tokenize features earlier in window.open() by annevk · Pull Request #3108 · whatwg/html () <https://github.com/whatwg/html/pull/3108>

[236] Normalize the target attribute to a string (annevk著, ) <https://github.com/whatwg/html/commit/055e6b757a94bc1b77d4e07383bc8f0699005e32>

[237] Browsing context name is always a string by annevk · Pull Request #3450 · whatwg/html () <https://github.com/whatwg/html/pull/3450>

[238] Undo changes to `target` attribute/prop on `a` element (AmeliaBR著, ) <https://github.com/w3c/svgwg/commit/5d5cc13f57bd5275b1b97c0ddba762baf6547626>

[239] Update SVGAElement to match attributes on HTMLAnchorElement by dstorey · Pull Request #409 · w3c/svgwg () <https://github.com/w3c/svgwg/pull/409>