13 ms·

Mistakes in the Design of CSS (2013)

112 points by ARCarr 3y ago

corethree 3y ago
The Entire front end web stack looks like a design mistake. 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.
- dtagames 3y ago
  I disagree. First of all, all of computing is locked into decades-only technology: assembler language and machine instructions. Everything comes down to that whether you write front or back end and regardless of what other "tech" is in the middle. Today, we can do anything on the front end. Some of the most popular and complex apps in history are front end apps made with JS/HTML and web components (Discord, Spotify, Photoshop for Web, YouTube, and many others.) The reason that this "stack" has survived and thrived is precisely that it does, at this point, allow front end devs to do anything and to do it in a way that runs everywhere. And that's a Very Good Thing.
  - treyd 3y ago
    > assembler language and machine instructions Except no we're not, new processors bring along new features and drop/discourage old ones, on x86 they even run in different modes depending on requirements, and compilers can choose to target specifically new ones and drop support for older processors without them. This isn't a valid comparison. I think it's a bad thing because even though "you can do anything" it doesn't mean you can do it well because the web was always designed to be narrow and restricted for privacy/security reasons. That's good, but there's large classes of applications (chat clients, music players, image editors, etc) where that shouldn't be an issue and the costs of running in a web-like environment. Which, even if you drop the security features, manifests as worse UX to users due to the layers of indirection you're dealing with between the developer and the host OS.
  - corethree 3y ago
    But front end is a high level specification. The principles of physics remain the same but the machines around those laws of physics should improve.
  - blackbear_ 3y ago
    Lol, do you really consider a music player and a chat application as the most complex apps in history?
- cantSpellSober 3y ago
  This article is just about CSS not the entire frontend web stack. Curious though, do you consider server-side-rendered components "frontend?" What about React Server Components?
  - corethree 3y ago
    >This article is just about CSS not the entire frontend web stack. Why waste your effort to inform me something I already know? You know that I know. >Curious though, do you consider server-side-rendered components "frontend?" Why are you curious about vocabulary and categorization? If you know what I'm talking about by "front-end-stack" then who cares?
    - cantSpellSober 3y ago
      Oh, strange non-sequitur then. I don't know what you mean specifically by "front end stack", so I asked (unanswered) clarifying questions. > Why are you curious about vocabulary and categorization Because the frontend/backend lines are blurring, and I want to define our terms before discussion.
      - corethree 3y ago
        You haven't answered my question. Why inform me on something obvious that I know? I know the article is about css. And you know that I know. By front end I mean any technology directly associated with rendering and processing on the browser. The lines of this definition are blurry so I will adjust those lines and move them accordingly to fit the intent of what I'm saying here. But again you know my intent so why make me waste my time to specify something you clearly know?
        cantSpellSober 3y ago
        I thought your question was simply rhetoric. I didn't realize how confused you were. To answer: if there's an article about tomato slices and someone goes on a rant about hamburgers (tomato slices being a small part of the whole) it's not clear or "obvious" that they read or understood the article. You haven't answered my question, do you consider server-side-rendered components "frontend?" They are "directly associated with rendering and processing on the browser." (Even if they aren't rehydrated.)
- PaulHoule 3y ago
  What's the alternative? The 1990s style HTML form app that works like a green screen mainframe application? (It seems to be forgotten technology in the age of React like Stonehenge or the Egyptian Pyramids but I think it's quite appropriate for the kind of application it's capable of, which is more > 50% of what people use React for.) Cross-platform frameworks like GTK, Qt, Tk, FLTK, wxWidgets (was that a winner in the world cup for "ugliest UI"?), Flutter, etc. (I did a shootout of x-platform UI frameworks and concluded that Electron really is the best of the bunch, is it any worse to make people download a 30MB Electron runtime than a 50MB Java runtime or a 25MB Python runtime?) Apple fanboys inexplicably seem to like iTunes and MacOS, they all swear by xCode but even people who think "it is is all good" when it comes to fruit swear at the App Store when it comes to delays and restrictions. I'm pretty sure there is a good UI framework somewhere inside Windows but it might be hard to find in a maze of twisty little APIs that all look alike: https://www.reillywood.com/blog/windows-ui-frameworks/ https://www.reillywood.com/blog/windows-ui-frameworks/ Compare that to the freedom of the web platform. I've lately been playing around with this framework with my Meta Quest 3: https://aframe.io/examples/showcase/modelviewer/ https://aframe.io/examples/showcase/modelviewer/ which makes it straightforward to make an application that targets desktop, mobile, VR and AR headsets. Although it is based on React it has the same entity-component architecture as the Unity framework. I'm sure I could get better performance writing a more-or-less Android app based on Unity but dealing with Facebook's App Store seems like messing around with IBM cards, particularly when I want to target Apple Vision when it comes out and when I need to have an experience for people that don't have a VR headset because those aren't very common yet.
  - sproketboy 3y ago
    [dead]
  - cantSpellSober 3y ago
    > What's the alternative? Good question! What do you mean? There is no alternative, just enough experience writing it that these mistakes become hardwired, or having browsers updated to interpret "no-wrap" as "nowrap" for ex. The options you mention make sense, but just a level of abstraction. CSS is still the compile target (unless you're using WASM etc). Unless you mean alternatives to, say, using things like `!important`?
