<p><strong>Infusion</strong> is built using the static site engine, <ahref="https://gohugo.io/">Hugo</a>, and NPM. The codebase is available to download on Github. Let’s get set up step-by-step.</p>
<h2id="install-hugo">Install Hugo</h2>
<p>First you need to install Hugo globally.</p>
<h3id="osx-users">OSX users</h3>
<p>If you are a Mac user and have <ahref="https://brew.sh/">Homebrew</a> on your system, installing Hugo is simple:</p>
<p>Alternatively, you can manually <ahref="https://github.com/gohugoio/hugo/releases">install Hugo from a package</a>. You can verify the installation was successful by typing:</p>
<preclass="cmd"><code>hugo version</code></pre>
<h3id="windows-users">Windows users</h3>
<p>Installing on Windows is a bit more involved than on OSX. The authors of Hugo provide <ahref="https://gohugo.io/tutorials/installing-on-windows/">a guide</a> with instructions for technical and less technical users.</p>
<p>It’s also best you install a Windows Subsystem for running Linux, and therefore <ahref="https://en.wikipedia.org/wiki/Bash_(Unix_shell)">bash</a> (<strong>Infusion</strong> incorporates some bash commands in its scripts). <ahref="https://msdn.microsoft.com/en-gb/commandline/wsl/install_guide">Microsoft offer a complete guide</a>.</p>
<h2id="install-node-npm">Install Node & NPM</h2>
<p>It is likely you already have Node and NPM installed on your system. If so, you can skip this step. Otherwise, <ahref="https://docs.npmjs.com/getting-started/installing-node">refer to NPM’s own guide</a>, which includes a video tutorial.</p>
<p><strong>Infusion</strong> is hosted on Github. To start using it, you’ll need to get the files from there. If you are comfortable with the command line, just fork the <ahref="https://github.com/ThePacielloGroup/infusion">github.com/ThePacielloGroup/infusion</a> repository, then do a <code>git clone</code> to your local system. Replace <code>[your username]</code> in the following:</p>
<p>If the command line is not your thing, fork <ahref="https://github.com/ThePacielloGroup/infusion">github.com/ThePacielloGroup/infusion</a> and choose <strong>Open in Desktop</strong> from <strong>Clone or download</strong> (see figure 1, below).</p>
<p><imgsrc="https://thepaciellogroup.github.io/infusion/images/open_in_desktop.png"alt="The open in desktop option, revealed when clicking clone or download"/></p>
<p>Now it’s time to consult the <aclass="pattern-link"href="https://thepaciellogroup.github.io/infusion/patterns/library-setup/"><svgclass="bookmark"aria-hidden="true"viewBox="0 0 40 50"focusable="false"><usexlink:href="#bookmark"></use></svg>Library setup</a> pattern.</p>
<p>By now, you should have followed the <aclass="pattern-link"href="https://thepaciellogroup.github.io/infusion/patterns/installation/"><svgclass="bookmark"aria-hidden="true"viewBox="0 0 40 50"focusable="false"><usexlink:href="#bookmark"></use></svg>Installation</a> instructions. You should have Hugo and Node installed, and a local copy of a forked version of <strong>Infusion</strong>. You should also have run <code>npm install</code> in the root of that codebase.</p>
<h2id="cleaning-the-content-folder">“Cleaning” the content folder</h2>
<p>Before you can start documenting patterns, there are a few things still to do in order to get set up. At the moment, your version of <strong>Infusion</strong> is a facsimile of the original, containing all this documentation content. We want to delete that content and replace it with some starter content. There’s a simple <code>clean</code> command for this.</p>
<p>If you are contributing to an existing <strong>Infusion</strong> library, do not run the following command. It will delete all of the patterns in that library. The <code>clean</code> command is just for libraries that you are starting from scratch.</p>
<p>This will leave your <code>content</code> folder with just an <code>_index.md</code> file and a <code>patterns</code> folder containing a single demonstration pattern file. Find out more about these in <aclass="pattern-link"href="https://thepaciellogroup.github.io/infusion/patterns/writing/library-structure/"><svgclass="bookmark"aria-hidden="true"viewBox="0 0 40 50"focusable="false"><usexlink:href="#bookmark"></use></svg>Library structure</a>.</p>
<p>You’ll also want to name your library and configure one or two other things in the <code>config.toml</code> file that’s found at the root of your project. Here’s how that file looks:</p>
description = "Documentation for the **Infusion** pattern library builder. This documentation is constructed using the builder itself."
codePenUser = "Heydon"
</code></pre>
<ul>
<li><strong>title</strong> — This is the library’s name, like “Megacorp 5000 Pattern Library”. You don’t have to include the term “pattern library” if you don’t want to. For <strong>Infusion’s</strong> own version of <strong>Infusion</strong>, the <code>title</code> is, naturally, <em>Infusion</em> :-)</li>
<li><strong>baseURL</strong> — This is the root of the live site. Typically you will publish the site to Github Pages, so this should be the base URL for your Github Pages site.</li>
<li><strong>theme</strong> — This is the theme the library is using. Don’t change this from “infusion”.</li>
<li><strong>description</strong> — This is a short description of the library and comes under the logo. You can include markdown syntax here, like <em>**Infusion**</em> in the above example for making the name of the library bold.</li>
<li><strong>codePenUser</strong> — If you want to embed codePens in your pattern files, you need to supply a codePen username here.</li>
<h2id="the-web-app-manifest">The Web App Manifest</h2>
<p><strong>Infusion</strong> libraries work as progressive web applications, meaning users can save them to their home screen and read them offline. The web app manifest, found at the root of the <code>static</code> folder defines names and icons for the app. You’ll probably want to open <code>/static/manifest.json</code> and personalize the <code>name</code> and <code>short_name</code> values.</p>
<p><imgsrc="https://thepaciellogroup.github.io/infusion/images/samsung_homescreen.png"alt="Teacup Infusion app icon with Infusion Docs written underneath"/></p>
<p>The <code>short_name</code> value refers to the text that appears under the icon on your homescreen. As the name suggests, it should be as short as possible to fit well.</p>
<p>In the <code>images/static</code> folder, you’ll find a <code>logo.svg</code> file. Replace this file with your own company or project logo. Currently, only the SVG is supported this easily because SVG the superior format for logotypes. However, if you must use a different format, you can open up the <code>themes/infusion/layouts/_default/baseof.html</code> file and edit the image reference:</p>
<pre><codeclass="language-html"><a class="logo" href="/" aria-label="{{ .Site.Title }} pattern library home page">
<p>Now that your logo’s in place, everything should be ready. Where next? You can learn about <aclass="pattern-link"href="https://thepaciellogroup.github.io/infusion/patterns/writing/library-structure/"><svgclass="bookmark"aria-hidden="true"viewBox="0 0 40 50"focusable="false"><usexlink:href="#bookmark"></use></svg>Library structure</a> to help you get writing, or find out how to serve the library locally and on Github Pages in <aclass="pattern-link"href="https://thepaciellogroup.github.io/infusion/patterns/serving/"><svgclass="bookmark"aria-hidden="true"viewBox="0 0 40 50"focusable="false"><usexlink:href="#bookmark"></use></svg>Serving</a>.</p>
<p>While you’re creating content for your library, you’ll probably want to see what the finished product looks like. Fortunately, <strong>Infusion</strong> is easy to serve locally using the <code>serve</code> command:</p>
<preclass="cmd"><code>npm run serve</code></pre>
<p>This will serve your working library from <code>localhost:1313</code>. Whenever you make changes to your library’s files, the site will automatically rebuild. No need to refresh the web page!</p>
<h2id="publishing-on-github-pages">Publishing on Github Pages</h2>
<p><strong>Infusion</strong> creates a <code>/docs</code> folder containing the latest version of your library whenever you do an <code>npm run build</code> or a <code>git commit</code>. So long as you forked the <strong>Infusion</strong> repository when making your own library (see <aclass="pattern-link"href="https://thepaciellogroup.github.io/infusion/patterns/library-setup/"><svgclass="bookmark"aria-hidden="true"viewBox="0 0 40 50"focusable="false"><usexlink:href="#bookmark"></use></svg>Library setup</a>), whenever you push to master, you will also be updating the site found at your Github Pages URL.</p>
<p>You’ll also need to add this value to your <code>config.toml</code> file as the <code>baseURL</code>. For <strong>Infusion</strong>’s own documentation it looks like the following. Just overwrite it.</p>
<p>If you created a new library repo manually (without forking) you will find the <code>docs</code> folder is not automatically setup as the publishing source. This folder can be made the source for your Github Pages site by selecting it under <strong>Settings → Github Pages → Source</strong> in the web interface.</p>
<p><imgsrc="https://thepaciellogroup.github.io/infusion/images/serve_from_docs.png"alt="The publishing source dropdown menu on Github"/></p>
<p><strong>Infusion</strong>’s output site includes a one-page <aclass="pattern-link"href="https://thepaciellogroup.github.io/infusion/print-version/"><svgclass="bookmark"aria-hidden="true"viewBox="0 0 40 50"focusable="false"><usexlink:href="#bookmark"></use></svg>Print version</a> of the generated library, available at <code>/print-version</code>. So, if your library base URL is <code>https://yourName.github.io/your-library</code>, you can print the whole library — to PDF if wanted — from the following address:</p>
<li><strong>_index.md</strong> — This is the content file for your home page.</li>
<li><strong>print-version.md</strong> — This is a placeholder for the single-page / print-friendly version of you library. Leave this file as it is.</li>
<li><strong>/patterns</strong> — This is the folder where individual pattern files are kept.</li>
</ul>
<h2id="subsections">Subsections</h2>
<p>You may have noticed that this site’s navigation is divided partly into subsections, with labels like “Writing”. <strong>Infusion</strong> (or, rather, Hugo) allows you to create such subsections by simply nesting folders under the <code>/patterns</code> folder. In the following example, I have a subsection about different types of “popup” pattern.</p>
<p>Note that subfolders like <code>/popups</code> must each have an <code>_index.md</code> file. This file doesn’t need any content except the TOML metadata defining the title (name) of that subsection:</p>
<pre><code>+++
title = "Popups"
+++
</code></pre>
<p>The <code>/patterns</code> folder itself does not need indexing explicitly in this way.</p>
<p><strong>Infusion</strong> does not currently support <em>sub</em>-subsections.</p>
<p>Now that you know where to put everything, it’s time to talk about how to actually write individual patterns. Don’t worry, it’s pretty straightforward. Turn to <aclass="pattern-link"href="https://thepaciellogroup.github.io/infusion/patterns/writing/markdown-and-metadata/"><svgclass="bookmark"aria-hidden="true"viewBox="0 0 40 50"focusable="false"><usexlink:href="#bookmark"></use></svg>Markdown & metadata</a>.</p>
<p>In <strong>Infusion</strong>, design patterns are documented using markdown. To create a new pattern file, just add a file with the <code>.md</code> extension to the <code>/patterns</code> folder. It’s recommended you use “kebab case” to name the file ( words separated by hyphens). For example, a pattern with the title “Menu button” should probably have the filename <code>menu-button</code>. Then you get a nice clean URL: <code>username.github.io/your-library/patterns/menu-button</code>.</p>
<p>If you’re not familiar with writing markdown, there are a number of tutorials available. One of the best is <ahref="https://guides.github.com/features/mastering-markdown/">Mastering Markdown</a> offered by Github. There’s also a <ahref="https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet">nice cheatsheet here</a>.</p>
<h2id="the-metadata">The metadata</h2>
<p>Like many static site generators, Hugo lets you add metadata to its markdown files. Hugo’s brand of metadata is called TOML (although YAML is also accepted). The only thing you <em>have</em> to put in the TOML is a <code>title</code> — like this:</p>
<pre><code>+++
title = "Menu button"
+++
</code></pre>
<h3id="tags">Tags</h3>
<p>If you like, you can also tag the pattern so that it turns up in lists of similar content. You add tags in an array format. Note that all the TOML data is found at the top of the markdown file, between the <code>+++</code> lines.</p>
<p>This will create links to pages listing content tagged with the same terms using the URL schema <code>/tag/[tag name]</code>. Some example tags links are provided for this page, which you can see listed under the main heading.</p>
<h3id="weight">Weight</h3>
<p>By default, patterns are listed in alphabetical order. However, sometimes you might like to change the order around. This is possible by adding a <code>weight</code> parameter. To make my menu button pattern appear at the top of its subsection, I would give it a <code>weight</code> of <code>1</code>:</p>
<p>In some cases, where there is a lot of content, it’s helpful to collapse certain sections. That way, readers get an overview of what’s in the content and can choose where to focus in. <strong>Infusion</strong> provides a shortcode method for creating expandable sections which generates accessible markup using <code>aria-expanded</code>.</p>
<p>The <code>expandable</code> shortcode takes three parameters:</p>
<ul>
<li><strong>label</strong> — This is the label for the the section heading.</li>
<li><strong>level</strong> — This is the heading level (e.g. <code>level="2"</code> for a <code><h2></code>) that will contain the label. If you omit a level parameter, no heading is used; it’s just a button.</li>
<li><strong>open</strong> — Include this and give it a value of “true” or “yes” to make the section expanded on page load.</li>
</ul>
<p>Here’s what the code might look like for a simple expandable section containing markdown:</p>
<preclass=" "><codedata-codeblock-shortcode>
{{% expandable label="A section of dummy text" level="2" %}}
Here is some markdown including [a link](https://twitter.com/heydonworks). Donec erat est, feugiat a est sed, aliquet pharetra ipsum. Vivamus in arcu leo. Praesent feugiat, purus a molestie ultrices, libero massa iaculis ante, sit amet accumsan leo eros vel ligula.
<p>Here is some markdown including <ahref="https://twitter.com/heydonworks">a link</a>. Donec erat est, feugiat a est sed, aliquet pharetra ipsum. Vivamus in arcu leo. Praesent feugiat, purus a molestie ultrices, libero massa iaculis ante, sit amet accumsan leo eros vel ligula.</p>
</div>
</div>
<p>Successive collapsible sections fit snugly together. The second of the following two has <code>open="true"</code>.</p>
<p>Mauris eget elit ut neque venenatis placerat id nec libero. Nunc accumsan cursus elit nec iaculis. Proin id rutrum magna, a aliquet sem. Sed et tortor id sem eleifend porta vitae eget elit. Cras sodales porta malesuada. Suspendisse at odio ac tortor.</p>
<p>Ut vulputate enim ut lorem iaculis, vel faucibus metus iaculis. Aliquam erat volutpat. Aliquam luctus orci vel consectetur dignissim. Nullam et efficitur lorem, et ornare est. Sed tristique porttitor justo, quis malesuada velit. Nullam et elit finibus, sollicitudin velit placerat, ultricies dui.</p>
</div>
</div>
<p>Unfortunately, it is not currently possible to include shortcodes inside other shortcodes, using the “<code>%</code>” notation (which is designated for markdown content). If you use the angle brackets notation (illustrated below) it is possible, but markdown will no longer be permitted. You will have to code HTML inside such a section manually.</p>
<preclass=" "><codedata-codeblock-shortcode>
{{<expandable label="A section of dummy text" level="2">}}
<p>Here is a pattern reference shortcode: {{% pattern "Writing inline demos" %}}.</p>
<p>When you go to print a pattern from your library, some print styles take care of collapsible sections, making them appear expanded and like any other section.</p>
<p><strong>Infusion</strong> acknowledges that simple markdown is limiting when it comes to writing compelling documentation, so it provides a number of “shortcodes”. Shortcodes offer a simple syntax for including rich content. For example, <strong>Infusion</strong> provides shortcodes for including notes and warnings.</p>
<h2id="notes">Notes</h2>
<p>You may wish to pick out some content in your pattern’s documentation as a note — an aside to the main thrust of the pattern’s description. This is possible using the following syntax:</p>
<preclass=" "><codedata-codeblock-shortcode>
{{% note %}}
This is a note! It's something the reader may like to know about but is supplementary to the main content. Use notes when something may be interesting but not critical.
<p>This is a note! It’s something the reader may like to know about but is supplementary to the main content. Use notes when something may be interesting but not critical.</p>
</div>
</aside>
<h2id="warnings">Warnings</h2>
<p>Warnings are like notes, but with more urgency.</p>
<preclass=" "><codedata-codeblock-shortcode>
{{% warning %}}
This is a warning! It's about something the reader should be careful to do or to avoid doing. Use warnings when something could go wrong.
<p><strong>Infusion</strong> provides an easy mechanism to cross-reference patterns, by title, using the <code>pattern</code> shortcode. For example, I can reference the <aclass="pattern-link"href="https://thepaciellogroup.github.io/infusion/patterns/writing/notes-and-warnings/"><svgclass="bookmark"aria-hidden="true"viewBox="0 0 40 50"focusable="false"><usexlink:href="#bookmark"></use></svg>Notes & warnings</a> pattern. Here’s what the markdown looks like, including the shortcode:</p>
I can reference the {{% pattern "Notes & warnings" %}} pattern here.
</code></pre>
<p>This saves you having to worry about pathing and decorates the generated link with a bookmark icon, identifying the link as a pattern reference visually.</p>
<p>The title argument you supply to the shortcode must be exactly the same as the referenced pattern’s <code>title</code> metadata value and is case sensitive.</p>
</div>
</aside>
<h2id="wcag-references">WCAG References</h2>
<p><ahref="https://www.w3.org/TR/WCAG/">WCAG 2.0</a> is the <em>de facto</em> standard for accessible interfaces. When writing about inclusive design patterns, sometimes you’ll want to refer to WCAG to highlight which success criteria the pattern meets.</p>
<p>Instead of having to copy and paste content and links to WCAG, <strong>Infusion</strong> provides a shortcode mechanism that lets you simply list the success criteria by number:</p>
<preclass=" "><codedata-codeblock-shortcode>
{{% wcag include="1.2.1, 1.3.1, 4.1.2" %}}
</code></pre>
<p>This generates a list of references that includes the names of each criterion and links to them directly. Like this:</p>
<p>You don’t have to leave spaces after the comma separators. They are optional.</p>
</div>
</aside>
<h3id="full-descriptions">Full descriptions</h3>
<p>Sometimes, you’ll want to include the full descriptions of the success criteria inline. This is possible by setting <code>descriptions</code> to <code>true</code>:</p>
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
<p>Some inclusive design concepts are not reducible to success or fail criteria. This is why The Paciello Group wrote the <ahref="http://inclusivedesignprinciples.org/">Inclusive Design Principles</a>. These can be listed by name.</p>
<p><preclass=" "><codedata-codeblock-shortcode>
{{% principles include="Add value, Be consistent" descriptions="true" %}}
</code></pre>
</p>
<p>Here’s the output with <code>descriptions="true"</code>:</p>
<em>Use familiar conventions and apply them consistently.</em>
<p>Familiar interfaces borrow from well-established patterns. These should be used consistently within the interface to reinforce their meaning and purpose. This should be applied to functionality, behavior, editorial, and presentation. You should say the same things in the same way and users should be able to do the same things in the same way.</p>
<em>Consider the value of features and how they improve the experience for different users.</em>
<p>Features should add value to the user experience by providing efficient and diverse ways to find and interact with content. Consider device features such as voice, geolocation, camera and vibration API's, and how integration with connected devices or a second screen could provide choice.</p>
<p>A lot of the time, your larger patterns will share some common techniques and utilities. For this reason, <strong>Infusion</strong> lets you save snippets of markdown in a <strong>snippets</strong> folder, alongside the main content folder.</p>
<p>The example <code>visually-hidden.md</code> snippet describes the CSS needed to create content that is visually hidden but still available to screen readers. Since this is a technique/utility you are likely to use often, it’s nice to be able to just drop a snippet into your markdown content. The <code>snippet</code> shortcode lets you do exactly that:</p>
<p>To make your snippets truly reusable, try to write them in such a way that they make sense independent of surrounding text, a little bit like this note does.</p>
<p>Pattern pages in <strong>Infusion</strong> that have two or more subheadings — <code><h2></code>s — automatically get a <strong>table of contents</strong>: a list of links to the main subsections for the page. This feature is made accessible as a navigation region with the “Table of contents” label and uses an ordered list. The table of contents markup for the <aclass="pattern-link"href="https://thepaciellogroup.github.io/infusion/patterns/library-setup/"><svgclass="bookmark"aria-hidden="true"viewBox="0 0 40 50"focusable="false"><usexlink:href="#bookmark"></use></svg>Library setup</a> page looks something like this:</p>
<a href="#including-a-logo">Including a logo</a>
</li>
</ol>
</nav>
</code></pre>
<p>Tables of contents are a neat way to break down the content of the page and give users a navigable overview. However, they may not be to your taste. Never fear, you can turn tables of contents off by adding <code>toc = false</code> to the TOML metadata for your pattern:</p>
<p>From time to time, you’ll be wanting to include images illustrating the documented pattern in hand. Images live in the static folder, which is a sibling of the <code>/content</code> folder you’ll be mostly working in.</p>
<p>When you first make a copy of <strong>Infusion</strong>, <strong>Infusion’s</strong> own logo will be included. You should replace this with your own company or project logo.</p>
</div>
</aside>
<p>The path to the <code>/images</code> folder should begin with a forward slash, so include that when referencing images in your markdown.</p>
<p>Sometimes you will want to include a caption with your illustration. This is what the <code><figure></code> and <code><figcaption></code> elements are for. However, <strong>Infusion</strong> doesn’t ask you to code all that manually. A special shortcode is provided, which takes a <code>caption</code> parameter. Note that the image markdown is provided between the opening and closing shortcode tags, and that you can use markdown syntax in the <code>caption</code> value.</p>
<p><imgsrc="https://thepaciellogroup.github.io/infusion/images/bad_design_system.png"alt="Diagram of a design pattern represented by a turd emoji begetting three bad implementations"/></p>
<p><img src="http://localhost:1313/images/bad_design_system.png" alt="Diagram of a design pattern represented by a turd emoji begetting three bad implementations"></p>
<p><strong>Infusion</strong> has a lot of its own shortcodes, but you can still use Hugo’s <ahref="https://gohugo.io/extras/shortcodes#built-in-shortcodes">built in shortcodes</a>. These include a simple shortcode for including YouTube videos in your content. The shortcode takes just one parameter — the video’s <code>id</code>.</p>
<p>Markdown already supports code samples both inline (using single backticks like `some code here`) and in blocks. <strong>Infusion</strong> will syntax highlight HTML, CSS, and JavaScript if you provide the correct language in the formulation of the block.</p>
<p>Note that the syntax highlighting uses a greyscale theme. <strong>Infusion</strong> is careful not to use color as part of its own design, because these colors may clash with those of the design being illustrated and discussed.</p>
<p>In addition to the basic markdown support, <strong>Infusion</strong> provides a mechanism to display code blocks with line numbers. This is via the <code>codeBlock</code> shortcode. Here is the code for a block of JavaScript with line numbers:</p>
<preclass=" "><codedata-codeblock-shortcode>
{{<codeBlock lang="js" numbered="true">}}
var toggle = demo.querySelector('[aria-pressed]');
toggle.addEventListener('click', (e) => {
let pressed = e.target.getAttribute('aria-pressed') === 'true';
e.target.setAttribute('aria-pressed', !pressed);
});
{{</codeBlock>}}
</code></pre>
<p>The output will look like the following. Now you can refer to particular bits of the code by line number, like the arrow function on line <code>3</code>.</p>
<p>To preserve the wrapping inside code blocks, horizontal scrolling is implemented. To make sure scrolling is keyboard accessible, code blocks are focusable. An <code>aria-label</code> is provided to identify the code block to screen reader users.</p>
<p>Sometimes just pictures of the pattern you’re documenting aren’t enough. Interactive patterns benefit from live demos, so that readers can test their functionality.</p>
<h2id="codepen">CodePen</h2>
<p><strong>Infusion</strong> offers a couple of ways to do this. The first is by embedding CodePen demos into the content. The <code>codePen</code> shortcode takes just one argument: the codePen’s <code>ID</code>.</p>
<preclass=" "><codedata-codeblock-shortcode>
{{% codePen VpVNKW %}}
</code></pre>
<p>This will embed the identified codePen into the content wherever you placed the shortcode, with the result view showing by default:</p>
<iframeheight="300"scrolling="no"title="code demonstration with codePen"src="//codepen.io/heydon/embed/VpVNKW/?height=265&theme-id=dark&default-tab=result,result&embed-version=2"frameborder="no"allowtransparency="true"allowfullscreen="true"style="width: 100%;">
<div>
<ahref="//codepen.io/heydon/pen/VpVNKW">See the demo on codePen</a>
<p>The compiled site will output an error if your <code>config.toml</code> does not include your CodePen username (in the <code>codePenUser</code> parameter). This is needed to construct the embed URL.</p>
</div>
</aside>
<h2id="jsbin">jsBin</h2>
<p>You can embed JS Bins just like CodePens, supplying a single <code>id</code> parameter.</p>
<preclass=" "><codedata-codeblock-shortcode>
{{% jsBin juwowaq %}}
</code></pre>
<p>However, you can also have finer control over which panes are displayed. Use two parameters: one for the <code>id</code> and another, <code>show</code>, listing the panes you want to include.</p>
<preclass=" "><codedata-codeblock-shortcode>
{{% jsBin id="juwowaq" show="css,output" %}}
</code></pre>
<p>The options for the <code>show</code> parameter are:</p>
<ul>
<li>html</li>
<li>css</li>
<li>js</li>
<li>console</li>
<li>output</li>
</ul>
<p>(Note that, under some circumstances, the <code>html</code> pane is added whether you select it or not.)</p>
<iframesrc="https://jsbin.com/juwowaq/embed?css%2coutput"title="JS Bin demo"height="300"width="100%"></iframe>
<p><strong>Infusion</strong> also supports the ability to write inline demos directly in markdown files. See <aclass="pattern-link"href="https://thepaciellogroup.github.io/infusion/patterns/coding/writing-inline-demos/"><svgclass="bookmark"aria-hidden="true"viewBox="0 0 40 50"focusable="false"><usexlink:href="#bookmark"></use></svg>Writing inline demos</a>.</p>
<p>There are some issues with , like them not working offline. They also come with CodePen branding, which will clash with the pattern you’re trying to illustrate.</p>
<p><strong>Infusion</strong> offers another option: a special <code>demo</code> shortcode that allows you to write HTML, CSS, and JavaScript directly into the markdown file. The outputted demo is encapsulated using Shadow DOM, so you don’t have to worry about broken styles and global JS.</p>
<p>Here’s the example code for an inline demo of a toggle button:</p>
var toggle = demo.querySelector('[aria-pressed]');
toggle.addEventListener('click', (e) => {
let pressed = e.target.getAttribute('aria-pressed') === 'true';
e.target.setAttribute('aria-pressed', !pressed);
});
</script>
{{</demo>}}
</code></pre>
<p>Note the <code>demo.querySelector</code> on line <code>21</code>. <strong>Infusion</strong> automatically provides <code>demo</code>, representing the root node of the demo. It’s like the <code>document</code> keyword but for a demo’s subtree.</p>
<p>Here’s a live demo of… the demo:</p>
root.innerHTML = '<pclass="site-error"><strongstyle="font-weight:bold">Site error:</strong> A browser supporting Shadow DOM is needed to run encapsulated demos. You can launch the demo in a separate window ↓</p>';
<li>It provides a fallback for browsers that do not support Shadow DOM encapsulation (a warning message will replace the inline demo).</li>
<li>It creates an isolated test case for the demo, allowing you to run browser extensions and bookmarklets on the the demo code and <em>just</em> the demo code.</li>
<p>It’s possible to give your demo a caption using an accessible <code><figure></code> and <code><figcaption></code> structure. All <em>you</em> need to do is supply a <code>caption</code> attribute. For example:</p>
<p>Along with the standard <code>figure</code> shortcodes (described in <aclass="pattern-link"href="https://thepaciellogroup.github.io/infusion/patterns/media/including-images/"><svgclass="bookmark"aria-hidden="true"viewBox="0 0 40 50"focusable="false"><usexlink:href="#bookmark"></use></svg>Including images</a>), demo figures are numbered automatically according to their order in the page. You can use markdown syntax in the caption text value.</p>
<p>Sometimes your component will be expected to appear in a context where the parent element has a background color. You can add a backgroundColor for your demo block using the <code>backgroundColor</code> attribute. Any valid CSS color value is acceptable:</p>
<p>There’s no reason why your <strong>Infusion</strong>-powered pattern library has to be all about functionality. You can include style guide-like information such as color palettes too. The <code>colors</code> shortcode makes it easy to exhibit colors and their values together. Just supply a comma-separated list of CSS color values.</p>
<preclass=" "><codedata-codeblock-shortcode>
{{% colors "#111111, #cccccc, #ffffff" %}}
</code></pre>
<p>The result is a one row strip showing each color supplied in order. The colors for <strong>Infusion</strong> are greyscale:</p>
<p>If you’re wondering whether you need to put a space after the commas in the shortcode, don’t worry: <code>"#254f7b, #579a6d, #666666"</code> and <code>"#254f7b,#579a6d,#666666"</code> are both accepted. Any CSS color value is acceptable, not just hex colors.</p>
<p>Your pattern documentation may need to include commands for installing packages or using <abbrtitle="command line interface">CLI</abbr>s. <strong>Infusion</strong> offers the <code>cmd</code> shortcode for making code blocks look like terminal commands.</p>
<p>The <code>cmd</code> shortcode currently only supports single commands. If you want to show multiple, successive commands use separate <code>cmd</code> blocks.</p>
<p>Representing folder/file structures is simple and accessible in <strong>Infusion</strong>. Which is just as well, because some components may need to conform to a certain folder structure.</p>
<p>The file tree is described using a markdown nested list structure:</p>
<preclass=" "><codedata-codeblock-shortcode>
{{% fileTree %}}
* Level 1 folder
* Level 2 file
* Level 2 folder
* Level 3 file
* Level 3 folder
* Level 4 file
* Level 3 folder
* Level 4 file
* Level 4 file
* Level 3 file
* Level 2 folder
* Level 3 file
* Level 3 file
* Level 3 file
* Level 2 file
* Level 1 file
{{% /fileTree %}}
</code></pre>
<p>This is drawn in the following fashion, but preserves the underlying nested list structure for assistive technologies such as screen readers:</p>
<p>The only reliable way to nest unordered lists in markdown is to indent the nested item by exactly four spaces. Using tabs or less than four spaces are unreliable methods.</p>
<p>When you’re an inclusive designer, it’s pertinent to do some testing. Following specs is one thing, but you need to verify that your component works okay for users.</p>
<p><strong>Infusion</strong> provided a <code>tested</code> shortcode that lets you show which browsers and assistive technologies you’ve tried your design out in. Here’s an example. Note the commas and “+” signs.</p>
<p>The value for the <code>using</code> attribute follows a specific format: each testing setup is separated by a comma (with a space if you like, but it’s not mandatory). If you want to add an assistive technology (or any other “add on”) this needs to follow a “+”. This additional part can be anything, like “A VR headset I borrowed”, but there are only a few browser terms available. These are case sensitive, so you need to write them as below:</p>
<ul>
<li>Firefox</li>
<li>Chrome</li>
<li>Safari</li>
<li>IE</li>
<li>Edge</li>
<li>Opera</li>
<li>Chrome Android</li>
<li>Firefox Android</li>
<li>Safari iOS</li>
</ul>
<p>Obviously, this is not a comprehensive list and more may be added over time. But it covers most of the main browsers for pairing with other software — at least for testing purposes.</p>
