まずは本家のサーバ移行に関する問題で、Windows版のNightlyビルドが公開されていなかった問題。
既に解決済だが、ファイル名が変化しているので注意。 特にzip版は無くなったと勘違いされている方もいるのではないだろうか?
旧ファイル名 | 新ファイル名 | |
---|---|---|
フルインストーラ | mozilla-win32-installer-sea.exe | mozilla-win32-installer.exe |
ネットワークインストーラ | mozilla-win32-installer.exe | mozilla-win32-stub-installer.exe |
zip版 | mozilla-win32.zip | mozilla-i586-pc-msvc.zip |
非常に鬱陶しかったこのバグもようやく修正されている。
半透明化させた要素のスクロールバーがうまく機能していなかったバグ。
これはいつの間にやら再現しなくなっていた。
object要素を絶対配置、もしくは相対配置すると、その内容にアクセスできなくなるという問題。
ステータスはassignedのままだが、再現しないという報告があり、確認済み。
修正されたが、個人的にはあまり使わない。
要約の通りのバグだが修正された。
このバグで改めてこの機能の便利さを教えられた。
例えば私の場合、他のページから引用する場合や、id値を調べたい時にその部分のみを選択し、ソースを参照している。
当然invalidとしたのだが、この勘違いはどこから来ているのだろうか。
これらのどちらかが原因だと思うのだが、どちらにせよ仕様書を読んだことがない、 もしくはその存在を知らない人がコンテンツの発信者となることが多いというのは現在のWebの問題点のひとつである。
今のWebサイトの作成者には責任感が欠如していると思う。 例えばアップロードすることをソフトウェアによってはpublishとしている。 直訳すれば「出版する」ということである。 こう言えば、多少はWebでの情報発信に対する重みを考えてもらえるのではないだろうか。
Webは書籍に比べて情報を発信しやすいことがその最大の特徴のうちのひとつであるが、 その内容(文章等はもちろん、HTML、CSSも含む)については情報の発信者、つまりサイトの作成者は責任を負うべきである。
だから、管理することができない掲示板を運営するという2ちゃんねるのひろゆき氏は無責任以外の何者でもないと思う。 管理できないのであれば公開するべきではない。
内容の真偽は自分で見極めなければいけない
とよく2ちゃんねらーは言うが、
これはコンテンツを見る側に必要な話であって、だから虚偽の情報を発信して良いということではない。
虚偽の内容(もしくは真相が不明確な内容)が匿名の人間によって書き込まれた場合、2ちゃんねるでも管理人であるひろゆき氏に管理責任が発生すると思うがいかがなものか?
前々から気になっていた問題。
春永さんは仕様上の理由からinvalidとしたが、 私はOpera7との互換性からtop、home、startは全て同じものとして扱われるべきだと思い、reopenした。
だが、本家の判断ではhomeとはそのサイト作者のホームページを示すものであり、 そのサイトのトップページは仕様通り、startを用いるべきであるとの判断のようである。
この理屈は拡大解釈における話なので、本家の決定はもはやくつがえらないだろう。
しかし、Opera7との互換性の問題があるのでWeb標準化Tipsにこの件の追加は必要だ。
本家ではパッチの一回目のレビューが終了した。 1.7aに間に合えば良いのだが。。。
こちらも本家でDavid Baronがパッチを提出した。
現在、レビュー待ち。
文字参照が文字参照のまま保存されない、という問題。
complete保存は元々、そのWebページをそのまま完全保存するわけではない。 例えば画像やCSSファイルは全てひとつのフォルダにまとめられ、 HTMLファイル内のそれらへのパスも修正される。
つまり、DOM解析を行った後に保存を行っていることになる。
Mozillaの処理順序が分からないが、文字参照を解決した後でHTMLファイルを加工していることは間違いないようだ。
以上のような理由から未加工のHTMLファイルが必要なのであればHTMLファイル自体をそのまま保存するしかない。 となると、wontfixということで良いのかもしれない。
意見があれば是非コメントを頂きたい。
ちなみにcomment 2に書いたが少し補足。
WebSiteManagerはWindowsAPI非依存の日本語文字コードとUnicodeとの変換を行う様に修正しているが、 Windowsの多くのテキストエディタではWindowsAPIを使ってUnicode変換を行っている。
例えば今回のケースの場合、EUC-JPの0x8F 0xA2 0xEDという文字がテキストエディタで文字化けするという報告だった。 EUC-JPにおいて0x8Fで始まる3バイト文字はJIS X 0212補助漢字と言い、 Shift_JISでは扱うことができない文字である。
WindowsのテキストエディタでWindowsAPIを利用してUnicode変換しようとすると、
となってしまう。
この最初の変換が不可能であるため、文字化けを起こしてしまうのだ。
この唯一の解決法はShift_JISを通さずにEUC-JPをUnicodeに変換することである。 つまり、WindowsAPIに頼らず、自前で変換テーブルを用意して変換するしか無いのである。
Windowsのテキストエディタでは、Unicode対応と謳っていてもこの問題を抱えているエディタは多い。 これにはユーザが注意するしかない。
ちなみにWebSiteManagerでも検索、置換にはUnicodeを使えないというバグがある。 これはDelphiのEditコントロールがShift_JISで処理を行っているのが原因であるが、 将来的にはこれを独自コンポーネントに変更する予定である。
このweblog、Windows版InternetExplorerでアクセスする人がほとんど皆無、 ということで/studio/weblog配下の*.htmlファイルをapplication/xhtml+xmlとして送信するように変更しています。
で、その後、IEの他にも影響があったのでメモです。
まずははてなアンテナさん。
ヘッダを修正した途端にこのweblogへのはてなアンテナ経由のアクセスが激減していることに気づきました。 最後にtext/htmlとして受け取った時のまま、更新が止まっているかのようになっていたのがその原因でした。
こちらの方は、はてなアンテナさんに連絡したら即、修正してもらえましたので、一応、XHTML対応にはなってます。
ただ、Well-Formedかどうかは多分検証していないものと思われます。
content-type に xml が含まれる場合も内容を取得するように設定させていただきました。
という回答でしたから。
次に問題のGoogleさん。
application/xhtml+xmlは不明なファイルタイプとなってしまいます。
メールで対応してもらえるようにお願いしていますが既に結構な時間、放置されています。 まあ、こんな対応状況なので、
檢索エンジンのクローラ・ロボットの類についても、XHTMLの文書をXMLとしてパースし、他のHTMLや謎の文書とは異る處理をしてゐる、とは聞かない。GoogleのロボットがHTML文書の構造を參考にして文書を解釋する事はSEOの世界で常識だが、GoogleのプログラムがXHTML文書に出會つた時、XMLパーサに頭を切替へてゐるか何うかは不明。どなたか詳細を希望。
GoogleのエンジンがXHTMLをXMLとして真面目に処理しているとは考えにくいです。
:hover
や:target
といった動的疑似クラスと隣接セレクタ(+
)とを組み合わせても、
隣接セレクタが正しく機能していなかった問題。
これが解決した上に、このバグがブロックしていた、 Bug-org 135141 [RFE] implement CSS 3 indirect adjacent combinator も修正された。
これで、MozillaではCSS3セレクタの~
が使えるようになった。
body要素内の子要素が全て絶対配置であるため、body要素の高さが0pxとなり、
body{ overflow: hidden; }
という指定により内容が何も表示されていなかった問題。
これは少し話がややこしい。 この問題が発生したのはMozillaのregressionが原因だったようだ。 しかし、Mozillaのバグではなかったことに注意してもらいたい。
CSS2.0ではoverflowによって切り取られるものは次のように定義されている。
しかし、CSS2.1では次のように仕様変更が行われる予定である。
- A line cannot be broken, causing the line box to be wider than the block box.
- A block-level box is too wide for the containing block. This may happen when an element's 'width' property has a value that causes the generated block box to spill over sides of the containing block.
- An element's height exceeds an explicit height assigned to the containing block (i.e., the containing block's height is determined by the 'height' property, not by content height).
- A descendent box is positioned absolutely, partly outside the box. Such boxes are not clipped by the overflow property on their ancestors.
- A descendent box has negative margins, causing it to be positioned partly outside the box.
- The 'text-indent' property causes an inline box to hang off either the left or right edge of the block box.
Mozillaは再びCSS2.1の仕様に変更され、このサイトの表示ができるようになった。 しかし、これはCSS2.0のUAとは互換性のないという問題があるので、remindとして処理した。
基本的な話として、overflow: hidden;
は使うべきではないプロパティ値だろう。
これによって得をするのは誰なのだろうか?
それは、そのページをデザインした人であり、その環境での話ではないだろうか。
利用者にとって情報にアクセスできないということは致命的な問題であることは言うまでもない。
しかし、それを実現してしまう危険性を伴うのがoverflow: hidden;
である。
私はclipプロパティの実装もままならない現状では、overflow: hidden;
を使うことにメリットを見いだせないので、これを使わないことをお勧めする。
こんなのが修正されている。
というか、今までできなかったんだと初めて気づいた。
一応、本家ではWorksForMeとなったが、 WinXPでしか確認できていない。
是非、LinuxやMac、それにBSD等でのテスト結果をコメントして欲しい。
Comment 14に書いたようにinvalidとした。
本家ではhttp://x.com/victim/%2E%2E/evil/hack.htmlというURIに対して次のような意見が出ている。
If a literal ".." is used then Mozilla coalesces the path before matching against cookies, with the result that "/victim" will not match "/evil". Some servers (Netscape's NES, for example) will not accept %2E%2E as a relative path, but others (e.g. Apache) do. We should not depend on the server implementation for our security, the coalescing code should treat %2e as a '.'
- 邦訳
もしMozillaが「..」をCookieとパスを比較する前にデコードしないと、「/victim」と「/evil」は一致しないことがある。 サーバによっては(例えば、NetscapeのNES)は%2E%2Eを相対パスとして受け入れないが、 他のサーバ(例えば、Apache)はそうではないことがその原因である。 私たちのセキュリティはサーバの実装に依存するべきではない。 そのために%2eは「.」として扱うべきである。
正直なところ、この問題は難しいので異論があればコメントが欲しい。
しかし、もともと問題のWeblogサービスが何故かURLデコードを行わずにパラメータを処理しているところに問題がある。
とあるWeblogサービスのためにMozillaにセキュリティーホールを生む可能性のある修正をいれるべきかと問われると、 やはりNo!だと私は考え、invalidとしたことに注意してもらいたい。
いよいよCSS3のセレクタの実装に向けて準備が進んでいるようだが、 このバグで気になるコメントが。
------- Additional Comment #3 From Boris Zbarsky 2003-11-05 22:02 -------
So this would be "easy" to implement by just looking at the textContent of the node during style resolution and searching for the arg to contains() in that string. That's not likely to be anything like fast, though. Then again, I see no real way this selector could ever be fast.
要約するなら、実装は簡単だが、速度に問題が出るという話である。
このセレクタは例えば対応表を作る際に、セルの内容が"×"なら背景色を変える、 といったことができる非常に便利なものなので実装はしてもらいたいが、 下手に使うとMozillaのパフォーマンスが著しく低下する恐れがある。
単純に考えるなら、このセレクタを使いつつ、速度低下を防ぐにはWebページの作者が気を使う必要が出てしまう。 当然、それは望ましいことではないが、画期的なアイデアが無い限りはそこが妥協点となるだろう。
例えば次のようにすればパフォーマンスをあまり落とさずに適用できるのでは無いかと推測できる。
こういった点を考えると、まだまだWYSIWYGをCSSで実現しようとしても壁があることを暗示してしまっている様に思える。 結局、いつの時代になっても、Webページの制作は手書きでもできなくては良質のWebページは作れないと思う (別にWYSIWYGを全否定するわけではない)。
ようやく、鬱陶しかったこのバグが修正された。
文書内に埋め込まれた*.swfファイルを保存するために、多用していたもので……
fixedとなった。
資料が非公開なので見れないのだが、どうも仕様に関するディスカッションがあったようで、 フラグメントが無い場合、*:target疑似クラスがルート要素を示すとはみなさないようである。
これはDavid Baronが明言しているわけではないが、
Descriptionがimplement :target (left open for :target on root)
から現在のものに変更され、それと同時にfixedとなっていることから、そう解釈するのが自然だろう。
テストケースでの挙動を見てもそれの裏付けとなる。
テストケース を見て、CSSだけでタブインターフェースを実現できることに感動したのは私だけではないと思う。
しかしこのテストケース、ソースを見ると分かるようにアクセシビリティにおいて重大な問題を抱えている。
もし、CSS自体をサポートしていないUAの場合、アクセシビリティに問題は無い。 また当然、:target疑似クラスを実装している場合も同様である。 だが、多くのCSS2.1以下のWebブラウザではコンテンツが表示できないという重大な欠点があることに注意してもらいたい。 CSS最大の欠点はこのCSSレベル間での後方互換性の無さである。
という訳で、この疑似クラスは遊び程度に使うことをお勧めする。
嫌な問題がやってきた。
comment 8は書いたものの、 安直すぎるかなぁ……