- paulddraper 3y ago
  Sorry I can't hear you over the sound of my fifteen hundred microservice infrastructure configured with Chef, no actually Puppet, no actually Ansible, no actually Terraform, no actually Tofu, no actually Pulumi. Wait, what is Docker Swarm and does anyone use it?
  - corethree 3y ago
    Bro backend is a different set of problems.
  - lmm 3y ago
    Thankfully you can opt out of most of those and pick the one that works for you. Sadly there's no alternative to CSS.
    - paulddraper 3y ago
      Yes, if you restrict it to web browsers, and more specifically HTML (not Canvas, WebGL).
pprotas 3y ago
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.
- danielvaughn 3y ago
  Yeah without a demo, it's hard even for me to grasp why some of them are mistakes, and I've been writing CSS since 2009.
danielvaughn 3y ago
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. Then again, the cynic in me thinks we'd just endlessly fight over the design decisions anyways.
- rusk 3y ago
  You’d have to get people to use it. Like any established warty system, the warts provide just enough of a moat for established practitioners to keep it just the way it is.
  - fiddlerwoaroof 3y ago
    The thing is, you could use doctypes like a racket #lang to precisely opt into the new format. Same with the type attribute on style, script and link elements. I’ve always found it a bit sad that we haven’t really taken advantage of the built-in extension points of HTML and related technologies because they’re designed pretty well for breaking changes without breaking compatibility.
    - danielvaughn 3y ago
      This sounds interesting - what do you mean by the "built-in extension points"?
      - fiddlerwoaroof 3y ago
        I already listed them: doctypes, the lang/type attribute for script/style/link tags, and custom elements/attributes. Back in the day, you could use alternate scripting languages in IE: VBScript shipped by default, but there was also the ability to install an ActiveX extension to enable Python and some others in the script tag.
    - rusk 3y ago
cantSpellSober 3y ago
>That should be corrected There used to be a PostCSS plugin that did 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.
__jonas 3y ago
> background-position and border-spacing (all 2-axis properties) should take vertical first, to match with the 4-direction properties like margin. I hate that margin / padding short-hands, especially with 2 values, expect vertical first. In my head it's always (x,y) and (width,height) – always horizontal then vertical, I feel like it works like this everywhere else? 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..
- rusk 3y ago
  I think there’s a historical reason for this, that probably made more sense back in the 90s … I seem to remember learning computer graphics back then and being similarly frustrated by the reversed notation. My guess is it goes back to raster based calculations where you would go down a number of lines and then across. Oh yea orig is top left rather than bottom left as one would also naturally expect
  - valyagolev 3y ago
    it is quite sensible that origin is top left in potentially scrollable situations
  - __jonas 3y ago
    Interesting! I am not too annoyed by the coordinate system with flipped y-axis, but I understand that other graphics APIs handle it differently, the vertical-first order I really don't get though. Out of curiosity, I just briefly looked at the OpenGL 1.0 specification from 1994 [1] and it seems it is also taking coordinates in the order (x,y), I wonder why CSS then decided to go the other way. [1] https://registry.khronos.org/OpenGL/specs/gl/glspec10.pdf https://registry.khronos.org/OpenGL/specs/gl/glspec10.pdf
    - giantrobot 3y ago
      Some drawing systems take coordinates in x,y but the origin is top left. Ascending coordinates go down and right. Then other systems have an origin at the bottom left so ascending coordinates go right and up. There's good reasons for both depending on the context and nature of the drawing.
