You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
306 lines
19 KiB
306 lines
19 KiB
<style>
|
|
quote {
|
|
box-shadow: 4px 4px 4px 4px var(--color-shadow);
|
|
padding: 1em;
|
|
font-style: italic;
|
|
background-color: var(--color-bg-secondary);
|
|
}
|
|
|
|
pre code {
|
|
font-size: 0.8em;
|
|
}
|
|
</style>
|
|
|
|
<hr>
|
|
<h1>Discussion</h1>
|
|
|
|
<p>We can analyze the problems with modern CSS by looking at how popular frameworks use specificity and the cascade:</p>
|
|
<ol>
|
|
<li>Relying on <b>div</b> to structure layout, which breaks the separation between display and content originally intended for CSS and HTML.</li>
|
|
<li>Relying on <b>class</b> (or worse <b>tag.class=tag</b>) which subverts the normal specificity rules originally intended to reduce duplication.</li>
|
|
<li>Relying on the vaguely defined cascade rules to dominate the entire CSS cascade using #1 and #2.</li>
|
|
</ol>
|
|
|
|
<h2><div> as Structure</h2>
|
|
|
|
<p>The simplest criticism is the use of <b>div</b> as a structure element in the HTML. Take this example from <a href="https://getbootstrap.com/docs/4.0/layout/grid/">Bootstrap</a>:</p>
|
|
|
|
<pre>
|
|
<code class="language-html">
|
|
<div class="container">
|
|
<div class="row">
|
|
<div class="col">Column</div>
|
|
<div class="col">Column</div>
|
|
<div class="w-100"></div>
|
|
<div class="col">Column</div>
|
|
<div class="col">Column</div>
|
|
</div>
|
|
</div>
|
|
</code>
|
|
</pre>
|
|
|
|
<p>This simple example shows how a large proportion of modern CSS frameworks rely on <b>div</b> to create structure and layouts when the <b>div</b> has absolutely nothing to do with the content. Another example from bootstrap is their image carousel:</p>
|
|
|
|
<pre>
|
|
<code class="language-html">
|
|
<div id="carouselExampleSlidesOnly" class="carousel slide" data-ride="carousel">
|
|
<div class="carousel-inner">
|
|
<div class="carousel-item active">
|
|
<img class="d-block w-100" src="..." alt="First slide">
|
|
</div>
|
|
<div class="carousel-item">
|
|
<img class="d-block w-100" src="..." alt="Second slide">
|
|
</div>
|
|
<div class="carousel-item">
|
|
<img class="d-block w-100" src="..." alt="Third slide">
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</code>
|
|
</pre>
|
|
|
|
<p>This snippet of code is 13 lines long of which only 3 are actually image content. It also contains both <b>id</b> and <b>class</b> specificity, making it nearly impossible to override when used locally. If you compare that my Carousel demo you can see it much simpler:</p>
|
|
|
|
<pre>
|
|
<code class="language-html">
|
|
<carousel>
|
|
<figure class="active">
|
|
<img alt="Stock photo" src="...">
|
|
<figcaption>Image 1</figcaption>
|
|
</figure>
|
|
|
|
<!-- this image is not seen until set active -->
|
|
<figure>
|
|
<img alt="Stock photo" src="...">
|
|
<figcaption>Image 2</figcaption>
|
|
</figure>
|
|
<prev><Icon name="arrow-left" size="48" /></prev>
|
|
<next><Icon name="arrow-right" size="48" /></next>
|
|
</carousel>
|
|
</code>
|
|
</pre>
|
|
|
|
<p>This is the same numbe of lines of code, but every line is clearly idenfitied and easy to understand. Each part of the display is named, matches its use in the display, and is semantically related to the concept of images.</p>
|
|
|
|
<p>CSS was designed to be a style sheet language used for describing the presentation of a document. You can read from <a href="https://developer.mozilla.org/en-US/docs/Learn/CSS">Mozilla their own explanation as well</a>:</p>
|
|
|
|
<quote>
|
|
While HTML is used to define the structure and semantics of your content, CSS is used to style it and lay it out. For example, you can use CSS to alter the font, color, size, and spacing of your content, split it into multiple columns, or add animations and other decorative features.
|
|
</quote>
|
|
|
|
<p>The original intent of CSS--and still a major factor in its design--is that the HTML content doesn't have to change to alter the display for different situations. <a href="https://developer.mozilla.org/en-US/docs/Learn/CSS">CSS Zen Garden</a> is the classic example of the principle, with a single HTML document being styled in many different ways using only CSS.</p>
|
|
|
|
<p>The above examples from Bootstrap (and most other CSS frameworks) subverts this original CSS design by forcing you to add non-semantic <b>div</b> tags only to create a display structure (not information structure) for their CSS properties.</p>
|
|
|
|
<h3>The Impact</h3>
|
|
|
|
<p>What's the impact of this <b>div.class</b> heavy design? By subverting CSS's original separation from the HTML you end up with the following usability problems:</p>
|
|
|
|
<ol>
|
|
<li>Reasoning about the CSS visuals becomes more difficult due to the overlay of complicated boxes that have nothing to do with the visually perceived content.</li>
|
|
<li>Understanding the document structure is more difficult because of the semantically irrelevant structure divs adding noise.</li>
|
|
<li>Changing the structure--or even just fixing it--becomes more challenging since you have to alter <b>both</b> your own CSS <b>and</b> the HTML that uses their CSS structure divs.</li>
|
|
<li>Debugging layout issues using the browser inspector tool is more difficult because you have to troll through the entire CSS structure div tree to find the style impacting your design decision.</li>
|
|
<li>Debugging why your local design changes aren't working becomes a process of trolling through the CSS via the structure divs and slowly turning off CSS rules until you find the one breaking your design.</li>
|
|
</ol>
|
|
|
|
<p>A succinct way to put all of the above is this infection of CSS rules into the HTML document means you no longer have a single place to go when there's a problem with one, but instead have to constantly work in both to fix anything. If a button isn't the right size, you can't simply go to the CSS and fix it. You have to go to:</p>
|
|
|
|
<ol>
|
|
<li>Your local CSS</li>
|
|
<li>Your HTML with their <b>divs</b></li>
|
|
<li>Their CSS classes for each div</li>
|
|
</ol>
|
|
|
|
<p>This turns one target area for debugging the presentation (the CSS), into 3 potential interacting locations making it more difficult to solve the problem. If you stick to "layout and style is in CSS" then when you have a problem with the layout or style...you just go to the CSS.</p>
|
|
|
|
<h2>class as Configuration</h2>
|
|
|
|
<p>Let's take a look at a simple example from <a href="https://bulma.io/documentation/overview/modular/">Bulma</a> to explain what's happening:</p>
|
|
|
|
<pre>
|
|
<code class="language-html">
|
|
<button class="button">
|
|
Button
|
|
</button>
|
|
|
|
<button class="button is-primary">
|
|
Primary button
|
|
</button>
|
|
</code>
|
|
</pre>
|
|
|
|
<p>In this example we see that Bulma is using <b>both</b> tags <b>and</b> classes to style buttons. This means that Bulma effectively corrupts 2/3rds of the specificity rules for its design (not to mention is needlessly repetitive). If you used this code in a part of your app, but needed to slightly change the padding, you'd be forced to struggle with Bulma taking over 2 of the 3 slots reserved for specificity:</p>
|
|
|
|
<ol>
|
|
<li><b>button as a tag</b> means Bulma has taken over the specificity at the tag level.</li>
|
|
<li><b>class=button</b> means it's also taken the primary slot of class specificity.</li>
|
|
<li>That leaves you with <b>id</b> as your only way to modify a button, <b>!important</b>, or strange specificity hacks like doubling your <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity#The_!important_exception">classes as recommended by Mozilla.</a></li>
|
|
</ol>
|
|
|
|
<h3>Mozilla as Patient Zero</h3>
|
|
|
|
<p>Mozilla's recommendations are another source of confusion in CSS frameworks and is most likely the <b>cause of frameworks using structure divs</b>. <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity#The_!important_exception">Mozilla recommends</a> that instead of using <b>!important</b> you add a structure <b>div</b> to get one more level of specificity:</p>
|
|
|
|
<pre>
|
|
<code class="language-html">
|
|
<div id="test">
|
|
<span>Text</span>
|
|
</div>
|
|
</code>
|
|
</pre>
|
|
|
|
<pre>
|
|
<code class="language-css">
|
|
div#test span { color: green; }
|
|
div span { color: blue; }
|
|
span { color: red; }
|
|
</code>
|
|
</pre>
|
|
|
|
<p>In this "fix" for <b>!important</b> your only choice is to wrap the component you want to modify with even more <b>div</b> structure and then create a more specific path with the new class. The problem with this fix is it overcomplicates the HTML but <b>also</b> breaks separation of content from style. Rather than keep your content in HTML, and your style in CSS, you're now forced to infect your HTML with helpers for CSS, all because someone else thinks you shouldn't use <b>!important</b> to override their classes.</p>
|
|
|
|
<p>The other odd hack they recommend is simply doubling the class:</p>
|
|
|
|
<pre>
|
|
<code class="language-css">
|
|
#myId#myId span { color: yellow; }
|
|
.myClass.myClass span { color: orange; }
|
|
</code>
|
|
</pre>
|
|
|
|
<p>There's no explanation regarding why this odd quirk of browsers isn't just a hack, but it's put forward as superior to the very clear <b>!important</b>. It'd be incredibly easy to miss this double-class hack if you were trying to find it in the CSS, but finding <b>!important</b> is trivial to find and fix later if you want. In fact, I can't actually see why this is better if it does the same thing as !important but in a sneaky way.</p>
|
|
|
|
<h3>The Impact</h3>
|
|
|
|
<p>The end result of these recommendations from Mozilla is people solve specificity by adding on more and more <b>divs</b> because they've used <b>class</b> everywhere and can't get around the specificity calculations any other way. You can see this in how Bulma uses extra <b>divs</b> in its forms:</p>
|
|
|
|
<pre>
|
|
<code class="language-html">
|
|
<div class="field">
|
|
<label class="label">Subject</label>
|
|
<div class="control">
|
|
<div class="select">
|
|
<select>
|
|
<option>Select dropdown</option>
|
|
<option>With options</option>
|
|
</select>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</code>
|
|
</pre>
|
|
|
|
<p>You have three levels of <b>divs</b> just to style a plain <b>select</b> tag. Most likely the use of classes forces Bulma to add more divs to increase specificity because they have hijacked the class <b>specificity</b> everywhere.
|
|
</p>
|
|
|
|
<p>Meanwhile, similar styling is done in <a href="https://andybrewer.github.io/mvp/">MVP.css</a> and other "classless" frameworks by using perfectly normal and valid tag based selectors:</p>
|
|
|
|
<pre>
|
|
<code class="language-css">
|
|
select {
|
|
display: block;
|
|
font-size: inherit;
|
|
max-width: var(--width-card-wide);
|
|
border: 1px solid var(--color-bg-secondary);
|
|
border-radius: var(--border-radius);
|
|
margin-bottom: 1rem;
|
|
padding: 0.4rem 0.8rem;
|
|
}
|
|
</code>
|
|
</pre>
|
|
|
|
<p>We can also say that <b>if</b> there is some failing of CSS that requires extra class divs then where is the explanation for this limitation? Why can't we just use a simple tag selector to completely alter the appearance of a <b>select</b>? Why is it suddenly these problems go away when I slather on a mountain of <b>divs</b>? If this is really the situation then that means CSS has a serious flaw as the "styling and layout" component of the web and everyone advocating for it needs to be honest and stop blaming others for not knowing it well enough. My understanding though is CSS is perfectly fine at styling a <b>select</b> tag all you want, and it's the way CSS is used today that's causing the problems.</p>
|
|
|
|
<h2>The Cascade</h2>
|
|
|
|
<p>At first glance most of the criticism might seem minor. Who cares if a single .class in a single .css file overrides my local CSS? That'd be fairly easy to find right? Where this turns into a usability nightmare is when <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade">the cascade</a> is added to the system. The cascade's purpose is to allow for CSS styles to come from different sources, but combine in a kind of hierarchy of importance. From <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade">Mozilla's documentation</a> we can see an initial problem:</p>
|
|
|
|
<quote>
|
|
<p>Only CSS declarations, that is property/value pairs, participate in the cascade. This means that at-rules containing entities other than declarations, such as a @font-face rule containing descriptors, don't participate in the cascade. In these cases, only the at-rule as a whole participates in the cascade: here, the @font-face identified by its font-family descriptor. If several @font-face rules with the same descriptor are defined, only the most appropriate @font-face, as a whole, is considered.</p>
|
|
|
|
<p>While the declarations contained in most at-rules — such as those in @media, @document, or @supports — participate in the cascade, declarations contained in @keyframes don't. As with @font-face, only the at-rule as a whole is selected via the cascade algorithm.</p>
|
|
|
|
<p>Finally, note that @import and @charset obey specific algorithms and aren't affected by the cascade algorithm.</p>
|
|
</quote>
|
|
|
|
<p>So the cascade combines properties from <b>different sources</b> but only properties that aren't @at-rules containing <em>descriptors</em>, and @import or @charset follow another set of rules entirely. Got it? Great. So easy and consistent, and we're not done yet.</p>
|
|
|
|
<p>Mozilla goes on to define the order these rules are processed (minus all the edge cases of @at-rules):</p>
|
|
|
|
<quote>
|
|
<ol>
|
|
<li>It first filters all the rules from the different sources to keep only the rules that apply to a given element.</li>
|
|
<li>Then it sorts these rules according to their importance, that is, whether or not they are followed by !important, and by their origin.</li>
|
|
<li>In case of equality, the specificity of a value is considered to choose one or the other.</li>
|
|
</ol>
|
|
</quote>
|
|
|
|
<p>What is this ordering of rules? Why a handy list in this order (which isn't clearly described as being in most or least important ordering):</p>
|
|
|
|
<quote>
|
|
<ol>
|
|
<li>user agent == normal</li>
|
|
<li>user == normal</li>
|
|
<li>author == normal</li>
|
|
<li>animations == </li>
|
|
<li>author == !important</li>
|
|
<li>user == !important</li>
|
|
<li>user agent == !important</li>
|
|
<li>transitions</li>
|
|
</ol>
|
|
</quote>
|
|
|
|
<p>However, these calculations are completely pointless because <b>user style sheets have been slowly phased out.</b> A "user style" is a piece of CSS that someone who is <b>using</b> a browser adds--on their own computer--to change the defaults set by the <b>author</b> of the site. The catch is, Chrome <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=347016">does not support user style sheets</a>, and it's the most popular browser. That means they are completely dead for practical purposes. That leaves the user agent, which is usually reset by designers anyway, and "author" styles which is simply, <b>"all of the CSS you write"</b>.</p>
|
|
|
|
<p>The confusing part of this description is it makes it <b>seem</b> like someone writing a web page is having to contend with these rules that include user styles when you actually have zero control over them, so they don't matter. The real calculations for practical purposes should be (from least to most important):</p>
|
|
|
|
<ol>
|
|
<li>Sort by !important.</li>
|
|
<li>Sort by specificity.</li>
|
|
<li>Sort by order, later wins over earlier.</li>
|
|
</ol>
|
|
|
|
<p>That's it. User agent styles are so low level they are easily replaced with a reset style. No user agents have !important rules (that I know of), and if they do this means you probably can't change them anyway. You can't control user styles as that's added by the user out of your control, so trying to add them to your calculations is meaningless. That leaves only the rules for cascade precedence in the CSS you write, and this simplifies the ordering.</p>
|
|
|
|
<p>Remember how you were admonished to never use <b>!important</b>? If you follow that edict, then, that means we finally arrive at only two sorting rules:</p>
|
|
|
|
<ol>
|
|
<li>Sort by specificity.</li>
|
|
<li>Sort by order, later wins over earlier.</li>
|
|
</ol>
|
|
|
|
<p>But finally, the last rule of sorting by order is <b>only if there's a tie</b> in the previous sorting. That means there's really only 1 rule, or maybe 1.5 rules, where you sort by specificity only and then order wins in a tie.</p>
|
|
|
|
|
|
<h2>The Impact</h2>
|
|
|
|
<p>I call these simplified practical rules the "real cascade" because they're the practical sorting rules you actually have to deal with, and they also help finally describe how modern CSS breaks this sorting cascade to make CSS harder:</p>
|
|
|
|
<ol>
|
|
<li>If we sort by !important, but nobody uses !important, then the only sorting done is by specificity.</li>
|
|
<li>If we sort by specificity 99% of the time, then modern CSS forces itself into the second highest priority of the sorting calculation leaving no room for your own local <b>class</b> or <b>tag</b> styles.</li>
|
|
<li>If we then sort by order of declaration <b>on specificity ties</b> it doesn't matter because #2 means the CSS framework will win unless we add an additional structure div to increase specificity, use the double-class trick, or add !important (which everyone says not to do).</li>
|
|
</ol>
|
|
|
|
<p>Effectively, this situation promotes CSS frameworks winning over your own styles, encourages convoluted nested <b>div</b> structure to hack specificity, and complicates cascade calculations needlessly by changing the priority of an author style that uses <b>div.class</b> such that it's difficult to modify design elements locally.</p>
|
|
|
|
<h2>An Alternative Approach</h2>
|
|
|
|
<p>Can we simplify CSS usage to avoid as many pitfalls as possible while still allowing for modern visual presentation? Since CSS lacks clear rules for the cascade, and has overly complicated rules governing the calculations of specificity using these unclear cascade rules, a good approach is to simply avoid as many of these rules as possible. We can do this by realizing that...we can just not use most of this:</p>
|
|
|
|
<ol>
|
|
<li><b>Simplify specificity</b> by using tag selectors (aka type selectors) instead <b>classes</b>.</li>
|
|
<li><b>Simplify HTML</b> by using actual <b><tags></b> instead of <b><div.class="basically-a-tag"></b>.</li>
|
|
<li><b>Simplify layout and HTML</b> by using flexbox and CSS grids instead of convoluted structure <b>divs</b>.</li>
|
|
<li><b>Simplify visual reasoning</b> by naming tags to match their actual role in the visual display.</li>
|
|
<li><b>Simplify interactions</b> by using <b>class</b> sparingly for variants or state changes.</li>
|
|
<li><b>Simplify extension and modification</b> by using <b>id</b> for specific local elements that have their own style changes overriding the previous definitions.</li>
|
|
<li><b>Simplify development</b> by adding more complicated CSS <b>after</b> you get simpler CSS working.</li>
|
|
</ol>
|
|
|
|
Links:
|
|
|
|
https://www.w3.org/TR/CSS22/cascade.html#specificity
|
|
|
|
|
|
|