aboutsummaryrefslogtreecommitdiff
path: root/build/over-nesting/index.html
diff options
context:
space:
mode:
authorBradley Taunt <bt@btxx.org>2024-07-02 14:22:21 -0400
committerBradley Taunt <bt@btxx.org>2024-07-02 14:22:21 -0400
commit3f6a9546ec13063d0d5bdf21d30a93d3e8aa6050 (patch)
tree947985c4eda1bceb1910bc01739c32fd0baad181 /build/over-nesting/index.html
parent14074019d62d98885c4c764401a9e7e1fd129f79 (diff)
Rebuild changes based off latest barfHEADmaster
Diffstat (limited to 'build/over-nesting/index.html')
-rw-r--r--build/over-nesting/index.html81
1 files changed, 81 insertions, 0 deletions
diff --git a/build/over-nesting/index.html b/build/over-nesting/index.html
new file mode 100644
index 0000000..25f9cc1
--- /dev/null
+++ b/build/over-nesting/index.html
@@ -0,0 +1,81 @@
+<!doctype html>
+<html lang="en">
+<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>Over-Nesting</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;}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>
+ <a href="#menu">Menu &darr;</a>
+</nav>
+
+<main>
+<h1 id="over-nesting">Over-Nesting</h1>
+<p>2019-01-06</p>
+<p>I think since our design industry moves so quickly and exciting new technologies get released almost daily, that we often forget some of the basics when writing CSS. I bring this up because I&#8217;ve recently worked on a few projects that show a slight disregard for proper class&#47;selector nesting.</p>
+<p>Now it&#8217;s completely understandable why designers and teams alike shrug off the concept of &#8220;over-nesting&#8221;:</p>
+<ul>
+<li>As a team we know the structure of our code (no outside party needs to interact with it)</li>
+<li>Everything is written in <code>insert pre-processor here</code> - so it&#8217;s cleaner&#47;compiled anyway</li>
+<li>It&#8217;s <em>technically</em> DRY</li>
+</ul>
+<p>I personally believe these are all weak excuses that don&#8217;t justify the poor experience future maintainers of your code will face. <em>You should always write your code with the idea someone completely new to the project will have to maintain it</em>.</p>
+<p>Let&#8217;s look at an average example of poor nesting that I&#8217;ve seen out in the wild:</p>
+<pre><code>&#47;* These children elements can&#39;t be used outside
+of the parent - not very flexible *&#47;
+.main-container {
+ .child-container {
+ &#47;* This class specificity is too deep *&#47;
+ .sub-child-container {}
+ }
+}
+</code></pre>
+<p>Even if you know a child element will never be structured outside of it&#8217;s parent, what harm does it cause to still place it out of such deep specificity?</p>
+<pre><code>&#47;* This code is far more reusable *&#47;
+.main-container {}
+.child-container {}
+.sub-child-container {}
+</code></pre>
+<h3 id="exceptions">Exceptions</h3>
+<p>As with anything, there are exceptions to the <em>rule</em>. If the nested elements pertain to the parent itself, it makes complete sense to group these stylings together. A button or link item are excellent examples of this:</p>
+<pre><code>.btn-lg {
+ &#38;:hover {}
+ &#38;:active {}
+ &#38;:disabled{}
+}
+
+.link-item {
+ &#38;:hover{}
+ &#38;:focus{}
+}
+</code></pre>
+<p>Of course, this is all easier said than done. Limitations exist within teams or even on an individual level that might make this impossible to change. Maybe you don&#8217;t have the authority to rework your current CSS or it would eat up too many cycles and time is valuable - especially in the world of startups. </p>
+<p>I&#8217;m not saying this is <strong>the only way to structure CSS</strong> - I&#8217;m only trying to make the lives of future designers&#47;developers easier moving forward. </p>
+<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">&uarr; Top of the page</a></li>
+ </ul>
+ <small>
+ Built with <a href="https://barf.btxx.org">barf</a>. <br>
+ Feeds: <a href="/atom.xml">Atom</a> & <a href="/rss.xml">RSS</a><br>
+ Maintained with ♥ for the web. <br>
+ Proud supporter of <a href="https://usefathom.com/ref/DKHJVX">Fathom</a> &amp; <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