Use this file as a style guide when creating new cue-by-example documents, and use the file template.md as a template you can copy and adapt.
Use a single H1 heading (#
), at the top, to indicate the document's title.
On the Markdown line directly underneath the H1 line, include a <sup>
HTML
element containing your preferred attribution as the document author, and for
each co-author. For example:
# Using CUE to get ahead in Hollywood
<sup>by [George Clooney](https://www.imdb.com/name/nm0000123/)</sup>
<sup>and [Halle Berry](https://www.imdb.com/name/nm0000932/)</sup>
... which renders as:
by George Clooney and Halle Berry
Use H2 headings (##
) to differentiate between isolated, stand-alone
scenarios.
Use H3 headings (###
) to mark sections within a single scenario.
Use H4 headings (####
) to name individual steps within a section. This will
allow the step to be linked to by users, which will be useful if a user gets
stuck and needs to post in CUE Slack, asking for some help, and wants to
identify the step they're stuck on.
In the H4 line, prefix the name of each step that the user should perform with
a ➡️ icon (:arrow_right:
).
For example:
#### :arrow_right: Frobnicate the doodahs
Frobnicating the doodahs remotely is easy, if you remember to loofah the
widgets. To do that, ...
... which renders as:
Frobnicating the doodahs remotely is easy, if you remember to loofah the widgets. To do that, ...
Please include at a minimum:
- an introduction section, covering at least the prerequisites the reader must be aware of to successfully use the document
- a section containing the steps to follow, with step markers as described above
- a conclusion section
Indicate each file that the user should create:
- with a 💾 icon (
:floppy_disk:
) - followed on the same line by the file's path and name in an inline code block
- followed by a fenced code block with a content type preamble, containing the file's content.
For example:
:floppy_disk: `some_file.cue`
```CUE
package cbe123
some_content: "some string"
```
... which renders as:
💾 some_file.cue
package cbe123
some_content: "some string"
Indicate one or more commands that the user should run in a shell:
- with a 💻 icon (
:computer:
) - followed on the same line by the word
terminal
in an inline code block - followed by a fenced code block with a content type of
sh
- with each command the user needs to run on a line by itself, each with no prefix
- with any critical comments trailing after their associated command, separated
by an appropriate shell comment symbol (usually
#
).
The lack of any prefix means that using the "copy" button that GitHub
automatically places at the top right of each code block will give the reader
useful, paste-able text. If you were to include a prefix, such as $
, then the
reader wouldn't be able to paste the commands directly into a terminal.
Include example output in a separate fenced code block, after the command code block, to help the user judge if the command has run as expected on their local machine.
For example:
:computer: `terminal`
```sh
echo "hello world" | tr 'a-z' 'A-Z' | tr -s 'A-Z' # this is a really important command
echo 'CUE is awesome!'
```
Expected output:
```
HELO WORLD
CUE is awesome!
```
... which renders as:
💻 terminal
echo "hello world" | tr 'a-z' 'A-Z' | tr -s 'A-Z' # this is a really important command
echo 'CUE is awesome!'
Expected output:
HELO WORLD
CUE is awesome!
When a file or shell block's contents is long enough that it disrupts the flow
of the guide, consider placing the lengthy content inside a "click-to-expand"
<details>
HTML element.
This element has 2 parts:
- a short preable that's always visible (the
<summary>
) - the folded content that's only visible after a click
Please use the folding element as follows:
- Place the element inside a pair of horizontal lines (
<hr>
), to indicate to the reader where the unfolded content finishes - Wrap the file's name in a
<code>
element (instead of single backticks) - Follow the file's name with the words
(click to open)
- Place a blank (source) line between the closing
</summary>
tag and the opening of the file's fenced code block (```
), so that GitHub's markdown formatting works correctly
Here's an example of using a <details>
element to fold a file:
Here's a file that you might find useful:
<hr>
<details>
<summary>
:floppy_disk: <code>a_file.cue</code> (click to open)
</summary>
```text
A
long
file
but
not
really
as
this
is
just
an
example
```
</details>
<hr>
This renders as follows:
Here's a file that you might find useful:
💾 a_file.cue
(click to open)
A
long
file
but
not
really
as
this
is
just
an
example
If your reader needs to be warned or informed at a specific point in the document, use a Markdown table like one of the following, with one of the headings exactly as provided:
| :exclamation: WARNING :exclamation: |
|:----------------------------------- |
| This warning text must appear on a single line in the markdown source, as if there's a line break then the formatting will break. Whilst this can result in unwieldy source text, the rendered result looks fine. To force a line break, use an HTML `<br>` tag, like this:<br> To force a blank line use two, like this:<br><br> This source line, unlike the 2 above it, **doesn't** need to end with a pipe symbol. Most markdown formatting elements work correctly in tables, such as [links](https://example.com), *italic*, **bold**, and `inline code blocks`. Anything with multiple lines, such as fenced code blocks, probably won't work.
| :grey_exclamation: Info :grey_exclamation: |
|:------------------------------------------ |
| This Info block is less "shouty" than the WARNING, above. All the formatting and content notes in the WARNING example also apply here.
This renders as follows:
❗ WARNING ❗ |
---|
This warning text must appear on a single line in the markdown source, as if there's a line break then the formatting will break. Whilst this can result in unwieldy source text, the rendered result looks fine. To force a line break, use an HTML <br> tag, like this:To force a blank line use two, like this: This source line, unlike the 2 above it, doesn't need to end with a pipe symbol. Most markdown formatting elements work correctly in tables, such as links, italic, bold, and inline code blocks . Anything with multiple lines, such as fenced code blocks, probably won't work. |
❕ Info ❕ |
---|
This Info block is less "shouty" than the WARNING, above. All the formatting and content notes in the WARNING example also apply here. |