diff options
Diffstat (limited to 'build/default-html-style-updates')
| -rw-r--r-- | build/default-html-style-updates/index.html | 103 |
1 files changed, 103 insertions, 0 deletions
diff --git a/build/default-html-style-updates/index.html b/build/default-html-style-updates/index.html new file mode 100644 index 0000000..3e18575 --- /dev/null +++ b/build/default-html-style-updates/index.html @@ -0,0 +1,103 @@ +<!doctype html> +<html lang="en" id="top"> +<head> + <meta charset="utf-8"> + <meta name="viewport" content="width=device-width, initial-scale=1"> + <link rel="icon" href="data:,"> + <title>Modern Improvements for Default Browser Styles</title> + <link href="https://bt.ht/atom.xml" type="application/atom+xml" rel="alternate" title="Atom feed for blog posts" /> + <style>*{box-sizing:border-box;}body{font-family:sans-serif;margin:0 auto;max-width:650px;padding:1rem;}img{max-width:100%;}pre{overflow:auto;}table{text-align:left;width:100%;}</style> +</head> + +<nav> + <a href="#menu">Menu ↓</a> +</nav> + +<main> +<h1>Modern Improvements for Default Browser Styles</h1> +<p>2021-11-09</p> +<p>This website <em>almost</em> exclusively uses the browser's (whichever one that might be) default styling to render it's HTML. I firmly believe, and have <a href="/css-js-mistake/">stated in a previous post</a>, that the default HTML styling across all browsers is a thing of beauty. "Consistent and boring" is how I tend to refer to default browser styles - and I mean that in a <em>good way</em>.</p> +<p>But that doesn't mean some minor, modern improvements couldn't be made...</p> +<h2>Boosting Margins and Increasing Font Size</h2> +<p>A little extra breathing room for a website's content never hurts. Browser defaults set the inner content too close to the main window borders, creating mild eye strain to focus on the far edges of the screen when reading. Pair this with a typeface set too small and you've got a recipe for disaster (in terms of user experience and accessibility). Luckily for us, adding two basic CSS properties fixes all of our readability woes. All that is required is a simple boost to the existing <code>margin</code> property set on the <code>body</code> element (I personally lean towards a very specific <code>1.5em</code>) and overriding the default <code>font-size</code> to <code>18px</code>[^1]:</p> +<pre><code>body { + font-size:18px; + margin:1.5em; +} +</code></pre> +<p>There is one <em>small</em> caveat with setting the <code>font-size</code> across the whole <code>body</code> element: code elements set in <code>monospace</code>. They will stand out larger than the other fonts found in the document (due to variations in different typeface heights, spacing etc.) so we will need to target these elements specifically:</p> +<pre><code>code { + font-size:14px; + /* Word wrap is optional if you plan to have long inline code snippets */ + word-wrap:break-word; +} +</code></pre> +<h2>Code & Pre Tags</h2> +<p>Since we've mentioned <code>code</code> elements, let's fix those as well. The existing styling for inline code snippets and larger pre-formatted text sections leave a lot to be desired. They don't provide any means to wrap their inner content or make use of <code>overflow</code> properties to avoid vertically scrolling on smaller device screens. Sharing code examples becomes quite a pain when your webpage's flow and layout is broken just by including them. Browsers could fix this easily enough by defaulting to:</p> +<pre><code>pre { + overflow:auto; +} +</code></pre> +<h2>Basic Dark Mode Support</h2> +<p>Barebones styling in current web browsers have no sane defaults[^2] for system-level dark mode. What a huge letdown. This is where the most "drastic" changes will be implemented with our browser default updates. We will need the browser to change the main <code>background-color</code>, along with resetting both the text and anchor link <code>color</code> for improved accessibility. Browser defaults for anchor link color in "light mode" are blue/purple - so I've opted towards using gold, orange and orangered in dark mode respectively:</p> +<pre><code>/* Dark mode */ +@media (prefers-color-scheme: dark) { + @media not print { + html {background:#0e0e0e;color:#e1e1e1; } + a {color: gold;} + a:visited {color: orange;} + a:hover,a:focus{color: orangered;} + } +} +</code></pre> +<p>That is probably the most streamlined dark mode on the web...</p> +<h2>The "Reading Length" Debate</h2> +<p>Proper reading length tends to be quite the point of contention on the web. Hell, even I've <a href="/character-unit/">written about it quite a bit</a> in the past (and many of my side projects follow that standard). The main problem I have with this is lack of <em>user control</em>. I don't think the browser (or designers for that matter) should determine the best reading length for my own personal reading preferences. UX testing and group feedback has (somewhat) agreed upon 66-75 characters per line to be the most optimal reading experience. That is good to know. I <em>still</em> believe it should come down to user preference.</p> +<p>Do you want to know an incredible feature built into browsers? <em>Window resizing</em>. Abandon the idea that you "know better" than your users and give them the power to adjust as they see fit. The web was meant to be personal and flexible.</p> +<h2>Conclusion</h2> +<p>There isn't much else to say, really. I think these tiny tweaks would greatly improve the default browser experience and maybe even convince others to just <em>use</em> these defaults instead of falling down the CSS rabbit hole (as fun as that might be sometimes). For easier convenience, I'll leave the full set of CSS changes below:</p> +<pre><code>body { + font-size:18px; + margin:1.5em; +} +code { + font-size:14px; +} +pre { + overflow:auto; +} +@media (prefers-color-scheme: dark) { + @media not print { + html {background:#0e0e0e;color:#e1e1e1; } + a {color: gold;} + a:visited {color: orange;} + a:hover,a:focus{color: orangered;} + } +} +</code></pre> +<h2>Refs</h2> +<ol> +<li><code>18px</code> seems to be the perfect sweet spot between "almost too large, yet not small enough to strain my eyes"</li> +<li>At the time of this article's publish date</li> +</ol> +<footer role="contentinfo"> + <h2>Menu Navigation</h2> + <ul id="menu"> + <li><a href="/">Home</a></li> + <li><a href="/projects">Projects</a></li> + <li><a href="/uses">Uses</a></li> + <li><a href="/wiki">Wiki</a></li> + <li><a href="/resume">Resume</a></li> + <li><a href="/colophon">Colophon</a></li> + <li><a href="/now">Now</a></li> + <li><a href="/donate">Donate</a></li> + <li><a href="/atom.xml">RSS</a></li> + <li><a href="#top">↑ Top of the page</a></li> + </ul> + <small> + Built with <a href="https://git.sr.ht/~bt/barf">barf</a>. <br> + Maintained with ♥ for the web. <br> + Proud supporter of <a href="https://usefathom.com/ref/DKHJVX">Fathom</a> & <a href="https://nextdns.io/?from=74d3p3h8">NextDNS</a>. <br> + The content for this site is <a href="https://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA</a>.<br> The <a href="https://git.sr.ht/~bt/bt.ht">code for this site</a> is <a href="https://git.sr.ht/~bt/bt.ht/tree/master/item/LICENSE">MIT</a>. + </small> +</footer>
\ No newline at end of file |