Actual mobile toc; dark mode; speed up site loading #3950
There are no files selected for viewing
|
There was a problem hiding this comment. This file (as with If you make changes here, they'll be lost whenever we need to update it for changes to the header or footer or are you wanting to break away from the site-wide versions and have a documentation-only version? There was a problem hiding this comment. To support dark mode, we do need to tweak the header and footer files, as otherwise they'll remain in light mode at all times. I've kept the tweaks minimal (mostly colour based, with some padding trimmed from the header to reduce excess space usage), so we could try to mostly share. But unless we add dark mode to the main site as well, this will require deviation. There was a problem hiding this comment. Given that this PR is modifying both the navigation and also adding a dark-mode, I wonder if it might be worth splitting that into two separate PRs? I.e. get the navigation changes merged in, and then add dark-mode theme as separate (later) step? 🤔 Or would it be far too much work to disentangle the two things? Also, we'll probably want @jackbenwillis to design us some "light mode" and "dark mode" icons which would integrate with the design better than the generic sun and moon icons that you're currently using? There was a problem hiding this comment. Rather than modifying There was a problem hiding this comment. Great point. Opened https://github.com/raspberrypi/raspberrypi.com-header-and-footer/pull/81 to address this -- once we've merged that, I'll update this PR to use that new approach (and likely some new header and footer-specific variables). |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,12 +1,13 @@ | ||
| <meta charset="utf-8"> | ||
| <meta http-equiv="X-UA-Compatible" content="IE=edge"> | ||
| <link rel="shortcut icon" href="{{ site.baseurl }}/favicon.ico"> | ||
|
There was a problem hiding this comment. Is this different to the default behaviour of using https://www.raspberrypi.com/favicon.ico? There was a problem hiding this comment. Currently, local builds of the docs yell at you on the CLI about a missing favicon and lack a favicon entirely. I added this to fix the issue locally, and I think it shouldn't break anything. Though your sanity check is appreciated. Hopefully that makes sense now. |
||
| <meta name="viewport" content="width=device-width, initial-scale=1"> | ||
| <title>{{ page.title | strip_html}}</title> | ||
| <meta name="description" content="The official documentation for Raspberry Pi computers and microcontrollers"> | ||
| <meta property="og:title" content="{{ page.title }}"> | ||
| <meta property="og:description" content="The official documentation for Raspberry Pi computers and microcontrollers"> | ||
| <meta property="og:url" content="https://www.raspberrypi.com{{ page.url | relative_url }}"> | ||
| <meta property="og:image" content="https://www.raspberrypi.com{{ '/images/opensocial.png' | relative_url }}"> | ||
| <meta name="twitter:card" content="summary_large_image"> | ||
| <meta name="twitter:site" content="@Raspberry_Pi"> | ||
| <meta name="twitter:title" content="{{ page.title }}"> | ||
|
|
@@ -17,9 +18,15 @@ | |
| <link rel="preconnect" href="https://IHWGNTJ1NP-dsn.algolia.net" crossorigin> | ||
| <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@docsearch/css@3"/> | ||
| <link rel="stylesheet" href="{{ site.baseurl }}/css/style.css?ver={{ site.time | date: '%s' }}"> | ||
| <link rel="stylesheet" href="{{ site.baseurl }}/css/asciidoctor-tabs.css?ver={{ site.time | date: '%s' }}"> | ||
| <link rel="stylesheet" href="{{ site.baseurl }}/css/syntax-highlighting.css?ver={{ site.time | date: '%s' }}"> | ||
| <link rel="stylesheet" href="{{ site.baseurl }}/css/tocbot.css?ver={{ site.time | date: '%s' }}"> | ||
| <script type="text/javascript" src="{{ site.baseurl }}/scripts/theme.js?ver={{ site.time | date: '%s' }}"></script> | ||
| <script type="text/javascript" src="{{ site.baseurl }}/scripts/tocbot.js?ver={{ site.time | date: '%s' }}"></script> | ||
| <script type="text/javascript" src="{{ site.baseurl }}/scripts/toc.js?ver={{ site.time | date: '%s' }}"></script> | ||
| <script async type="text/javascript" src="{{ site.baseurl }}/scripts/asciidoctor-tabs.js?ver={{ site.time | date: '%s' }}"></script> | ||
| <script async src="{{ site.baseurl }}/scripts/clipboard.min.js?ver={{ site.time | date: '%s' }}"></script> | ||
| <script async src="{{ site.baseurl }}/scripts/copy-to-clipboard.js?ver={{ site.time | date: '%s' }}"></script> | ||
| <script async src="https://www.googletagmanager.com/gtag/js?id=G-V8TFXM3BKJ"></script> | ||
| <script> | ||
| window.dataLayer = window.dataLayer || []; | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,3 @@ | ||
| <div id="theme-toggle-container"> | ||
| <a id="theme-toggle" alt="toggle site theme" title="toggle site theme" onclick="toggleTheme()"></a> | ||
|
There was a problem hiding this comment. Would it be better to be unobtrusive here and add a e.g. document.getElementById("theme-toggle").addEventListener("click", (e) => {
e.preventDefault();
toggleTheme();
});There was a problem hiding this comment. My understanding is that this ultimately does the exact same thing, but with an element lookup. Is there a performance benefit that I'm not aware of, or some penalty to using onclick? There was a problem hiding this comment. See my other comment re separating the HTML from the JavaScript but also the broader concept of unobtrusive JavaScript to encourage progressive enhancement. |
||
| </div> | ||
Uh oh!
There was an error while loading. Please reload this page.