From 16d28628aca9b2d356de31c319f5e7bc0f5b2b02 Mon Sep 17 00:00:00 2001
From: Bradley Taunt <bt@btxx.org>
Date: Sat, 8 Jun 2024 13:43:37 -0400
Subject: Remove incorrectly generated files, fix up markdown articles

---
 build/default-html-style-updates/index.html | 26 ++------------------------
 1 file changed, 2 insertions(+), 24 deletions(-)

(limited to 'build/default-html-style-updates/index.html')
diff --git a/build/default-html-style-updates/index.html b/build/default-html-style-updates/index.html
index bf123dc..389b78b 100644
--- a/build/default-html-style-updates/index.html
+++ b/build/default-html-style-updates/index.html
@@ -3,11 +3,12 @@
 <head>
 	<meta charset="utf-8">
 	<meta name="viewport" content="width=device-width, initial-scale=1">
+	<meta name="color-scheme" content="dark light">
 	<link rel="icon" href="data:,">
 	<title>Modern Improvements for Default Browser Styles</title>
 	<link href="/atom.xml" type="application/atom+xml" rel="alternate" title="Atom feed for blog posts" />
 	<link href="/rss.xml" type="application/rss+xml" rel="alternate" title="RSS feed for blog posts" />
-<style>*{box-sizing:border-box;}body{font-family:sans-serif;line-height:1.33;margin:0 auto;max-width:650px;padding:1rem;}img{max-width:100%;}pre{border:1px solid;overflow:auto;padding:5px;}table{text-align:left;width:100%;}.footnotes{font-size:90%;}</style>
+<style>*{box-sizing:border-box;}body{font-family:sans-serif;line-height:1.33;margin:0 auto;max-width:650px;padding:1rem;}blockquote{background:rgba(0,0,0,0.1);border-left:4px solid;padding-left:5px;}img{max-width:100%;}pre{border:1px solid;overflow:auto;padding:5px;}table{text-align:left;width:100%;}.footnotes{font-size:90%;}</style>
 </head>
 
 <nav>
@@ -16,45 +17,31 @@
 
 <main>
 <h1 id="modern-improvements-for-default-browser-styles">Modern Improvements for Default Browser Styles</h1>
-
 <p>2021-11-09</p>
-
 <p>This website <em>almost</em> exclusively uses the browser&#8217;s (whichever one that might be) default styling to render it&#8217;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. &#8220;Consistent and boring&#8221; 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&#8217;t mean some minor, modern improvements couldn&#8217;t be made&#8230;</p>
-
 <h2 id="boosting-margins-and-increasing-font-size">Boosting Margins and Increasing Font Size</h2>
-
 <p>A little extra breathing room for a website&#8217;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&#8217;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;
     &#47;* Word wrap is optional if you plan to have long inline code snippets *&#47;
     word-wrap:break-word;
 }
 </code></pre>
-
 <h2 id="code-pre-tags">Code &#38; Pre Tags</h2>
-
 <p>Since we&#8217;ve mentioned <code>code</code> elements, let&#8217;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&#8217;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&#8217;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 id="basic-dark-mode-support">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 &#8220;drastic&#8221; 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 &#8220;light mode&#8221; are blue&#47;purple - so I&#8217;ve opted towards using gold, orange and orangered in dark mode respectively:</p>
-
 <pre><code>&#47;* Dark mode *&#47;
 @media (prefers-color-scheme: dark) {
     @media not print {
@@ -65,19 +52,12 @@
     }
 }
 </code></pre>
-
 <p>That is probably the most streamlined dark mode on the web&#8230;</p>
-
 <h2 id="the-reading-length-debate">The &#8220;Reading Length&#8221; Debate</h2>
-
 <p>Proper reading length tends to be quite the point of contention on the web. Hell, even I&#8217;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&#8217;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 &#8220;know better&#8221; 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 id="conclusion">Conclusion</h2>
-
 <p>There isn&#8217;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&#8217;ll leave the full set of CSS changes below:</p>
-
 <pre><code>body {
     font-size:18px;
     margin:1.5em;
@@ -97,9 +77,7 @@ pre {
     }
 }
 </code></pre>
-
 <h2 id="refs">Refs</h2>
-
 <ol>
 <li><code>18px</code> seems to be the perfect sweet spot between &#8220;almost too large, yet not small enough to strain my eyes&#8221;</li>
 <li>At the time of this article&#8217;s publish date</li>
-- 
cgit v1.2.3-54-g00ecf