PaulHoule 3y ago
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. I remember this notorious book https://www.amazon.com/Creating-Killer-Sites-David-Siegel/dp/1568304331 https://www.amazon.com/Creating-Killer-Sites-David-Siegel/dp... 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 particular 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".)
- Brajeshwar 3y ago
  `!important` was our ultimate weapon designing unbreakable embeddable widgets that other sites will drop in to their webpages at their whims.
  - PaulHoule 3y ago
    Exactly -- that's what is missing in the (at least conventional) HTML and CSS stack. One of the great ideas from Ted Nelson's https://en.wikipedia.org/wiki/Project_Xanadu https://en.wikipedia.org/wiki/Project_Xanadu was transclusion: any document could embed part of some other document. Now Ted saw that being done by a special kind of hyperlink (you're not copying the target but linking to it) and he imagined there was a micropayments system such that I get 10 cents for the document and author of the target gets 1 cent. In the case of HTML it would be great if you could snip a piece of HTML out of a document together with CSS and associated assets and then incorporate these into another document and have it "just work". I mean, if it was easy to do we wouldn't see people collect and post so many screenshots from X, they could just make an HTML page that embeds the content. I prototyped a server-side templating system that would break HTML down into a DOM graph and made some progress on the problem of rewriting identifiers such as classes and identifiers in a donor document to address problems similar to the "hygenic macro" problem when it is embedded in a host document. I got it to work in some simple cases but wasn't sure how general I could make it. (In some cases you are going to have to modify the CSS to make the donor work inside the host, for instance, and that probably does involve judgement calls.) It's quite a miracle that people get CSS to work inside React components, Web components, and stuff like that, given that out of the box CSS doesn't have any mechanism to stop people from using the same classes, not to mention a rather complex mechanism of inheritance, etc.
Izkata 3y ago
> Box-sizing should be border-box by default. It was in Internet Explorer, everything being misaligned because of this difference was one of the reasons it got the nickname Internet Exploder. 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.
epups 3y ago
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
codedokode 3y ago
> 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. Disagree. All margins, including horizontal, should collapse. Typically you want 20px between buttons, not 20 + 20.
- Nathanael_M 3y ago
  But I can get that functionality very easily with an owl selector, whereas opinionated default functionality means there are cases where I have to actively fight the system.
- ForkMeOnTinder 3y ago
  In that case you probably want a `gap` of 20px, not a margin.
  - pavlov 3y ago
    And this illustrates why margin as defined in CSS doesn’t really make sense at all. Outer margin is not usually a property of the element itself, but its container.
    - Chabsff 3y ago
      To be fair, it makes sense when you look at the use-case that spawned margins in the first place: <h1/><h2/>, <h1/><p/>, <h3/><h4/>, <h3/><p/>, etc... It does make for a fairly elegant way of handling all of those permutations with a reasonable amount of attributes. That comes in to play particularly in cases where you don't have control over which will show up in the wild (e.g. when dealing with Markdown content)
      - pavlov 3y ago
        Even for text flows, the margins should be derived from properties of the container. Traditional graphic designers creating print layouts didn’t use randomly different margins for elements on a page. The margins were derived from a grid system that was applied to the entire page. Within that system, the margin between a body paragraph and a header might be (for example) two grid squares, while the margin between body paragraphs would be one grid square. CSS designers should have thought more conceptually about the HTML page as a container for text elements. Instead they just created a whole bunch of properties that allow elements themselves to define any spacing anywhere in any units, then tried to patch up the conceptual mess with hacks like margin collapse.
Jeema101 3y ago
> z-index should be called z-order or depth and should Just Work on all elements (like it does on flex items). 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.
- Nathanael_M 3y ago
  z-index causes me physical pain. z-index puts stress on my marriage. My children will experience generational trauma through z-index.
creata 3y ago
> rgba() and hsla() should not exist, rgb() and hsl() should have gotten an optional fourth parameter instead That one got fixed without a time machine!
oftenwrong 3y ago
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.
r2b2 3y ago
The list-style properties should be called marker-style, and list-item renamed > to marked-block or something. I think list and list-item are clear. How about just `mark` instead of `marker-style` to be consistent with other properties that decorate part of an element like `border` or `background`?
dang 3y ago
Related: Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=25891435 https://news.ycombinator.com/item?id=25891435 - Jan 2021 (68 comments) Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=18297757 https://news.ycombinator.com/item?id=18297757 - Oct 2018 (150 comments) Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=10453850 https://news.ycombinator.com/item?id=10453850 - Oct 2015 (106 comments) Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=7665667 https://news.ycombinator.com/item?id=7665667 - April 2014 (1 comment)
eternityforest 3y ago
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. I also wonder if you couldn't have a more transparent and parameterizable auto width algorithm based on a lowest cost solver. 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". Maybe instead of flex-grow, you'd just add negative cost to the width of something. You could have alternate rulesets so the browser could choose one or the other for lowest overall page cost. Also, class inheritance. I don't see why that's not a thing. "Not needing processors" should be a pretty big design goal.
- 4death4 3y ago
  How would your flex box solution handle a simple two column layout where the first column is a variable size? There isn’t a fixed multiple to “snap” to.
  - eternityforest 3y ago
    Didn't think of that case! But if you had a full algebra/constraints/logic programming system, you could set a solver rule where the first column items had width X, with fairly high priority. And other rules(like fit-content) on that same property, to specify what the width should be. The solver would figure out what X should be, and everything in the first column would have that width unless something even more important changed it. You could even give rules a "layer" in addition to the solver cost, and properties would only take rules from the highest active layer, so you could still do overriding, just explicitly instead of with specificity. To avoid confusion with different CSS files, layer could be a hierarchal tuple, and you could manually specify the layer of an imported file, forcing all its layers to become sub layers of the one you specified, so you could override a file, or merge two files in one layer, etc.
  - onion2k 3y ago
    You could snap to a percentage width.
