We're looking for a user researcher to understand the needs of developers and designers. Is this you or someone you know? Check out the post: https://mzl.la/2IGzdXS

この翻訳は不完全です。英語から この記事を翻訳 してください。

整理され、標準化され、読みやすい書き方でドキュメンテーションを示すために、Mozilla Developer Netework スタイルガイドはテキストがどのような体系、表記、書式などに従うべきなのかを説明します。これらは厳密な規則というのではなくガイドラインです。形式よりも内容が重要であり、このため貢献する前にガイドラインを学ばなければならないと重荷に感じたりしないでください。とはいえ、真面目な他のボランティアが、あとであなたの成果をガイドラインに添うように書き換えても、びくびくしたり、ぎょっとしたりもしないでください。

あるタイプのページをどのように構成するべきかについて詳細を知りたければ、MDN ページレイアウトガイドを参照してください。



MDN 以外のサイトの記事での標準的なスタイルを知りたければ、One Mozilla style guideを参照してください。


一般的なスタイルガイドのやり方に習って、とても基本的な文章上の取り決めから始めて、ドキュメンテーションを首尾一貫したものにしましょう。以下のセクション では、その基本のアウトラインを示します。


ページタイトルは検索結果に利用されます。またページ上部でページ間の階層構造を示すパンくずリストのために利用されます。ページタイトルは(ページのトップと検索結果に表示され)ページの「スラグ」とは違っていても構いません。「スラグ」とは、ページのURLの "<locale>/docs/" に続いている部分のことです。


ページタイトルセクションの見出しはセンテンス スタイルの大文字化(文頭と固有名詞の初めの1字だけを大文字にします)を用いるべきです。一般的なヘッドライン スタイルは用いません。

  • 正しい: "A new method for creating JavaScript rollovers"
  • 間違い: "A New Method for Creating JavaScript Rollovers"







例えば、JavaScript ガイド を見てみましょう。以下のような構造になっています。



General article content guidelines

When writing any document, it's important to know how much to say. If you ramble on too long, the article becomes tedious to read and nobody will use it. Getting the amount of coverage right is important for several reasons. Among those reasons: to ensure that the reader finds the information they truly need, and to provide enough quality material for search engines to adequately analyze and rank the article. We'll discuss the former (providing the information the reader may need) here. To learn a little about ensuring that pages are properly classified and ranked by search engines, see the article How to write for SEO on MDN.

The goal is to write pages that include all the information that readers may need without going on too long about it all. We have a few recommendations in this area.

Consider your audience

Keep in mind that these are guidelines. Some of these tips may not apply in every case. Certainly keep your article's audience in mind. An article on advanced network techniques likely doesn't need to go into as much detail about basic networking concepts as the typical article on networking code, for instance.

Provide a useful summary

Make sure the article's summary—that is, the opening paragraph or paragraphs before the first heading—provides enough information for the reader to understand if the article is likely to be covering what they're interested in reading about. In guide or tutorial content, the summary should let the reader know what topics will be covered and what they're already expected to know, if anything. It should mention the technology, technologies, and/or APIs that are being documented or discussed, with links to those, and it should offer hints as to the situations in which the article's contents might be useful.




Example: Too long!

Here, we've updated the summary, but now it's far too long. Too much detail is included, and the text gets far too much into other methods and properties. Instead, the summary should focus on the strokeText() method, and should refer to the appropriate guide where the other details are offered.

When called, the Canvas 2D API method CanvasRenderingContext2D.strokeText() strokes the characters in the specified string beginning at the coordinates specified, using the current pen color. In the terminology of computer graphics, "stroking" text means to draw the outlines of the glyphs in the string without filling in the contents of each character with color.

The text is drawn using the context's current font as specified in the context's font property.

The placement of the text relative to the specified coordinates are determined by the context's textAlign, textBaseline, and direction properties. textAlign controls the placement of the string relative to the X coordinate specified; if the value is "center", then the string is drawn starting at x - (stringWidth / 2), placing the specified X-coordinate in the middle of the string. If the value is "left", the string is drawn starting at the specified value of x. And if textAlign is "right", the text is drawn such that it ends at the specified X-coordinate.

