1 *Style guide for the Ardour manual*
8 The Ardour manual should be consistent across different media, and it should
9 be easily updatable when Ardour's behaviour changes.
10 The markup should be semantic - looks are determined in the CSS, and only
11 there. If you feel you must compromise the markup in order to obtain a
12 certain look: don't do it. Accept the look.
13 Alternatively, edit the CSS, but be careful not to make matters worse
20 <b>,<i>,<u>,<font> or any other purely visual elements are not used in
22 What you really mean is an <em>phasis or a <strong> emphasis.
23 If you feel that some special terms should always be green and underlined, the
24 approach of choice is this:
25 <span class="my_important_keyword">foobar</span>
27 .my_important_keyword {
28 text-decoration: underline;
30 background-color: #eeffee;
33 If you add a new class with semantic meaning, document it below, under
34 "Custom classes", and be sure to explain it to the reader at
35 _manual/01_welcome-to-ardour/02_about-ardour-documentation.html.
38 2. Format and Validation
39 ========================
41 The Ardour manual has been converted to valid XHTML 1.0. That means it must
42 be valid XML, with all tags closed properly. The reason for this extra
43 complication is that XML can be more easily checked and automatically
44 refactored than plain HTML, which eases maintenance.
46 Watch out for the ampersand "&" and angle brackets "<" and ">". They will
47 render your XHTML invalid, and must be replaced by their named entities
48 "&", "<", and ">".
54 We use the class attribute for some aspects of styling (such as to float an
55 image left or right in a text paragraph), and also for more fine-grained
56 semantic markup than core XHTML allows.
58 Any XHTML element can include a class attribute. If you need to add a class
59 attribute to a word or a few words which don't have an element of their own,
60 use <span class="my_new_category">foo bar</span>.
61 If you need to apply a class to several block-level elements such as
62 paragraphs or lists, enclose them in a <div>..</div>. Wherever possible,
63 create semantic classes rather than visual ones.
66 make an element float left in the surrounding paragraph.
69 make an element float right in the surrounding paragraph.
72 use for important notes that should be visually distinct from the
73 normal text flow, or asides. Currently rendered in a gray box.
76 use for potentially dangerous situations involving data loss, malfunction,
77 or sound quality issues. Currently rendered in a red box.
80 use as additional classes to mark a section as relevant for these operating
83 Check _manual/01_welcome-to-ardour/02_about-ardour-documentation.html, it
84 serves as a style and markup guide.
91 4.1 Main structural elements
92 ----------------------------
95 A <h1/> heading is added by the Ruby framework, so it should not be used in
96 the manual page itself. If you feel you need another <h1>, start a new
98 Heading levels must not be skipped. Any sub-heading must be exactly one
99 level below its predecessor. Do not abuse headings to style a head line.
102 Every snippet of text should be enclosed in a block level element. The
103 default choice is <p>, the plain paragraph.
106 Cross-reference links in the manual are reasonably stable, since they are
107 independent of the ordering number (which gets removed from the URL) and the
108 pretty page title (the URL is created from the file name). So unless a file
109 is renamed or moved to another sub-directory, links should be ok.
115 encloses a newly introduced term that is being explained. Use for the first
116 occurrence of the main concept of every manual page, or the first occurrence
117 of a new concept after a sub-heading if necessary. Renders in bold face. Keep
118 in mind that <dfn> tags might be used to generate an index of keywords--don't
122 is used to explain an abbreviation such as <abbr title="Linux Audio
123 Developers Simple Plugin API">LADSPA</abbr>. Browsers will usually pop up the
124 definition when the user hovers over the word. Renders as dotted underlined
126 On each page, use only for the first occurrence of every abbreviation. Avoid
127 a redundant explanation in the text--the expansion can easily be extracted
128 via CSS for printing.
129 Use only in the text body, not in headings.
132 is used to emphasize a word. Commonly rendered as italics.
133 Use only if its a truly ad-hoc, one-off situation. For anything else,
134 consider adding a new semantic markup with <span class="foo">.
137 is used to strongly emphasize a word. Commonly rendered in bold.
141 Most of the time, these should be avoided, and used very infrequently.
142 A line-break can sometimes be used to structure a paragraph, or to split a
143 longish heading. Never use spurious <br/>s at the end of paragraphs or to
144 control the spacing of sections. If you're unhappy with those, fix the CSS
145 (which fixes the entire manual in one go!)
152 Use the unordered list for information snippets that do not have an implied
153 order. The ordered list should always be used when a sequence of actions is
154 described. Within the lists, each item must be enclosed in <li> tags.
155 Lists cannot be included in <p>aragraphs. Close the paragraph first.
158 Definition lists are for technical terms <dt> and their definition <dd>. Do
159 not abuse them for anything else.
166 is used when an entire paragraph is quoted. Must contain a
167 cite="http://mysource.net/foo.pdf" attribute. Do not abuse to indent a
171 For inline citations, the <cite>W3C</cite> recommends to <q
172 cite="http://www.w3.org/TR/xhtml1/dtds.html">use the cite and q
176 4.4 Keyboard/Controller interaction
177 ------------------------------------
180 Any keys or key combinations, mouse buttons or controllers, menu items or
181 textual user input should be marked with this element. It is used here in
182 the widest possible sense, qualified by classes.
184 "Press <kbd>f</kbd> to fit all tracks to the height of the Editor window."
185 "Move <kbd>Fader 1</kbd> on your MIDI controller to bind it.
187 Since modifier keys are not cross-platform and Ardour makes a point of
188 abstracting them, do not hard-code "Alt", "Cmd" and friends, use
191 So if you want the user to press Ctrl-N on Linux, that's actually <kbd
192 class="mod1">N</kbd>. It will render as "Ctrl N" for you, and as "Cmd N" for
193 your Mac-using friend. Nice, uh?
195 N.B.: If you want to have just the name of the modifier key by itself, use
196 <kbd class="mod1>‌</kbd> (zero-width non-joiner).
198 For anything you want the user to type, use <kbd> as a block-level element.
199 See above for other <kbd> classes to denote menu items, selections, mouse
200 events and controller actions.
202 Keys and mouse key names should always be entered lowercase, even though the
203 stylesheet might capitalize them.
205 CSS Classes used with <kbd> are:
207 .mouse: mouse buttons
209 .lin, .win, .mac: add nice prompts to that command line
210 .input: inline text to be entered by the user
211 .menu: path to an Ardour menu or other GUI item
212 .option: path to an option, with (X) at the end.
213 .optoff: path to an option, with ( ) at the end.
214 .button, .fader, .knob: external controllers (OSC or MIDI).
217 is only used for program code, or the content of configuration files etc. Do
218 not abuse to style keys or user input, use <kbd> instead.
221 is only used for the textual output of any code, never for anything the user
229 The image tag must contain a 'src="/images/yourimage.png"' element and a
230 descriptive 'alt="A short textual description of the image content"'
232 Images are usually placed as block-level elements, i.e. outside of a
233 paragraph, unless they are no higher than one row and make sense in the text
234 flow. Aside from this exception, they should *always* be wrapped inside of a
244 * Avoid any typographical quotation marks to highlight terms or express any
245 kind of subtle inflection, use semantic markup instead.
246 * The hyphen is used to for compound words such as this well-advised example.
247 * Do not hyphenate words at line breaks.
248 * For breaks in thought—such as this splendid example—use
249 the long em-dash. Note that the em-dash is snugged up against the text on both
250 sides--this is the proper way to use them.
251 * For ranges of values, use the en-dash: Monday–Friday, 0–11. Note
252 again, the en-dash is snugged up to its surrounding elements.
253 * Use a non-breaking space (" ") between a number and its unit.
254 * Colons (":") always snug up to their text on the left: it is an error to add
255 space between text on the left and the colon.
261 * The Ardour manual is written in American English spelling.
262 * Use SI units with standard abbreviations. Give imperial units only as
263 additional information, if at all.
264 * Do not use contractions like "it'll", always write full forms.
265 * Do not over-use "You", write about the program, not the user. Avoid it if at
266 all possible, it makes for tighter and better reading text.
267 * Always write out numbers less than 11. E.g., "One or two ..." instead of
271 5.3 Chapter Headline Capitalization
272 ------------------------------------
274 Capitalization follows
275 https://developer.gnome.org/hig-book/3.6/design-text-labels.html.en#layout-capitalization
278 * Capitalize all words in the headline, with the following exceptions:
279 Articles: a, an, the.
280 Conjunctions: and, but, for, not, so, yet ...
281 Prepositions of three or fewer letters: at, for, by, in, to ...
282 * Keep headlines short and concise.
283 * secondary headlines in articles are not capitalized
284 * Do not capitalize concepts in the text body, with the possible exceptions
285 of _the_ Editor and _the_ Mixer.
288 5.4 Janitorial tasks/review
289 ---------------------------
291 If you encounter something that is unclear or patent nonsense, but you are
292 not bold or knowledgeable to fix it, express your doubts with an <p
293 class="fixme">editorial note</p>, so that readers will be warned and fellow
294 editors know where there's work to do.
296 5.5 Writing style suggestions
297 -----------------------------
299 * "Click OK" and similar explanations of the utterly obvious should be
300 avoided. Keep the writing concise and to the point. Explain as much as
301 possible, with as few words as possible.
302 * Do not fear repetitions, this is not artistic prose. Repeat important
303 keywords, rather than burden the user with synonyms made up on the spot.
304 * Do not create headings for different ways of doing the same thing (<h>Via
305 the context menu</h>,...<h>Via hotkeys</h>). Headings separate new
306 concepts. To not add gratuitous sub-headings if there is very little
307 content per heading and you do not expect the article to grow.
308 * If pages grow long, consider splitting them into sub-chapters at their
310 * Nobody needs "the next paragraph is about the following" paragraphs.
311 * When creating a <p class="note">NOTE</p>, *do not* put the word NOTE into
312 the note, the styling tells the user that it is a note.
317 * Pages should be encoded in UTF-8, with Unix-style newlines if possible
318 (although that's not critical). Avoid using verbatim special symbols, use
319 HTML character entities instead, for example for cursor arrows: →
320 ← ↑ ↓. Diacriticals on vowels and other special letters are
321 probably ok by now, so don't bother with é and friends, just type é.