Animats 3y ago
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. 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. Maybe it shouldn't be textual at all. Maybe layout should be designed entirely in graphical tools. Cannot put text on top of text. Boxes must be disjoint. If you want another layer, OK, but layers should work like windows.
roblh 3y ago
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. Also, if anybody can figure it out, I would absolutely love to see and discuss.
stevage 3y ago
> It shouldn't be `!important` — that reads to engineers as “not important”. We should have picked another way to write this. Oh absolutely. Even `important!` would have been better.
- n3storm 3y ago
  Prevails
mediumsmart 3y ago
Flexbox is obsolete and as with JavaScript you are supposed to wrestle with a subset of css aka the good parts. 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.
- reidjs 3y ago
  Wait what??? Since when is flexbox obsolete I use it all the time, I think I used it today. What had replaced it? Don’t say grid, that’s better for 2d layouts.
- shepherdjerred 3y ago
  > Flexbox is obsolete Not it's not.
locallost 3y ago
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. 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.
- onion2k 3y ago
  This is interesting because my first reaction was to recoil in horror at the idea of CSS without the cascade, but my second reaction was to realie you're actually describing approximately how Tailwind works eg small classes that you can use to apply an aspect of styling to a specific element, and use to build up to a design. Utility classes would be the obvious choice if you couldn't rely on the cascade any more. Tailwind styles still cascade but in a far more manageable and override-able way. Perhaps you're on to something.
  - locallost 3y ago
    Which is better or correct is a question of basically how do you organize code. It's not irrelevant, but at the core should've been how to style content in a way that people actually want to style content. Instead a lot of time was spent on making up rules about cascading and specificity, which the vast majority of developers don't truly know. I knew them 15 years ago well, and realized also in horror as I wrote that I don't really know them so well. And turns out it's not so important. CSS gave us a bunch of primitive things to do, and we were supposed to figure it out, but the primitive things were not that well designed either. It was always a bunch of trickery, but at least the separation of concerns was taken care of.
matheusmoreira 3y ago
Why can't there be aliases for those names? I'd certainly use them. Is there a reason nowrap and no-wrap can't both work?
hknmtt 3y ago
The biggest fuckup of CSS, to this day, is lack of vertical centering of content.
- maxloh 3y ago
  I always use `display: flex` for that.
noelwelsh 3y ago
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.
- krapp 3y ago
  I disagree. No one needed that in the 90s when CSS came out, all they needed was a way to reference document styles from one file, rather than adding it manually to every HTML file. And besides, don't all front-end frameworks just add CSS directives into the HTML anyway? I feel like the incessant urge to make webdev look and feel like pure programming that emerged with the SV gold rush would have led us where we are anyway - except in the universe where CSS was already a full fledged programming language, things would just be exponentially more complex than they are now.
  - noelwelsh 3y ago
    A programming language doesn't have to be Turing complete to be a programming language. Programming languages do at least one of two things: control a machine or provide a notation for solutions to a problem. CSS is both. It controls the layout engine in the browser and it provides a declarative notation for doing so. All programming languages need some way to provide abstraction, which means hiding irrelevant details, and composition, which means building bigger things out of small things. CSS related examples are until recently you couldn't say "Use the main theme color" (abstraction; hiding the actual color behind a name.) You still cannot name a group of styles and reuse them, so you cannot say "the dark theme is the base theme with these colors added" (abstraction and composition). If you look at what Tailwind is, the core is just composition: being able to say "this element's style is built out of the following components". The @apply CSS extension that Tailwind provides is pure composition.
- bdw5204 3y ago
  Nobody expected entire applications to be built out of HTML, CSS and JavaScript when those languages were being designed. CSS's main purpose was to get inappropriate bloat out of HTML because HTML was supposed to describe content not what it looks like but the IE vs Netscape browser wars had created a proliferation of new HTML tags that went against the purpose of the language. JavaScript was designed for writing simple scripts to enhance web sites not to be a full programming language. Web application development was supposed to be done through plugins like Java (applets), Flash and Shockwave. It wasn't until 10-15 years ago that the idea to just do all of this in HTML, CSS and JavaScript occured to anybody because it would have been really slow and inefficient on older hardware (HTML5 video on Youtube instead of Flash used to slow my mid-00s mid range Windows XP laptop to a crawl). For CSS in particular, the expectation of its creators was that users would specify their own style sheet which would override the web site's style sheet. To the best of my knowledge, this feature ended up being little used and is not even possible in modern browsers. (The above is what I remember from teaching myself web 1.0 style web development from books in the early 00s as a preteen and then teenager)
