Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.
検索結果

    Mozilla Web Developer FAQ

    この文書では Web ページの作者が特に Mozilla や Firefox などの Gecko ベースのブラウザに関して頻繁に聞く質問に答えます。文書の最後にはより一般的な Web ページ作成の FAQ へのリンクを用意しています。

    Quirks モードと Standards モードというのは何？

    Mozilla には Quirks と Almost Standards 及び Standards という 2 つ半のレイアウトモードがあります。Standards モードでは Mozilla は World Wide Web Consortium の 勧告 に従って書かれたドキュメントを W3C 勧告通りに扱うことを目指しています。Quirks モードでは — 後方互換性のため — Mozilla は過去のブラウザの挙動をある程度真似しています。この場合 W3C 勧告に従うドキュメントが W3C 仕様に反して扱われることもあります。Almost Standards モードは、次の質問 の問題について昔からの方法で画像を表のセル中に描画するように扱うことを除いて、Standards モードと同じものです。モードは HTML ドキュメント冒頭の doctype 宣言 (あるいはその欠如) に基づいて選ばれます。

    • HTML で確実に「Standards モード」を起動する最も簡単な方法はこの DOCTYPE 宣言を使用することです:
      <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "https://www.w3.org/TR/html4/strict.dtd">
    • HTML で確実に「Almost Standards モード」を起動する最も簡単な方法はこの DOCTYPE 宣言を使用することです:
      <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "https://www.w3.org/TR/html4/loose.dtd">

    上の宣言は推奨されないマークアップをまったく含まない文書用です。下の宣言は推奨されないマークアップを含んでいるかも知れない文書用です。いずれにしろ文書は 検証 され CSS2 レイアウトモデルに準じるべきです。

    HTML で Quirks モード を起動する最も簡単な方法は DOCTYPE 宣言を省略することです。しかし、Quirks モードに依存する文書を新たに書くことは推奨できません。

    Almost Standards モード は Mozilla 1.1 ベータ及び Mozilla 1.0.1 で導入されました。それ以前のバージョンでは現在では Almost Standards モードを起動する DOCTYPE 宣言は Standards モードを起動していました。

    DOCTYPE 判別は text/html として渡された文書に対してのみ利用されます。XML として送信された文書は常に Standards レイアウトモードを起動します。これは application/xhtml+xml として送られた文書も含みます。この結果として、XHTML 1.0 Transitional 文書は 付録 C にかこつけて text/html として渡された場合は Almost Standards モード で描画されますが、(しかるべくして) application/xhtml+xml として渡された場合は Standards モードで描画されることになります。

    Since also other contemporary browsers have a standards mode, activating the Standards mode or the Almost Standards mode in other browsers as well (using the above-mentioned exact doctypes) is the best way to get consistent CSS layout results across different browsers. On the other hand, the quirks implemented in the quirks modes of different browsers vary from browser to browser.

    レイアウトエンジンが Standards モードである際に表中の画像行間に隙間があるのはなぜ？

    CSS2 のボックスレイアウトモデルではレイアウトボックスの 垂直サイズ の初期値と画像の 垂直位置揃え の初期値が以前のブラウザの振る舞いとは異なります。レイアウトのこれらの特徴は画像 (場合によってはそれを囲んでいる <a> 要素) の display CSS プロパティを明示的に block と設定することで変更できます。

    例えば画像のみを含む表のセルが <td class="imgcell"> のようにマークアップされているなら、必要な CSS ルールは: .imgcell img, .imgcell a { display: block; }

    より詳しい解説…

    Why are there still gaps even between text rows in tables when the layout engine is in the Standards mode or in the Almost Standards mode?

    In the Standards mode and in the Almost Standards mode Mozilla does not suppress the default margins of the first and last child element in table cells. Therefore, the default margins for paragraphs apply even with markup such as <td><p>foo</p></td>.

    Often the content of a cell in a table of tabular data does not constitute a paragraph. In that case, the easy solution is not to mark the contents of the cell as a paragraph.

    When the paragraph markup is called for but the default margins are unwanted, zero margins can be suggested using CSS.

    スタイルシートが機能しない！ どうして？

    チェックリストを用意しました:

    • HTML 文書の 有効性検査 はされましたか？ CSS はタグのごった煮とは合いません。
      • <link> 及び <style> 要素は <head> 要素中に書かれるべきです。
    • CSS スタイルシートは 文法チェック にパスしていますか？ The CSS エラー処理の規則 では、間違った部分は推測によって修正するのではなく無視すべきとされています。
      • ゼロ以外の長さ値は数字と単位との間にスペースを入れずに適切な単位を付記するべきです (例: 1.2em)。
      • プロパティ名と値の間に使用する文字はコロンであり等号ではありません。
      • <style> のような HTML マークアップは .css ファイル中には含めません。
      • font-face は実際の CSS プロパティではありません。プロパティであるのは font-family であり、@font-face は @ルール です。【訳注: あまり知られていないようですが CSS2 ではより柔軟なフォント指定の為に新たな @ルール として @font-face が定義されています。なお、「at-rule」の訳は「@規則」とされることがありますが、CSSではスタイル指定記述 (セレクタと宣言のセット) を「ルール」と呼ぶのが通例であり、その特殊なものという位置づけですから同様に「@ルール」と呼ぶのが妥当だと思います。】
      • @import を使用する場合、CSS ファイルの最初に書くべきです。
      • Mozilla 1.8a4 以降 (Firefox 1.0 は含まれません) では、CSS パースエラーは JavaScript コンソールに出力されます。
    • サーバが CSS ファイルを適切な Content-Type ヘッダで送信していますか？
    • クラス及び ID 名は大文字小文字を区別します。
    • XML では要素セレクタは大文字小文字を区別します。
    • スタイルシート処理命令は XML 文書の冒頭でのみ認められています。さらに、XML 文書でのみ機能し、text/html として渡された文書では機能しません。
    • width や height は (初期設定では) <span> のような非置換インライン要素には適用されません。
    • text-align: center; とするとブロック内部のインラインコンテントが中央に配置されます。ブロックボックス自体は中央配置されません (してはなりません)。ブロックはその margin-left と margin-right を auto に設定し、width をそのブロックがそれを含むブロックよりも狭くなる値に設定することで中央に配置されます。

    あまり無いことではありますが、バグに遭遇することもあります。

    JavaScript が機能しない！ どうして？

    document.all や document.layers といった独自拡張のドキュメントオブジェクトは W3C DOM には含まれておらず、Mozilla ではサポートされていません。(なお、比較的新しいバージョンの Mozilla では、document.all の部分不検知サポートが含まれています。しかし、この機能は IE 専用に作られたサイトとの互換性のために存在しているだけです。新しいページに関して Mozilla の document.all サポートに依存すべきではありません。) document.getElementById() メソッドを 代わりに使用できます。

    In the Standards mode Mozilla does not generate implicit top-level JavaScript variable bindings for elements with the id or name attribute. The correct way to access an element by id is to call the document.getElementById() method with the id as a string as the argument.

    また、古いクライアント判別コードは新しいブラウザを閉め出すかも知れないことに注意してください。共通 API (W3C DOM) を採用する目的は実行環境への依存をなくすこと (相互運用性) であり、特定のブラウザをチェックすることはその目的に反します。DOM を使用する場合には使用するつもりのメソッドやオブジェクトの存在を確認する方がより適切です。例えば、document.getElementById() の存在は次のようにして確認できます: 

    if(document.getElementById) {
   /* code that uses document.getElementById() */
}

    Mozilla はどうして alt ツールチップを表示してくれないの？

    Windows プラットフォームで動作する 2 つのブラウザの挙動から一般に考えられているのとは異なり、alt は「tooltip」ではなく「alternative」の短縮形です。 alt 属性の値は画像のテキストによる「置き換え」であり、画像が存在しない時に表示されるものです。

    そうしてしまえば作者達が属性を誤用するのを促進してしまうことが分かっているので、Mozilla は alt 属性をツールチップとして表示しません。

    • 置き換えテキストをツールチップとして表示すれば、一部の作者はテキストを画像の置き換えではなく補助ツールチップのつもりで使用して不作法な alt テキストを書いてしまいます。(画像を見ない人にとってテキスト置き換えが役に立たないという意味で「不作法」ということです)
    • 置き換えテキストをツールチップとして表示すれば、他の作者はツールチップを表示したくないために置き換えテキストを一切提供したくなくってしまいます。(繰り返しますが、画像を見ない人が困るのです)

    Mozilla がツールチップとして表示するための title という別の属性があります。実際、HTML 4.01 仕様は title 属性はツールチップとして表示してもよいと提示しています。しかしながら、この決まった表示方法が要求されているわけではなく、例えば他のブラウザはステータスバーに title 属性を表示しています。

    現在の所一部の人はニュースグループや Bugzilla で「でも IE は…」と騒ぎ主張しなければならないと感じているようですが、Mac IE 5 は alt 及び title 属性に対して Mozilla と同様の振る舞いを見せているし、Windows IE も title 属性をツールチップに表示するということを分かってください。

    Mozilla はダウンロード可能なフォントをサポートしているの？

    ダウンロード可能フォントはサポートされていません。

    ダウンロード可能フォントは以前のブラウザが適切なサポートを欠いていた記述システムを用いたサイトで通常使用されています。これらのサイト (例えば一部のインドのサイト) ではブラウザやオペレーティングシステムにはラテン語 【訳注: 英語など西欧の主言語はこれにあたる】 フォントのように見えるが例えばデーバナーガリー文字 【訳注: サンスクリット語やヒンディー語で使用される文字】 を収めたちんぷんかんぷんなラテン語テキストを書いています。そのフォントでちんぷんかんぷんなラテン語が描画されると人間の読み手には何らかの言語で理解できるようになるわけです。ラテン語ベーステキストで他にも数学の記号としてギリシャ文字を含めるのに同じ手法が使用されています。

    明らかに、この手の応急的措置は Unicode 対応のブラウザが現れてちんぷんかんぷんなラテン語を (Unicode の視点からすればそれがファイルに書かれているものであるため) ちんぷんかんぷんなラテン語として描画すれば破綻してしまいます。ダウンロード可能フォントをサポートするのではなく、Mozilla は真の問題に取り組んでいます。Unicode の多くの領域をサポートしているのです。

    しかしながら、一部のプラットフォームでは未だにインド語の記述へのサポートに関してバグがあります。例えば、 Mac OS X では、Mozilla はシステムに付属するデーバナーガリーフォントを使用しませんが、TITUS Cyberbit などのサードパーティフォントを使用できます。

    多大な労力が Mozilla の Unicode サポートにつぎ込まれています。クロスプラットフォームな方法でのダウンロード可能フォントのサポートもまた多大な作業となり更に過去のパテントの山を通り抜けていく必要がありますが、得られるものは僅かでしょう。 ISO-8859-1 文字以外を描画する目的では Mozilla は既に Unicode のサポートを提供しており、それは長い目で見れば各サイトで別々の疑似ラテン語のダウンロード可能フォントを使用するよりも遙かに実りある手法なのです。

    Why aren’t symbol/dingbat fonts working?

    They are working. Characters in HTML 4 and XML documents are Unicode characters (even if the document has been encoded using a legacy encoding for transfer)—not font glyph indexes.

    <font face="Symbol">a</font> means the character LATIN SMALL LETTER A (U+0061) preferably displayed using the Symbol font. Since the Symbol font does not have glyph for that character, another font is used. If you mean α, you should use GREEK SMALL LETTER ALPHA (U+03B1). If you are using a legacy encoding that cannot represent that character, you can use a numeric character reference: &#945;.

    Likewise, to use a dingbat, you should use the appropriate Unicode character instead of trying to apply a dingbat font to an ASCII character. For example, to represent ☺, you should use WHITE SMILING FACE (U+263A).

    どうして Mozilla は私の意図する通りに描画してくれないの？ 確かに私のページは標準準拠ではないわ。でも、ちゃんとしたブラウザだったら何はともあれ作者の意図通りにページを描画するべきよ！

    作者は Web 標準を用いてその意図を伝えることが求められます。そうしなければ、それぞれ特定の作者の意図を理解することはソフトウェアに実装するには物理的に不可能なのです。人間であれば意図を推定できるような場合でも、ソフトウェアがそのようにするのは大変遅く、バグを誘引することとなり、難しく複雑なものなのです。

    お決まりの反論は考えるまでもなく、Mozilla は何でもブラウザ <var>X</var> のするようにすればいいのよ (ここで <var>X</var> は大概反論を述べている人が好きな Mozilla 以外のブラウザ)、というものです。ですがしかし、先の主張で述べられたところでは簡単なことのように見えても、考え得るあらゆる場合にブラウザ <var>X</var> のようにするというのは決して簡単ではないのです。

    人が違えば Mozilla が合わせるべき <var>X</var> についての意見も異なります。第二の問題は Web 作者達は標準を逸脱した様々な方法を持ち出してくるのに大変創造的だということです。事実、ブラウザへの入力は恣意的長さとなり、標準からの脱線方法が異なる数には上限がないのです。それゆえ、Mozilla が可能な入力全てに対して正確にブラウザ <var>X</var> のように反応するかどうか確かめることは不可能なのです。(同様に、標準の多様な機能自身が組み合わされ得る方法の数にも上限はなく、ソフトウェア品質保証を厳しいものとしています)

    また、ブラウザ <var>X</var> の標準非準拠入力に対する反応の仕方は必ずしも意図的ではありません。一部の反応は複雑なプログラム内部での不明で意図されない相互作用に因るものです。ブラウザ <var>X</var> のソースコードを持っていたとしても、1 つあるいはそれ以上のプログラム内部の不明で意図されない相互作用を変更する危険を冒すことなく何一つ変えることなどできないでしょう。

    お決まりの反論となるのは、Mozilla はあり得る場合全てでブラウザ <var>X</var> の振る舞いに合わせる必要などないわ、ただ特定されている一般的な場合だけ合わせればいいのよ、というものです。ですがこれは既に Mozilla がしていることになります。 Mozilla の Standards モードは、明らかに、同じ標準をそれなりに正しく実装している他のブラウザと既に互換性があります。その一方で、Mozilla の Quirks モードは一般的なレガシーブラウザの振る舞いが原因である一般的な非標準状態に既に適応しています。

    リバースエンジニアリングやレガシーブラウザを真似するのに時と労力を費やすのではなく、標準を実装するのに注力するほうがもっと効果があります。レガシーソフトのバグを一つ一つ真似るよりも標準は (他でも同様に実装されれば) よりしっかりと相互利用性を促進します。

    また、HTML は異なる表現メディアに適応するよう設計されているため、同じドキュメントでも異なった表示になるのは意図されたことなのです。

    According to the Accept header, Mozilla prefers application/xhtml+xml over text/html. Should I serve application/xhtml+xml to Mozilla?

    The preference for application/xhtml+xml was added to the Accept header in order to enable the serving of MathML to both Mozilla and IE with Apache without scripting back when the MathPlayer plug-in for IE did not handle application/xhtml+xml.

    If your document mixes MathML with XHTML, you should use application/xhtml+xml. If you’re developing XHTML Basic content for mobile devices and are serving it as application/xhtml+xml, you can serve it as application/xhtml+xml to Mozilla as well without taking special steps (except perhaps providing a different style sheet for the handheld and screen media).

    However, if you are using the usual HTML features (no MathML) and are serving your content as text/html to other browsers, there is no need to serve application/xhtml+xml to Mozilla. In fact, in versions prior to Gecko 1.9/Firefox 3, doing so would deprive the Mozilla users of incremental display, because incremental loading of XML documents has not been implemented in those versions. Serving valid HTML 4.01 as text/html ensures the widest browser and search engine support.

    There is a fad of serving text/html to IE but serving the same markup with no added value as application/xhtml+xml to Mozilla. This is usually done without a mechanism that would ensure the well-formedness of the served documents. Mechanisms that ensure well-formed output include serializing from a document tree object model (eg. DOM) and XSLT transformations that do not disable output escaping. When XHTML output has been retrofitted to a content management system that was not designed for XML from the ground up, the system usually ends up discriminating Mozilla users by serving tag soup labeled as XML to Mozilla (leading to a parse error) and serving the same soup labeled as tag soup to IE (not leading to a parse error).

    How is the treatment of application/xhtml+xml documents different from the treatment of text/html documents?

    • An XML parser (expat) is used instead of the tag soup parser.
      • Most well-formedness constraints are enforced. (Currently Mozilla does not catch character encoding errors, because the document is re-encoded using a lenient encoding converter before the document reaches the XML parser. This is a bug.) Despite common allegations to the contrary, the document is not checked for validity.
      • Externally defined character entities other than the five pre-defined ones (&lt;, &gt;, &amp;, &quot; and &apos;) are only supported if the document references a public identifier for which there is a mapping in Mozilla’s pseudo-DTD catalog and the document has not been declared standalone.
      • In older versions of Mozilla as well as in old Mozilla-based products, there is no pseudo-DTD catalog and the use of externally defined character entities (other than the five pre-defined ones) leads to an XML parsing error. There are also other XHTML user agents that do not support externally defined character entities (other than the five pre-defined ones). Since non-validating XML processors are not required to support externally defined character entities (other than the five pre-defined ones), the use of externally defined character entities (other than the five pre-defined ones) is inherently unsafe in XML documents intended for the Web. The best practice is to use straight UTF-8 instead of entities. (Numeric character references are safe, too.)
      • document.write() is not supported. The stream that is going into the parser can’t be tampered with in mid-parse.
      • Things that look like XML comments are treated as XML comments—even inside script or style elements.
      • Elements need to be in the XHTML namespace in order to be treated as XHTML elements.
      • meta tags are not examined for character encoding information.
      • tbody, head, body, and html are not inferred if the tags are not explicitly present.
      • CDATA sections are supported.
      • XML empty element notation (<foo/>) is supported.
      • White space characters in attribute values are normalized to spaces at parse time, so the original white space never makes it to the DOM. This affects data round tripping using hidden form inputs.
    • In versions prior to Gecko 1.9/Firefox 3, the document is not loaded and rendered incrementally. That is, the document is displayed only after the entire document has been received and parsed. Contrary to a common misguided assertion, this is not done in response to a requirement set forth in any W3C specification. In particular, the XML specification does not require the entire document to be checked for errors before rendering can start. The lack of incremental loading and display is simply a bug (or a missing feature). This has been fixed in Gecko 1.9/Firefox 3.
    • The layout mode is the (Full) Standards Mode regardless of doctype.
    • CSS works according to the XML+CSS rules.
      • HTML-specific CSS exceptions do not apply. For example, the body element gets no special treatment.
      • CSS selectors are case-sensitive.
    • The DOM is in the XML mode.
      • Namespace-aware variants of methods need to be used when working with elements (eg. createElementNS() instead of createElement()).
      • In older versions of Mozilla, the document object does not implement the HTMLDocument interface.
      • Element and attribute names are not normalized to upper case.
      • In older versions (including Firefox 1.0), content cannot be added using innerHTML.
    • Other namespaces are supported.
      • MathML
      • Simple XLink
      • SVG (in SVG-enabled builds only)
      • XUL (Please note that XUL is Mozilla-specific and, therefore, using it on the public Web causes interoperabilty problems.)
    • xml:base is observed when following links.
    • Style sheets can be references using processing instructions.

    求める答えが見つかりませんでした。 何処で聞けばいいの？

    comp.infosystems.www.authoring.* 階層にある質問に関連するニュースグループか、JavaScript/ECMAScript や DOM に関してであれば、comp.lang.javascript で聞いてみてください (もちろんそのグループの FAQ を最初に読んでから)。 Webページ作成の質問を Mozilla 開発に関する議論のためのニュースグループでは聞かないようにお願いします。

    原文書の情報

    • 著者: Henri Sivonen (このアドレスにページ作成関連の質問をしないでください)
    • 最終更新日: May 12, 2007
    • 著作権: Henri Sivonen

    ドキュメントのタグと貢献者

    タグ: 
     このページの貢献者: Mgjbot, Kohei
     最終更新者: Mgjbot,