This page showcases the various formatting and layout options available for content. Note that there is a separate page for formatting images, videos, animations and prototypes. This allows editors to better understand their toolbox and access reference code. It also allows designers to see the design system in one place.
The design source file is a public Figma community file you can find here. To improve the design, please start with the Figma file and make a proposal in Slack or Github before implementing.
We use Markdown when writing content. Markdown is a plain-text formatting syntax that helps us better prepare our text for the web. Below you can find an overview of commonly used syntax elements.
Typically used for lists of terms and descriptions.
{%includedl/open.html%}{%includedl/item-open.htmlcolor="red"%}
“You will be shown your recovery phrase on the next screen”
{%includedl/item-middle.htmlcolor="red"%}
Prepares a user for what they are about to **see**.
{%includedl/item-close.html%}{%includedl/close.html%}
“You will be shown your recovery phrase on the next screen”
Prepares a user for what they are about to see.
“Your recovery phrase is a group of 12 random words”
Explains to users what a recovery phrase is.
“Your recovery phrase is the only way to access your wallet if your phone is lost or stolen.”
Explains to users what the purpose of a recovery phrase is and why it’s important.
“If you lose your recovery phrase, you will no longer be able to access your wallet. Never share your recovery phrase with anyone. Anyone who has it can access your funds.”
Explains to users what the consequences of their behavior are, and how it can affect the safety of their funds.
“We recommend writing these words down in order on a piece of paper and storing it somewhere safe that you will remember.”
Guides and gives users actionable items on how to safely handle their recovery phrase.
| head1 | head two | three |
|:-------------|:------------------|:------|
| ok | good swedish fish | nice |
| out of stock | good and plenty | nice |
| ok | good `oreos` | hmm |
| ok | good `zoute` drop | yumm |
Long, single-line code blocks should not wrap. They should horizontally scroll if they are too long. This line should be long enough to demonstrate this.
Long, single-line code blocks should not wrap. They should horizontally scroll if they are too long. This line should be long enough to demonstrate this.
For additional useful information, but does not fit into the main flow of the content. This component has two presets, but can also be customized. Here are the presets:
{%includetip/tip.html%}
Sed in lacus vitae turpis lobortis ultrices. Aenean hendrerit nec elit in sagittis. Nulla mi ante, luctus vitae tincidunt ut, rhoncus ac ex. Morbi sit amet mauris est.
{%includetip/close.html%}
Tip
Sed in lacus vitae turpis lobortis ultrices. Aenean hendrerit nec elit in sagittis. Nulla mi ante, luctus vitae tincidunt ut, rhoncus ac ex. Morbi sit amet mauris est.
For highlighting moments when we think there is a particular approach or solution that the reader should strongly consider following.
{%includetip/recommendation.html%}
Most bitcoin products should use HD Wallets with Native Segwit addresses (unless focusing on maximum backwards compatibility).
{%includetip/close.html%}
Recommendation
Most bitcoin products should use HD Wallets with Native Segwit addresses (unless focusing on maximum backwards compatibility).
You can also customize which color, title and icon the component should display with the following template. Available colors are red, orange, yellow, green, and blue.
{%includetip/open.htmlcolor="green"icon="check"label="My title"%}
Most bitcoin products should use HD Wallets with Native Segwit addresses (unless focusing on maximum backwards compatibility).
{%includetip/close.html%}
Do this
Most bitcoin products should use HD Wallets with Native Segwit addresses (unless focusing on maximum backwards compatibility).
Don't do this
Most bitcoin products should use HD Wallets with Native Segwit addresses (unless focusing on maximum backwards compatibility).
A table that provides specific descriptions based on standardized properties. Variations available are:
fact/pros.html
fact/cons.html
fact/dos.html
fact/donts.html
fact/variations.html
fact/products.html
{%includefact/pros.html%}
Can provide higher resistance to loss from theft and negligence.
{%includefact/close.html%}
Pros
Can provide higher resistance to loss from theft and negligence.
Cons
Require precise coordination of key-shares when signing, few advantages over multi-key setups with Schnorr signatures, individual implementations not interoperable.
Do's
When the target audience is knowledgeable, and risk of theft is higher than negligence.
Don'ts
When Schnorr signatures are available enabling multi-key setups.
Variations
Number of signatures required, location and distribution of pieces, signing procedure.
This component allows for visual display and comparison of good and bad design implementations. The component consists of open, middle and close tags, between which regular markdown can be used.
{%includedo/open.htmllabel="Do"icon="check"color="green"%}
Provide clear error messages that tell users how to solve the problem.
{%includeimage.htmlimage="/assets/images/guide/contribute/formatting/example-image-square.jpg"retina="/assets/images/guide/contribute/formatting/example-image-square@2x.jpg"alt-text="Example image"width=400height=400%}{%includedo/middle.htmllabel="Don't"icon="forbid"color="red"%}
Write overly complex error messages that require deep technical knowledge.
{%includeimage.htmlimage="/assets/images/guide/contribute/formatting/media/example-image-square.jpg"retina="/assets/images/guide/contribute/formatting/media/example-image-square@2x.jpg"alt-text="Example image"width=400height=400%}{%includedo/close.html%}
Do
Provide clear error messages that tell users how to solve the problem.
Don't
Write overly complex error messages that require deep technical knowledge.