CM30 3y ago
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. 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.

112 points by ARCarr 3y ago

The Entire front end web stack looks like a design mistake. 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.

dtagames 3y ago
I disagree. First of all, all of computing is locked into decades-only technology: assembler language and machine instructions. Everything comes down to that whether you write front or back end and regardless of what other "tech" is in the middle. Today, we can do anything on the front end. Some of the most popular and complex apps in history are front end apps made with JS/HTML and web components (Discord, Spotify, Photoshop for Web, YouTube, and many others.) The reason that this "stack" has survived and thrived is precisely that it does, at this point, allow front end devs to do anything and to do it in a way that runs everywhere. And that's a Very Good Thing.
- treyd 3y ago
  > assembler language and machine instructions Except no we're not, new processors bring along new features and drop/discourage old ones, on x86 they even run in different modes depending on requirements, and compilers can choose to target specifically new ones and drop support for older processors without them. This isn't a valid comparison. I think it's a bad thing because even though "you can do anything" it doesn't mean you can do it well because the web was always designed to be narrow and restricted for privacy/security reasons. That's good, but there's large classes of applications (chat clients, music players, image editors, etc) where that shouldn't be an issue and the costs of running in a web-like environment. Which, even if you drop the security features, manifests as worse UX to users due to the layers of indirection you're dealing with between the developer and the host OS.
- corethree 3y ago
  But front end is a high level specification. The principles of physics remain the same but the machines around those laws of physics should improve.
- blackbear_ 3y ago
  Lol, do you really consider a music player and a chat application as the most complex apps in history?
cantSpellSober 3y ago
This article is just about CSS not the entire frontend web stack. Curious though, do you consider server-side-rendered components "frontend?" What about React Server Components?
- corethree 3y ago
  >This article is just about CSS not the entire frontend web stack. Why waste your effort to inform me something I already know? You know that I know. >Curious though, do you consider server-side-rendered components "frontend?" Why are you curious about vocabulary and categorization? If you know what I'm talking about by "front-end-stack" then who cares?
  - cantSpellSober 3y ago
    Oh, strange non-sequitur then. I don't know what you mean specifically by "front end stack", so I asked (unanswered) clarifying questions. > Why are you curious about vocabulary and categorization Because the frontend/backend lines are blurring, and I want to define our terms before discussion.
    - corethree 3y ago
      You haven't answered my question. Why inform me on something obvious that I know? I know the article is about css. And you know that I know. By front end I mean any technology directly associated with rendering and processing on the browser. The lines of this definition are blurry so I will adjust those lines and move them accordingly to fit the intent of what I'm saying here. But again you know my intent so why make me waste my time to specify something you clearly know?
      - cantSpellSober 3y ago
        I thought your question was simply rhetoric. I didn't realize how confused you were. To answer: if there's an article about tomato slices and someone goes on a rant about hamburgers (tomato slices being a small part of the whole) it's not clear or "obvious" that they read or understood the article. You haven't answered my question, do you consider server-side-rendered components "frontend?" They are "directly associated with rendering and processing on the browser." (Even if they aren't rehydrated.)
PaulHoule 3y ago
What's the alternative? The 1990s style HTML form app that works like a green screen mainframe application? (It seems to be forgotten technology in the age of React like Stonehenge or the Egyptian Pyramids but I think it's quite appropriate for the kind of application it's capable of, which is more > 50% of what people use React for.) Cross-platform frameworks like GTK, Qt, Tk, FLTK, wxWidgets (was that a winner in the world cup for "ugliest UI"?), Flutter, etc. (I did a shootout of x-platform UI frameworks and concluded that Electron really is the best of the bunch, is it any worse to make people download a 30MB Electron runtime than a 50MB Java runtime or a 25MB Python runtime?) Apple fanboys inexplicably seem to like iTunes and MacOS, they all swear by xCode but even people who think "it is is all good" when it comes to fruit swear at the App Store when it comes to delays and restrictions. I'm pretty sure there is a good UI framework somewhere inside Windows but it might be hard to find in a maze of twisty little APIs that all look alike: https://www.reillywood.com/blog/windows-ui-frameworks/ https://www.reillywood.com/blog/windows-ui-frameworks/ Compare that to the freedom of the web platform. I've lately been playing around with this framework with my Meta Quest 3: https://aframe.io/examples/showcase/modelviewer/ https://aframe.io/examples/showcase/modelviewer/ which makes it straightforward to make an application that targets desktop, mobile, VR and AR headsets. Although it is based on React it has the same entity-component architecture as the Unity framework. I'm sure I could get better performance writing a more-or-less Android app based on Unity but dealing with Facebook's App Store seems like messing around with IBM cards, particularly when I want to target Apple Vision when it comes out and when I need to have an experience for people that don't have a VR headset because those aren't very common yet.
- sproketboy 3y ago
  [dead]
- cantSpellSober 3y ago
  > What's the alternative? Good question! What do you mean? There is no alternative, just enough experience writing it that these mistakes become hardwired, or having browsers updated to interpret "no-wrap" as "nowrap" for ex. The options you mention make sense, but just a level of abstraction. CSS is still the compile target (unless you're using WASM etc). Unless you mean alternatives to, say, using things like `!important`?
