Mozilla Web开发人员 FAQ


修订版 283074:

由 Andyyard 在 进行的修订 283074

修订版 208673:

由 Andyyard 在 进行的修订 208673

Mozilla Web开发人员 FAQ
Mozilla Web开发人员 FAQ

修订版 283074
修订版 208673
t7    <p>t
8      This document answers questions that Web authors ask freque
>ntly specifically in connection with Mozilla and other Gecko-base 
>d browsers such as Firefox. There are links to more general Web a 
>uthoring FAQs at the end of this document. 
9    </p>
10    <h2 id=".E4.BB.80.E4.B9.88.E6.98.AF.E2.80.9C.E6.80.AA.E5.BC.8
>E2.80.9C.E6.A0.87.E5.87.86.E6.A8.A1.E5.BC.8F.E2.80.9D.EF.BC.9F" n 
11      什么是“怪异模式”,什么是“标准模式”?
12    </h2>
13    <p>
14      Mozilla has two and a half layout modes: <a href="cn/Mozill
>a's_Quirks_Mode">Quirks, Almost Standards and Standards</a>. In t 
>he Standards mode Mozilla aims to treat documents authored in com 
>pliance with the <a class="external" href=" 
>Recommendations">Recommendations</a> of the <a class="external" h 
>ref="">World Wide Web Consortium</a> according  
>to the W3C Recommendations. In the Quirks mode—for the purpose of 
> backwards compatibility—Mozilla mimics some behaviors of legacy  
>browsers in ways that could cause W3C Recommendation-compliant do 
>cuments to be handled against the W3C specifications. The Almost  
>Standards mode is like the Standards mode except it addresses the 
> issue of the <a href="#Why_are_there_gaps_between_image_rows_in_ 
>tables_when_the_layout_engine_is_in_the_Standards_mode.3F">next q 
>uestion</a> by rendering table cells with images in the tradition 
>al way. The mode is picked based on the doctype declaration (or t 
>he lack thereof) at the beginning of an HTML document. 
15    </p>
16    <ul>
17      <li>The easiest way to make sure that the <i>Standards mode
></i> is activated for HTML, is to use this doctype declaration:<b 
18        <code><span class="nowiki">&lt;!DOCTYPE HTML PUBLIC "-//W
>3C//DTD HTML 4.01//EN" ""&gt 
19      </li>
20      <li>The easiest way to make sure that the <i>Almost Standar
>ds mode</i> is activated for HTML, is to use this doctype declara 
21        <code><span class="nowiki">&lt;!DOCTYPE HTML PUBLIC "-//W
>3C//DTD HTML 4.01 Transitional//EN" " 
22      </li>
23    </ul>
24    <p>
25      The former declaration is for documents that don’t include 
>any deprecated markup. The latter is for documents that may inclu 
>de deprecated markup. In either case the document should <a class 
>="external" href="">validate</a> and be c 
>ompatible with the CSS2 layout model. 
26    </p>
27    <p>
28      The easiest way to activate the <i>Quirks mode</i> for HTML
> is to omit the doctype declaration. However, authoring new docum 
>ents that rely on quirks is discouraged. 
29    </p>
30    <p>
31      The Almost Standards mode was introduced in Mozilla 1.1 bet
>a and Mozilla 1.0.1. In earlier versions the doctype declarations 
> that now activate the Almost Standards mode activated the Standa 
>rds mode. 
32    </p>
33    <p>
34      Doctype sniffing only applies to documents served as <code>
>text/html</code>. Documents sent as XML always activate the Stand 
>ards layout mode. This includes documents sent as <code>applicati 
>on/xhtml+xml</code>. The consequence is that XHTML 1.0 Transition 
>al documents are rendered in the Almost Standards mode when serve 
>d as <code>text/html</code> under pretext of the Appendix C but i 
>n the Standards Mode when served as <code>application/xhtml+xml</ 
35    </p>
36    <p>
37      Since also <a class="external" href="
>/doctype/">other contemporary browsers</a> have a standards mode, 
> activating the Standards mode or the Almost Standards mode in ot 
>her browsers as well (using the above-mentioned exact doctypes) i 
>s the best way to get consistent CSS layout results across differ 
>ent browsers. On the other hand, the quirks implemented in the qu 
>irks modes of different browsers vary from browser to browser. 
38    </p>
39    <h2 id="Why_are_there_gaps_between_image_rows_in_tables_when_
>the_layout_engine_is_in_the_Standards_mode.3F" name="Why_are_ther 
40      Why are there gaps between image rows in tables when the la
>yout engine is in the Standards mode? 
41    </h2>
42    <p>
43      In the CSS2 box layout model the default <a class="external
>" href="">vertical  
>sizing</a> of layout boxes and the default <a href="cn/CSS/vertic 
>al-align">vertical alignment</a> of images is different from the  
>behavior of old browsers. These aspects of the layout can be chan 
>ged by explicitly setting the <code>display</code> CSS property o 
>f the images (and possible surrounding <code>&lt;a&gt;</code> ele 
>ments) to <code>block</code>. 
44    </p>
45    <p>
46      If the table cells that contain only an image are marked wi
>th <code>&lt;td class="imgcell"&gt;</code>, the required CSS rule 
> is: <code>.imgcell img, .imgcell a { display: block; }</code> 
47    </p>
48    <p>
49      <a href="cn/Images%2c_Tables%2c_and_Mysterious_Gaps">Longer
> explanation…</a> 
50    </p>
51    <h2 id="Why_are_there_still_gaps_even_between_text_rows_in_ta
>most_Standards_mode.3F" name="Why_are_there_still_gaps_even_betwe 
52      Why are there still gaps even between text rows in tables w
>hen the layout engine is in the Standards mode or in the Almost S 
>tandards mode? 
53    </h2>
54    <p>
55      In the Standards mode and in the Almost Standards mode Mozi
>lla does not suppress the default margins of the first and last c 
>hild element in table cells. Therefore, the default margins for p 
>aragraphs apply even with markup such as <code>&lt;td&gt;&lt;p&gt 
56    </p>
57    <p>
58      Often the content of a cell in a table of tabular data does
> not constitute a paragraph. In that case, the easy solution is n 
>ot to mark the contents of the cell as a paragraph. 
59    </p>
60    <p>
61      When the paragraph markup is called for but the default mar
>gins are unwanted, zero margins can be suggested using CSS. 
62    </p>
63    <h2 id=".E4.B8.BA.E4.BB.80.E4.B9.88.E6.88.91.E7.9A.84.E6.A0.B
>E4.BD.9C.EF.BC.9F" name=".E4.B8.BA.E4.BB.80.E4.B9.88.E6.88.91.E7. 
64      为什么我的样式表不能正常工作?
65    </h2>
66    <p>
67      Here’s the check list:
68    </p>
69    <ul>
70      <li>Does the HTML document <a class="external" href="http:/
>/">validate</a>? Styling misnested markup may ca 
>use strange effects. 
71        <ul>
72          <li>The <code>&lt;link&gt;</code> and <code>&lt;style&g
>t;</code> elements should be inside the <code>&lt;head&gt;</code> 
> element. 
73          </li>
74        </ul>
75      </li>
76      <li>Does the CSS style sheet pass the <a class="external" h
>ref="">syntax check</a>? The < 
>a class="external" href=" 
>parsing-errors">CSS error handling rules</a> require erroneous pa 
>rts to be ignored rather than fixed by guessing. 
77        <ul>
78          <li>Lengths other than zero should be followed by a pro
>per unit without a space between the number and the unit (eg. <co 
79          </li>
80          <li>The character to use between the property name and 
>the value is the colon—not the equal sign. 
81          </li>
82          <li>HTML markup, such as <code>&lt;style&gt;</code>, do
>es not belong in .css files. 
83          </li>
84          <li>
85            <code>font-face</code> is not a real CSS property. Th
>e property is <code>font-family</code> and <code>@font-face</code 
>> is an at-rule. 
86          </li>
87          <li>If <code>@import</code> is used, it should be the f
>irst thing in a CSS file. 
88          </li>
89          <li>In Mozilla 1.8a4 and later (not in Firefox 1.0) CSS
> parsing errors are reported to the JavaScript console. 
90          </li>
91        </ul>
92      </li>
93      <li>Is the server sending the proper <code>Content-Type</co
>de> header for CSS style sheets? 
94        <ul>
95          <li>The correct type is <code>text/css</code>.
96          </li>
97          <li>In <a href="#What_are_the_Quirks_mode_and_the_Stand
>ards_mode.3F">the Standards mode and the Almost Standards mode</a 
>> only style sheets with the correct type are applied. 
98          </li>
99          <li>You can see the HTTP headers sent by the server by 
>using the <a class="external" href="http://livehttpheaders.mozdev 
>.org/">LiveHTTPHeaders</a> extension or by using the <a class="ex 
>ternal" href="">Web sniffer</a>. 
100          </li>
101        </ul>
102      </li>
103      <li>Class names and ids are case-sensitive.
104      </li>
105      <li>The element selectors are case-sensitive with XML.
106      </li>
107      <li>Style sheet processing instructions are only allowed in
> the prolog of XML documents. Also, they only work in XML documen 
>ts—not in documents served as <code>text/html</code>. 
108      </li>
109      <li>
110        <code>width</code> and <code>height</code> do not apply t
>o non-replaced inline elements such as (by default) <code>&lt;spa 
111      </li>
112      <li>
113        <code>text-align: center;</code> centers inline content w
>ithin a block. It does not (and should not) center the block box  
>itself. A block is centered by setting its <code>margin-left</cod 
>e> and <code>margin-right</code> to <code>auto</code> and its <co 
>de>width</code> to a value that makes the block narrower than its 
> containing block. 
114      </li>
115    </ul>
116    <p>
117      It is also possible, although not very likely, that you are
> seeing a bug. 
118    </p>
119    <h2 id=".E4.B8.BA.E4.BB.80.E4.B9.88JavaScript.E4.B8.8D.E8.83.
>BD.E5.B7.A5.E4.BD.9C.EF.BC.9F" name=".E4.B8.BA.E4.BB.80.E4.B9.88J 
120      为什么JavaScript不能工作?
121    </h2>
122    <p>
123      Some proprietary document objects such as <code>
>l</code> and <code>document.layers</code> are not part of the W3C 
> DOM and are not supported in Mozilla. (There is partial undetect 
>able support for <code>document.all</code>, though, in newer vers 
>ions of Mozilla. However, that functionality only exists for comp 
>atibility with sites authored specifically for IE. You should not 
> rely on Mozilla’s <code>document.all</code> support on new pages 
>.) The method <code>document.getElementById()</code> <a href="cn/ 
>_Elements_with_the_W3C_DOM">can be used instead</a>. 
124    </p>
125    <p>
126      In the Standards mode Mozilla does not generate implicit to
>p-level JavaScript variable bindings for elements with the <code> 
>id</code> or <code>name</code> attribute. The correct way to acce 
>ss an element by id is to call the <code>document.getElementById( 
>)</code> method with the id as a string as the argument. 
127    </p>
128    <p>
129      Also, old client sniffers can shut out new browsers. The po
>int of having a common API (the W3C DOM) is interoperability, and 
> checking for a particular browser defeats that purpose. When wor 
>king with the DOM, it is better to check for the existence of the 
> methods and objects you are planning on using. For example, the  
>existence of <code>document.getElementById()</code> can be checke 
>d as follows: 
130    </p>
131    <pre class="eval">
132if(document.getElementById) {
133   /* code that uses document.getElementById() */
136    <h2 id=".E4.B8.BA.E4.BB.80.E4.B9.88Mozilla.E4.B8.8D.E8.83.BD.
>.E5.85.B7.E6.8F.90.E7.A4.BA.EF.BC.9F" name=".E4.B8.BA.E4.BB.80.E4 
137      为什么Mozilla不能正常显示我的<code>alt</code>工具提示?
138    </h2>
139    <p>
140      Contrary to a popular belief stemming from the behavior of 
>a couple browsers running on the Windows platform, <code>alt</cod 
>e> isn’t an abbreviation for ‘tooltip’ but for ‘<i>alt</i>ernativ 
>e’. The value of the <code>alt</code> attribute is a textual <i>r 
>eplacement</i> for the image and is displayed when the image isn’ 
141    </p>
142    <p>
143      Mozilla doesn’t display the <code>alt</code> attribute as a
> tooltip, because it has been observed that doing so encourages a 
>uthors to misuse the attribute. 
144    </p>
145    <ul>
146      <li>When the alternative text is shown in a tooltip, some a
>uthors write bad <code>alt</code> texts, because they intend the  
>text as auxiliary tooltip text and not as a replacement for the i 
>mage. (‘Bad’ in the sense that the textual alternative is less us 
>eful for people who don’t see the image.) 
147      </li>
148      <li>When the alternative text is shown in a tooltip, other 
>authors don’t want to supply textual alternatives at all, because 
> they <i>don’t want</i> tooltips to appear. (Again, making things 
> harder for people who don’t see the image.) 
149      </li>
150    </ul>
151    <p>
152      There is <i>another</i> attribute that Mozilla shows as a t
>ooltip: <code>title</code>. In fact, the HTML 4.01 specification  
>suggests that the <code>title</code> attribute may be displayed a 
>s a tooltip. However, this particular display method is not requi 
>red and some other browsers show the <code>title</code> attribute 
> in the browser status bar, for example. 
153    </p>
154    <p>
155      At this point some people feel compelled to post a “But IE…
>” rant in the newsgroups or in Bugzilla. Please note that Mac IE  
>5 behaves in the same way as Mozilla when it comes to the <code>a 
>lt</code> and <code>title</code> attributes. Windows IE also show 
>s the <code>title</code> attribute in a tooltip. 
156    </p>
157    <h2 id="Does_Mozilla_support_downloadable_fonts.3F" name="Doe
158      Does Mozilla support downloadable fonts?
159    </h2>
160    <p>
161      Downloadable fonts are not supported.
162    </p>
163    <p>
164      Downloadable fonts are usually used on sites using writing 
>systems for which proper support has been missing in browsers in  
>the past. These sites (for example some Indian sites) code the te 
>xt in Latin gibberish and then use a font that to the browser and 
> operating system seems to be a Latin font but has eg. Devanagari 
> glyphs, so that when the Latin gibberish is rendered with the fo 
>nt it seems to a human reader to be intelligible text in some lan 
165    </p>
166    <p>
167      Obviously, that kind of ad hockery falls apart when Unicode
>-savvy browsers come along and render Latin gibberish as Latin gi 
>bberish (since that’s what is coded in the file from the Unicode  
>point of view). Instead of providing support for downloadable fon 
>ts, Mozilla is addressing the real issue: support for various Uni 
>code ranges. 
168    </p>
169    <p>
170      However, there are still bugs related to support for Indic 
>scripts on some platforms. For example, on Mac OS X Mozilla does  
>not use the Devanagari font that comes with the system but can us 
>e a third-party font like TITUS Cyberbit. 
171    </p>
172    <p>
173      A <i>lot</i> of work has been put into Mozilla’s Unicode su
>pport. Supporting downloadable fonts in a cross-platform way woul 
>d also be a <i>lot</i> of work and would potentially require navi 
>gating past a bunch of patents but the rewards would be small. Fo 
>r the purpose of rendering non-ISO-8859-1 characters Mozilla alre 
>ady provides Unicode support that, in the long run, is a lot bett 
>er approach than using pseudo-Latin downloadable fonts separately 
> on each site. 
174    </p>
175    <h2 id=".E4.B8.BA.E4.BB.80.E4.B9.88symbol.2Fdingbat.E5.AD.97.
>E4.BD.93.E4.B8.8D.E8.83.BD.E5.B7.A5.E4.BD.9C.EF.BC.9F" name=".E4. 
176      为什么symbol/dingbat字体不能工作?
177    </h2>
178    <p>
179      They are working. Characters in HTML 4 and XML documents ar
>e Unicode characters (even if the document has been encoded using 
> a legacy encoding for transfer)—not font glyph indexes. 
180    </p>
181    <p>
182      <code>&lt;font face="Symbol"&gt;a&lt;/font&gt;</code> 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 sho 
>uld use GREEK SMALL LETTER ALPHA (U+03B1). If you are using a leg 
>acy encoding that cannot represent that character, you can use a  
>numeric character reference: <code>&amp;#945;</code>. 
183    </p>
184    <p>
185      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 WHI 
186    </p>
187    <h2 id="Why_isn.E2.80.99t_Mozilla_rendering_my_page_as_I_inte
>browsers_should_render_pages_as_the_author_intended_anyway.21" na 
188      Why isn’t Mozilla rendering my page as I intended? So my pa
>ge isn’t standards-compliant, but good browsers should render pag 
>es as the author intended anyway! 
189    </h2>
190    <p>
191      Authors are supposed to communicate their intentions using 
>the Web standards. Otherwise, finding out the intentions of each  
>particular author would require psychic abilities which can’t be  
>implemented in software. Even in cases where a human could deduce 
> the intention, doing so in software would be very slow, bug-indu 
>cing, difficult and complicated. 
192    </p>
193    <p>
194      The usual counter argument is that there is no need to gues
>s—Mozilla should do whatever browser <var>x</var> does (where <va 
>r>x</var> is the favorite non-Mozilla browser of whoever is prese 
>nting the counter argument). However, doing whatever browser <var 
>>x</var> does in every conceivable case isn’t simple at all, even 
> though it might appear to be simple when presented as a passing  
195    </p>
196    <p>
197      Different people have different ideas about what <var>x</va
>r> should be. The second problem is that Web authors are very cre 
>ative in coming up with different ways of deviating from the stan 
>dards. In fact, since the input to the browser can be of arbitrar 
>y length, there is no upper bound for the number of distinct ways 
> of deviating from the standards. Therefore, it is impossible to  
>test whether Mozilla reacts exactly like browser <var>x</var> to  
>every possible input. (Likewise, there is no upper bound for the  
>number of ways different features of the standards themselves can 
> be combined, which makes software quality assurance challenging. 
198    </p>
199    <p>
200      Also, the ways in which browser <var>x</var> reacts to some
> standards-incompliant input are not all intentional. Some of the 
> reactions are due to unknown and unintentional interactions with 
>in a complex program. Even if you had the source code for browser 
> <var>x</var>, you couldn’t change <i>anything</i> without riskin 
>g changing one or more of the unknown and unintentional interacti 
>ons within the program. 
201    </p>
202    <p>
203      The usual counter argument is that Mozilla doesn’t need to 
>match the behavior of browser <var>x</var> in every possible case 
> but only in the alleged <i>common</i> cases. However, it turns o 
>ut Mozilla is doing that already. Mozilla’s Standards mode is, ob 
>viously, already compatible with other browsers that implement th 
>e same standards reasonably correctly. On the other hand, Mozilla 
>’s quirks mode already accommodates common non-standardisms that  
>are due to the behaviors of common legacy browsers. 
204    </p>
205    <p>
206      Instead of putting time and effort into reverse-engineering
> and cloning legacy browsers, it makes more sense to focus on imp 
>lementing standards. Standards (when implemented by others as wel 
>l) promote interoperability better than cloning legacy software b 
>ug by bug. 
207    </p>
208    <p>
209      Also, HTML was designed to adapt to different presentation 
>media, so different presentations of the same document are to be  
210    </p>
211    <h2 id="According_to_the_Accept_header.2C_Mozilla_prefers_app
>on.2Fxhtml.2Bxml_to_Mozilla.3F" name="According_to_the_Accept_hea 
212      According to the <code>Accept</code> header, Mozilla prefer
>s <code>application/xhtml+xml</code> over <code>text/html</code>. 
> Should I serve <code>application/xhtml+xml</code> to Mozilla? 
213    </h2>
214    <p>
215      The preference for <code>application/xhtml+xml</code> was a
>dded to the <code>Accept</code> header in order to enable the ser 
>ving of MathML to both Mozilla and IE with Apache without scripti 
>ng back when the MathPlayer plug-in for IE did not handle <code>a 
216    </p>
217    <p>
218      If your document mixes MathML with XHTML, you should use <c
>ode>application/xhtml+xml</code>. If you’re developing XHTML Basi 
>c content for mobile devices and are serving it as <code>applicat 
>ion/xhtml+xml</code>, you can serve it as <code>application/xhtml 
>+xml</code> to Mozilla as well without taking special steps (exce 
>pt perhaps providing a different style sheet for the <code>handhe 
>ld</code> and <code>screen</code> media). 
219    </p>
220    <p>
221      However, if you are using the usual HTML features (no MathM
>L) and are serving your content as <code>text/html</code> to othe 
>r browsers, there is no need to serve <code>application/xhtml+xml 
></code> to Mozilla. In fact, in versions prior to Gecko 1.9/Firef 
>ox 3, doing so would deprive the Mozilla users of incremental dis 
>play, because incremental loading of XML documents has not been i 
>mplemented in those versions. Serving valid HTML 4.01 as <code>te 
>xt/html</code> ensures the widest browser and search engine suppo 
222    </p>
223    <p>
224      There is a fad of serving <code>text/html</code> to IE but 
>serving the same markup with no added value as <code>application/ 
>xhtml+xml</code> to Mozilla. This is usually done without a mecha 
>nism that would ensure the well-formedness of the served document 
>s. Mechanisms that ensure well-formed output include serializing  
>from a document tree object model (eg. DOM) and XSLT transformati 
>ons that do not disable output escaping. When XHTML output has be 
>en retrofitted to a content management system that was not design 
>ed for XML from the ground up, the system usually ends up discrim 
>inating Mozilla users by serving tag soup labeled as XML to Mozil 
>la (leading to a parse error) and serving the same soup labeled a 
>s tag soup to IE (not leading to a parse error). 
225    </p>
226    <h2 id="MIME.E7.B1.BB.E5.9E.8B.E4.B8.BAapplication.2Fxhtml.2B
>0.E4.B9.88.E4.B8.8D.E5.90.8C.EF.BC.9F" name="MIME.E7.B1.BB.E5.9E. 
227      MIME类型为<code>application/xhtml+xml</code>的文档和类型为<code>text/
228    </h2>
229    <ul>
230      <li>An XML parser (expat) is used instead of the tag soup p
231        <ul>
232          <li>Most well-formedness constraints are enforced. (Cur
>rently Mozilla does not catch character encoding errors, because  
>the document is re-encoded using a lenient encoding converter bef 
>ore the document reaches the XML parser. This is a bug.) Despite  
>common allegations to the contrary, the document is <i>not</i> ch 
>ecked for validity. 
233          </li>
234          <li>Externally defined character entities other than th
>e five pre-defined ones (<code>&amp;lt;</code>, <code>&amp;gt;</c 
>ode>, <code>&amp;amp;</code>, <code>&amp;quot;</code> and <code>& 
>amp;apos;</code>) are only supported if the document references a 
> public identifier for which there is a mapping in Mozilla’s pseu 
>do-DTD catalog and the document has not been declared standalone. 
235          </li>
236          <li>In older versions of Mozilla as well as in old Mozi
>lla-based products, there is no pseudo-DTD catalog and the use of 
> externally defined character entities (other than the five pre-d 
>efined ones) leads to an XML parsing error. There are also other  
>XHTML user agents that do not support externally defined characte 
>r entities (other than the five pre-defined ones). Since non-vali 
>dating XML processors are not required to support externally defi 
>ned character entities (other than the five pre-defined ones), th 
>e use of externally defined character entities (other than the fi 
>ve pre-defined ones) is inherently unsafe in XML documents intend 
>ed for the Web. The best practice is to use straight UTF-8 instea 
>d of entities. (Numeric character references are safe, too.) 
237          </li>
238          <li>
239            <code>document.write()</code> is not supported. The s
>tream that is going into the parser can’t be tampered with in mid 
240          </li>
241          <li>Things that look like XML comments are treated as X
>ML comments—even inside <code>script</code> or <code>style</code> 
> elements. 
242          </li>
243          <li>Elements need to be in the XHTML namespace in order
> to be treated as XHTML elements. 
244          </li>
245          <li>
246            <code>meta</code> tags are not examined for character
> encoding information. 
247          </li>
248          <li>
249            <code>tbody</code>, <code>head</code>, <code>body</co
>de>, and <code>html</code> are not inferred if the tags are not e 
>xplicitly present. 
250          </li>
251          <li>CDATA sections are supported.
252          </li>
253          <li>XML empty element notation (<code>&lt;foo/&gt;</cod
>e>) is supported. 
254          </li>
255          <li>White space characters in attribute values are <a c
>lass="external" href=""> 
>normalized</a> to spaces at parse time, so the original white spa 
>ce never makes it to the DOM. This affects data round tripping us 
>ing hidden form <code>input</code>s. 
256          </li>
257        </ul>
258      </li>
259      <li>In versions prior to Gecko 1.9/Firefox 3, the document 
>is not loaded and rendered incrementally. That is, the document i 
>s displayed only after the entire document has been received and  
>parsed. Contrary to a common misguided assertion, this is not don 
>e in response to a requirement set forth in any W3C specification 
>. In particular, the XML specification does <i>not</i> require th 
>e entire document to be checked for errors before rendering can s 
>tart. 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. 
260      </li>
261      <li>The layout mode is the (Full) Standards Mode regardless
> of doctype. 
262      </li>
263      <li>CSS works according to the XML+CSS rules.
264        <ul>
265          <li>HTML-specific CSS exceptions do not apply. For exam
>ple, the <code>body</code> element gets no special treatment. 
266          </li>
267          <li>CSS selectors are case-sensitive.
268          </li>
269        </ul>
270      </li>
271      <li>The DOM is in the XML mode.
272        <ul>
273          <li>Namespace-aware variants of methods need to be used
> when working with elements (eg. <code>createElementNS()</code> i 
>nstead of <code>createElement()</code>). 
274          </li>
275          <li>In older versions of Mozilla, the <code>document</c
>ode> object does not implement the <code>HTMLDocument</code> inte 
276          </li>
277          <li>Element and attribute names are not normalized to u
>pper case. 
278          </li>
279          <li>In older versions (including Firefox 1.0), content 
>cannot be added using <code>innerHTML</code>. 
280          </li>
281        </ul>
282      </li>
283      <li>Other namespaces are supported.
284        <ul>
285          <li>MathML
286          </li>
287          <li>Simple XLink
288          </li>
289          <li>SVG (in SVG-enabled builds only)
290          </li>
291          <li>XUL (Please note that XUL is Mozilla-specific and, 
>therefore, using it on the public Web causes interoperabilty prob 
292          </li>
293        </ul>
294      </li>
295      <li>
296        <code>xml:base</code> is observed when following links.
297      </li>
298      <li>Style sheets can be references using processing instruc
299      </li>
300    </ul>
301    <h2 id=".E6.88.91.E6.B2.A1.E6.9C.89.E6.89.BE.E5.88.B0.E9.97.A
>.B8.AE.E5.8A.A9.EF.BC.9F" name=".E6.88.91.E6.B2.A1.E6.9C.89.E6.89 
302      我没有找到问题的答案,我还可以到哪里寻找帮助?
303    </h2>
304    <p>
305      Try asking in the newsgroup relevant to your question in th
>e comp.infosystems.www.authoring.* hierarchy or, if your question 
> is about JavaScript/ECMAScript or the DOM, in comp.lang.javascri 
>pt (after reading the group FAQs first, of course). Please do not 
> ask Web authoring questions in the newsgroups intended for discu 
>ssion about the development of Mozilla. 
306    </p>
307    <ul>
308      <li>
309        <a class="external" href="
>l/">comp.infosystems.www.authoring.html Web Authoring FAQ</a> 
310      </li>
311      <li>
312        <a class="external" href="
>ml">comp.infosystems.www.authoring.stylesheets FAQ</a> 
313      </li>
314      <li>
315        <a class="external" href="
>ml">ciwas stylesheet authoring FAQ</a> 
316      </li>
317      <li>
318        <a class="external" href="">
>comp.lang.javascript FAQ</a> 
319      </li>
320    </ul>
321    <div class="originaldocinfo">
322      <h2 id=".E5.8E.9F.E5.A7.8B.E6.96.87.E6.A1.A3.E4.BF.A1.E6.81
>.AF" name=".E5.8E.9F.E5.A7.8B.E6.96.87.E6.A1.A3.E4.BF.A1.E6.81.AF 
323        原始文档信息
324      </h2>
325      <ul>
326        <li>作者: <a class="link-mailto" href="mailto:hsivonen@iki.
>fi">Henri Sivonen</a> (Please, no authoring questions to this add 
327        </li>
328        <li>最后更新时间: May 12, 2007
329        </li>
330        <li>版权信息: Henri Sivonen
331        </li>
332      </ul>
333    </div>{{ languages( { "ja": "ja/Mozilla_Web_Developer_FAQ", "
>en": "en/Mozilla_Web_Developer_FAQ" } ) }}