(etc etc etc...)

You can, optionally, provide a fourth parameter that lets you specify a maximum width for the string, in pixels. If you provide this parameter, the text is compressed horizontally or scaled (or otherwise adjusted) to fit inside a space that wide when being drawn.

You can call the fillText() method to draw a string's characters as filled with color instead of only drawing the outlines of the characters.

Example: Much better!

Here we see a much better overview for the strokeText() method.

The CanvasRenderingContext2D method strokeText(), part of the Canvas 2D API, strokes—that is, draws the outlines of—the characters of a specified string, anchored at the position indicated by the given X and Y coordinates. The text is drawn using the context's current font, and is justified and aligned according to the textAlign, textBaseline, and direction properties.

For more details and further examples, see Text in Drawing graphics in the Learning Area as well as our main article on the subject, Drawing text.

Include all relevant examples

More pages should have examples than should not have them. The majority of pages most likely deserve multiple examples, in fact. It's important to ensure that you use examples to clarify what every parameter is used for, and to clarify any edge cases that may exist. You should also use examples to demonstrate solutions for common tasks, and you should use examples to demonstrate solutions to problems that may arise.

Each example should be preceded by text explaining what the example does and anything the reader should know before beginning to read or try out the example.

In addition, each piece of code should include an explanation of how it works. Keep in mind that it may make sense to break up a large piece of code into smaller portions so they can be described individually. The text following each piece of code should explain anything relevant, using an appropriate level of detail. If the code is very simple and doesn't really feature anything directly related to the API being documented, you may only give a quick summary of what it is and why it's there. If the code is intricate, uses the API being documented, or is technically creative, you should provide a more detailed explanation.

When using the live sample system, it's helpful to be aware that all of the <pre> blocks in the area that contains the sample are concatenated together before running the example, which lets you break any or all of the HTML, CSS, and JavaScript into multiple segments, each optionally with its own descriptions, headings, and so forth. This makes documenting code incredibly powerful and flexible.

Overly-short articles are hard to find

If an article is "thin"—that is, too short—it may not be indexed properly (or at all) by search engines. As a rule of thumb, the article's body text should be at least 250-300 words. Don't artificially inflate a page that simply can't reasonably be made longer than that, but treat this guideline as a target to shoot for as a minimum when possible.


降順に見出しレベルを使い分けてください。 <h2><h3><h4>という順に、途中を飛ばさず使って下さい。H2 が最高の見出しレベルなのは H1 はページタイトルのために用意されているからです。H3 、H4 より深いレベルの見出しが必要になったときは、小さい記事に分割し、ランディングページにまとめてNextPreviousPreviousNext マクロでリンクすることを考慮してみてください。

Enter (かReturn) キーは新しいパラグラフを開始します。空行無しに改行したい場合は、Shift キーと Enter キーを同時押ししてください。





Lists should be written in a similar format across all contributions. Correct procedures should include suitable punctuation and sentence structure regardless of the list format. However dependent on the type of list you are writing, you must adjust your format accordingly. Refer to the documentation below to understand the differences of each.

Bulleted Lists

Bulleted lists should be used for grouping purposes to create concise but effective pieces of information. Each new piece of information must start with a '•' to signify a new piece. Bulleted lists must follow standard punctuation usage, pay attention to the use of full stops; they must be included at the end of each sentence just like standard writing practice.

An example of a correctly structured bulleted list:

In this example we should include:

  • A condition, with a brief explanation.
  • A similar condition, with a brief explanation.
  • Yet another condition, some further explanation.

Note how the format remains the same from bullet to bullet. Create a bullet point, state a condition that has relevence to your indented topic and add some pausing punctuation in order to follow up the condition with a concise explanation.

Numbered Lists

Instruction lists must follow suitable numbering and format. It is important to include these attributes as with instructions, being clear is a key priority. Create the list in a similar style to a bulleted list, however numbered or instruction lists can be extensive where necessary, meaning correct punctuation is vital as you will be forming complex sentences.