paulddraper 3y ago
Sorry I can't hear you over the sound of my fifteen hundred microservice infrastructure configured with Chef, no actually Puppet, no actually Ansible, no actually Terraform, no actually Tofu, no actually Pulumi. Wait, what is Docker Swarm and does anyone use it?
- corethree 3y ago
  Bro backend is a different set of problems.
- lmm 3y ago
  Thankfully you can opt out of most of those and pick the one that works for you. Sadly there's no alternative to CSS.
  - paulddraper 3y ago
    Yes, if you restrict it to web browsers, and more specifically HTML (not Canvas, WebGL).

pprotas 3y ago

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.

danielvaughn 3y ago
Yeah without a demo, it's hard even for me to grasp why some of them are mistakes, and I've been writing CSS since 2009.

danielvaughn 3y ago

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. Then again, the cynic in me thinks we'd just endlessly fight over the design decisions anyways.

rusk 3y ago
You’d have to get people to use it. Like any established warty system, the warts provide just enough of a moat for established practitioners to keep it just the way it is.
- fiddlerwoaroof 3y ago
  The thing is, you could use doctypes like a racket #lang to precisely opt into the new format. Same with the type attribute on style, script and link elements. I’ve always found it a bit sad that we haven’t really taken advantage of the built-in extension points of HTML and related technologies because they’re designed pretty well for breaking changes without breaking compatibility.
  - danielvaughn 3y ago
    This sounds interesting - what do you mean by the "built-in extension points"?
    - fiddlerwoaroof 3y ago
      I already listed them: doctypes, the lang/type attribute for script/style/link tags, and custom elements/attributes. Back in the day, you could use alternate scripting languages in IE: VBScript shipped by default, but there was also the ability to install an ActiveX extension to enable Python and some others in the script tag.
  - rusk 3y ago

cantSpellSober 3y ago

>That should be corrected There used to be a PostCSS plugin that did 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.

__jonas 3y ago

> background-position and border-spacing (all 2-axis properties) should take vertical first, to match with the 4-direction properties like margin. I hate that margin / padding short-hands, especially with 2 values, expect vertical first. In my head it's always (x,y) and (width,height) – always horizontal then vertical, I feel like it works like this everywhere else? 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..

rusk 3y ago
I think there’s a historical reason for this, that probably made more sense back in the 90s … I seem to remember learning computer graphics back then and being similarly frustrated by the reversed notation. My guess is it goes back to raster based calculations where you would go down a number of lines and then across. Oh yea orig is top left rather than bottom left as one would also naturally expect
- valyagolev 3y ago
  it is quite sensible that origin is top left in potentially scrollable situations
- __jonas 3y ago
  Interesting! I am not too annoyed by the coordinate system with flipped y-axis, but I understand that other graphics APIs handle it differently, the vertical-first order I really don't get though. Out of curiosity, I just briefly looked at the OpenGL 1.0 specification from 1994 [1] and it seems it is also taking coordinates in the order (x,y), I wonder why CSS then decided to go the other way. [1] https://registry.khronos.org/OpenGL/specs/gl/glspec10.pdf https://registry.khronos.org/OpenGL/specs/gl/glspec10.pdf
  - giantrobot 3y ago
    Some drawing systems take coordinates in x,y but the origin is top left. Ascending coordinates go down and right. Then other systems have an origin at the bottom left so ascending coordinates go right and up. There's good reasons for both depending on the context and nature of the drawing.

PaulHoule 3y ago

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. I remember this notorious book https://www.amazon.com/Creating-Killer-Sites-David-Siegel/dp/1568304331 https://www.amazon.com/Creating-Killer-Sites-David-Siegel/dp... 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 particular 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".)

