最終更新: 2014-05-12T15:38+0900
最終更新: 2009-08-25T02:45+0900
20090628p01で書いた Firefoxのバグっぽいものが XRegExpに影響するみたい。
// Firefox 3.0.11 + XRegExp 1.0.1 での実行結果 alert( XRegExp("[]").test("a") ); //=> true alert( RegExp("[]").test("a") ); //=> false
[] と [^] の意味するところってなんでしょうね。[] は空の文字集合だから「どれでもない一文字」とマッチする(=空文字列にもマッチせず必ず失敗する)。[^] は空の文字集合の補集合だから「任意の一文字」だろうか。
参考ページを見つけた > 文字クラス(http://suika.fam.cx)
結局、こういうことだ。
(IEの件を除いて)どのパターンも規格上の正解やデファクトスタンダードがなくて混乱してんじゃないかなあ。こういうのには近づかないに限る。
正しくコメントが読めてるといいんだけど……。
IEが空の文字セット [] を処理しないのは(ECMAScriptの仕様をすっとばして) Perlその他、JavaScript以外の多くの実装にならっているもので、[ に続く最初の文字を文字通りの文字 ] だとしているから。だから []] は [\]] と同じ意味になる。
Firefoxで (?!) の代わりに (?!|)、(?=) の代わりに (?=|) を使うのは良くなくて、つまりこれらの結果は同じになるべきだけど、どちらになるかは将来の Firefox次第だから。バックトラックの発生にもつながって効率的にも不利。だから (?!) の代わりは \b\B。(?=) の代わりは (?:) が良い。
\b\B というのは覚えておこう。
冒頭の指摘ははずしてる。考える前に、気付いたことをただ書いたせいだ。
XRegExpの目的の一つは、ブラウザごとにまちまちな挙動を見せる JavaScriptの正規表現に関するメソッドを仕様に準拠させることだったと思う(String.split()とか RegExp.lastIndexとか)。
だから空の文字セット( [] と [^] )を提供する第一の目的は 5ブラウザ(IE, Fx, Opera, Safari, Google Chrome)のうち不当にこれを受け付けない IEにおいて、仕様で許された正規表現パターンを利用可能にすること、かもしれない。
その過程で、Firefoxがネイティブに処理する空の文字セットと、XRegExpの提供する空の文字セットの挙動が食い違ってしまっている(1行目 1、2列)、というのが冒頭の指摘。でもこれは重要ではないし、同様の指摘を Operaについても行うことができる(3行目 1、2列と 3、4列)。
そうではなくて、ライブラリ利用者として「仕様に準拠した」「ブラウザ間で統一された」機能を望む視点から、XRegExpの提供する空の文字セットが Firefoxにおいてのみ違う意味になること(2列目)をこそ指摘すべきだった。(実際そうしたんだけど、日記の内容だけが古かったのでこうして追記している)
1列目 | 2列目 | 3列目 | 4列目 | |||
RegExp("[]") | XRegExp("[]") | RegExp("[^]") | XRegExp("[^]") | |||
---|---|---|---|---|---|---|
1行目 | Firefox(3.0.11, 3.5RC3) | 必ず失敗 | 任意の一文字 | 任意の一文字 | ||
2行目 | IE(8.0) | 例外 | 必ず失敗 | 例外 | 任意の一文字 | |
3行目 | Opera(9.64) | 任意の一文字 | 必ず失敗 | 必ず失敗 | 任意の一文字 | |
4行目 | Safari(4.0) | 必ず失敗 | 必ず失敗 | 任意の一文字 | 任意の一文字 | |
5行目 | Chrome(2.0.172.33) | 必ず失敗 | 必ず失敗 | 任意の一文字 | 任意の一文字 |
全てのパターンに (?!) が含まれているから、本当は全て falseになってほしい。
/(?!)/.test("abc") //=> true! /(?!)(?!)/.test("abc") //=> false /^(?!)/.test("abc") //=> false /(?!)$/.test("abc") //=> true! /a(?!)/.test("abc") //=> false /(?!)a/.test("abc") //=> true! /\b(?!)/.test("abc") //=> false /(?!)\b/.test("abc") //=> true! /(?:)(?!)/.test("abc") //=> true! /(?!)(?:)/.test("abc") //=> true!
(?!) が実質的にパターンの先頭にあるときだけ、存在しないかのように振る舞っているような。すごく限定された状況でのみ発動するんだったんだ。
ここまで書いてなかったことに気付いたけど、これが XRegExp("[]") に影響するのはこのパターンが内部的に (?!) に書き換えられるから。XRegExp (1.1.0, 2009-07-04)では \b\B に置き換えられるようになっていて、Firefoxのおかしな挙動に影響されて他のブラウザと違う結果になることはなくなっている。
もう書かれてた! > http://blog.stevenlevithan.com/archives/xregexp-1-0/comment-page-1#comment-37653
自身の機能を XRegExp.addToken()で提供しており、ユーザーも同じ方法で拡張できる。トークンの有効範囲が文字セット [……] の内か外か、その両方かは addToken()の第3引数のビットフラグ( XRegExp.INSIDE_CLASS, XRegExp.OUTSIDE_CLASS )で指定できるし、エスケープシークェンスは予め処理されているので \(?!) を \\b\B に置き換えてしまう心配もない。簡単でしょう。
でも鬼車の \g を追加しようとして、名前付きキャプチャ内部のパターンを手に入れられず、中断。
その \gの利用例が次。
XRegExp("(?<any_backref>\\3|\\4){0} \ (?<smiles>(?::-[D)])+){0} \ ([ab]) ([12]) \\g<any_backref>+\ \\g<smiles> ", "x").test("a22aaa:-):-D"); // true
解説すると、まず名前付きキャプチャを使って再利用を前提としたパターンを定義する(any_backrefと smiles)。ポイントは量指定子{0}の存在で、現状ではこれが必ず必要になる。これによりこの名前付きキャプチャはマッチに参加せず、一文字も消費せずに成功する。その存在意義は \g<smiles> のように、後で名前を使ってパターンを再利用できること。
上の例で、実際に文字を消費するパターンは後半分、次の部分だけ。
/([ab])([12])\g<any_backref>+\g<smiles>/
Rubyで同じ意図を持って書くとこういうふうになる。
irb> any_backref = /\1|\2/ => /\1|\2/ irb> smiles = /(?::-[D)])+/ => /(?::-[D)])+/ irb> re = /([ab])([12])#{any_backref}+#{smiles}/ => /([ab])([12])(?-mix:\1|\2)+(?-mix:(?::-[D)])+)/ irb> re.match( "a22aaa:-):-D" ).to_a => ["a22aaa:-):-D", "a", "2"]
さて、パターンの再利用が \g の利用法だけど、個人的にそれが最大の効果を発揮するのは、パターン定義の中でパターンを呼び出したとき、再帰的なパターンを定義できることだと思っている。20080111p01で既に書いているが、
/%[Qq]?(?<brace>\{[^\{}]*(?:\g<brace>[^\{}]*)*})/
名前付きキャプチャ (?<brace>……) の中に \g<brace> がある。こういう GNUの命名のような再帰的定義ができてこそ \g を利用する価値があると個人的には思う。
addToken()で \g を定義する方法として考えていたのは「パターン文字列を、上限を決めて再帰的に展開する」というもの。このように。
実際の手順は addTokenの第二引数が文字列を返す代わりに toString()を定義したオブジェクトを返し、xregexp.jsの下の引用部分、output.join("") の時点で、名前付きキャプチャ内のパターンを参照してパターン文字列を返そうというもの。
regex = RegExp(output.join(""), real.replace.call(flags, /[^gimy]+/g, "")); regex._xregexp = { source: pattern,
コードの枠組みはこんなの。もちろんこのままでは動かない。
function PatternOfNamedCapture(name) { this.name = name; } PatternOfNamedCapture.prototype.toString = function(){ // ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ if(MAX_RECURSION < count++) { return "(?:)"; } else { return output.slice( defs[this.name].start, defs[this.name].end ).join(""); } // ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑ }; XRegExp.addToken( /\\g<([$\w]+)>/, function(match) { return new PatternOfNamedCapture(match[1]); } );
最終更新: 2009-10-28T01:40+0900
再帰っていっていいのかな?鬼車は明らかに再帰だったけど。
.NETの正規表現を利用した経験はありません(念のため)。想像です。
.NETの再帰に関係した部分のドキュメントがあまりにわかりにくかったので整理。(実はわかりにくさの半分は日本語のせいだった。英語の方のドキュメントを読みましょう)
キャプチャ内容を読み出す従来の記法が \1, \2。名前付きキャプチャの場合は \k<name1>, \k'name1'など(実装ごとに異なる)。キャプチャグループに量指定子がくっついている場合、これらで読み出せるのは最後のキャプチャ内容だけ。だけどキャプチャの記憶領域はキャプチャグループごとに一つではなくスタックになっていて、その一番上の内容を読み出していると考える(.NETだか Javaだかではプログラムからこのスタックにアクセスできたはず)。
まず、これは name2という名前付きキャプチャグループ。と同時に、name1のキャプチャスタックを POPする。name2を省略して name1を POPするだけも可能。MSDNの日本語ドキュメントを名前の部分だけこちらに合うように書きかえたのが次。
既に定義されていたグループ name1 の定義を削除し、既に定義されていた name1 グループと現在のグループの間隔をグループ name2 に格納します。
実際に name2のキャプチャ内容がどういうものになるのか(直前の name1のキャプチャ内容、name2の……にマッチした部分、その間、がそれぞれ含まれるのかどうか)は読み取れないけど、直前の name1キャプチャをなかったことにし、name1のキャプチャ部分から ……までを name2に保存するという。(覚え方: name2は直前の name1から……まで)
当然のこと、name1のキャプチャスタックが空のとき name2のキャプチャは ……のマッチ正否に関わらず失敗する。
name1のキャプチャに成功しているかどうかで適用するパターンを変化させる条件分岐 (?(name1)truepattern|falsepattern) と、必ず失敗するパターン (?!) の組み合わせにより、name1のキャプチャスタックが空でないと必ず失敗する。逆に name1のキャプチャスタックが空のときは(省略された空の falsepatternが何にでもマッチして)必ず成功する(はず)。
(?(name1)(?!)) が成功する(=name1のキャプチャスタックが空である)とは、name1に含まれるパターンが開きかっこ、name2のパターンが閉じかっこにマッチし、その間のパターンが開き閉じどちらのかっこにもマッチしないとき、開きかっこと閉じかっこがバランスしている、ということ(MSDNの例がこれ)。
なんてこったい。
// Firefox 3.0.11と 3.5RC3のロケーションバーでの実行結果。 javascript:alert(/(?!)/.test("")) //=> true (falseであってほしい) javascript:alert(/(?=)/.test("")) //=> false (trueであってほしい) javascript:alert(/(?:)/.test("")) //=>
// Windows Vistaでの JScript(WSH)実行結果。 WScript.Echo(""+ /(?!)/.test("")) //=> false (期待通り) WScript.Echo(""+ /(?=)/.test("")) //=> true (期待通り) WScript.Echo(""+ /(?:)/.test("")) //=> true (期待通り)
必ず失敗するパターンを試してみたら Firefoxで真逆の結果が出てしまった。Firefoxが間違っててくれないと困るよ。(ブラウザにより逆の結果がでていることがもう困るけど)
(参考)間違いなく失敗する* > 詳説正規表現第3版 - Google ブック検索, 詳説正規表現第3版 - Google ブック検索
Internet Explorer 8.0.6001.18783 64-bit Edition、Safari 4.0.530.17、Opera 9.64、Google Chrome 2.0.172.33 でもみんな Firefoxとは逆の結果になる。Firefoxだけが 3.0から 3.5RC3になっても違っているのは悪夢だ。
Firefoxに理がないことは次の例からも判断できないか。空のパターンを空と空の選択パターンにするだけで結果がひっくり返ってる。
// Firefox 3.0.11のロケーションバーでの実行結果。 javascript:alert(/(?!)/.test("")) //=> true (下と同じであるべき) javascript:alert(/(?!|)/.test("")) //=> false (期待通り) javascript:alert(/(?=)/.test("")) //=> false (下と同じであるべき) javascript:alert(/(?=|)/.test("")) //=> true (期待通り) javascript:alert(/(?:)/.test("")) //=> true (期待通り) javascript:alert(/(?:|)/.test("")) //=> true (期待通り)
* 念のため断っておくと、書籍の文脈では、この断定は Perlと .NETの正規表現に(ちゃんと)限られている。
例えばこのページ http://vvvvvv.sakura.ne.jp/ds14050/diary/20080112-7.html 。Endキーで末尾に移動して PageUpで戻っていくと空白の PREが目に入ると思う。その少し上にはページの内容を覆い隠す黒い領域があるはず。(そうでなければ修正されたのだろう。Firefox2で最初に確認し、Firefox3.0RC1でも直っていなかったが)
大量の PREが存在したり、一つだけでも巨大な PREが存在する場合に起こる様子。innerHTMLで PREの内容を置き換えているのも原因になっているかもしれない。
画面の末端にスクロールした状態でページをリロード(F5 or Ctrl+R)すると下方の PREが正常に表示される反面、上端付近の PREに同じ問題が生じる。遠方の PREの書き換えに問題があるのでは?
真っ白の PREの中で、右クリックしたりテキストを選択したりといったアクションを起こせば正常に表示されることが多い。
あと、PREの中から開始した選択は PREの外に出られなかったり。(これは TEXTAREAと違い PREでは Ctrl+Aで全文選択ができないために用意された代替手段だという気もする)
Firefox2が標準ユーザーでのアップデートに失敗するようになっていて 2.0.0.14のインストールが面倒くさかった*ので 2をアンインストールして 3 beta5をインストール。Firefox2のときと違って
extensions.checkCompatibility false
を知ってるから、バージョンの数字だけを見て、ほとんどの拡張を使用不可能にされるアホらしい事態慎重すぎる対応は避けられる。(といっても半数近くの拡張がすでに 3に対応していた。Google Toolbarは Fx3をクラッシュさせた)
というのが気付いたところ。
フォームの背景色の問題は起こるところと起こらないところがある。自サイトの tDiaryと本棚では色が変わらないが、はてなや、google.co.jpのホームページの検索窓は色が変わる。google.co.jpでも、結果ページの検索ボックスは背景色が変わらない。(いずれも Firebugで Inspectして、userContent.cssで行った background-colorの指定が有効なのは確認している)
Firefox2と 3(の Gecko)で何が変わったのだろう。背景色が全く変えられなくなったわけじゃないみたいだけど。
borderや border-styleや border-widthをインラインスタイル属性として <input>タグに書き込むと背景色が変わった。(ボーダーの属性値は noneでも solidでも 0pxでも良い)
わけがわからないから、Firefoxの CSSへの準拠度が上がったせいでサイトデザインの不具合が明らかになった、というわけではないな。
* 管理者として起動すればアップデートは簡単に済む。標準ユーザーのプロファイルに残された更新情報の削除がめんどうくさい。
Firefoxも IE7も可能な場所はすべてメイリオを使うことにしているが、Serif(明朝)と等幅フォントをメイリオにするわけにはいかない。いままで等幅フォントはデフォルトの MS ゴシックのままにしていたのだが、よく耐えられたものだと思う。日本語部分は MS ゴシックなりなんなりに頼らなければならない*にしても英字部分の選択肢は無数にあるじゃないか、ということに気付いてしまった。
http://www.codestyle.org/css/font-family/sampler-Monospace.shtml
これはもう Bitstream Vera Sans Monoしかない。Nimbus Mono Lも悪くはないけど、Bitstream Vera Sans Monoは線が太めで、MSゴシックみたいに掠れた感じが全くしないのがいい。他のフォントはヒゲが多かったり、四角かったりで好みではない。
Firefoxで Bitstream Vera Sans Monoの文字をどれだけ拡大しても太字と普通の字が区別できないのはフォントの問題じゃない気がしてきた。ノーマル、太字、斜体、太字&斜体の四種がインストールされてるのは確認してるし、フォントビューアでは区別できるのに、Firefoxでは区別できない。
……。Firefoxを再起動したら区別できるようになった。フォントをインストールした後は一回再起動した方がいいみたい。
フォントの選択肢が少なすぎる。Bitstream Vera Sans Monoも設定できなかった。それに日本語のページでのデフォルトのフォントは指定できるのに英語のページでのフォントが指定できないのはなんで?⁑
等幅でも明朝でもゴシックでもない。そもそも Googleの検索ボックスの中の文字があまりに見苦しかったから新しい等幅フォントを探してきたというのに。どのフォントの設定をいじっても変化しない。ユーザースタイルシートでなんとかなるか?
……。userContent.cssに
input { font-family: monospace }
を追加したら Bitstream Vera Sans Monoになった。ヽ(^0^)ノわーい
なんでもかんでも monospaceにしたら場所(幅)をとって仕方ないのでやっぱりちょっと変更。
input { font-family: monospace } input[type] { font-family: sans-serif } input[type=text], input[type=file] { font-family: monospace }
Consolasは Vistaに付いてくる、Bitstream Vera Sans Monoの左右を詰めたようなフォント。空間効率って大事。(自分は気にしないけど、ゼロの形もシータの大文字みたいなのから一般的な斜線の入ったものになっている)
body { padding : 0 2.5% ; font-family : 'Verdana', 'Osaka', 'MS UI Gothic', sans-serif ; font-size : 100% ; }
Verdanaは嫌いじゃないよ、プロポーショナルだから Sakura Editorでは使えないけど。MS UI ゴシックも悪くない。メイリオ以前はこれを常用していた。sans-serif(ゴシック)も serif(明朝)より断然好きだ。
でもフォントは自分で(見る人間が)選ぶ。ファウスト並みにこだわってるのならその意志は尊重する(けど読みにくかったら読まない)けれども。
スペースキーやページダウンキーで Webページを読み進めていくと、次のページ、といったリンクが最後にあるのはよくあること。Tabキーでそこにフォーカスを持って行こうとすると、サイドバーを上から下まで辿り本文を上から下まで 辿りする羽目になるのもよくあること。うんざりです。
Firefoxでスクリプトからフォーカスを順(逆)に辿るには
document.commandDispatcher.advanceFocus(); document.commandDispatcher.rewindFocus();
を使えばいいらしいが、onfocusイベントでこれらを使ったのではページは既にスクロールしてしまったあと。DHTMLの onfocusinのタイミングでフォーカスをスキップしたい。userCrome.jsでちょちょいと何とかならんものか。
マウスが手許になくなったとき恒例のぼやきでした。
驚いた。Firefoxでブラウズ中に普通のサイトでどせいさんフォントが表示されたから。
そのサイトは font-familyとして fantasyを指定していた。自分はどせいさんフォントをインストールしていた。でも Firefoxが fantasyと cursiveなフォントとして どせいさん を選んだ理由がわからぬ。そんな設定項目があっただろうか。(フォントにそういうメタデータが含まれているのだろうか。プロポーショナルか等幅かをプログラムが見分けられる(はず)のだから不思議はないか)
何日かマウスを使っていないのでブラウザ(Firefox)のキーボードインターフェイスが気になる。
Firefoxの設定で「オプション > 詳細 > 一般 > アクセシビリティ > キー入力時に検索を開始する」を有効にすると、Ctrl+Fやスラッシュを押してからでなくとも、目に付いた単語をタイプするだけでインクリメンタルなページ内検索が行える。このとき検索結果の文字列にフォーカスが移動するのが非常に都合が良くて、リンク文字列がアルファベットであればタブキーを使って順番にフォーカスを移動するよりスムーズにリンクにフォーカスをあててページを移動できる。
Firefoxの拡張機能のひとつである Mouseless Browsingもまたキーボードを使ったナビゲーションを円滑にする。そのアプローチは全てのリンクにシリアルナンバーを割り振るというもの。リンクの右下隅に表示される数字をタイプして Enterを押すとリンク先に移動し、Enterの代わりにプラスキーを押すと新しいタブで開くといった具合。
ところで、「オプション > 詳細 > 一般 > アクセシビリティ > キー入力時に検索を開始する」と Mouseless Browsingは競合する。数字をタイプすると両方が同時に動き出すのだ。
最初は、Mouseless Browsingにはシリアルナンバーを割り振ることだけを任せて、Find As You Typeで数字をタイプしてリンクにフォーカスを合わせ、リンクをクリックするのは Enter(新しいタブで開くなら Ctrl+Enter。どちらも Windows版 Firefoxの標準割り当て)、でうまくいくように思えた。実際、悪くない動作をする。
唯一、気に入らないのはスクロール位置がガタガタ移動するのが避けられないこと。例えば 125番のリンクをクリックしようと [1][2][5][Enter]とタイプすると、Enterを押すまでの間に、1番のリンク、12番のリンク、125番のリンクの順にフォーカスが移動しスクロール位置も合わせて移動するので見てて疲れる。前にも書いたが、フォーカスの移動に伴ってスクロール位置が移動するのはストレス。目の見える自分にとってフォーカスをあてたい対象は今、見えている範囲にあるのだから。
原因は Find As You Typeがインクリメンタルな検索を行うことにあって、Mouseless Browsingならそういうことは起こらないのだが。
Mouseless Browsingは良くできたやつで、こいつの設定に「Use numpad exclusively for Mouseless Browsing」というのがある。これをチェックしておけば、テンキー以外のキーをタイプしたときは Find As You Type、テンキーを使ったときは Mouseless Browsing、とどちらも有効にしたまま棲み分けができる。テンキーを使う時にはスクロールの問題も起こらない。
ところがこれにも問題が。このチェックが有効だとフォームに数字を入力するときにテンキーが使えない。exclusiveだとはいってもフォーカスが文字入力可能な場所にあるときはキーボード入力を Firefoxの標準のハンドラに譲って欲しい。そんなわがままを可能にする修正が下の 4点。元がいいから変更も楽だった。
<Fx profile>*\extensions\{c0bcf963-624b-47fe-aa78-8cc02434cf32}\defaults\preferences\mlb_prefs.js の 13行目に一行挿入。(初期設定を追加)
12 pref("mouselessbrowsing.exclusiveNumpad", false); 13 pref("mouselessbrowsing.exclusiveNumpadUnlessWritable", false); 14 pref("mouselessbrowsing.executeAutomatic", false);
<Fx profile>\extensions\{c0bcf963-624b-47fe-aa78-8cc02434cf32}\chrome\mouselessbrowsing.jar\content\mouselessbrowsing\prefs.xul に 70-72行目を挿入。(設定画面に項目を追加)
67 <row> 68 <checkbox id="exclusiveNumpad" label="Use numpad exclusively for Mouseless Browsing" prefid="mouselessbrowsing.exclusiveNumpad" defaultValue="0"/> 69 </row> 70 <row> 71 <checkbox id="exclusiveNumpadUnlessWritable" style="margin-left:30px" label="Unless a writable element has focus" prefid="mouselessbrowsing.exclusiveNumpadUnlessWritable" defaultValue="0"/> 72 </row> 73 <row> 74 <checkbox id="executeAutomatic" label="Execute automatically without pressing Enter" prefid="mouselessbrowsing.executeAutomatic" defaultValue="false"/> 75 </row>
<Fx profile>\extensions\{c0bcf963-624b-47fe-aa78-8cc02434cf32}\chrome\mouselessbrowsing.jar\content\mouselessbrowsing\mouselessbrowsingInit.js に 164行目を追加。(設定の読み込み)
163 MLB_exclusiveUseOfNumpad = prefs.getBoolPref("mouselessbrowsing.exclusiveNumpad"); 164 MLB_exclusiveUseOfNumpadUnlessWritable = prefs.getBoolPref("mouselessbrowsing.exclusiveNumpadUnlessWritable"); 165 MLB_executeAutomaticEnabled = prefs.getBoolPref("mouselessbrowsing.executeAutomatic");
<Fx profile>\extensions\{c0bcf963-624b-47fe-aa78-8cc02434cf32}\chrome\mouselessbrowsing.jar\content\mouselessbrowsing\mouselessbrowsingEvent.js の 361行目を変更。(条件判定ロジックの変更)
361 return MLB_exclusiveUseOfNumpad && isNumpad;
↓
361 return MLB_exclusiveUseOfNumpad && isNumpad && 362 !(MLB_exclusiveUseOfNumpadUnlessWritable && Utils.isWritableElement(event.originalTarget));
う〜ん。満足。
* Firefoxのプロファイルフォルダ。%APPDATA%/Mozilla/Firefox/Profiles/xxxxxxxx.default
あるページを読んでいる。読み進んでいく。「次のページへ」というリンクがある。タブキーを押す。ページがギュンッと巻き戻って一番最初のリンク*にフォーカスが移動する。さらにタブを押す、押し続ける。サイドバーのリンクを順にたどってフォーカスがページ下方へ移動していく。やがてまたもページが巻き戻る。今度は本文中のリンクを順に下方にたどっていく。やっと「次のページへ」にたどり着く。
今見ているリンクにフォーカスを合わそうとしているのに、フォーカスはとんでもないところに飛んでいく。タブキーを押すことによってスクロール位置が変わるのが非常にストレス。タブキーでフォーカスが移動する先は現在表示されてる(フレームに収まってる)部分だけで良い。
HTML作成者が tabindexをリンクやフォームに割り振っていた場合 tabindexの小さい順にフォーカスが移動するのだった。tabindexが一つでも指定されていればそちらを優先すべきだな。(といっても、tabindexが指定されていて欲しいのは自分がよく使うページだけだけど。不特定の人に見せるのが目的のページで押し付けは良くない。)
tabindexはフォーカスの順番を決めるだけのものではないのだなぁ。
ありものは↓。
Mouseless Browsingを使っているが Find As You Typeと競合するのでテンキーを Mouseless Browsing専用にしている。そうすると、テキストフィールドに数字を入力するのが不便(テンキーが使えないので)。
自前でやる場合、次にフォーカスを得るエレメントがどれなのかを自前で探すのは避けたいところ。それをするんだったら greasemonkeyで onblurを捕まえて、次にフォーカスを得るエレメントを順に辿っていって、最初に見つかったブラウザのフレーム内に収まってる(=見えている)エレメントを focus()すればいいはず。
* 普通はソーステキスト中に一番最初に登場したもの。tabindexが指定されていれば最小の tabindexを与えられたもの。
♭ Steven LevithanActually, IE treats [] and [^] like Perl and almost every ..
♭ Steven LevithanThanks for finding and documenting the Firefox (?!) bugs. ..
♭ Steven LevithanRegarding your latest update (dated 2009-07-05 04:40), Oni..
♭ Steven LevithanI just updated the example page I linked to so that the so..