リンクを別窓で開く機能の標準実装†
- ページ: BugTrack
- 投稿者: tera
- 優先順位: 低
- 状態: 却下
- カテゴリー: 本体新機能
- 投稿日: 2004-10-14 (木) 10:49:21
- バージョン: 1.4.4
メッセージ†
PukiWiki/1.4/ちょっと便利に/リンクを別窓で開く機能の標準実装を希望します。
XHTML1.1ではtarget属性が使えないので、それをJavaScriptで実現させた物で、PukiWiki外へのリンクを別に開きたい場合などに非常に重宝するものです。
PukiWikiとHTMLによるサイトをうまく融合することにも利用出来ます。（フレームなど）
過去の質問箱などを見ると、元々要望が多かった機能だったようです。
以下は1.3系の話題†
XHTML1.1、アクセシビリティ vs 「target属性により新規ウィンドーを開く」†
- なぜ そんな便利な機能がXHTML1.1で無くなったのかを考えてみられましたか? アクセシビリティという言葉を御存じですか? -- merlin
- 「誰にでも見れる環境を作ること」で解釈はあっていますでしょうか？フレームをなるだけ排除するということでこの機能がXHTML1.1から無くなったということでしょうか？別窓に開くことがアクセシビリティにどう繋がるのか、無学ゆえ、教えていただけるのでしたら助かります。 -- tera
- キーボード一つで見ることができるウェブサイトを作るという部分でtarget属性が適さないと判断された結果でしょうか？
それとも、もっと単純に「JavaScriptを使うということ」自体が問題とされているのでしょうか？
単に、別ウィンドウを開くこと自体がアクセシビリティに反しているということでしょうか？ -- tera
- そういうことでしたら、提案を取り下げるべきでしょうか？ -- tera
- XHTML1.1から消された(正確には外部モジュール化された)理由はHTMLで実装するべき機能ではないからです。(X)HTMLはHyperText Markup Languageであって、意味による区別(<ins><del>タグとか)を行う目的にのみ絞られた設計が進められています。JavaScriptによって対応する事も可能ですが、JavaScriptでは設定がoffになっている場合には動作しない、という問題も発生します。勿論、キーボードで扱えなくなる事も問題ですが、もっと単純にXHTML的に推奨されていないわけです。ですから、XHTMLでtarget属性がモジュール化されているのと同様に、PukiWikiでも拡張機能として扱うのが妥当だと思われます。 -- Ratbeta
- JavaScriptで対応する場合は、対応していない環境でも正常に動作するよう考慮する必要が有りますから…。関連:BugTrack/578 -- Ratbeta
- アクセシビリティガイドラインの10.1に載っていますが、実際には、ユーザビリティに属する概念から新規ウィンドーを開く属性は廃止方向です。理由は、ナビゲーションを失うということと、ウィンドーを新規に開くかどうかは、HTML側の問題では無くユーザー(閲覧者)に任せられるべき問題だからです。*1 無学でも、文字が読めない*2のではないのですから Accessibilityのページに載っているリンクなどに目を通されたらいかがかと思います。 -- merlin
- さしでがましいことをしてすみません。 -- arky
- あっ、すみません。さしでがましくは無いですよ。Wikiなんですから -- merlin
- 標準での実装は無理だとしても、今のように複数のファイルを改造するではなく、固有のプラグインなどの外部モジュールを置くことのみでこれらの機能が実現できればかなり便利でしょうね。モジュールを入れた人のみの拡張機能で、入れてない人には関係の無いというような‥‥。 --
- (今日はみんな疲れているんだ。そうに違いない) そうですね。ちょうど数日前から、パラグラフ編集の副産物である「キャンセル」ボタンを本体に盛り込もうとしているところですが、今回の件についても、それぞれの要素を複数の提案に分解して行くと、もう少し話が進むと思いますよ :) -- henoheno
BugTrack/578 JavaScript 使用時の<meta>出力の管理†
- これに対応させるなら上に挙げたBugTrack/578の修正を先に行わなければいけませんね…(TrackBackを使用しない環境で文法違反が発生します)。 -- Ratbeta
- BugTrack/578で書くべきかも知れませんがこちらに書きます。私の場合は Ratbetaさんの指摘のとおり、あってもなくても meta JavaScript は記述しています。（というより、default.jsを読み込んでいる関係上そうせざるをえなかったのですが・・・） -- みこ
- どのみちXHTMLというのはタグ（とその中の属性）さえあっていれば中身は問わない（問えない）ので、管理者およびユーザに混乱をおこさないためにも meta JavaScript はデフォルトであるべきだとおもっています。*3 -- みこ
- BugTrack/578は片付けました。次いきましょ～次どうぞ～ :) *4 -- henoheno
XHTML1.1、アクセシビリティ vs 「JavaScriptにより新規ウィンドーを開く」 その１†
- ということで、上の話題を前提にして、「PukiWikiに(追加で)JavaScriptを盛り込む」、あるいは「より簡単に盛り込める」様にするために必要な要素、あるいはPukiWiki本体の進化などについて意見のある方もぜひコメントして下さい。題材はコレ(この件)で。 -- henoheno
- それと、skin/trackback.js が寂しそうにしているので、話に混ぜてやって下さい。 -- henoheno
- なぜXHTML1.1で無くなった機能が再三要望として上がるか、という観点もあると思いますよ。以前の議論も一応読んではいましたが、開発者側あるいはテクニカル側からはXHTML1.1 validかつアクセシビリティの業界動向にあわせることが重要というのは、大義としては、わかります。ただ、私の例でいうと、サイトのメインユーザが自分自身であり、その他のユーザを含めてもかなり限定した範囲しか考えなくてよい状況なので、アクセシビリティの優先度は限りなく低いです。極論すれば自分さえ使いやすければよいサイトもあると思うのです。他のサイト管理者の方も、少人数やブログ的用途で使われている場合は、近い状況なのではと想像しています -- jitte
- ボランティアがベースのPukiWiki開発者の方々が、やりたい方向にイニシアチブを取って進んでいくのは当然のことで、ケチをつけるつもりは毛頭ないのですが、そういった思惑や業界動向とは別のところで、さまざまな用途でPukiWikiが気に入られて、使われるようになった、ということではないでしょうか。プラグインかiniファイルで切り替える程度でよいので、本体に組み込んでいただくことを、PHPは書けないけれどPukiWikiをこよなく愛するユーザとして強く希望します。 :) -- jitte
- jitteさんに同意。でも自分で書け！って言われるのよねー。それが敷居だって。 --
- 無くて誰も作ってくれそうにない場合は、自分で作るしかないでしょうね。 --
- 正直な所、これだけ話が長くなっていると思っていませんでした。 (^^; 私は技術的なことはよく分からない一介のユーザです。でも、PukiWikiの便利さをこよなく愛する一人です。「こんなこといいな、出来たらいいな」の気持ちでついこのようなことを書いてしまいましたが、このような話になるとは思っていませんでした。 -- tera
- アクセシビリティという言葉自体は存じておりました。しかしそれについての知識を充分深めることはしておりませんでした。ここの方々のように広く深く知識をもたずにここに書き込んだことを悔いております。一介のユーザは無謀な欲求は持たずに、標準のまま使うのが一番なのかもしれません。 :( ただ、技術論を展開することが出来ないユーザがいること、またそういうユーザもPukiWikiを愛していることをご理解いただければ幸いです。もう少し勉強して出直します。 -- tera
- この機能は、WindowsのExploreでの動作と同様にブラウザ側でもつべき機能でしょう。すなわち、Websiteから新しい窓開けといっても、ブラウザの設定如何によって 新しい窓で開かれたり、開かなかったり、既存の窓で開いたりを選択できるような形ですね。W3Cの勧告では、そういった機能がブラウザに持たされるまで target要素は無くす方向と言っています。では、ブラウザが対応するまでPukiWikiではどうするのかまたその実装をどうするか ってことになりますね。技術的には、CookieとJavascriptで実現できますが、もっと良い解はないのかな? *7 -- merlin
- PukiWikiは、多数がそうだからそれに対応するという方向よりは、みんな 幸せになろうよって方向で開発されていると思っています。なので、多数がそうだからそうするっていう考え方は無く、いろいろな場合に適用できるようにしていく方向だと思います。ただ、開発パワーは限られていますので優先順位の問題かと思います。 -- merlin
- XOOPSみたいなスキン選択の仕組みって難しいのでしたっけ。もし実現可能であれば、別窓設定をスキンに仕込んでおいて、ユーザがスキンを選ぶことで別窓動作が選択できる、というのはどうでしょう。(1)サイト設置者の意図として、iniかconfig:でデフォルト設定できる (2)ページ作者の意図として、インラインまたはブロックプラグインで動作選択できる (3)読者の意図として、(1)(2)に従うか無視するかをスキンで選べる、と。携帯端末の場合はスキンを固定するような制御もできますよね。 -- jitte
- Xoops は、ユーザーエージェントによる分岐も含めて ページ作成の最初の部分でまとめて処理していますね。PukiWikiもスキンの関連も含めて今後そのような実装にした方がよいのでは思います。従来のスキンファイルでいろいろやるより見通しがよくなりますから。 --merlin
XHTML1.1、アクセシビリティ vs 「JavaScriptにより新規ウィンドーを開く」 その２†
- CookieとJavaScirptを用いる事は(それによってXHTML Not Validにならないのであれば)いいと思います。勿論、ブラウザの対応を見て行く必要が有りますし、mobile環境を考慮する必要が有ります。開発はできるだけXHTML Validでやってほしい、というのが(XHTML Validにこだわる)私の考えです。方法としては、ユーザ定義を用いてtarget属性を表示することもできますね。ユーザ定義なら、導入も簡単ですし、Valid派はそれを削除するだけで済みますし…(でも既存のリンクとの共存が難しいですね…)。 -- Ratbeta
- JavaScript/target/Cookie関連の話は別の所にしませんか？このページだけでは要点の整理なども出来ませんし、このページに合わない話題も増えてくるはずですので…。 -- Ratbeta
- Cookie&Javascriptは XHTML Validのまま実装できると思います。窓を新規に開くのをサーバ側で指定した場合に、ユーザ側でどうするかを選択する画面が最初に出て、その値はCookieとしてユーザ側が持つ。それにしたがって Javascriptで窓を開くというような実装を考えています。問題は Cookieの期限ですけど.. どうかなぁ? -- merlin
- 一度Cookieで開くよう設定してからJavaScriptがoffにされたらどうしましょう？(^^; また、"このリンクは新規ウインドウで開きたいが、こっちのリンクは…"というのも出て来るでしょうから…。umm,..(--; -- Ratbeta
- javascript の on/offは検出できたと思います。 新規窓を開くかどうかはデフォルト値を設定しておいてそれ以外のリンクを置きたい場合は、インラインプラグインでは如何でしょう? -- merlin
- 単に意味を持たないイメージ( alt=" "のイメージ)をリンクの横に置いて、そっちを target jump するんじゃだめなの？（サンプル） XHTML1.1 も アクセシビリティ（alt属性の例外）も ユーザビリティ（ユーザに選択権あり）もこれで OK だとおもいますが・・・（元ネタはしろくろのへや） -- みこ
- 見た目はみこさんのイメージでいいと思いますが、aタグを使わずにimgタグにonclick属性(とonkeypress属性)を付加する、というのはどうでしょうか？alt属性(とtitle属性)には"(with new window)"とか差し障りのない文字列を付けておくというのもいいと思います。できればCSSでクラス設定した時みたいに通常は選択しても無視される、ってのがいいと思いますが、流石にそれは無理ですよね(^^; -- Ratbeta
- altに何か入れると読み上げのときに混乱しませんか？何も入れないほうがアクセシビリティ的にはいいかとおもいますが・・・ -- みこ
- altに何もないと、読み上げ(が必要な)環境で新しいウインドウでリンクを開きたい場合にリンクが何処にあるか分からない、という事になると思います。そういう場合には新しいウインドウでリンクを開く、なんてことはないのかもしれませんが…。 -- Ratbeta
- そのとおり！・・・というより読み上げの場合は onclick をリンク代わりに使えませんので読み上げず、動作せずのほうが自然です。
携帯からなのでツリーにぶら下げられなくてごめんなさい -- みこ
- ツリーに下げておきました。で、読み上げではonclick(onkeypress)属性は使えないんですか…。それなら、何もない方がいいですね。alt属性が空なのもXHTML的にはOKなのでいいの…かな？(^^; -- Ratbeta
- はい、altが空なのはOKの上に、読み上げで２度読みおよびURL読みさせないため altの例外とするのはJISアクセシビリティ 5.4aで必須です。 解説 および JISX8341-3-- みこ
- とりあえず、Ratbeta さんのパターン案である <a href="xxx">リンク<img src="yyy" alt=" " title=" " onclick="zzzz"></a>としてみました。 onkeypress は何を押しても反応するので外しましたが、その挙動でいいですか？＞Ratbetaさん -- みこ
- これでいいと思います。onkeypressはこの場合意味がないので外しても問題ないでしょうし。後は設定のon/offができればそれでいいと思います。 -- Ratbeta
- 元ソースが「別窓で開く」からの派生なのですでにpukiwiki.ini.php には埋め込んでいますが、ここのところの本家cvs版修正ラッシュに追いつくために、どこを修正したか忘れかけています (^^; しばしお待ちを・・・ -- みこ
- きょうも cvs は更新ラッシュがかかっているようなので、面倒なんでPukiWiki Plus! u3 開発版の１機能として公開しました。もし、本家にマージするなら、どなたかこの件のみ上手くdiffしてください (^^; （無責任モード (^^;） -- みこ
- 議論の結果ポイントが明確になっていればOKなのですよ。何と何をどうまとめてどこをどうすれば良いですか？ :) -- henoheno
- 結果としてはpukiwiki.ini.phpで使用するしないを指定できる一機能として取り込みの方向でお願いします。diffを含めてみこさん御意見をどうぞ (^^; -- Ratbeta
- えっと、わたしとしては対決（vs.）しているつもりはないし、オフィシャルではいろいろなこだわりやしがらみもあると思うので正直なところ取り込まれても取り込まれなくてもどっちでもいいです。ちなみに、この件については実装サンプルまであるので、初期に意見のあったmerlinさんのコメントもほしいところ*8です。 -- みこ
- アクセシビリティ的には問題無いと思います。読み上げソフトでも問題ないですね。ただ、onclickとonkeypressは対で使うことが推奨されているのでonkeypressも追加しては如何でしょう? -- merlin
- おそらく、対で使うという根拠は Techniques for WCAG-1.0(12.4) ですか？これは、WCAG-1.0 と違い、現実として即していないと判断しています。なぜなら、いまの実装ならどのブラウザの実装もTABなどでそこにフォーカスはいかないためと、a タグに入れると逆にTABでも反応してしまうためです。WCAG-1.0 デバイスに依存しない -- みこ
- ただ、そのコメントがくるのは織り込み済みでWCAGチェッカなどを気にする方もいらっしゃるでしょうから PukiWiki Plus! u3 開発版では ja.lng で修正できるようにしています。*9 -- みこ
- はい 12.4ですね。 onkeyperss 了解。 ちょっと寝惚けてましたね。少し実装を見てからコメントいたします -- merlin
- aDesignerを用いてもチェックしました。Opera の次バージョンが音声対応するので*10タイムリーかと思います。結果、問題無しですね。 -- merlin
- ふむふむ。私は、skin/*.js との冗長な部分(ファイル構成含む)を無くせないかどうかとか、内外のサイト識別の部分を単独の機能として取り出せないか、といったあたりから始めることにします :) みこさんのソースもチェックしてみます。 -- henoheno
- プラグインで実装でもいいのでは？ただ、利便性だけを考えると、別ウィンドウにしたいものは結構ありますね。たとえば、編集画面の[[整形ルール]とか。 -- Logue
- 整形ルールはNucleusみたいに小窓が表示されたら嬉しいですね。その辺も考えるとプラグインの方がいいのかもしれませんが…。既存のページにも新規ウインドウのリンクをつけるとなると標準機能にする方が遥かに効率がいいですし…。[[]]構文に何かのパラメータをいれれば良いのかもしれませんが…。 -- Ratbeta
- Nucleusはわかんないですけど、アクセシビリティとかでなくても、あまり新規ウィンドウと考えずに右サイドに出すほうがいいとおもいますけどね (^^;＞整形ルール（の簡易版） たとえばCONFLUENCEの編集画面 見たいな感じとか・・・ -- みこ
・概要
外部リンクに対して横にイメージを出しそれをクリックするとブラウザでの新規ウィンドーを開く機能を追加する。
・PukiWiki.Plus での実装
内部ページの取扱いに関しては 現在 コメント状態。
-設定ファイル~
pukiwiki.ini.php：
同一サーバ内は、Farmを構成している可能性があるので別設定としている。
InterWikiに関しては別設定としている。
// URIの種類によって開く動作を設定。
// "_blank"で別窓へ表示、falseを指定すると無効
$open_uri_in_new_window_opis = false; // pukiwikiの外で同一サーバー内
$open_uri_in_new_window_opisi = false; // pukiwikiの外で同一サーバー内(InterWikiLink)
$open_uri_in_new_window_opos = "_blank"; // pukiwikiの外で外部サーバー
$open_uri_in_new_window_oposi = "_blank"; // pukiwikiの外で外部サーバー(InterWikiLink)
// (注意：あえて拡張しやすいようにしていますが、"_blank"以外は指定しないでください)
#.lng
$_symbol_extanchor = '<img src="./image/plus/ext.png" alt="" title="" class="ext" onclick="return open_uri(\'$1\', \'$2\');" />';
$_symbol_innanchor = '<img src="./image/plus/inn.png" alt="" title="" class="inn" onclick="return open_uri(\'$1\', \'$2\');" />'
・設定改善案
pukiwiki.ini.phpの設定
1.(InterWikiへの考慮はとっても良い。)
2.拡張性はいらないのではないか
3.Farmへの考慮は、パターンマッチによる除外の方が良くないか？
#.lng内での設定
1.言語が異なっても関係ないのと, 通常ブラウザでの表記にかぎればいいので default.ini.php/keitai.ini.phpでの設定ではどうか？
- 分かりやすい説明と案ありがとうございます。＞merlinさん 2.の拡張性はおっしゃるとおりでオフィシャルでは true/false(or 1/0) のみのほうがすっきりするとおもいます。（XHTML1.0 FRAMESET や XHTML1.1 のOBJECTインラインフレーム対応なんていらないですしね (^^)）。3.はテクニカル的にできそうですね。lngにあったのは、画像でなかったころ（"⇒" や "»" ）の名残*11なので今となってはどっちでもいいです。 -- みこ
- ちなみに、最終構想としては a タグにも class="ext" もしくは class="inn" を入れて CSS 指定というのも考えていたのですが、正規表現がうまく出来ずに挫折 (..; -- みこ
- lng の件は了解。たぶんそういう事だと思ってました :) 下の議論とも関連して 以下のようなのはどうでしょう?
外部リンクへの表示の on/off の設定の設置。
それにより 外部リンクなのを示すアイコンが付く。
新規窓を開くフラグが on の時は、javascriptを呼ぶ。
そうでないときは alt titleに外部リンクであることを入れる。
*12
-- merlin
- （ひょっとして私がドライブしないといけない状況かしら (^^; ） -- jitte
- みこさん案（1.4.4plus-u3snap1）を自分のサイトに取り込んで見ました。表示を確認しているうちにアイコンやonclickの挿入場所をカスタマイズしたくなったので (^^; 以下のような案も考えてみました -- jitte
$_symbol_extanchor = '<img src="./image/plus/ext.png" alt="" title="" class="ext" />';
$_symbol_innanchor = '<img src="./image/plus/inn.png" alt="" title="" class="inn" />';
$_onclick_str = ' onclick="return open_uri(\'$1\', \'$2\');" ';
としておいて最後の三行を
//$insertpos = mb_strpos($anchor, '</a>', mb_detect_encoding($anchor));
$insertpos = mb_strpos($anchor, '>', mb_detect_encoding($anchor)) + 1;
$anchor = mb_substr($anchor, 0, $insertpos) . $symbol . mb_substr($anchor, $insertpos);
preg_match('#href="([^"]+)"#', $anchor, $href);
$_onclick_str = str_replace('$1', $href[1], $_onclick_str);
$_onclick_str = str_replace('$2', $frame, $_onclick_str);
//$insertpos = mb_strpos($anchor, "<img", mb_detect_encoding($anchor)) + 4;
$insertpos = mb_strpos($anchor, "<a", mb_detect_encoding($anchor)) + 2;
$anchor = mb_substr($anchor, 0, $insertpos) . $_onclick_str . mb_substr($anchor, $insertpos);
return $anchor;
としてみました。この例では、アイコンはリンクの先頭、onclickはAタグに付きます。コメントアウトしてある行をそれぞれ下の行と入れ替えればみこさんのと同じ動作（のはず）です。
- B-Wiki(1.4.3ベース)ですが → 設置例 。別窓と同時にリファラを消してます。 :) -- jitte
- エイリアスに&ref;で画像URL指定しているとアイコンの種類を間違える場合があることに気づきました。対応版 →
open_uri_in_new_window-041101.php -- jitte
- a タグにonclickをつけるときは（同ウィンドウリンクへの）代替リンクがなくなるため、アクセシビリティが下がるので気になさる方は注意が必要です。（カスタマイズとしては問題ありません (^^)＞jitteさん） -- みこ
- ちなみに、つける場所は単語の前と後ろとどっちがいいんでしょう？ (^^; -- みこ
| 選択肢 | 投票 |
| 前の方がいい | 6 |
| 後ろのほうがいい | 0 |
| どっちでもいい | 17 |
| 単語によって制御したい | 1 |
同じPukiWiki内、同じコンテンツ内、同じサイト内、サイト外のリンク判別†
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
