diff options
| author | Bradley Taunt <bt@btxx.org> | 2024-06-10 09:41:25 -0400 |
|---|---|---|
| committer | Bradley Taunt <bt@btxx.org> | 2024-06-10 09:41:25 -0400 |
| commit | 07e4a2dafe248280b5610f8c7d09b0f30b530f54 (patch) | |
| tree | 8a145d1d4d07e1278a837ff15dadccc322d27515 /build/posts/over-nesting/index.html | |
| parent | 16d28628aca9b2d356de31c319f5e7bc0f5b2b02 (diff) | |
Initial modifications to rebuilt only changed files based on mod date, performance updates
Diffstat (limited to 'build/posts/over-nesting/index.html')
| -rw-r--r-- | build/posts/over-nesting/index.html | 80 |
1 files changed, 80 insertions, 0 deletions
diff --git a/build/posts/over-nesting/index.html b/build/posts/over-nesting/index.html new file mode 100644 index 0000000..f5dc54d --- /dev/null +++ b/build/posts/over-nesting/index.html @@ -0,0 +1,80 @@ +<!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 ↓</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’ve recently worked on a few projects that show a slight disregard for proper class/selector nesting.</p> +<p>Now it’s completely understandable why designers and teams alike shrug off the concept of “over-nesting”:</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’s cleaner/compiled anyway</li> +<li>It’s <em>technically</em> DRY</li> +</ul> +<p>I personally believe these are all weak excuses that don’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’s look at an average example of poor nesting that I’ve seen out in the wild:</p> +<pre><code>/* These children elements can't be used outside +of the parent - not very flexible */ +.main-container { + .child-container { + /* This class specificity is too deep */ + .sub-child-container {} + } +} +</code></pre> +<p>Even if you know a child element will never be structured outside of it’s parent, what harm does it cause to still place it out of such deep specificity?</p> +<pre><code>/* This code is far more reusable */ +.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 { + &:hover {} + &:active {} + &:disabled{} +} + +.link-item { + &:hover{} + &: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’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’m not saying this is <strong>the only way to structure CSS</strong> - I’m only trying to make the lives of future designers/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">↑ 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 |