An example of a correctly structured numbered list:

In order for you to structure a correct numbered list you must:

1. Begin with creating an introductory heading to lead into the instructions. This way we can provide the user with context before beginning the instructions.

2. Start creating your instructions, listing your instructions with numbers. This is a standard format of a numbered list that is easily recognizable by the user. Your instructions may be quite extensive, so it is important to write effectively and use correct punctuation where necessary.

3. After you have finished your instructions, close off the numbered list with a brief explanation of the outcome upon completion.

This is an example of writing your closing explanation. We have created a short numbered list which provides instructive steps to produce a numbered list with the correct formatting. 

Numbered lists are almost exclusive for instructive purposes, so before writing consider your approach based on the context of the information you are trying to relay.  


"Formatting Styles" ドロップダウンリストを使ってあらかじめ設定されたスタイルを選択範囲に適用してください。

注記: "注記" は重要な注意を呼びかけるのに使われます。こんな感じです。
警告:同様に、"警告" は警告ボックスをこのように作成します。

特別にそのように指示されたのでない限りは、HTML style 属性を手作業で付加しないようにしてください。既存のクラスでうまくいかなければ、#mdn で質問してみてください。





if (condition) {
  /* handle the condition */
} else {
  /* handle the "else" case */



       || class.YET_ANOTHER_CONDITION ) {
  /* something */

var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-service;1"]

インライン コードの書式

"コード"ボタン("<>"という山括弧記号が付いています)を使ってください。インライン コード スタイルの書式を関数名、変数名、メソッド名に適用することができます(これには、<code> 要素が使われています)。例えば、"frenchText() 関数"。

メソッド名の後には括弧をつけるべきです: doSomethingUseful() のように。括弧があることでメソッドとその他のコードの用語を区別できます。


Screenshot of the "syntax highlighting" menu.コード行全体(もしくは数行のコード)はシンタックスハイライトによってフォーマットされるのが好ましく、<code>要素は使われるべきではありません。ツールバーの"pre"ボタンをクリックしてください。書式設定されたコンテンツボックスが挿入されます。そこにコードを入力しましょう。それからテキスト入力カーソルをコンテンツボックス内に置いたまま、右図のように"pre"ボタンの右にあるリストボタンから適切な言語を選択しましょう。以下の例は JavaScript の書式です。

for (var i = 0, j = 9; i <= 9; i++, j--)
  document.writeln("a[" + i + "][" + j + "]= " + a[i][j]);

探している言語が見当たらなければ、言語を指定せずに pre タグを利用して下さい(リストの"No Highlight"を選びます)。

x = 42;


シンタックスの定義を挿入する場合には、エディタのツールバーの"Styles"ドロップダウンメニューから、"Syntax Box"オプションを選択することができます。これより、シンタックスの定義で、通常のコードと区別する特別な書式を与えることができます。

Blocks not referring to code

There are a few use cases where a <pre> block does not refer to code and doesn't have syntax highlighting nor line numbers. In such cases you should add a <pre> without class. Those cases include things like tree structures:




To create preformatted content without syntax highlighting and line numbers click the "pre" button in the toolbar. Then start to type the text.

HTML 要素リファレンスのスタイル

HTML 要素について記述するときに従うべきルールは様々あります。これに従うと、HTML 要素とそのコンポーネントについて首尾一貫した記述が生成され、適切なリンクと詳細なドキュメンテーションも保証されます。

HTMLElementマクロを使って下さい。その要素用のページへのリンクを生成します。例えば、{{HTMLElement("title")}}と書けば、"<title>"と出力されます。リンクを作りたくなければ、角括弧("<>")で名前を囲んで行中に埋め込むコードのスタイルで書いてください(例えば、 <title>)。
定義名にはhtmlattrdefマクロを使用してください(例えば、{{htmlattrdef("type")}})。他記事からのリンクを貼ることができます。次に属性定義を参照するためにhtmlattrxrefマクロを使用してください(例えば、 {{htmlattrxref("attr","element")}})。
"文中でのコード"スタイルで書いて下さい。文字列を引用符で囲まないでください、ただしコードサンプルのシンタックスハイライトの為に必要な場合は別です。例えば: When the type attribute of an <input> element is set to email or tel ...



  • よく使われるラテン語の略記(etc.、i.e.、e.g.)は括弧や注釈の中で使用できます。略記にはピリオドを使用してください。
    • 正しい: Web browsers (e.g. Firefox) can be used ...
    • 間違い: Web browsers e.g. Firefox can be used ...
    • 間違い: Web browsers, e.g. Firefox, can be used ...
    • 間違い: Web browsers, (eg: Firefox) can be used ...


  • 通常の文では(つまり注釈や括弧の外で)、英語における同等の表現を使用してください。
    • 正しい: ... web browsers, and so on.
    • 間違い: ... web browsers, etc.
    • 正しい: Web browsers such as Firefox can be used ...
    • 間違い: Web browsers e.g. Firefox can be used ...


略記 ラテン語 英語
cf. confer compare
e.g. exempli gratia for example
et al. et alii and others
etc. et cetera and so forth, and so on
i.e. id est that is, in other words
N.B. nota bene note well
P.S. post scriptum postscript

注記: ラテン語の略記表現が有用かどうか常に考えるようにしましょう。めったに使われないようなものは、多くの読者にとっては理解できず、他のものと勘違いしてしまうこともありえます。使用するあなたが正しく使用することを肝に銘じてください。例えば、"e.g."と"i.e."の取り違えはよくある間違いです。




  • 正しい: XUL
  • 間違い: X.U.L.; Xul


ある用語についてページ内で初めて言及がある場合は、ユーザにとって馴染みがないと思われる略語を展開しましょう。よく分からなければ、展開するかもしくは記事や、用語の説明をする glossary の項目へのリンクを貼りましょう。

  • 正しい: "XUL (XML User Interface Language) is Mozilla's XML-based language..."
  • 間違い: "XUL is Mozilla's XML-based language..."


頭字語と略語の複数形については、s を末尾に付加するだけにしてください。アポストロフィは使用しないでください。絶対に。お願いします。

  • 正しい: CD-ROMs
  • 間違い: CD-ROM's


文章中では、英語における標準的な大文字のルールに従ってください。"World Wide Web" や "Web"のようにしてください。






  • 正しい: syllabuses, octopuses
  • 間違い: syllabi, octopi



  • 正しい: email, re-elect, co-op
  • 間違い: e-mail, reelect, coop




A confirmation dialog appears, asking the user if he allows the Web page to make use of his Web cam.

A confirmation dialog appears, asking the user if she allows the Web page to make use of her Web cam.


A confirmation dialog appears, asking the user if they allow the Web page to make use of their Web cam.

注記: MDN では、とても一般的な文法 (それは使用法の権威の議論対象です) を使うのを許可されており、これは英語で中性がないのを穴埋めするためのものです。三人称複数型を中性名詞として使う (つまり、"they"、"them"、"their"、"theirs"を使う) ことは許容されるやり方で、一般には "singular 'they'" として知られています。


A confirmation dialog appears, asking the user if he or she allows the web page to make use of his/her Web cam.


A confirmation dialog appears, asking the users if they allow the Web page to make use of their Web cams.


A confirmation dialog appears, requesting the user's permission for Web cam access.

A confirmation dialog box appears, which asks the user for permission to use the Web cam.




日付については(コード中の日付は関係ありません)、"January 1, 1990"のようなフォーマットを使用してください。

  • 正しい: February 24, 2006
  • 間違い: February 24th, 2006; 24 February, 2006; 24/02/2006

YYYY/MM/DD フォーマットを使っても構いません。

  • 正しい: 2006/02/24
  • 間違い: 02/24/2006; 24/02/2006; 02/24/06


年代の表現には、"1990s" フォーマットを使って下さい。アポストロフィはいりません。

  • 正しい: 1990s
  • 間違い: 1990's



  • 正しい: 486s
  • 間違い: 486's



  • 正しい: 4000; 54,000
  • 間違い: 4,000; 54000


Serial Comma(連続のカンマ)

Serial comma(連続のカンマ)を使用してください。 Serial Comma または "Oxford" comma(オックスフォードカンマ)としても知られるこのカンマは、3つ以上の文を並列する際に接続詞の直前に置きます。

  • 正しい: I will travel on trains, planes, and automobiles.
  • 間違い: I will travel on trains, planes and automobiles.

注記: これは One Mozilla style guide のやり方とは対対照的です。Serial Comma (連続のカンマ)は使われないと明記しています。MDN のやり方はこのルールの例外です。


ゆれのあるスペルについては  Dictionary.com で最上位にくるエントリを使用して下さい。他のものは使用しないでください。

  • 正しい: localize, honor
  • 間違い: localise, honour



"要素" は、"タグ" ではなく、 HTML と XML との要素を指します。また、要素は常に "<>" 内に記述されるべきで、<code> のスタイルに従うべきです。それから、少なくとも記事においてその要素について初めて言及する際はHTMLElement マクロを利用してください。その要素についてのドキュメンテーションへのリンクが生成されます。ただしまさにその要素についてのリファレンス記事を作成している場合は必要ありません。

  • 正しい: the <span> element
  • 間違い: the span tag

Parameters vs. arguments

The preferred term on MDN is parameters. Please avoid the term "arguments" for consistency if at all possible.



  • 正しい: Click the Edit button.
  • 間違い: Click Edit.


能動態が一般的には好ましいですが、MDN の堅苦しくない雰囲気から考えると受動態も問題ありません。けれど、どちらか首尾一貫させる意識は必要です。

Wiki のマークアップとその用法


wikiが協力な学習・教育ツールとなるのに、大半はリンクのおかげです。以下にいくつかの基本情報がありますが、完全なガイドは編集ガイド内の MDNでリンクを作成・編集する で見る事ができます。

We encourage you to create appropriate links among articles; they help improve navigation and discoverability of content. You can easily create links not only among pages on MDN (internal links) but also to pages outside MDN (external links).

There are two ways to create links: you explicitly create a link using the Link button in the editor's toolbar—or by pressing Ctrl+K (Cmd-K on the Mac)—or you can use MDN's powerful macro system to generate links automatically or based on an input value.

When deciding what text to use as a link, there are a few guidelines you can follow:

  • Whenever a macro exists which will create the link you need, and you are able to do so, please do. Using macros to create links will not only help you get it right, but will allow future improvements to MDN to automatically be applied to your link.
  • For an API name, use the entire string of the API term as written in your content. The easiest way to do this is to use the appropriate macro to construct a properly-formatted link for you.
  • For a term for which you're linking to a page defining or discussing that term, use the name of the term and no additional text as the link's text. For example:
    • Correct: You can use JavaScript code to create dynamic applications on the Web.
    • Incorrect: You can use JavaScript code to create dynamic applications on the Web.
  • Otherwise, when adding a useful link to prose, try to choose an action and object phrase, such as:

URL スキーム


  • http://
  • https://
  • ftp://
  • mailto:


特に、 about:chrome:// スキームは、動作しないので使用しないよう注意してください。同様に javascript: スキームはたいていのモダンブラウザからブロックされ、jar: も同様です。


タグはページについてのメタ情報を提示するか、内容に改善すべき点があるということを示します。あるいはその両方です。Wiki のどのページもタグづけされる必要があります。タグ付けのやり方については適切にタグづけする方法のガイドに詳しいです。


Screenshot of the UX for adding and removing tags on MDN

タグを追加するには、タグリスト末尾の編集ボックスをクリックしてタグ名を入力します。タグには補完機能があります。Enter (かreturn) キーで新規タグを投稿できます。どの記事も必要なだけタグを追加してよいです。例えば、AJAX プログラミングにおける JavaScript の記事には "JavaScript" と "AJAX" のどちらのタグも必要でしょう。

タグを削除するには、タグアイコンの "X" をクリックしてください。





  • Junk: スパム記事、誤って作られたページ、見る価値の無い劣悪なページにはこのタグをつけて下さい。このタグがつけられたページは定期的に削除されます。
  • Obsolete: 技術的に既に古いが、ある文脈上では使用されうることについての記事にはこのタグをつけて下さい。例えば、HTML5 では時代遅れな HTML 要素も HTML 4.01 ではまだ有効です。そのトピックについて obsolete_header マクロを使って目印をつけることができます。
  • Archive: 技術的に既に古く、最早役に立たないものにはこのタグをつけてください。できれば、読者にもっと新しい記事を読むように促す注記をつけてください。例えば、 Mozilla CVS リポジトリをどのように使うかについての記事は Mercurial リポジトリについての新しい記事に読者を誘導するべきでしょう(対応する記事が存在しなければ、NeedsUpdate タグをつけてください。そして Talk ページに説明を加えて下さい)。Archive タグのつけられた記事はそのうち、MDN の主要部分から Archive セクションへと移されます。

SEO summary

SEO summary は簡潔なページの概要です。サイトを巡回するプログラムに記事の概要として渡され、ページの検索結果として表示されます。MDN のランディングページの作成を自動化するマクロにも利用されます。

デフォルトでは、ページ最初の段落が SEO summary として利用されます。しかし、WYSIWYGエディタ内の "SEO summary" スタイルを利用してセクションをマークすることで上書きすることができます。


ランディングページ はサイトにおける、ある分野の起点となるページです。例えば CSSHTML のメインページです。下記の3エリアからなる標準的なフォーマットがあります。

  1. その技術がどういうもので、どのように使用されるかについての簡潔な(大抵はひとつのパラグラフからなる)概観。詳しくは Writing a landing page overview を参照してください。
  2. 適切に見出しがつけられた、2段組のリンクリスト。Creating a page link list のガイドラインを参照してください。
  3. ページ最下部の "ブラウザの互換性" は任意です。


MDN ランディングページのリンクリストセクションは2段組からなります。下記の HTML コードによって生成されます。

<div class="row topicpage-table">
  <div class="section">
    ... left column contents ...
  <div class="section">
    ... right column contents ...

左の段は記事のリストになります。上部の <h2> ヘッダはとあるトピック(例えば、"Documentation and tutorials about foo")についての記事のリストであることを説明します。つまり、このヘッダは CSS の "Documentation" クラスを使用するべきです。その下には、記事の <dl> リストが続きます。リストには各記事へリンクした <dt> ブロックと、1行から2行程度の記事の概要に対応した <dd> ブロックがあります。


このセクションは IRC チャンネルと、トピックについて役に立つメーリングリストの情報を提供します。見出しは "Community" クラスを利用するべきです。
このMDNセクションに記述された技術を使う時に、ユーザの助けになるツールの一覧です。見出しは "Tools" クラスを利用するべきです。
その他の、関係する技術についてのランディングページへのリンクリストです。見出しは "Related_Topics" クラスを利用するべきです。

<<<finish this once we finalize the landing page standards>>>



  1. 適切なイメージファイルを記事に添付しましょう(編集モードで記事の最下部にてできます)。
  2. WYSIWYG エディタでイメージを作成します。
  3. WYSIWIG エディタの添付ファイルのドロップダウンリストから、新規作成した、あなたのイメージの添付ファイルを選択します。
  4. OK を押してください。



ここで取り扱われていない用法とスタイルについて疑問があれば、Economist style guide を、それでもダメなら Chicago Manual of Style を参照してください。


単語の綴りにわからないことがあれば、 Dictionary.com を参照してください。このサイトのスペルチェッカはアメリカ英語を基準にしています。それ以外の表記を使用しないでください(例えば colour でなく color です)。

何度もガイドが拡張されることになるでしょう、ですからこのドキュメントで取り扱われていないことについて知りたければ、その質問を MDC mailing listproject lead に送ってください。MDNの協力者が追加すべき記事を知ることができます。

MDN 独自の内容について




このページの貢献者: horichiyo, SphinxKnight, Uemmra3, dai, 5ara5treamer
最終更新者: horichiyo,