aboutsummaryrefslogtreecommitdiff
path: root/build/goodbye-css-preprocessors/index.html
diff options
context:
space:
mode:
Diffstat (limited to 'build/goodbye-css-preprocessors/index.html')
-rw-r--r--build/goodbye-css-preprocessors/index.html33
1 files changed, 2 insertions, 31 deletions
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>