回避法発見──Opera で、TEXTAREAの表示テキストとvalueプロパティの連動がなくなる問題

先の2つのポストでのべた問題の現象は、問題を（開発中のアプリ以外の場所で）再現しようとしてもうまくいかない…。が、ともかくこの現象を回避するための方法がわかった。

TEXTAREA要素を、非表示の要素に追加してはいけない。表示してから追加しないと、valueプロパティと表示されているTEXTAREA内のテキストとの連動が切れる現象が起きやすくなる。

結局のところ、2つの値の連動がなくなってしまう決定的な条件・理由は不明のままだが、ともかくOperaでは上記の対策が有効な模様。

実際にこの問題がおきたのは、jQuery UIライブラリの、DialogとTabsのUI内であった。どちらも、コンテンツを隠す──Dialogの場合はダイアログそのものを表示・非表示できるし、Tabsの場合は選択されているタブのコンテンツ以外は非表示になる──機能があり、この隠している状態で、コンテンツにTEXTAREA要素を追加すると上述の問題が100％発生していた。

Opera 9 および 10 におけるTEXTAREAのValueプロパティに関するバグ

先のポストにも書いたバグに3日間悩まされ続けている。
バグの症状をまとめてみると……

Opera 9 および 10 で、

1. あるDOM要素──ここでは仮にWとする──内（たとえばDIV要素内）に、jQueryで$('<textarea></textarea>') などとして作成したTEXTAREA要素を子要素もしくは孫要素などとして関連付ける（appendメソッドなどを使用）。
2. W要素を空にする──子要素をすべて削除するなり、innerHTMLプロパティに空文字列を代入するなりする。jQuery要素としてのWであれば、emptyメソッドでこれができる。
3. もう一度、1と同じ手順でTEXTAREAを作成して要素Wに関連付ける。

これでもう、TEXTAREAのvalueプロパティと、実際に表示されているTEXTAREA内のテキストとが、連動しなくなる。

こうなると、もう、どんなテキストを入力しても、あるいは既存のテキストをどう編集しようとも、それらがvalueプロパティに反映されないため、JavaScript側からユーザが入力したテキストを取得しようとしても、あくまでもプロパティとしてのvalueの値しか取得できなくなる。

プロパティとしてのvalue──表示されているテキストとの連携を失ったvalueの値──は、もちろんvalueプロパティに対して別の文字列を代入することで変更可能だし、当然jQueryのメソッドでも変更できる。しかしこうしてvalueプロパティの値を変更しても、もう表示には反映されない。

これはかなり最悪な状態である。どうしても回避できない！ こんな簡単なことなのに、検索でしらべてみても他に同様の症状の報告がない。これはぼくのPCにおいてだけ発生するもの？！

Opera 9 - 10 で、フォーム要素のvalueと表示に食い違い

Opera 9 および 10 で、フォーム要素──とくにTEXTAREAとINPUT（type=text）のvalueプロパティと、実際にそれらの要素内に表示されているテキストとが食い違う、したがってフォーム内に記述され編集され表示されているデータをJavaScriptからうまく取得できない、という非常に厄介な問題に遭遇している。

TEXTAREAについては、CSSと関連して値の取得がうまくいかない、とかほかにもOpera旧バージョンのバグが報告されているようだけど、上述のような問題は見あたらない様子。

問題は頻繁に起きるのだが、いまいち正確な条件がわからない。

Opera 10.00 をさっそくインストール

WebブラウザOpera 10.00 の正式版がリリースされたというので、さっそくインストールしてみた。デザインがなんとなくChromeなのだが、単にデザインの流行の問題なのかもしれない。

例のごとくFirefoxとその拡張機能によるブラウジングに慣れてしまったぼくにとっては、テキストエリア内のテキストを外部エディタで編集するようなメニューがないことが残念なのだけど、またしばらく使ってみようか。

Opera 10のこととは関係ないが、Operaのインターフェースは、タブが、メニューバーとアドレスバーの間にあるところがけっこうお気に入り。デフォルトではウィンドウの左側に表示される「ブックマーク」その他のパネルの表示位置──パネルの上端は、タブバーの下辺に接していて、まるでサイドパネルは個々のタブに従属して居るみたいだ！──には疑問を感じるけれど、タブバーの位置はまったく理にかなっている。

Firefoxの開発コミュニティはといえば、Operaのみがこのデザインを採用していたころには見向きもしなかったのに、Chromeが同じデザインで登場したとたんに、タブバーの位置を移動すべきかどうか、という議論が突然に（？）はじまったような感じ。ちょっと滑稽に感じたが（Operaなら捨て置いても良いが、Chrome＝Googleだと焦りを感じるという）、これはあるいはネット・ニュースのつくりだしたフィクションだろうか。