Brajeshwar 3y ago
`!important` was our ultimate weapon designing unbreakable embeddable widgets that other sites will drop in to their webpages at their whims.
- PaulHoule 3y ago
  Exactly -- that's what is missing in the (at least conventional) HTML and CSS stack. One of the great ideas from Ted Nelson's https://en.wikipedia.org/wiki/Project_Xanadu https://en.wikipedia.org/wiki/Project_Xanadu was transclusion: any document could embed part of some other document. Now Ted saw that being done by a special kind of hyperlink (you're not copying the target but linking to it) and he imagined there was a micropayments system such that I get 10 cents for the document and author of the target gets 1 cent. In the case of HTML it would be great if you could snip a piece of HTML out of a document together with CSS and associated assets and then incorporate these into another document and have it "just work". I mean, if it was easy to do we wouldn't see people collect and post so many screenshots from X, they could just make an HTML page that embeds the content. I prototyped a server-side templating system that would break HTML down into a DOM graph and made some progress on the problem of rewriting identifiers such as classes and identifiers in a donor document to address problems similar to the "hygenic macro" problem when it is embedded in a host document. I got it to work in some simple cases but wasn't sure how general I could make it. (In some cases you are going to have to modify the CSS to make the donor work inside the host, for instance, and that probably does involve judgement calls.) It's quite a miracle that people get CSS to work inside React components, Web components, and stuff like that, given that out of the box CSS doesn't have any mechanism to stop people from using the same classes, not to mention a rather complex mechanism of inheritance, etc.

Izkata 3y ago

> Box-sizing should be border-box by default. It was in Internet Explorer, everything being misaligned because of this difference was one of the reasons it got the nickname Internet Exploder. 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.

epups 3y ago

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

codedokode 3y ago

> 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. Disagree. All margins, including horizontal, should collapse. Typically you want 20px between buttons, not 20 + 20.

Nathanael_M 3y ago
But I can get that functionality very easily with an owl selector, whereas opinionated default functionality means there are cases where I have to actively fight the system.
ForkMeOnTinder 3y ago
In that case you probably want a `gap` of 20px, not a margin.
- pavlov 3y ago
  And this illustrates why margin as defined in CSS doesn’t really make sense at all. Outer margin is not usually a property of the element itself, but its container.
  - Chabsff 3y ago
    To be fair, it makes sense when you look at the use-case that spawned margins in the first place: <h1/><h2/>, <h1/><p/>, <h3/><h4/>, <h3/><p/>, etc... It does make for a fairly elegant way of handling all of those permutations with a reasonable amount of attributes. That comes in to play particularly in cases where you don't have control over which will show up in the wild (e.g. when dealing with Markdown content)
    - pavlov 3y ago
      Even for text flows, the margins should be derived from properties of the container. Traditional graphic designers creating print layouts didn’t use randomly different margins for elements on a page. The margins were derived from a grid system that was applied to the entire page. Within that system, the margin between a body paragraph and a header might be (for example) two grid squares, while the margin between body paragraphs would be one grid square. CSS designers should have thought more conceptually about the HTML page as a container for text elements. Instead they just created a whole bunch of properties that allow elements themselves to define any spacing anywhere in any units, then tried to patch up the conceptual mess with hacks like margin collapse.

Jeema101 3y ago

> z-index should be called z-order or depth and should Just Work on all elements (like it does on flex items). 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.

Nathanael_M 3y ago
z-index causes me physical pain. z-index puts stress on my marriage. My children will experience generational trauma through z-index.

creata 3y ago

> rgba() and hsla() should not exist, rgb() and hsl() should have gotten an optional fourth parameter instead That one got fixed without a time machine!

oftenwrong 3y ago

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.

r2b2 3y ago

The list-style properties should be called marker-style, and list-item renamed > to marked-block or something. I think list and list-item are clear. How about just `mark` instead of `marker-style` to be consistent with other properties that decorate part of an element like `border` or `background`?

dang 3y ago

Related: Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=25891435 https://news.ycombinator.com/item?id=25891435 - Jan 2021 (68 comments) Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=18297757 https://news.ycombinator.com/item?id=18297757 - Oct 2018 (150 comments) Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=10453850 https://news.ycombinator.com/item?id=10453850 - Oct 2015 (106 comments) Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=7665667 https://news.ycombinator.com/item?id=7665667 - April 2014 (1 comment)

eternityforest 3y ago

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. I also wonder if you couldn't have a more transparent and parameterizable auto width algorithm based on a lowest cost solver. 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". Maybe instead of flex-grow, you'd just add negative cost to the width of something. You could have alternate rulesets so the browser could choose one or the other for lowest overall page cost. Also, class inheritance. I don't see why that's not a thing. "Not needing processors" should be a pretty big design goal.

4death4 3y ago
How would your flex box solution handle a simple two column layout where the first column is a variable size? There isn’t a fixed multiple to “snap” to.
- eternityforest 3y ago
  Didn't think of that case! But if you had a full algebra/constraints/logic programming system, you could set a solver rule where the first column items had width X, with fairly high priority. And other rules(like fit-content) on that same property, to specify what the width should be. The solver would figure out what X should be, and everything in the first column would have that width unless something even more important changed it. You could even give rules a "layer" in addition to the solver cost, and properties would only take rules from the highest active layer, so you could still do overriding, just explicitly instead of with specificity. To avoid confusion with different CSS files, layer could be a hierarchal tuple, and you could manually specify the layer of an imported file, forcing all its layers to become sub layers of the one you specified, so you could override a file, or merge two files in one layer, etc.
