The list reminds me of when people refactor code and then just rename things. Ok, foo should've been called bar, but is that really a design mistake? The biggest design mistake for me is that it contains the letter C - it never should've been cascading. There's probably a need to resolve conflicting rules but it never should've been THE feature around which the language is designed. The precedence algorithm, the specificity etc. has been a source of endless bugs because you almost never know if somewhere somehow an outdated selector is messing everything up in a hidden place far away from what you're actually doing.<p>Instead the core features should've been simple ways to, well, style. From the beginning you should've been able to e.g. position vertically. There's a huge list of these issues where for a long time the simplest things were difficult and involved too much thought to get anything done. Granted things have improved, but the main issue I have is that standards like CSS should be more practice driven, e.g. what are the things I want to get done and how do I do that. Instead this is how you will override a selector as if that's the most important thing.
Related:<p><i>Incomplete List of Mistakes in the Design of CSS</i> - <a href="https://news.ycombinator.com/item?id=25891435">https://news.ycombinator.com/item?id=25891435</a> - Jan 2021 (68 comments)<p><i>Incomplete List of Mistakes in the Design of CSS</i> - <a href="https://news.ycombinator.com/item?id=18297757">https://news.ycombinator.com/item?id=18297757</a> - Oct 2018 (150 comments)<p><i>Incomplete List of Mistakes in the Design of CSS</i> - <a href="https://news.ycombinator.com/item?id=10453850">https://news.ycombinator.com/item?id=10453850</a> - Oct 2015 (106 comments)<p><i>Incomplete List of Mistakes in the Design of CSS</i> - <a href="https://news.ycombinator.com/item?id=7665667">https://news.ycombinator.com/item?id=7665667</a> - April 2014 (1 comment)
Make flexbox the default layout for everything, and add a flex-snap feature that will snap to the nearest multiple of some given size. I'm not sure we actually would still need grids.<p>I also wonder if you couldn't have a more transparent and parameterizable auto width algorithm based on a lowest cost solver.<p>So you could say "If this element wraps, it's cost 50", meaning you want all the boxes to stay on as few lines as possible. Or "Every em of height this element has is cost 10, if anything triggers a scrollbar, that's cost 100".<p>Maybe instead of flex-grow, you'd just add negative cost to the width of something.<p>You could have alternate rulesets so the browser could choose one or the other for lowest overall page cost.<p>Also, class inheritance. I don't see why that's not a thing. "Not needing processors" should be a pretty big design goal.
> Box-sizing should be border-box by default.<p>It was in Internet Explorer, everything being misaligned because of this difference was one of the reasons it got the nickname Internet Exploder.<p>Edit: To be clear this was more of just a fun fact, I agree with this statement. The misalignment was because people would build to content-box without knowing it was different in IE. Worse still IIRC they acted differently even before this CSS attribute was exposed, so you had to make it work both ways if you wanted your site to look nice everywhere.
> background-position and border-spacing (all 2-axis properties) should take <i>vertical</i> first, to match with the 4-direction properties like margin.<p>I hate that margin / padding short-hands, especially with 2 values, expect vertical first.<p>In my head it's always (x,y) and (width,height) – always horizontal then vertical, I feel like it works like this everywhere else?<p>Now my issue is that I've committed to memory that margin and padding short-hands work the exact opposite way I would expect, so sometimes I still mix them up because I type them 'correctly' and then flip them because I memorized it like that..
Personally, I think box-sizing being content-box by default was probably the biggest misstep here, and something that genuinely feels at odds with how 99% of the population would design or build something. The fact IE got it right initially and then it took another few years to even get things fixed across the board just feels utterly ridiculous to me.<p>Also, not having something like Flexbox or Grid earlier on was another mistake that should have been listed too. The fact we had to resort to hacks related to floats and table layout to create basic layouts was an absolute joke, and indicates that the creators at the time had no idea what a site or application would usually be like design or functionality wise.
> The top and bottom margins of a single box should never have been allowed to collapse together automatically as this is the root of all margin-collapsing evil.<p>Disagree. All margins, including horizontal, should collapse. Typically you want 20px between buttons, not 20 + 20.
While many of these are obvious and don't need further explanation, the article would benefit a lot from showing a few simple examples for some of these items, or a justification for why the author's proposed naming is better.
Backwards compatibility may be a fundamental design philosophy of the web, but wouldn't it still be possible to support a different document format with a new programming model that gives us a clean break from the past? It's a naive question, I realize, but it's tantalizing to imagine what we could have if we went that route.<p>Then again, the cynic in me thinks we'd just endlessly fight over the design decisions anyways.
I thought "!important" was always about appealing to the emotions of overwhelmed and confused CSS authors as it seems to make the computer "listen to you" when it doesn't seem to be.<p>I remember this notorious book<p><a href="https://www.amazon.com/Creating-Killer-Sites-David-Siegel/dp/1568304331" rel="nofollow noreferrer">https://www.amazon.com/Creating-Killer-Sites-David-Siegel/dp...</a><p>about techniques used to get pixel perfect results with HTML back in the 1990s. The author of that book was quite impressed with CSS as it really does give designers great tools to work with, but it's still got the problem that designers find it hard to be disciplined with. That is, a lot of designers are stuck in a "let's draw a pretty picture" mindset but find it hard to think like "let's develop a system that makes it easy to draw lots of pretty pictures". Thus we get a lot of things like bootstrap and tailwind that erode the idea of CSS classes being somewhat semantic and being related to the structure of the system (e.g. this <i>particular</i> toolbar as it manifests in this application) as opposed to "a generic toolbar that comes out of a framework" or "something that has 15px of margin".)
> z-index should be called z-order or depth and should Just Work on all elements (like it does on flex items).<p>Z-index is one of the most aggravating things I've run into with CSS. It should always Just Work as the author says and be absolute across the whole page and intuitive. But it isn't. And every time I run into a problem where it's not behaving in the way I expect, I have to once again Google 'z index not working' and refresh my memory on all the reasons why it might not be working with the specific example I'm dealing with.
> It shouldn't be `!important` — that reads to engineers as “not important”. We should have picked another way to write this.<p>Oh absolutely. Even `important!` would have been better.
ChatGPT is a CSS deity, I have been using it lately and have been impressed by it. I suppose it's because so many issues were raised about it, so it is now trained on every possible mistake you can make
It shouldn't have had inheritance by default. It was designed at the height of object-oriented programming, and so it had to have inheritance. This results in blocks of CSS turning off stuff in case some outer CSS turned it on.<p>It really should have been a constraint system. Layout should be something that says that X is to the right of Y, Y is below Z, A and B have the same height, etc. But people didn't really know how to do those back then. See the 2D sketching system in Autodesk Inventor/Fusion to see this done right. That can do more than boxes (it understands curves) but web layout should probably just be boxes.<p>Maybe it shouldn't be textual at all. Maybe layout should be designed entirely in graphical tools.<p>Cannot put text on top of text. Boxes must be disjoint. If you want another layer, OK, but layers should work like windows.
No, the biggest mistake in the design of CSS is not realizing they are designing a programming language, and consequently not adding means for abstraction and composition. Less, Sass, Tailwind etc. would not exist if abstraction and composition existed in CSS. This list is just a layer of paint.
> rgba() and hsla() should not exist, rgb() and hsl() should have gotten an optional fourth parameter instead<p>That one got fixed without a time machine!
The Entire front end web stack looks like a design mistake.<p>Backend looks better only because of the flexibility. You can do anything in the back. But the front you're locked into multi decade old tech and the decade old wrappers written around it.
More tools to manipulate scroll targeting, scroll bars, and better access to more parameters around scrolling. Also better tools around display: clip. I spent maybe 6 hours trying to recreate instagram on iOS’s appbar scrolling to hide/reveal and even with some JavaScript, I don’t think it’s actually possible to coax a browser into doing it perfectly. Particularly to have it be completely smooth without scrolling artifacts, and on mobile.<p>Also, if anybody can figure it out, I would absolutely love to see and discuss.
<p><pre><code> The list-style properties should be called marker-style, and list-item renamed > to marked-block or something.
</code></pre>
I think list and list-item are clear.<p>How about just `mark` instead of `marker-style` to be consistent with other properties that decorate part of an element like `border` or `background`?
Flexbox is obsolete and as with JavaScript you are supposed to wrestle with a subset of css aka the good parts.<p>Sensible user interfaces are a solved problem and it is totally fine that the tutorial industry shows all the other possibilities you have when you don’t need to display content while the framework industry points to general one size fits all solutions from which you can pick the one that fits your specific general use-case and favorite way of displaying the filler text around the advertising content.
There are even more fundamental mistakes in the concept of page styling. For example, that a webmaster should attempt to choose a readable font size and font colour on behalf of their users without knowing anything about the users' needs in that regard.
>That should be corrected<p>There used to be a PostCSS plugin that <i>did</i> fix some of these, for example you could write "white-space: no-wrap"
and it would compile to "nowrap" (which is syntactically correct). I can't remember what it was called.