davidbgk
/
larlet-fr-david-cache


			
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314
							<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
  See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
  See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Progressively Enhanced Builds (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
    function toggleTheme(themeName) {
        document.documentElement.classList.toggle(
            'forced-dark',
            themeName === 'dark'
        )
        document.documentElement.classList.toggle(
            'forced-light',
            themeName === 'light'
        )
    }
    const selectedTheme = localStorage.getItem('theme')
    if (selectedTheme !== 'undefined') {
        toggleTheme(selectedTheme)
    }
</script>

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://blog.jim-nielsen.com/2022/progressively-enhanced-builds/">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
  <header>
    <h1>Progressively Enhanced Builds</h1>
  </header>
  <nav>
    <p class="center">
      <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
      </svg> Accueil</a> •
      <a href="https://blog.jim-nielsen.com/2022/progressively-enhanced-builds/" title="Lien vers le contenu original">Source originale</a>
    </p>
  </nav>
  <hr>
  <p>With the advent of the Jamstack, so many of websites require a build step of some kind before a functioning website can be born.</p>
<p>Build steps are great. I use them all the time. But they do come at a cost.</p>
<p>One of those costs is fragility—builds are prone to breaking. It’s not uncommon to setup a project, return to it six weeks later, run <code>npm install &amp;&amp; npm start</code>, and <em>something</em> breaks. Then begins the troubleshooting. A project from 6 days ago, 6 weeks ago, or 6 years ago, each one of those could present its own set of build problems. Often, you end up with a non-functioning website you cannot edit, test, and update until your build is fixed.</p>
<p>We have a strategy for delivering robust, <a href="https://resilientwebdesign.com">resilient</a> experiences to users in the browser: progressive enhancement. Start with the most basic functionality that lets people do what they need, then enhance from there. In this way, lots of things could go wrong — JavaScript doesn’t load, network calls fail, the user is on an old browser, etc. — but the website remains functional and accessible.</p>
<p>What if we applied a mindset of progressive enhancement to builds and not only user agents? What if build processes were thought of as enhancements and not dependencies? Can you have a progressively enhanced build?</p>
<h2 id="conceptual-underpinnings">Conceptual Underpinnings</h2>
<p>I’ve had a few thoughts swirling in my head around this idea.</p>
<p>First there’s <a href="https://www.baldurbjarnason.com/2021/100-things-every-web-developer-should-know/">Baldur Bjarnason</a> who speaks on the value of tight feedback loops:</p>
<blockquote>
<p>Tight feedback loops are magic: build processes suck. They will always suck because they always loosen up the feedback loop. You can make builds quicker, but until they are virtually instantaneous, they will always suck…If you can make something without a build step, do so. If you can make something without compilation or building, do that. </p>
</blockquote>
<p>Then there’s <a href="https://inoads.com/articles/2021-01-09-Next-Gen-Static-Blogging">this proof-of-concept post from Maximilian Mackh</a> (with some <a href="https://news.ycombinator.com/item?id=25701053">intriguing hackernews comments</a>) which shows how to write a blog post and skip the build process using nifty tricks from HTML and CSS.</p>
<blockquote>
<p>My workflow consists of pressing CMD+S, switching to Safari and reloading the page. What you see now is what I get.</p>
</blockquote>
<p>Then there’s <a href="https://www.robinrendle.com/notes/blogging-and-the-heat-death-of-the-universe/">this post from Robin</a> who notes that entropy acts on all things, including websites and build processes until the last thing left standing is the markup.</p>
<blockquote>
<p>That complex build process? That’s a dependency…</p>
<p>the thing that lasts longest with our websites is probably the part that we spend the least time thinking about—the markup…</p>
<p>This is the second law of thermodynamics made clear on the web: the entropy of any isolated system always increases and, at some point or another, all that’s left of a website is the markup.</p>
</blockquote>
<p>Then there’s <a href="https://adactio.com/journal/17537">this post from Jeremy</a> which details how to think about your website’s features as an enhancements rather than dependencies.</p>
<blockquote>
<p>You certainly couldn’t use an experimental feature for anything mission critical…but you could use it as an enhancement.</p>
<p>And that is a pretty great way to think about all web features, experimental or otherwise. Don’t assume the feature will be supported. Use feature detection (or @supports in the case of CSS). Try to use the feature as an enhancement rather than a dependency.</p>
</blockquote>
<p>The key is to, as Jeremy says, “acknowledge and embrace unpredictability”. That seems like solid advice, whether you’re building on the client <em>or the server</em>.</p>
<blockquote>
<p>Instead of looking at the support table for something on caniuse.com and thinking, “I wish more browsers supported this feature so that I could use it!”, you can instead think “I’m going to use this feature today, but treat it as an experimental feature.”</p>
</blockquote>
<p>In a similar vein, what if you could look at building a website in a different light? Rather than thinking, “how do I combine a bunch of disparate content, templates, and tooling into a functioning website?”, you might think “how do I start at a functioning website with content and then use templates and build tooling to enhance it?”</p>
<p>[Granted: this is not a silver bullet for building every website. Lots of websites can’t start here—but maybe some could?]</p>
<h2 id="technical-ideas">Technical Ideas</h2>
<p>What could this look like? Honestly, I don’t know. But I’ll take a moment to try and imagine <em>something</em>.</p>
<p>I want to be able to view, edit, <em>and if need be ship</em> a website, even if the build process fails. In essence, if the build does fail I can still take all the source files, put them on a server, and the website remains functional (however crude).</p>
<p>I think this kind of approach begs for an HTML-first solution. Your content starts as something that works in the browser — in a less-than-ideal way, sure, but still functional — and the build process parses the base content, injecting additional “features” as enhancements (global header and footer, meta tags, links to CSS and JS, etc.). In this manner, your website starts as content at a URL. Everything else is an enhancement.</p>
<p>For example, think of a classic blog post as a markdown file.</p>
<pre><code class="language language-md">---
title: This is the title of my blog post
date: 2020-09-02
tags: 
<span class="hljs-bullet">  -</span> readingNotes
<span class="hljs-section">  - somethingElse
---</span>

<span class="hljs-section"># This is the title of my post</span>

I just want to start writing here whatever it is i'm about.

This is just another example of how you might do something that is really light and minimal. [<span class="hljs-string">Here’s a link</span>](<span class="hljs-link">./another-post.md</span>)

![<span class="hljs-string">An image for my blog post</span>](<span class="hljs-link">../images/my-image.jpg</span>)
</code></pre>
<p>What if you rewrote that using HTML for the front-matter semantics? If you want to continue to author the content of the post in markdown, do it, but embed it in a web component (which would get “enhanced” and rendered to HTML somewhere further down the line).</p>
<p>What’s beautiful about markdown is that it’s a kind of progressively-enhanced syntax for writing: link and image URLs are still accessible even when unparsed.</p>
<pre><code class="language language-html"><span class="hljs-meta">&lt;!doctype <span class="hljs-keyword">html</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">title</span>&gt;</span>This is the title of my blog post<span class="hljs-tag">&lt;/<span class="hljs-name">title</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">meta</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"date"</span> <span class="hljs-attr">content</span>=<span class="hljs-string">"2020-09-02"</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">meta</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"tags"</span> <span class="hljs-attr">content</span>=<span class="hljs-string">"readingNotes,somethingElse"</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">wc-markdown</span> <span class="hljs-attr">style</span>=<span class="hljs-string">"white-space: pre-line"</span>&gt;</span>
# This is the title of my post

I just want to start writing here whatever it is i'm about.

This is just another example of how you might do something that is really light and minimal. [Here is a link](./another-post.html)

![An image for my blog post](../images/my-image.jpg)
<span class="hljs-tag">&lt;/<span class="hljs-name">wc-markdown</span>&gt;</span>
</code></pre>
<p class="image-container"><img src="https://cdn.jim-nielsen.com/blog/2022/progressive-build-markdown.png" alt="">

</p>
<p>There are trade-offs here: authoring in markdown is a convenience for me, the author, and results in a more crude initial experience (if a build enhancement fails later).</p>
<p>Given that markdown supports HTML, you could trade the image syntax (<code>![]()</code>) for <code>&lt;img&gt;</code> tags or the link syntax (<code>[]()</code>) for <code>&lt;a&gt;</code> tags. That’ll improve the core experience a tiny bit in the browser, as links would be functionally clickable and images would display directly inline.</p>
<pre><code class="language language-html"><span class="hljs-meta">&lt;!doctype <span class="hljs-keyword">html</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">title</span>&gt;</span>This is the title of my blog post<span class="hljs-tag">&lt;/<span class="hljs-name">title</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">meta</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"date"</span> <span class="hljs-attr">content</span>=<span class="hljs-string">"2020-09-02"</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">meta</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"tags"</span> <span class="hljs-attr">content</span>=<span class="hljs-string">"readingNotes,somethingElse"</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">wc-markdown</span> <span class="hljs-attr">style</span>=<span class="hljs-string">"white-space: pre-line"</span>&gt;</span>
# This is the title of my post

I just want to start writing here whatever it is i'm about.

This is just another example of how you might do something that is really light and minimal. <span class="hljs-tag">&lt;<span class="hljs-name">a</span> <span class="hljs-attr">href</span>=<span class="hljs-string">"./another-post.html"</span>&gt;</span>Here is a link<span class="hljs-tag">&lt;/<span class="hljs-name">a</span>&gt;</span>

![An image for my blog post](../images/my-image.jpg)
<span class="hljs-tag">&lt;/<span class="hljs-name">wc-markdown</span>&gt;</span>
</code></pre>
<p>Or, as inspired by <a href="https://news.ycombinator.com/item?id=25701842">this comment</a>, you could author your content directly in as sparse a take on HTML as is possible.</p>
<pre><code class="language language-html"><span class="hljs-meta">&lt;!doctype <span class="hljs-keyword">html</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">title</span>&gt;</span>This is the title of my blog post<span class="hljs-tag">&lt;/<span class="hljs-name">title</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">meta</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"date"</span> <span class="hljs-attr">content</span>=<span class="hljs-string">"2020-09-02"</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">meta</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"tags"</span> <span class="hljs-attr">content</span>=<span class="hljs-string">"readingNotes,somethingElse"</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">h1</span>&gt;</span>This is the title of my post<span class="hljs-tag">&lt;/<span class="hljs-name">h1</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">p</span>&gt;</span>
I just want to start writing here whatever it is i'm about.
<span class="hljs-tag">&lt;<span class="hljs-name">p</span>&gt;</span>
This is just another example of how you might do something that is really light and minimal. <span class="hljs-tag">&lt;<span class="hljs-name">a</span> <span class="hljs-attr">href</span>=<span class="hljs-string">"./another-post.html"</span>&gt;</span>Here is a link<span class="hljs-tag">&lt;/<span class="hljs-name">a</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">p</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">img</span> <span class="hljs-attr">src</span>=<span class="hljs-string">"./image.jpg"</span> <span class="hljs-attr">alt</span>=<span class="hljs-string">"An image for my blog post"</span>&gt;</span>
</code></pre>
<p>You can see how trading authoring conveniences begins to enhance the base browser experience.</p>
<p class="image-container"><img src="https://cdn.jim-nielsen.com/blog/2022/progressive-build-html.png" alt="">

</p>
<p>These files could be opened in a browser, without a build process or server (i.e. at a URL of <code>file:///Users/Me/Path/To/my-post.html</code>) and the core content would be accessible. And if you markup all the page’s included resources (links, images, styles, scripts, etc.) as relative links, everything will work even without a server. (Granted you’d have to give some thought to structuring your files accordingly.)</p>
<pre><code>.
├── index.html
├── styles.css
├── scripts.js
├── posts/
│   ├── 2020-02-05-my-post.html
│   ├── 2020-02-05-my-post-image.jpg
│   └── 2020-03-21-another-post.html
</code></pre>
<p>If you want the base experience you author to be even slightly better, you could write the stylesheet links and script includes in every single file (rather than append them to each document through a build process). Going back to the markdown example:</p>
<pre><code class="language language-html"><span class="hljs-meta">&lt;!doctype <span class="hljs-keyword">html</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">title</span>&gt;</span>This is the title of my blog post<span class="hljs-tag">&lt;/<span class="hljs-name">title</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">meta</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"date"</span> <span class="hljs-attr">content</span>=<span class="hljs-string">"2020-09-02"</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">meta</span> <span class="hljs-attr">name</span>=<span class="hljs-string">"tags"</span> <span class="hljs-attr">content</span>=<span class="hljs-string">"readingNotes,somethingElse"</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">script</span> <span class="hljs-attr">type</span>=<span class="hljs-string">"./web-component-markdown.js"</span>&gt;</span><span class="hljs-tag">&lt;/<span class="hljs-name">script</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">wc-markdown</span>&gt;</span>
# This is the title of my post

I just want to start writing here whatever it is i'm about.

This is just another example of how you might do something that is really light and minimal. [Here is a link](./another-post.html)

![An image for my blog post](../images/my-image.jpg)
<span class="hljs-tag">&lt;/<span class="hljs-name">wc-markdown</span>&gt;</span>
</code></pre>
<p>In this example, the trade-off is: overhead to include the <code>&lt;script&gt;</code> tag in every post, but the core experience in the browser is now more enhanced (if JavaScript runs) because the <code>&lt;wc-markdown&gt;</code> component will turn the markdown to HTML in the browser. An additional enhancement from here would be to have the build process (again, if it runs) render the markdown to HTML so the client doesn’t even need the web component!</p>
<p>The beauty is the build process works like progressive enhancement in the browser: the core experience is functional and accessible, then the build process enhances whatever you want to add by injecting those enhancements to the original, accessible HTML documents (things like style tags, script tags, or global header/footer HTML — I could imagine something like <a href="https://cheerio.js.org/">cheerio</a> being useful here).</p>
<p>The build process is a progressive enhancement to the core content of your website. Whether it runs or not, your site remains accessible and deployable at any point in time.</p>
<p>I get it, this won’t work for every website. And things like permalinks get tricky. But I still think it’s an intriguing mindset to start from: don’t assume the presence of a build, treat it as an enhancement rather than a dependency.</p>
<p>I should prototype the idea. I could imagine doing this with a tool like Metalsmith:</p>
<ul>
<li>Put your source files in directory (which works and remains deployable if everything else fails).</li>
<li>Metalsmith reads in all the files and produces a data structure of all the content</li>
<li>Additional files and markup are generated from your site’s content, like index listings, “related posts” sections, etc., while other necessary elements like styles, scripts, or global header/footer markup are injected to each page.</li>
<li>The new site is output as an “enhanced” version of the site <em>before your build started</em>.</li>
</ul>
<p>Are there any build tools advocating this kind of mindset? If you know of any, hit me up. </p>
</article>


<hr>

<footer>
  <p>
    <a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
      </svg> Accueil</a> •
    <a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
      </svg> Suivre</a> •
    <a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
      </svg> Pro</a> •
    <a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
      </svg> Email</a> •
    <abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
        <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
      </svg> Légal</abbr>
  </p>
  <template id="theme-selector">
      <form>
          <fieldset>
              <legend><svg class="icon icon-brightness-contrast">
                <use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
              </svg> Thème</legend>
              <label>
                  <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
              </label>
              <label>
                  <input type="radio" value="dark" name="chosen-color-scheme"> Foncé
              </label>
              <label>
                  <input type="radio" value="light" name="chosen-color-scheme"> Clair
              </label>
          </fieldset>
      </form>
  </template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
    function loadThemeForm(templateName) {
        const themeSelectorTemplate = document.querySelector(templateName)
        const form = themeSelectorTemplate.content.firstElementChild
        themeSelectorTemplate.replaceWith(form)

        form.addEventListener('change', (e) => {
            const chosenColorScheme = e.target.value
            localStorage.setItem('theme', chosenColorScheme)
            toggleTheme(chosenColorScheme)
        })

        const selectedTheme = localStorage.getItem('theme')
        if (selectedTheme && selectedTheme !== 'undefined') {
            form.querySelector(`[value="${selectedTheme}"]`).checked = true
        }
    }

    const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
    window.addEventListener('load', () => {
        let hasDarkRules = false
        for (const styleSheet of Array.from(document.styleSheets)) {
            let mediaRules = []
            for (const cssRule of styleSheet.cssRules) {
                if (cssRule.type !== CSSRule.MEDIA_RULE) {
                    continue
                }
                // WARNING: Safari does not have/supports `conditionText`.
                if (cssRule.conditionText) {
                    if (cssRule.conditionText !== prefersColorSchemeDark) {
                        continue
                    }
                } else {
                    if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
                        continue
                    }
                }
                mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
            }

            // WARNING: do not try to insert a Rule to a styleSheet you are
            // currently iterating on, otherwise the browser will be stuck
            // in a infinite loop…
            for (const mediaRule of mediaRules) {
                styleSheet.insertRule(mediaRule.cssText)
                hasDarkRules = true
            }
        }
        if (hasDarkRules) {
            loadThemeForm('#theme-selector')
        }
    })
</script>
</body>
</html>