Powered by ScribeFire.

Opera9.46とjQuery1.3.2、TEXTAREA要素の値を利用する際の注意

Windows版Opera 9.46、jQuery 1.3.2の環境でのことであるが、改行を含むTEXTAREAの値を、DOM要素のvalueプロパティから得るか、jQuery要素のvalメソッドから得るかで、値の内容が異なることがわかった。

よくわからないが、改行文字に関連するらしい。
改行が存在する文字列の場合、jQueryのvalメソッドで得られる文字列の長さは、DOMのvalueプロパティで得られる文字列の長さより、改行の数分短い。

jQueryのソースコードをみると、valメソッド内では、DOM要素のvalueプロパティで得た文字列のなかの「\r」（復帰文字？）を取り除く処理が行われているから、これが原因かと思う。おそらくOSごと、ブラウザごとに得られる値が異なるのでは困る、ということでこうした標準化処理を行っているのだろう。これ自体は親切な機能である。

ただ今回このTEXTAREA要素の値を利用するのが、ほかならぬこの要素内の文字列の選択範囲の情報（選択範囲の開始や終了の位置、キャレットの位置など）を取得する、というものであったため問題が起きた。

［追記　2009/8/30］

Opera 9.64 ではTEXTAREA要素内の文字列の選択範囲操作のとき、「\r」（復帰文字）の存在を考慮して、選択開始位置、終了位置などの文字数を調整する必要がある──でないと他のブラウザとの間で挙動に差が生じる──が、IEではむしろ「\r」の存在は考慮しないほうがよいらしい。Opera同様に「\r」を1文字と数えて調整を行うと、逆に他のブラウザとの間で挙動がズレてしまう（すくなくともIE8ではそうであった）。

InternetExplorerのDOM属性認識

ここのところJavaScriptのライブラリjQueryのプラグインをいくつも作っていて気がついたのだが、InternetExplorer（IE）のJavaScript（JScript？）におけるDOM要素や、そのinnerHTMLプロパティからアクセスできるHTMLソースコードには独特なものがある。

Firefox、SafariではinnerHTMLプロパティからアクセスできるソースコードはタグ名がすべて小文字アルファベットで、XHTML的。ただしBR要素やHR要素、IMG要素などの元来閉じタグのない要素について末尾を「～/>」で終わらせる、というようなことはされていない。

Operaではある意味、innerHTMLというプロパティ名からして正しい挙動なのかもしれないが、タグ名はすべて大文字になる。

IEでは、innerHTMLプロパティから得られるソースコードは、Opera同様タグ名が大文字になる。そして属性値は、値にスペースが入らない種類のものである限り、「"～"」（クオテーション）で囲われていない。さらに、STYLE属性の、CSSプロパティ名がなぜかみな大文字アルファベットになっている。

これはDOM要素の属性にアクセスするためのプロパティを通じて、STYLE属性にアクセスした場合も同様であるらしい。CSSプロパティ名は大文字であった。

以上でもすでにして、IEのDOMが恐ろしくなってくるのだが、さらに問題があった。
IEでは手書きのソースコードや、DOMのメソッドを用いて作成したDOM要素に、手動で指定してはいない数多くの──おびただしい数の属性が追加される。innerHTMLプロパティを用いるにせよ、attributesプロパティを用いるにせよ、これらのプロパティによって得られるソースコードや属性の情報にはこちらが予期していない、しかもものすごい数の属性が含まれている。

たとえばTD要素（テーブルのセル）のcolspan、rowspanなどはこちらが指定しなくても、DOMのプロパティとしては存在していて、初期値は１。disabledという属性を持つことのできる要素については、かならず「disabled=false」。その他のすべての要素には「tabindex=1」が勝手にセットされているし、「on～」という形式のイベントリスナを指定する属性も空文字列が値として指定されて存在している。

これは結構タチが悪く、ソースコードがやたらと長く、また読みにくくなるし、下手に標準値などを指定されると困る場面がある（IEのDOMから得られたソースコードを他のブラウザで利用するときなど）。

結局上記４ブラウザでHTMLソースコードを標準化する（そして何らかの別の処理に用いる）には、

1. IEとOperaでは、タグ名の小文字化を実施し、
2. IEでは、「"～"」で囲われていない属性値を囲い、
3. IEでは、STYLE属性についてはCSSプロパティ名部分を小文字化し、
4. IEでは、さらに値が「0」であったり、「false」や「null」、「""」（空文字列）であるような属性は、（属性値だけでなく）属性ごとカットしてしまい、これは場合にもよるが「tabindex」については「1」であればこれも属性ごと削除する

