Shamusworld >> Repos - ardour-manual/blob - STYLE_GUIDE

   1 *Style guide for the Ardour manual*
   2
   3
   4
   5 1. Rationale
   6 ============
   7
   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
  14 elsewhere.
  15
  16
  17 1.1 visual markup
  18 -----------------
  19
  20 <b>,<i>,<u>,<font> or any other purely visual elements are not used in
  21 the Ardour manual.
  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>
  26 and then add
  27 .my_important_keyword {
  28         text-decoration: underline;
  29         color: #004400;
  30         background-color: #eeffee;
  31 }
  32 to apps.css.
  33 If you add a new class with semantic meaning, document it below, under
  34 "Custom classes".
  35
  36
  37 2. Format and Validation
  38 ========================
  39
  40 The Ardour manual has been converted to valid XHTML 1.0. That means it must
  41 be valid XML, with all tags closed properly. The reason for this extra
  42 complication is that XML can be more easily checked and automatically
  43 refactored than plain HTML, which eases maintenance.
  44
  45 Watch out for the ampersand "&" and angle brackets "<" and ">". They will
  46 render your XHTML invalid, and must be replaced by their named entities
  47 "&amp;", "&lt;", and "&gt;".
  48
  49
  50 3. Custom classes
  51 =================
  52
  53 We use the class attribute for some aspects of styling (such as to float an
  54 image left or right in a text paragraph), and also for more fine-grained
  55 semantic markup than core XHTML allows.
  56
  57 Any XHTML element can include a class attribute. If you need to add a class
  58 attribute to a word or a few words which don't have an element of their own,
  59 use <span class="my_new_category">foo bar</span>.
  60 If you need to apply a class to several block-level elements such as
  61 paragraphs or lists, enclose them in a <div>..</div>. Wherever possible,
  62 create semantic classes rather than visual ones.
  63
  64 .left:
  65 make an element float left in the surrounding paragraph.
  66
  67 .right:
  68 make an element float right in the surrounding paragraph.
  69
  70 .note:
  71 use for important notes that should be visually distinct from the
  72 normal text flow, or asides. Currently rendered in a gray box.
  73
  74 .warning:
  75 use for potentially dangerous situations involving data loss, malfunction,
  76 or sound quality issues. Currently rendered in a red box.
  77
  78 Check _manual/01_welcome-to-ardour/02_about-ardour-documentation.html, it
  79 serves as a style and markup guide.
  80
  81
  82 4. Element use
  83 ==============
  84
  85
  86 4.1 Main structural elements
  87 ----------------------------
  88
  89 <h1>..<h6>
  90 A <h1/> heading is added by the Ruby framework, so it should not be used in
  91 the manual page itself. If you feel you need another <h1>, start a new
  92 subpage.
  93 Heading levels must not be skipped. Any sub-heading must be exactly one
  94 level below its predecessor. Do not abuse headings to style a head line.
  95
  96 <p>
  97 Every snippet of text should be enclosed in a block level element. The
  98 default choice is <p>, the plain paragraph.
  99
 100
 101 4.1 Inline markups
 102 ------------------
 103
 104 <dfn>
 105 encloses a newly introduced term that is being explained. Use for the first
 106 occurrence of the main concept of every manual page, or the first occurrence
 107 of a new concept after a sub-heading if necessary.
 108 Keep in mind that <dfn> tags might be used to generate an index of keywords
 109 - don't pollute it too much.
 110
 111 <abbr>
 112 is used to explain an abbreviation such as <abbr title="Linux Audio
 113 Developers Simple Plugin API">LADSPA</abbr>. Browsers will usually pop up the
 114 definition when the user hovers over the word.
 115 On each page, use only for the first occurrence of every abbreviation. Avoid
 116 a redundant explanation in the text - the expansion can easily be extracted
 117 via CSS for printing.
 118
 119 <em>
 120 is used to emphasize a word. Commonly rendered as italics.
 121 Use only if its a truly ad-hoc, one-off situation. For anything else,
 122 consider adding a new semantic markup with <span class="foo">.
 123
 124 <strong>
 125 is used to strongly emphasize a word. Commonly rendered in bold.
 126 See above for usage.
 127
 128 <br />
 129 A line-break can sometimes be used to structure a paragraph, or to split a
 130 longish heading. Never use spurious <br/>s at the end of paragraphs or to
 131 control the spacing of sections. If you're unhappy with those, fix the CSS
 132 (which fixes the entire manual in one go!)
 133
 134
 135 4.2 Lists
 136 ---------
 137
 138 <ul>,<ol>
 139 Use the unordered list for information snippets that do not have an implied
 140 order. The ordered list should always be used when a sequence of actions is
 141 described. Within the lists, each item must be enclosed in <li> tags.
 142 Lists cannot be included in <p>aragraphs. Close the paragraph first.
 143
 144 <dl>
 145 Definition lists are for technical terms <dt> and their definition <dd>. Do
 146 not abuse them for anything else.
 147
 148
 149 4.3 Quotations
 150 --------------
 151
 152 <blockquote>
 153 is used when an entire paragraph is quoted. Must contain a
 154 cite="http://mysource.net/foo.pdf" attribute. Do not abuse to indent a
 155 paragraph!
 156
 157 <cite>,<q>
 158 For inline citations, the <cite>W3C</cite> recommends to <q
 159 cite="http://www.w3.org/TR/xhtml1/dtds.html">use the cite and q
 160 elements</q>.
 161
 162
 163 4.4 Keyboard/Controller  interaction
 164 ------------------------------------
 165
 166 <kbd>
 167 Any keys or key combinations, mouse buttons, or controllers  should be marked
 168 with this element.
 169 E.g.:
 170 "Press <kbd>F</kbd> to fit all tracks to the height of the Editor window."
 171 "Move <kbd>Fader 1</kbd> on your MIDI controller to bind it.
 172 "
 173 Since modifier keys are not cross-platform and Ardour makes a point of
 174 abstracting them, do not hard-code "Alt", "Cmd" and friends, use
 175         class="modN"
 176 instead.
 177 So if you want the user to press Ctrl-N on Linux, that's actually <kbd
 178 class="mod1">N</kbd>. It will render as "Ctrl+N" for you, and as "Cmd+N" for
 179 your Mac-using friend. Nice, uh?
 180
 181 For anything you want the user to type, use <kbd> as a block-level element.
 182 See above for other <kbd> classes to denote menu items, selections, mouse
 183 events and controller actions.
 184
 185 <code>
 186 is only used for program code, or the content of configuration files etc. Do
 187 not abuse to style keys or user input, use <kbd> instead.
 188
 189 <samp>
 190 is only used for the textual output of any code, never for anything the user
 191 types or presses.
 192
 193
 194 4.5 Images
 195 ----------
 196
 197 <img>
 198 The image tag must contain a 'src="/images/yourimage.png"' element and a
 199 descriptive 'alt="A short textual description of the image content"'
 200 element.
 201
 202
 203 5. Typography
 204 =============
 205
 206 * Avoid any typographical quotation marks to highlight terms or express any
 207   kind of subtle inflection, use semantic markup instead.
 208 * The hyphen is used to for compound words such as this well-advised example.
 209 * Do not hyphenate words at line breaks.
 210 * For breaks in thought &mdash; such as this splendid example &mdash; use
 211   the long em-dash.
 212 * For ranges of values, use the en-dash: Monday &ndash; Friday, 0 &ndash;
 213   11.
 214
 215