Live data from Hacker News

Mistakes in the Design of CSS (2013)

wiki.csswg.org

141–147 of 147 posts

Re: Mistakes in the Design of CSS (2013)

#141

Earlier quoted context omitted.

Tailwind-style selectorless approach is essentially a shorter form of inline style attributes. Surely there are better solutions?

Yes, I don't understand the modern trend towards utility classes. I wonder if many of the people who reinvent them were not around when HTML 4 was the markup language of the day and the tag reigned supreme.

In my experience, it’s because people fail to learn core CSS properties and principles but can remember which classnames to jam into an element to get it to align correctly (not realizing the sacrifice is duplicate CSS—and sometimes things only rendering because of specificity in the order of the classnames they jammed in—I.e. a lot of extraneous ones).

Tailwind and utility classes make things bloated. Source: been writing HTML and CSS for 20+ years and working with a lot of devs who just don’t get CSS.

Re: Mistakes in the Design of CSS (2013)

#142
post #47
post #27

Earlier quoted context omitted.

North East South West (never eat sour worms) not East South West North

That's actually a nice insight, I was so caught up in thinking in terms of screen space coordinates, it never occurred to me that it is based on cardinal directions. It makes a fair amount of sense for the full shorthand with all 4 properties specified.

Doesn't help for those of us who learned the order North, South, East, West.

Re: Mistakes in the Design of CSS (2013)

#143
post #90

Earlier quoted context omitted.

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?

Thankfully you can opt out of most of those and pick the one that works for you. Sadly there's no alternative to CSS.

Yes, if you restrict it to web browsers, and more specifically HTML (not Canvas, WebGL).

Re: Mistakes in the Design of CSS (2013)

#144

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…

What happens when you move on to the next project—which may have a completely different design motif—and you want to reuse those components? Do you have to restyle each component independently?

Re: Mistakes in the Design of CSS (2013)

#145
post #110
post #69

Earlier quoted context omitted.

I am old enough to remember when the css zen garden first came out! I've seen hundreds and hundreds of clever tech demos. I even believed in some of them for a time. Now I realize they were carefully constructed gimmicks. css zen garden is made explicitly to do one thing and it manages to do that one thing. It's hard for me to even say that it does it very well, clicking through the featured designs. Unfortunately, t…

I'm also old enough to remember that. But I think it was clear from the very beginning that it was meant to be aspirational. Nobody is really claiming that today with CSS you can arbitrarily change the design of a page just by modifying CSS. If you look at the evolution from earlier designs on the CSS zen garden to later ones, it's clear that advances in CSS itself has made some designs possible. The ::before and ::a…

I think it was different within different communities. For certain, not everyone shared the "dream" of a totally fungible web, but some did. I recall at the time a lot of discussion about user stylesheets. People actually believed that the same HTML could be sent to multiple different devices and the user would have their own stylesheet to effect the design by overriding the website provided styles. That might allow, for example, one person to have one font that they found more readable and another person to have color choices that suited their needs (e.g. for contrast), and another person to have different margin/padding to provide more/less whitespace between elements.

This was particularly a popular idea amongst semantic web people and was talked about a lot in the communities around things like rdf/rss/atom. You might have a reader for desktop, for your palm pilot, for your e-reader, etc. each with their own stylesheets being applied to the original document. XSLT was also a player in this space since you might want to alter the document structure itself ... a stylesheet for the XML structure itself.

Almost all of these wild ideas died on the vine. XHTML was one of the first to go. I haven't heard anyone talking about XSLT recently although it sometimes sneaks out from under a rock in some places. RSS readers are now marginal at best and the format is mostly used for distribution of podcasts these days. And I am not aware of anyone using user stylesheets for the web, or even if it is still possible.

Strangely enough the movement moved more towards open data formats. That is what Tim Berners Lee is working on these days inside the ODI. I think the movement rightly discarded most concerns about styling data or even displaying it at all. But we still have this legacy from the original ideas discussed above. The original semantic web folks were trying to solve both problems simultaneously and the formats we have are tainted by that history.

Re: Mistakes in the Design of CSS (2013)

#146
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…

You’re far too optimistic.

The pure-canvas approach is currently very bad, and most of what makes it so is fundamentally unfixable, because fixing it would require exposing unacceptable details (for privacy or functionality). I’ve written about this quite a few times on HN. A few of the things I tend to mention could conceivably be fixed, but browser-makers have shown absolutely no inclination to address any of it.

No, for at least the rest of this decade, doing things properly will absolutely require using the HTML DOM. And I’m very sceptical that browser-makers will ever seek to make the pure-canvas approach a viable alternative, there are just way too many problems with it.

If you reduce the scope to custom layout and such for CSS, there are interesting experiments in the CSS Houdini project.

Re: Mistakes in the Design of CSS (2013)

#147
post #113

Earlier quoted context omitted.

Maybe add `flex: 1` to the second column?

The second column can't always just be a tall column shaped div, because you probably want to reflow 12, 34, 56, 78 on mobile where you don't have room for 2 columns, to something like 12345678, not 13572468

You can reorder flex children with the CSS `order` property.

https://developer.mozilla.org/en-US/docs/Web/CSS/order

Post reply on HN