The Future of CSS (joshwcomeau.com)

But who needs these, when we can have bezel and whatnot...

Who needs ways to reliably trigger the display of the touch platform-native keyboard, to be notified if it is displayed and to move the input field in view so it is not obscured by the keyboard?

This is why the web is a terrible platform compared to Windows Forms for getting stuff done. Because those making the standards only work on creating gimmicks.

On that note I may know just enough to be dangerous thanks to Josh (casting spells: e.g. shouldn't we group those in their own container and then within that container shouldn't that be a flex box?). I guess I'm here to say humans are full of contradictions.

Many of my coworkers and friends are rejoicing that they don't have to write frontends anymore. I actually think that frontends are the last thing that should be vibecoded. It's the part that faces the user. It's what helps the user form their first impression of your product. If your landing page looks like it was made in 30 seconds by Claude, they'll assume the rest of your product was too. Use AI assistance on the parts of your codebase where only raw functionality matters (eg, the backend), and put real human effort and care into the frontend that reflects the effort put into the rest of the system.

https://youtu.be/0j-Wakm5B84?is=7dU_EvFyk_nQNwjO

It's like a peek into a CSS future from a different timeline. Something we could have had.

Especially functions.

Makes me think of a previous post from the author, who wrote 100k lines-of-code to power their blog.

https://www.joshwcomeau.com/blog/how-i-built-my-blog-v2/

It used to be that HTML was for content, CSS was for layout, and JS was for "code"

Now JS is for content and layout and code, HTML is for content and layout, and CSS if for layout and code

If you want them now, you have to do sort of verbose and clunky calculations to get outer corner radius.

[Outer Radius = Inner Radius + Padding](https://www.reddit.com/r/Design/s/oal9fZclJS)

This seems like something standard enough to be a built-in feature.

Most of CSS's design was informed by that idea. That styling is in separate files in the first place and then all the complicated cascading stuff that is even in the name of the thing.

I've always been fond of that idea and still am but there is no denial that it utterly and completely failed and now we live in a world where all these things are just cargo cult. Sometimes I think it'd be best to finish what Tailwind started and be consequential about it which would mean going back to presential HTML alltogether.

Especially CSS is such a miss fitting technology for what it is used today, that web frameworks actively fight it, by trying to keep its scope to components.

When looked at web tech from a distance, it is cristal clear to me that we need something new.

Instead of all the abysmal complicated rules of CSS, we would probably be much better served by something like ElmUI (a modern advanced version of the idea) + some scripting for dynamic things.

Anchor Positioning would be sweet and doesn't feel like it's got so much baggage.

  /* Define a function: */
  @function --gradient-to-transparent(--color, --direction: bottom) {
    result: linear-gradient(
      to var(--direction),
      var(--color),
      transparent;
    );
  }

I spent 3 months this year testing out a reporting system for large quantities of dynamic data.

My requirement was to generate pdf reports, but didn't want any reporting tools and installations. Especially something like Microsoft Excel, which the old system was based on.

After a lot of tests and proof-of-concept apps, I finally zeroed down to simple, pure, self contained html, that I am generating from a python script.

And it's glorious.

I am generating interactive charts when the html is viewed in the browser, and hiding all of them and only printing static svg images when in print mode, using css media print queries.

And there is so much more.

The format is awesome for ingestion by ai models.

> The Anchor Positioning API allows us to anchor one element to another.

Hello CSS, Welcome to 1996 Delphi :-/

I always thought that everything from Sass was pretty much ported over by now.

Just call it like it was: Chrome. It was Chrome that didn't move. We can all see the graph :P

Broad support for new CSS features is GOOD.

Making BASIC SITE FUNCTIONALITY depend upon new CSS features is bad.

remove inheritance and cascade from css and then we'll talk. but for now ill stick to tailwind.

a) they keep on making CSS more and more complex. You can reason in favour of it, of course, but it is undeniable that CSS becomes more and more complex - and complicated, too. Which leads us to b)

b) "CSS Subgrid is a good example. Subgrid is a super-powerful extension to CSS Grid which enables entirely new layouts."

Well ... I wanted two flexible divs side by side. It is possible, but there are like 5 different main strategies for this, grid is one of them.

Now via a "subgrid", they acknowledge that the existing ways SUCK. So they add yet-another-component here. This reminds us of:

https://xkcd.com/927/

I started to go back to oldschool - HTML tables.

People can hate it, but they work really almost flawlessly. I am not saying I use them for everything, but I totally changed my mind after I saw how flexbox and other things SUCK to no ends. So I now compare all of them to HTML tables. If they suck more than HTML tables, I discard them. This is my quality metric now. And a lot of this has to do with developers making these decisions, failing hard at DESIGN. What happened to simplicity? HTML tables are simple for the most part; they are kind of like a grid already.