も～ : 技術的なことに関して

参考文献

も～のデザインについては以下のウェブに関する技術スタンダードに従うようにしています。これらのほとんどのものは RFC もしくはウェブ・コンソーシアムの推薦するものです。

HTML 2.0 Proposed standard (rfc 1866)
HTML 3.2 Reference specification (W3C Recommendation)
HTTP/1.0 Proposed standard (rfc 1945)
rfc1630 on Universal Resource Identifiers (rfc 1630)
rfc1738 on Uniform Resource Locators (rfc 1738)
rfc1808 on Relative URL (rfc 1808)

しかしながら、ブラウザは完全にこれらの基準に従っているわけではありません。いくつか問題(下記)があります。何か問題を発見したばあい、私に、

どういった問題なのか
参考となるようなドキュメントや情報 (HTML ワーキンググループでの議論など)
表示する際に問題があった URL

を送ってください。

注意

も～は他のブラウザよりも親切ではありません。よって、「Mozilla とか Explorer が正しく表示できる文書をも～はエラーだと言ったり、表示できないよー」と思っても、それはも～が悪いのではなく、その文書そのものが腐っている場合があります。それら、何度言ってもきりがないのですが、

テーブルの実装は腐ってるよ
テーブルの実装は腐ってるぜ
テーブルの実装は腐ってるの
テーブルの実装は腐ってるっす
テーブルの実装は腐ってるで
テーブルの実装は腐ってるでゴンス
というわけ。ちゃんと事前に言ったからね。
それから遅いよ。
んでもってメモリも食うよ。

頼むからテーブルがちゃんと表示できないというレポートは見飽きているから送らないで下さい。Tk のバージョン 4.{0,1,2} を使って、テーブルをちゃんと表示する方法はないに違いないのです。

実装部分

ブラウザは次の独立した部分から成り立っています。

コミュニケーション・プロトコル
HTML ビューア
その他のビューワ
キャッシュ

コミュニケーソン・プロトコル

ウェブではさまざまなプロトコルが使用されていますが、も～に実装されているのは HTTP 1.0 のみです。それ以外のプロトコル (ftp, wais, gopher,...)などは Proxy サーバを介してやる必要があります。
いくつかのリクエストは並行して処理することができ、 DNS を引く以外のネットワーク上の読み込み、書き込みはノン・ブロッキングで行なわれます。
ブラウザは HTTP レクエストをまず直接サーバに送ろうとします。もしそれができないばあいはプロキシに再送します。もし、常にプロキシを使う (Always Use Proxy) オプションが ON になっている場合は、始めからプロキシに送ります。
HTTP 1.1 で提案されている Proxy authentication が実装されています。
某企業(複数)が勝手に拡張した HTTP プロトコル(Refresh, push/pull など) は実装されていません。
file: プロトコルのリクエストは次のように解釈されます。もしホスト名が "localhost" (file://localhost/path)の場合か指定されていない(file:///path)場合、pathはローカルファイルシステムの絶対パスを表すと見なします。注意： file:/some/path は not 正確な URL ではありませんが、受け付けます。
もし localhost 以外のホスト名が指定されている場合は、この URL は ftp: プロトコルと同様に扱われます。
telnet: プロトコルは全くサポートされていません。

も～は HTML (text/html タイプの文書) ビューワは HTML 2.0 といくつかの HTML 3.2 で定義されたエレメントを理解します。字句および文法解析は HTML の定義で使われている SGML の部分集合と DTD (HTML 2.0 か 3.2) に沿って行われます。タグアトリビュート値については、ビューワはそれらをチェックすべきですが、文法のチェックは行われません。 インライン・イメージの表示は Tk のイメージ表示機能をそのまま使っています。現在、GIF 形式 (つまり、MIME タイプ image/gif) (インタレース, アニメーテッド, トランスパレントには対応していません。)、 PNM 形式、 XBM 形式の画像に対応しています。それ以外の画像フォーマットは Tk 拡張 (外部ダイナミックリンクライブラリ) を使って対応させることができます。例えば PNG と JPEG (非 progressive) はこういったライブラリを使うと表示可能です。最近のも～では、アニメーテッド GIF ファイルを特別なデコーダを用意することで表示可能になっています。

イメージのロード

イメージのロードのポリシーにはいくつかの戦略が用意されていて、これらは設定パネルで変更可能です。イメージのロードは内部の順番待ち行列があり、同時に発生するネットワークコネクションの上限があります。

この他のビューワ

これ以外のメディアタイプの文書 (text/plainを除く) ではも～は metamail を呼び出し、表示を行なわせます。 (metamail は ~/.mailcap ファイルを見て、それぞれのメディアタイプによってどんなビューワを立ち上げるかを判断します。)

キャッシュ

も～のキャッシュには段階が二つあります。まず、グラフィカル・キャッシュ。これは実際に表示された文書の画面そのものです。そして次が、普通の意味でのキャッシュ、文書をソースの形で、メモリやディスクに一時保存するものです。

今までに発見されたバグ

HTML compliance problems

次の問題があることがわかっています

<!DOCTYPE> は正しくパースされません。でも知る限り、有名ブラウザで DOCTYPE を実際にパースしているものはないようです。
<! ホゲホゲ > はテキストとして表示されます。(とはいってもこれは文法的に正しいコメントではありません。)
スペースの取り扱いが時々変になります。
<IMG> の ALIGN がうまくいきません。(特に、 HTML3.2 ではテキストはイメージを回り込んで表示されねばいけないのですが、 Tk ではこれができないのです。)
BODY タグの background アトリビュートは無視されます。
PRE タグの width アトリビュートは実装されていません。
FORM タグの enctype アトリビュートは常に applications/x-www-form-urlencoded だということにしています。
INPUT の type=file は実装されていません。

HTTP Protocol

Only the most used subset of HTTP/1.0 is implemented. Only the GET, HEAD and POST methods are supported.