-
Notifications
You must be signed in to change notification settings - Fork 3
/
README-style.html
563 lines (507 loc) · 26.5 KB
/
README-style.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<link rel="top" title="Home" href="http://www.mozilla.org/">
<link rel="stylesheet" type="text/css" href="css/print.css" media="print">
<link rel="stylesheet" type="text/css" href="css/base/content.css" media="all">
<link rel="stylesheet" type="text/css" href="css/cavendish/content.css" title="Cavendish" media="screen">
<link rel="stylesheet" type="text/css" href="css/base/template.css" media="screen">
<link rel="stylesheet" type="text/css" href="css/cavendish/template.css" title="Cavendish" media="screen">
<link rel="icon" href="images/mozilla-16.png" type="image/png">
<title>mozilla.org Documentation Style Guide</title>
<script src="__utm.js" type="text/javascript"></script>
</head>
<body id="www-mozilla-org" class="deepLevel">
<div id="container">
<p class="important">You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is
highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If
there are any pages on this archive site that you think should be added back to www.mozilla.org, please <a
href="https://bugzilla.mozilla.org/enter_bug.cgi?product=Websites&component=www.mozilla.org">file a bug</a>.</p>
<p class="skipLink"><a href="#mainContent" accesskey="2">Skip to main content</a></p>
<div id="header">
<h1><a href="/" title="Return to home page" accesskey="1">Mozilla</a></h1>
<ul>
<li id="menu_aboutus"><a href="about/" title="Getting the most out of your online experience">About</a></li>
<li id="menu_developers"><a href="developer/" title="Using Mozilla's products for your own applications">Developers</a></li>
<li id="menu_store"><a href="http://store.mozilla.org/?r=mozorg1" title="Shop for Mozilla products on CD and other merchandise">Store</a></li>
<li id="menu_support"><a href="support/" title="Installation, trouble-shooting, and the knowledge base">Support</a></li>
<li id="menu_products"><a href="products/" title="All software Mozilla currently offers">Products</a></li>
</ul>
<form id="searchbox_002443141534113389537:ysdmevkkknw" action="http://www.google.com/cse" title="mozilla.org Search">
<div>
<label for="q" title="Search mozilla.org's sites">search mozilla:</label>
<input type="hidden" name="cx" value="002443141534113389537:ysdmevkkknw">
<input type="hidden" name="cof" value="FORID:0">
<input type="text" id="q" name="q" accesskey="s" size="30">
<input type="submit" id="submit" value="Go">
</div>
</form>
</div>
<hr class="hide">
<div id="mBody">
<div id="side">
<ul id="nav">
<li><a title="Roadmap" href="roadmap.html"><strong> Roadmap</strong></a></li>
<li><a title="Projects" href="projects/"><strong> Projects</strong></a></li>
<li><a title="For developers" href="developer/"><strong> Coding</strong></a>
<ul>
<li><a title="Module Owners" href="owners.html"> Module Owners</a></li>
<li><a title="Hacking" href="hacking/"> Hacking</a></li>
<li><a title="Get the Source" href="http://developer.mozilla.org/en/docs/Download_Mozilla_Source_Code"> Get the Source</a></li>
<li><a title="Building Mozilla" href="http://developer.mozilla.org/en/docs/Build_Documentation"> Build It</a></li>
</ul>
</li>
<li><a title="Testing" href="quality/"><strong> Testing</strong></a>
<ul>
<li><a title="Downloads of mozilla.org software releases" href="download.html"> Releases</a></li>
<li><a title="Latest mozilla builds for testers" href="developer/#builds"> Nightly Builds</a></li>
<li><a title="For testers to report bugs" href="https://bugzilla.mozilla.org/"> Report A Problem</a></li>
</ul>
</li>
<li><a title="Tools for mozilla developers" href="tools.html"><strong> Tools</strong></a>
<ul>
<li><a title="Bug tracking system for mozilla testers." href="https://bugzilla.mozilla.org/"> Bugzilla</a></li>
<li><a title="Latest status of mozilla builds" href="http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox"> Tinderbox</a></li>
<li><a title="Latest checkins" href="http://bonsai.mozilla.org/cvsqueryform.cgi"> Bonsai</a></li>
<li><a title="Source cross reference" href="http://lxr.mozilla.org/seamonkey/"> LXR</a></li>
</ul>
</li>
<li><a title="Frequently Asked Questions." href="faq.html"><strong> FAQs</strong></a></li>
</ul>
</div>
<hr class="hide">
<div id="mainContent">
<h1>mozilla.org Documentation Style Guide</h1>
<address class="author">Jamie Zawinski
and <a href="http://fantasai.inkedblade.net/contact">fantasai</a>
</address>
<p>Here are some basic style guidelines for writing content to be
hosted on mozilla.org. Some are important, some are arbitrary, but
please follow these guidelines in the name of consistency.</p>
<ol class="toc">
<li><a href="#adding">Adding Files</a>
<ol>
<li><a href="#filenames">Filenames</a>
<li><a href="#location">Location</a>
</ol>
<li><a href="#linking">Linking, Anchors, and URLs</a>
<li><a href="#code">Page Code</a>
<ol>
<li><a href="#format">Code Format</a>
<li><a href="#validation">Validation</a>
<li><a href="#markup">Markup</a>
<li><a href="#style">Adding Style</a>
</ol>
<li><a href="#content">Content</a>
<ol>
<li><a href="#meta">Meta Information</a>
<li><a href="#writing-form">Writing Form</a>
<li><a href="#writing-style">Writing Style</a>
</ol>
</ol>
<div class="section">
<h2><a name="adding">Adding Files</a></h2>
<div class="section">
<h3><a name="filenames">Filenames</a></h3>
<ul>
<li><p><strong>Use descriptive file names.</strong> The ideal filename
is succinct, specific enough to be descriptive, but general enough to
accommodate change or expansion (e.g. becoming a folder). Don't just
copy the page's title, as it isn't always appropriate for a
filename.</p>
<li><p><strong>Avoid abbrev.</strong> It makes the URL that much
harder to read and remember. We are not limited to 8.3 names, so make
the file names as long as necessary (and no longer).</p>
<li><p><strong>Don't use page/part numbers.</strong> Don't name
Chapter 4 <code class="filename">ch4</code>, because someday you may
want to insert another chapter between Chapter 4 and Chapter 5. Name
it after the chapter's title instead; this is also more descriptive.
The only numbers in filenames should be dates and application version
numbers.</p>
<li><p><strong>Filenames are lowercase.</strong> It makes URLs
consistent throughout the site, and it's easier to remember the URL
when case isn't an issue. The exception is documenting code; a doc on
<code>nsFoo</code> should be <code class="filename">nsFoo.html</code>,
not <code class="filename">nsfoo.html</code>, to match the code's casing.
In no event should you have two files in the same directory that differ
only in case: don't have <code class="filename">Foo</code> and <code
class="filename">FOO</code>.</p>
<li><p><strong>Hyphenate.</strong> Don't use StudlyCaps to separate
words. You can't use uppercase anyway. Use hyphens. Don't use
underscores to separate words; underscores don't show up in
underlined text.</p>
<li><p><strong>Don't use funny characters in file names.</strong>
Stick to alphanumerics and hyphen. Our server is a Unix machine, and
life gets somewhat more difficult if you use files with spaces,
ampersands, quotes, and so on in their names. <code
class="filename">this-and-that</code> is good. <code
class="filename">This&That.HTM</code> is bad. You will royally
screw anyone using a Macintosh (and Windows, I think) if you use
colons, so don't do that.</p>
<li><p><strong>Avoid redundancy; don't over-qualify.</strong> <code
class="filename">dom/domref/dom-window-ref</code> is too much—<code
class="filename">dom/reference/window</code> is better.</p>
</ul>
</div>
<div class="section">
<h3><a name="location">Location</a></h3>
<ul>
<li><p><strong>Pick (or create) the most logical location for the
document.</strong> Get a feel for the site's organization and fit the
document where it most belongs. <!-- Look at the site through it's tree
structure rather than through the site navigation to get a better
idea of where things go. The URI you're assigning to that file is
more or less permanent, so it has to be forwards-compatible. Choose
well, and run the new location past someone else before
publicizing.--></p>
<li><p><strong>Use subfolders.</strong> If you have a few files that
belong together, or <em>if you expect to</em>, make a subfolder that
contains all the related files.</p>
<!--
<li><p><strong>You can change a file to a directory!</strong> If
something logically belongs under what is right now a file, make it
the <code class="filename">index.html</code> of a folder with the
same name and put your file inside that folder. So if you want to add
a related page, or split a long page into several sub-pages, or add
an image, you can do that.</p>
-->
<li><p><strong>A file's images go in its folder.</strong> Don't create
an "images" folder. For example, a <code
class="filename">roadmap/</code> (<code
class="filename">roadmap/index.html</code>) would put its diagram at
<code class="filename">roadmap/diagram</code>. If the same image is
used in several pages, then put it in the deepest common
folder.</p>
</ul>
</div>
</div>
<div class="section">
<h2><a name="linking">Linking, Anchors, and URLs</a></h2>
<ul>
<li><p><strong>Don't point to <code class="filename">index.html</code>
directly.</strong> Point to the folder rather than the <code
class="filename">index.html</code> file.</p>
<li><p><strong>No file extensions on DevMo.</strong> Drop the
file extension when linking to files on developer.mozilla.org.
This way we can change the format of a file without changing the
content. Also, files can expand to become directories later on.</p>
<li><p><strong>Use relative links whenever practical.</strong> This
reflects the relationship between the two documents, and the link
won't break if, for instance, someone copies the documents to a
test site.</p>
<li><p><strong>Use <code class="markup"><a
name="anchor-name"></code>.</strong>
Linking to an ID isn't supported in many browsers. Also, anchors
should, like filenames, be lower case.</p>
<li><p><strong>Anchors should not be empty.</strong> They should
enclose some relevant fragment of text. For example, place the
anchor tags around the full text of a heading to create an anchor
for that section. If this is done right, highlighting all anchors'
text can be a meaningful and useful styling.</p>
</ul>
</div>
<div class="section">
<h2><a name="code">Page Code</a></h2>
<div class="section">
<h3><a name="format">Code Format</a></h3>
<ul>
<li><p><strong>Use the ISO-8859-1 aka. Latin-1 character
encoding.</strong> Represent characters that are outside the
ISO-8859-1 repertoire (eg. typographically correct dashes and quotes)
as decimal numeric character references. For example, encode the em
dash (—) as <code>&#8212;</code>.</p>
<p>Do not use references to Windows CP1252 code points even if they
appear to work. That is, do not use <code>&#151;</code> for em
dash (or any other references to the 128…159 range).</p></li>
<li><p><strong>Use short lines.</strong> Some HTML editors like to
produce documents that only insert line breaks in the HTML source at
the ends of paragraphs. Don't do that. Use editors that give the HTML
source sensibly short lines. If every paragraph is one long line,
then <span class="command">diff</span> is mostly useless (since
<span class="command">diff</span> is line-oriented.) Also there's
always the chance that some random Unix utility is going to blow a
buffer. Don't go there.</p>
<li><p>Lowercase is preferred (but not required) for HTML tags and
attributes.</p>
<li><p><strong>Don't use <code
class="markup">&nbsp;</code> unnecessarily.</strong> The fact
of life of HTML is that sentences don't end in two spaces. Accept
it. Don't try to work around it by using <code class="markup">&nbsp;</code>.
Corollary: use <code class="markup"><pre></code> if you need
to; not <code class="markup"><tt></code> and a bucketful of
non-breaking spaces. <!-- Note that the site stylesheets already assign
no-breaking rules to code and filenames
and the like, so if you mark the text up properly, things will take
care of themselves. --></p>
</ul>
</div>
<div class="section">
<h3><a name="validation">Validation</a></h3>
<p><strong>All new pages should validate as HTML 4.01 Strict</strong>
using the <a href="http://validator.w3.org/">W3C Validator</a>. This
ensures that the page doesn't have syntax errors, that it can be
processed by all sorts of more obscure browsers, and that it doesn't
use the presentational markup deprecated in HTML 4.0. Also, we're
making one of the most standards-compliant browsers around. It would
be bad show to have an incompliant website.</p>
<p>You can validate against HTML 4.01 Transitional instead, but only
if there's a good reason. (The <code class="markup"><font></code>
tag is not a good reason.)</p>
<!--
<p>Any exceptions to this rule (e.g. <code
class="markup"><textarea wrap='x'></code>) must be approved by
the <a href="mailto:[email protected]">site webmaster</a>.</p>
-->
</div>
<div class="section">
<h3><a name="markup">Markup</a></h3>
<ul>
<li><p><strong class="very-strong">Use semantic markup.</strong>
Semantic markup explains why something should be styled rather than
how it should be styled. This lets different style sheets and
different browsers present the same idea differently and still be
correct. <code class="markup"><p></code>, <code
class="markup"><code></code>, and <code
class="markup"><em></code> are semantic elements. <code
class="markup"><b></code> and <code
class="markup"><i></code> are not. Stylistic information
belongs in the style sheet, not the markup. Nearly everything else is
corollary. So:</p>
<ul>
<li>Presentational markup is <em>discouraged</em> on mozilla.org even
if it's allowed in HTML 4.01 Strict.
<li>Use <code class="markup"><p></code> to <em>enclose</em>
paragraphs, not <code class="markup"><br></code> or <code
class="markup"><p></code> to separate them.
<li>Use <a
href="http://www.w3.org/TR/html4/struct/global.html#h-7.5.5">Headings</a>
for headings, not an arbitrary combination of <code
class="markup"><b></code>, <code
class="markup"><big></code>, and/or <code
class="markup"><hr></code>.
<li>Don't use tables for layout. Tables are for tabular data. Text
columns are not tabular data.
</ul>
<p>You are encouraged to use the markup conventions defined in our
<a href="/contribute/writing/markup">Markup Reference</a> if you want
a richer presentation.</p>
<div class="note">Recommended Reading: <a
href="http://www.oasis-open.org/docbook/documentation/reference/html/ch01.html#AEN367">"Structured
and Semantic Markup"</a> from <cite>DocBook: The Definitive
Guide</cite> (in Chapter 1) It's about 5 pages in the print
version (4 pages printed), and worth the few minutes it takes to
read.</div>
</ul>
</div>
<div class="section">
<h3><a name="style">Adding Style</a></h3>
<p><strong>Check the classes defined in the <a href="/contribute/writing/markup">Markup
Reference</a> first</strong>. The Reference defines a number of
commonly-used classes that already have styles associated with them,
so you may not need to write any style rules. Also, if you think
something's missing from the Reference, file a bug asking fantasai to
add it instead of working around the deficiency in your corner of the
site.</p>
<h4>Localized Style Rules</h4>
<p>Stylistic information is centralized into several site-wide style
sheets. This way, the site has a coherent look and feel and the
formatting conventions are consistent. However, the site style sheets
can't handle everything, so some pages may need to incorporate
additional rules for local use or to handle specific page
layouts.</p>
<ul>
<li><p><strong>Don't depend on any particular presentation for an
element or class.</strong> HTML allows for alternate styles, which
means different visitors can use different style sheets. You can
depend on a set of sensible style rules, but don't depend on, e.g.
all filenames being rendered in a monospaced font. A style might
decide to make them italic serif.</p>
<li><p><strong>No inline styles.</strong> The <code>style</code>
attribute is banned from mozilla.org pages with two exceptions:
<code>float</code> and <code>clear</code>. Use semantic markup and
either <code class="markup"><link></code>ed style sheets or
<code class="markup"><style></code>.</p>
<li><p>If the same rules are used on more than one page, put them in a
separate style sheet file placed in the deepest folder common to
these files.</p>
<li><p><strong>Avoid creating presentational classes.</strong>
<code>class="center"</code> is no better than
<code>align="center"</code>.</p>
<li><p><strong>Do not set <code>font-family</code>.</strong> The font
is handled by site style sheets. Other font properties are allowed,
but don't change the font for the entire page (e.g. don't set
<code>font-size: small</code> on <code
class="markup"><body></code>).</p>
<li><p><strong>Avoid setting any colors</strong> on individual pages.
</p>
<p>If for some reason you need to set specific colors:</p>
<ul>
<li>Make sure you reset all the element's children as well.
<li>Make color rules <code>!important</code>.
<li>Never set a text color without also setting a background color,
and vice versa.
<li>Use the <code>background</code> shorthand property, not
<code>background-color</code> or <code>background-image</code>.
<li>If you're using a background image, also set a matching
background color.
</ul>
<div class="example">
<pre class="code"><!--
-->.class {
<!-- --> color: black !important;
<!-- --> background: gray url(slate.gif) !important;
<!-- -->}
<!-- -->.class * {
<!-- --> color: inherit !important;
<!-- --> background: transparent !important;
<!-- -->}<!--
--></pre>
</div>
<li><p><strong>Make sure multiple window sizes work.</strong> Resize
the window, both narrow and wide. Another common mistake made by
people using HTML editors is the presence of random <code
class="markup"><br></code> tags at the ends of lines.</p>
<li><p><strong>Pages must look decent in NS4+, MSIE4+, and
Mozilla.</strong> Try to avoid exposing bugs in their CSS support; at
the very least, make the page legible. A very useful resource is Eric
Meyer's <a
href="http://devedge.netscape.com/library/xref/2003/css-support/css1/mastergrid.html">Master
Compatibility Chart</a>. If you must, block a problem browser from
accessing your style sheet—but try to do it without scripting, ok?
For example, @import a style sheet NS4.x shouldn't see or block out
sections with the <a href="http://css-discuss.incutio.com/?page=CaioHack">comment
hack</a>.</p>
</ul>
</div>
</div>
<div class="section">
<h2><a name="content">Content</a></h2>
<div class="section">
<h3><a name="meta">Meta Information</a></h3>
<ul>
<li><p><strong>Each document's author should be listed at the
top.</strong> If it's a communal document, or an index, it's ok to
leave the author off. But if it's a document with real content, it
should list a way of contacting the author and providing feedback.
Anonymity is bad.</p>
<p> Look at the top of the document you're reading right now for the
suggested format.</p>
<li><p><strong>Add meta <code>description</code></strong> to help indexing.
The description text should be an <em>abstract</em> of the page.
If you're adding a <code>keywords</code> tag as well, pick keywords
that you would use if you forgot the URI and were searching for the page,
not just any remotely relevant word that comes to mind.</p>
<div class="example">
<pre class="code">
<!-- --><meta name="description"
<!-- --> value="Rules and guidelines for writing documents on
<!-- --> mozilla.org"
</pre>
</div>
<li><p><strong>Use <code class="markup"><link></code> elements
to link to related documents.</strong> It will improve the navigation
for visitors using a browser (like Mozilla) that supports this HTML
2.0 feature. <code class="markup"><link></code> denotes
relationships between the entire page and another resource (as
opposed to <code class="markup"><a></code>, which is a context
link; the relationship denoted applies to the immediate context of
the anchor element). <!-- explanation courtesy of Ian Hickson and
Christopher Hoess - see bug 87428. --></p>
</ul>
</div>
<div class="section">
<h3><a name="writing-form">Writing Form</a></h3>
<ul>
<li><p><strong>Avoid all caps.</strong> If the uppercase is used for
style (e.g. for <strong class="very-strong">emphasis</strong>), let the
style sheet handle it. If you are talking about SOME_RANDOM_C_TOKEN,
make sure you mark it with <code class="markup"><code></code>.</p>
<li><p><strong>mozilla.org is spelled in lowercase.</strong> The name
of the application is <strong>Mozilla</strong>. It is a proper noun,
and is therefore capitalized. The name of the organization is
<strong>mozilla.org</strong>. It is a host name, and therefore, is
lowercase. Even if it is at the beginning of a sentence, it should
always be lowercase. If it bothers you to begin a sentence with a
lowercase word, rephrase the sentence. (It's not hard.) Never type
Mozilla.org.</p>
<li><p><strong>Use proper capitalization for titles and
headings.</strong> This keeps capitalization consistent throughout
mozilla.org. Also, although CSS can manipulate case, it can't do
proper capitalization—so that needs to be written in.</p>
<li><p><strong>Use a spell checker.</strong> Say no more.</p>
</ul>
</div>
<div class="section">
<h3><a name="writing-style">Writing Style</a></h3>
<ul>
<li><p><strong>Eschew marketing obfuscation.</strong> These are
technical documents, folks. One of the things that people seem to like
best about the existing content on mozilla.org is that it is written
by people, for people, without bluster or self-promotion.</p>
<p>When describing something, don't tell people how great it is. Don't
tell them how useful it is. Tell them what it does. Tell them what
it's for.</p>
<p>Don't use buzzwords. Instead, say what you mean. Never use a long
word where a short one would do. If it's possible to cut a word out,
cut it out.</p>
<p>Read George Orwell's <a
href="http://www.k-1.com/Orwell/index.cgi/work/essays/language.html"><cite>Politics
and the English Language</cite></a>. Read it again. Have it tattooed
on the inside of your eyelids.</p>
<li><p><strong>Separate technical and religious topics.</strong> It is
ok to publish documents which advocate potentially controversial ideas
or approaches. However, it is generally better if such advocacy not be
in the same document as technical information. For example, a document
explaining what you have to do in order to successfully use C++ is a
good thing; and a document arguing that you should not use C++ is also
a good thing; however, they should not be the same document, because
the controversial part might cause the readers to disregard the
factual, non-controversial part, and miss out on important
information.</p>
<li><p><strong>Speak for yourself.</strong> You don't speak for
mozilla.org. Don't make promises about what mozilla.org will or will
not do in the future. Hedge your bets with words like might or (sometimes)
probably.</p>
<p>Be careful with the word we. It would be bad if you made some assertion
about what mozilla.org (as a whole) believes or desires or likes, only to
find that there are others in the organization who disagree.</p>
<p>Also, if you are employed to work on Mozilla, keep in mind that you
likely wear two hats: your company hat, where you are concerned with
shipping branded software; and your mozilla.org hat, where you are
concerned with shipping source code on which other developers can base
their own works. These two jobs are not the same, and you should be
careful not to conflate the two.</p>
<li><p><strong>Don't play lawyer.</strong> Sometimes you may find
yourself writing something about what is or is not allowed by the
terms of the NPL, MPL, or some other license. Be very, very careful.
It's probably best to say nothing at all, but if you must, you should
defer to the authority of the license itself. Unless you actually
<em>are</em> a lawyer, you're not qualified to interpret what it says,
and you don't want to inadvertently say something that might get
either mozilla.org or your employer into trouble.</p>
</ul>
</div>
</div>
<hr class="hide">
</div>
</div>
<div id="footer">
<ul>
<li><a href="sitemap.html">Site Map</a></li>
<li><a href="security/">Security Updates</a></li>
<li><a href="contact/">Contact Us</a></li>
<li><a href="foundation/donate.html">Donate</a></li>
</ul>
<p class="copyright">
Portions of this content are © 1998–2009 by individual mozilla.org
contributors; content available under a Creative Commons license | <a
href="http://www.mozilla.org/foundation/licensing/website-content.html">Details</a>.</p>
<p>
<span>Last modified May 22, 2004</span>
<span><a href="http://bonsai-www.mozilla.org/cvslog.cgi?file=mozilla-org/html/README-style.html&rev=&root=/www/">Document History</a></span>
</p>
</div>
</div>
</body>
</html>