- onion2k 3y ago
  You could snap to a percentage width.

Animats 3y ago

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. 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. Maybe it shouldn't be textual at all. Maybe layout should be designed entirely in graphical tools. Cannot put text on top of text. Boxes must be disjoint. If you want another layer, OK, but layers should work like windows.

roblh 3y ago

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. Also, if anybody can figure it out, I would absolutely love to see and discuss.

stevage 3y ago

> It shouldn't be `!important` — that reads to engineers as “not important”. We should have picked another way to write this. Oh absolutely. Even `important!` would have been better.

n3storm 3y ago
Prevails

mediumsmart 3y ago

Flexbox is obsolete and as with JavaScript you are supposed to wrestle with a subset of css aka the good parts. 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.

reidjs 3y ago
Wait what??? Since when is flexbox obsolete I use it all the time, I think I used it today. What had replaced it? Don’t say grid, that’s better for 2d layouts.
shepherdjerred 3y ago
> Flexbox is obsolete Not it's not.

locallost 3y ago

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. 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.

onion2k 3y ago
This is interesting because my first reaction was to recoil in horror at the idea of CSS without the cascade, but my second reaction was to realie you're actually describing approximately how Tailwind works eg small classes that you can use to apply an aspect of styling to a specific element, and use to build up to a design. Utility classes would be the obvious choice if you couldn't rely on the cascade any more. Tailwind styles still cascade but in a far more manageable and override-able way. Perhaps you're on to something.
- locallost 3y ago
  Which is better or correct is a question of basically how do you organize code. It's not irrelevant, but at the core should've been how to style content in a way that people actually want to style content. Instead a lot of time was spent on making up rules about cascading and specificity, which the vast majority of developers don't truly know. I knew them 15 years ago well, and realized also in horror as I wrote that I don't really know them so well. And turns out it's not so important. CSS gave us a bunch of primitive things to do, and we were supposed to figure it out, but the primitive things were not that well designed either. It was always a bunch of trickery, but at least the separation of concerns was taken care of.

matheusmoreira 3y ago

Why can't there be aliases for those names? I'd certainly use them. Is there a reason nowrap and no-wrap can't both work?

hknmtt 3y ago

The biggest fuckup of CSS, to this day, is lack of vertical centering of content.

maxloh 3y ago
I always use `display: flex` for that.

noelwelsh 3y ago

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.

krapp 3y ago
I disagree. No one needed that in the 90s when CSS came out, all they needed was a way to reference document styles from one file, rather than adding it manually to every HTML file. And besides, don't all front-end frameworks just add CSS directives into the HTML anyway? I feel like the incessant urge to make webdev look and feel like pure programming that emerged with the SV gold rush would have led us where we are anyway - except in the universe where CSS was already a full fledged programming language, things would just be exponentially more complex than they are now.
- noelwelsh 3y ago
  A programming language doesn't have to be Turing complete to be a programming language. Programming languages do at least one of two things: control a machine or provide a notation for solutions to a problem. CSS is both. It controls the layout engine in the browser and it provides a declarative notation for doing so. All programming languages need some way to provide abstraction, which means hiding irrelevant details, and composition, which means building bigger things out of small things. CSS related examples are until recently you couldn't say "Use the main theme color" (abstraction; hiding the actual color behind a name.) You still cannot name a group of styles and reuse them, so you cannot say "the dark theme is the base theme with these colors added" (abstraction and composition). If you look at what Tailwind is, the core is just composition: being able to say "this element's style is built out of the following components". The @apply CSS extension that Tailwind provides is pure composition.
bdw5204 3y ago
Nobody expected entire applications to be built out of HTML, CSS and JavaScript when those languages were being designed. CSS's main purpose was to get inappropriate bloat out of HTML because HTML was supposed to describe content not what it looks like but the IE vs Netscape browser wars had created a proliferation of new HTML tags that went against the purpose of the language. JavaScript was designed for writing simple scripts to enhance web sites not to be a full programming language. Web application development was supposed to be done through plugins like Java (applets), Flash and Shockwave. It wasn't until 10-15 years ago that the idea to just do all of this in HTML, CSS and JavaScript occured to anybody because it would have been really slow and inefficient on older hardware (HTML5 video on Youtube instead of Flash used to slow my mid-00s mid range Windows XP laptop to a crawl). For CSS in particular, the expectation of its creators was that users would specify their own style sheet which would override the web site's style sheet. To the best of my knowledge, this feature ended up being little used and is not even possible in modern browsers. (The above is what I remember from teaching myself web 1.0 style web development from books in the early 00s as a preteen and then teenager)

CM30 3y ago

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. 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.