──という処理が必要になる。

Operaで外部エディタ使用はできないのか

Operaをまともに使い始めておよそ1週間。

Firebugがない──Firebug Liteならあるが──ことはともかくとして、テキストエリアの内容を外部テキストエディタで編集することができないらしいことには、がっかりしてしまった。

最近はブラウザ上で動くWYSIWYGエディタも増えてきてテキスト入力の手間も減ってきているのはたしかだが、やはり広い画面で編集したいときもあるし、テキスト編集後、手もとにコピーを保存しておきたいときもある。そういうときに、外部エディタが使用できればかなり便利なのだが…

いくらか探してみたけれども、すくなくとも日本語の情報でこの点に触れているものはほぼ皆無であった。探索の結果からすると、（日本の）Operaユーザーはせいぜいページのソースコードさえ外部エディタで開ければ満足、ということのようである。

「まー、たしかにこんな機能をほしがるのはViewSourceWithなどの拡張機能に慣れきってしまった軟弱モノだけなのかもしれない」などとも考える。

Operaにハマりかけ

最近インターネット利用にはもっぱらOperaを使用している。

ウェブページやウェブアプリの開発作業はどうしてもFirefox以外ではできないが──なにしろFirefoxにはFirebugが付いている。Firebugに比べるとOpera内蔵の開発者用ツールDragonflyはまったく力不足である。ま、ないよりはマシなのだが──、しかしOperaにだって負けないところがある。

まずタブバーの下にアドレスバー（戻る、進む、再読込みなどのボタンとURL入力・表示フィールド窓と検索窓）がある。これがものの道理というものであろう。タブバーの上にアドレスバー（ロケーションバー）があるようなブラウザは設計思想がヒドイのだと思う。そしてそんなブラウザばかりなのである。

次にOperaは、通常版もポータブル版も、動作が速い。これはもっぱらFirefoxとの比較なのだが（SafariやChromeはまともに使ったことがない、使いたくもない）、この点では「コーディング→動作確認→コーディング→…」と繰り返す開発作業でも結構役に立つ。ポータブル版（Opera@USB）の起動の早さも、大変助かる（ポータブル版があること自体がたいへんな優位なのだが）。

しかしOperaで気に入っているところといったら、何よりもスキンの品質の良さである。OperaのTangoスキンやGammaスキンはかなりイイ。Thunderbirdでは随分前から、Firefoxではバージョン3に入ってから、Windows環境で利用できるTangoテーマに完成度において満足のいくものがなくなってしまったように感じている。Tangoファンとしては許し難いことなのである（Firefoxのテーマ一般の完成度の低さ──なんて実際に作ったこともないものが批判するのはちょっと卑怯な気もするのだが──は昔からのことである）。

拡張機能がない（ウィジェットってなに？）のがなんとも窮屈にも感じられるのだが、一方でサイトごとのクッキーやスクリプトの設定などがとても簡単にできたり、ファイルのダウンロード画面やブックマーク編集画面、そしてJavaScriptで開かれたポップアップウィンドウまでもがタブにみごとに統合されていたりすることには、かなり感心してしまった。

これはしばらく飽きそうにない。

Opera9.6

例のごとくOperaはアップグレードのたびに、デスクトップと「クイック起動」に自分のショートカットを勝手につくる。

なぜユーザの勝手に属する領域に踏み込むような無礼で不快な行為を繰り返すのだろう。

だいたいがこのマイナーブラウザ（マイナーであることは別に悪いことではない）につきあっている人士というのが、こんなものを望んでいるとはとてもではないが思えない。

それとは別に、このブラウザのアップデートは、Operaの「ヘルプ＞最新のリリースをチェック」経由でも、未だに、ふつうのファイルと同様の方法でインストーラをダウンロードし、その後ブラウザを閉じて、インストーラを実行し、インストール・プロセスを進める、というふうにしかできないのは、ちょっと面倒である。

ま、それにしても、いつもながら、インターフェイスの綺麗さはすばらしい。Operaのタブとロケーションバーの配置も、すばらしく合理的である。

Operaの「メイリオ」問題

CSSのfont-familyプロパティで、「Meiryo」を指定しても、Operaブラウザでは認識してくれない。
これは単に、「メイリオ」とすればOK。しかしこれをやると、CSSファイルの保存時に、文字コードへの配慮をする必要が出てきてしまう…。
くだらない失敗をするよりは、素直にOperaブラウザ上でのメイリオ・フォント表示を諦めた方がいいのかもしれない。だいたいCleartypeフォントなぞに頼った見栄え作りというのは、そもそも邪道なのかも、と。すくなくとも現状では。