Live data from Hacker News

Mistakes in the Design of CSS (2013)

wiki.csswg.org

131–140 of 147 posts

Re: Mistakes in the Design of CSS (2013)

#131
post #128

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.

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…

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.

Re: Mistakes in the Design of CSS (2013)

#132

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.

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)

Re: Mistakes in the Design of CSS (2013)

#133
post #118

Earlier quoted context omitted.

Your OS had a dark theme, that gets represented in the browser as a not !important user style. The website should be able to override this to avoid the white text on white background problem. But then if the user is tweaking a specific site, the user should be able to override anything with ! important if they really mean it.

Yeah, I understand that in general. But what's curious is that normally it goes browser user > author. Specifically the part where the browser now outranks the user style is interesting.

These are (presumably) for things that even user styles are not supposed to be able to "break". Sifting through https://meiert.com/en/blog/user-agent-style-sheets/ shows quite reasonable things such as

    @media (scripting) {
      noscript {
        display: none !important;
      }
    }

    optgroup {
      float: none !important;
      position: static !important;
      white-space: nowrap !important;
      word-wrap: normal !important;
    }
in the Firefox UA styles (though I'd permit overriding the former and I'd expect shadow DOM to handle the latter), or

    input[type="password" i] {
        -webkit-text-security: disc !important;
    }
in the Chrome UA style.

Re: Mistakes in the Design of CSS (2013)

#134
post #99

Earlier quoted context omitted.

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

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…

Usually one does not need to know all the rules of specificity in a project with sane style sheets. Often it is enough to know what styling applies to a parent element and then make the selector more specific by addressing the child element, or if element at the same level, make the selector more specific by adding more detail to where that element is located in the DOM to the selector. Then one automatically has something more specific.

In other cases one can look up how it values id selector for example, or watch the immediate result in the browser, as one adds such a selector.

I am guessing, that over time people, who deal a lot with CSS, will learn the specificity rules automatically.

Re: Mistakes in the Design of CSS (2013)

#135

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 spec…

Originally the „cascade“ referres to the ability for both the browser, and the the user, and the website to define styles for a single website. With the browsers styling being the weakest, the users styles the strongest and the websites own styles being in the middle of the cascads

Re: Mistakes in the Design of CSS (2013)

#136

Earlier quoted context omitted.

The designer doesn't work semantically. Working with tailwind is like digging the hole for a pool with a spoon instead of a bulldozer. They repeat the same tailwind classes 20,000 times and if the application gets bigger they repeat it 40,000 times and if they have to change the way it looks it is the mother of all cut and paste jobs. There is an unholy convergence of the tools being almost but not quite adequate, th…

> Tailwind would be a lot more appealing to me if it was coupled with some system where I could say "class X inherits from tailwind classes A, B and C" and thus have a layer of abstraction over just writing properties. This mindset is the problem. You don't want or need this abstraction in the CSS, what you want is to encapsulate these styles properties in a reusable "HTML component", and then use that component wher…

> Atomic CSS makes perfect sense in this context and makes composable development a breeze by comparison.

I should have also mentioned that your "semantic CSS" is necessarily anti-composable by contrast. Any reusable HTML components with semantic classes now require you to manually lift their CSS definitions into your CSS top-level context, which is a step that isn't required with atomic CSS / tailwind.

Re: Mistakes in the Design of CSS (2013)

#137

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

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.

Re: Mistakes in the Design of CSS (2013)

#138
post #33

Earlier quoted context omitted.

No what I'm referring to is much, much broader. I'm talking about literally a different file extension + rendering engine + execution context. There are a whole host of issues that are outside the scope of just CSS.

We're getting there, slowly but surely. WebGL + WASM will eventually let you simply drop down a custom rendering engine, but we've got a long way to go to get there. We're creeping up on being able to sensibly render an entire UI that way, but that UI will not have good accessibility until the browser exposes that more generically, and a lot of other little details. Then you can do whatever you want, or, more realist…

7. Mistakes in the Design of Layout.rs (2030)

Re: Mistakes in the Design of CSS (2013)

#139

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

> Thus we get a lot of things like bootstrap and tailwind that erode the idea of CSS classes being somewhat semantic

Can you link to somewhere explaining why and how CSS is meant to be semantic? Search bots and screen readers don't read or use class names. They expect certain semantics from HTML tag names and HTML attribute names though.

I think this is mixing up something that is really only meant to be a convenience for developers here.

Tailwind would advocate you wrap up common styles within a web component so the web component filename would take the place of a class name so there's not much difference for developers. Lots of styling is purely decorative as well and doesn't have semantics so there isn't always a useful name to provide e.g. `gallery-container-wrapper` isn't telling you much.

Re: Mistakes in the Design of CSS (2013)

#140

> 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 work…

z-index causes me physical pain. z-index puts stress on my marriage. My children will experience generational trauma through z-index.
Post reply on HN