I'm wondering if we'll ever see Houdini make its way into browsers. The idea is that instead of modern CSS, the browser provides a bunch of hooks for various parts of its layout engine. You can then provide custom code that uses those hooks to implement any layout system you want.
CSS is big and complex, and it still needs to support the whole legacy of web applications going back forever. Most applications just use a tiny subset of CSS. Houdini could allow smaller, faster layout engines with none of the legacy stuff. And because your app ships its own layout engine, if there's a feature you want, you can just add it to the layout engine and it'll instantly work in every browser.
I have no idea whats happened with it though. Now that flexbox, grid, sticky and a few other things are in all browsers, CSS feels good enough. But maybe I'm lacking imagination.
The one thing I'd really like for web layout is a "stretch unit" that works similarly to CSS Grid's fr units in that it would be defined as "taking up a proportion of available space after other siblings have been sized" except:
- It would have no automatic minimum, so it would actually be equivalent to minmax(0, 1fr) (this would make it much more performant, avoiding the exponential time complexity of many existing CSS layout modes.
- It could be used for the width/height properties (and potentially other places such as margin/padding/inset)
If you had that along with a simplified 1-dimensional display mode (i.e. like flexbox except with the flexing disabled) then I think most people probably wouldn't want much more in most circumstances.
Houdini is interesting, but as someone who has spent a lot of the last year implementing a web layout engine [0], I'm a little skeptical that JS is ever going to be fast enough to really compete with built-in layout modes. It could be an interesting use case for WASM if the problem of passing data into the WASM VM cheaply (perhaps by reference) can be solved.
> It could be an interesting use case for WASM if the problem of passing data into the WASM VM cheaply (perhaps by reference) can be solved.
WASM Reference Types should hopefully solve this. The WASM working group seems to have some good momentum - so I'm hopeful this (or a similar replacement spec) will land sooner rather than later.
>"taking up a proportion of available space after other siblings have been sized"
and
>- It could be used for the width/height properties (and potentially other places such as margin/padding/inset)
this to me is essentially what clamp does, although it can't take up size after siblings have been sized.
If at some point clamp can start taking values like inherited then it would be pretty cool, but that would be pretty difficult unfortunately.
> although it can't take up size after siblings have been sized
The key things about the proposed new unit are:
1. That it takes up space after siblings are sized (i.e. a dedicated syntax for what 90% of flexbox uses are trying to do)
2. It prevents that same node from being "auto" sized (i.e. sized based the size of it's children). This is an important optimisations which greatly improves layout performance.
Taken together this could both significantly simplify layout code and significantly improve layout performance.
hmm, yeah a guy I know recently wasted weeks trying to do a design that was actually undoable if all the ideas implicit in the design were given equal weight, and this would have allowed him to achieve what he was trying to do.
I honestly hope Houdini never makes it into a final spec. The demo use cases are interesting, but the last thing we need is more complexity in web development.
Browsers today already act more like operating systems than document viewers. Houdini basically takes it a step further allowing every app to bring its own renderer. Linux leans heavily into this today and it makes mundane tasks like global theming a huge pain in the butt.
> the last thing we need is more complexity in web development.
Thats one way to think about it. Another is that Houdini lets the browser be more simple - because CSS (as it exists today) can be moved into a reusable library that can be shared between browsers. In theory, if all the browsers supported houdini, they wouldn't need to maintain their own CSS implementations.
As an internal implementation detail for sharing code across browsers, that sounds compelling enough. Web developers would never need to no about it though, as its just part of a browser's rendering flow that happens to be shared by browser vendors.
In reality though, I don't see browser vendors playing well to that level. Sharing specs is slow, sharing rendering code would be a nightmare.
Beyond that, I've usually seen Houdini demoed with developers focused features, effectively adding small bits of your own logic into CSS rendering. That pulls it out of the shared library and into userland.
Can you share some examples of CSS features that could be deprecated if it weren’t for legacy websites? I have a use for pretty much every CSS feature I know, but I only know them because I looked them up when I needed them, so maybe I’m missing some features.
I don’t think you need even that to have a reasonable compact layout system. There might be an opportunity here for a kind of subset of css that covers all modern needs, documented, and with a linter to enforce it.
Yes only thing missing is full support of the web animation specs. For example scrolltimelines is missing in ios and firefox. That one is really needed to get similar performance in web app compared to native.
CSS is big and complex, and it still needs to support the whole legacy of web applications going back forever. Most applications just use a tiny subset of CSS. Houdini could allow smaller, faster layout engines with none of the legacy stuff. And because your app ships its own layout engine, if there's a feature you want, you can just add it to the layout engine and it'll instantly work in every browser.
I have no idea whats happened with it though. Now that flexbox, grid, sticky and a few other things are in all browsers, CSS feels good enough. But maybe I'm lacking imagination.
https://developer.mozilla.org/en-US/docs/Web/API/Houdini_API...
Oh, it looks like chrome and safari both already support a lot of Houdini: https://houdini.glitch.me/