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/goodbye-css-preprocessors/index.html | 33 ++----------------------------
 1 file changed, 2 insertions(+), 31 deletions(-)

(limited to 'build/goodbye-css-preprocessors')
diff --git a/build/goodbye-css-preprocessors/index.html b/build/goodbye-css-preprocessors/index.html
index 3f4391d..4a8ef6d 100644
--- a/build/goodbye-css-preprocessors/index.html
+++ b/build/goodbye-css-preprocessors/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>Goodbye CSS Preprocessors</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,79 +17,49 @@
 
 <main>
 <h1 id="goodbye-css-preprocessors">Goodbye CSS Preprocessors</h1>
-
 <p>2017-09-07</p>
-
 <p>I have been using preprocessors across all my side projects since they first popped onto the scene. Sass, Stylus, LESS — you name the CSS preprocessor and I&#8217;ve most likely used it because CSS preprocessors are awesome.</p>
-
 <p>But that all changes moving forward. I&#8217;m going back to basics with CSS. Straight vanilla, man.</p>
-
 <p><img src="/public/images/sass-cancel_rl1fsw_c_scale,w_800.webp" alt="No Sass" /></p>
-
 <h2 id="why-and-who-cares">Why? And who cares?</h2>
-
 <p>Let&#8217;s start by breaking down the main positives about preprocessors:</p>
-
 <ul>
 <li>Nested syntax</li>
 <li>Definable variables</li>
 <li>Advanced mathematical functions</li>
 <li>Reusable mixins</li>
 </ul>
-
 <p>All of these features are great and I completely understand the draw (I was also sucked into the hype) - but now let&#8217;s see the negatives.</p>
-
 <h2 id="1.-debugging-is-a-chore">1. Debugging is a chore</h2>
-
 <p>So you found some weird padding clobbering an element&#8217;s default styles on line 255 of your main complied CSS file? Excellent! Now you just need to figure out which file that property comes from.</p>
-
 <p>This might sound trivial or that you can fix this with rendered comments but if you ever work on a project with hundreds of Sass&#47;Stylus&#47;LESS files all importing and compiling into each other - it can get out of hand.</p>
-
 <p>Solution: Using plain CSS makes using browser dev tools a breeze. See a bug on line 255? No problem, let me fix line 255.</p>
-
 <h2 id="2.-dependencies-for-development">2. Dependencies for development</h2>
-
 <p>Building a project with a preprocessor brings with it unnecessary baggage; dependencies. You&#8217;ll need to be running some sort of task runner (see grunt or gulp) that will compile and minify your CSS. I see this as extra overhead both during the initial setup of the project for new team members and the testing environment.</p>
-
 <p>By using plain CSS, you avoid including an extra package in your package.json file (if applicable) or having to rely on third party compilers such as codekit (although I do recommend this app).</p>
-
 <h2 id="3.-variables-mixins-become-unwieldily">3. Variables &#38; mixins become unwieldily</h2>
-
 <p>Both variables and mixins are great in small doses, but if your project has any real size to it these helpers become a hinderance. By using comma-delimited CSS selectors you can achieve the same outcome without the horror of needing a specific preprocessor file to handle just variables and mixins.</p>
-
 <p>Basic example:</p>
-
 <pre><code>selector, selectTwo, .css-class {
     &#47;* shared styling *&#47;
 }
 </code></pre>
-
 <h2 id="4.-welcome-to-nesting-hell">4. Welcome to nesting hell</h2>
-
 <p>Honestly, I&#8217;ve never been a fan of nesting. From a file structure perspective it is indeed very &#8220;clean&#8221;, but you sacrifice that cleanliness in the final compiled production code. You&#8217;re making your development environment easier to glance at and work through at the cost of your production-ready, customer facing code.</p>
-
 <p>You also run into another big no-no in my eyes: extreme selector specificity. The DOM target search starts to get out of control once you start having classes and selectors building up towards 10 or more steps.</p>
-
 <p>Bad:</p>
-
 <pre><code>body #home .container .modal nav .inner-nav &#62; ul &#62; li &#62; a {
     color: red;
 }
 </code></pre>
-
 <p>Good:</p>
-
 <pre><code>.inner-nav a {
     color: red;
 }
 </code></pre>
-
 <p>Don&#8217;t forget the amount of work needed to override styling with such deep selector specificity. That&#8217;s where you end up diving into the world of !important tags.</p>
-
 <h2 id="final-thoughts">Final thoughts</h2>
-
 <p>It should go without saying that this is just my personal preference, there is no law behind this. If you use and absolutely love preprocessors - more power to you. All I suggest is using plain old vanilla CSS for your next project and see how it works out.</p>
-
 <p>And do you know what I&#8217;ve learned to appreciate after switching back to vanilla? CSS is more beautiful when developed in it&#8217;s rawest form.</p>
 <footer role="contentinfo">
     <h2>Menu Navigation</h2>
-- 
cgit v1.2.3-54-g00ecf

