I am currently in the process of building a wider browser engine / GUI toolkit on top of it (https://github.com/dioxuslabs/blitz). As part of that I am implementing a lot of the messier parts of CSS layout (floats, etc), and also grinding on fixing all the WPT tests which we track here: https://blitz.is/status/wpt/css/css-flexbox.
The vision is a complete standalone implementation of the web layout algorithms that can be easily embedded (with individual algorithms enabled/disabled on a pay what you use basis), and which can also be part of a modular ecosystem of browser engine components that make it easier for people to create new browser engines.
I used this for an internal project I can’t talk about, but it was a lifesaver. It allowed me to drop a really powerful layout system into a project that wasn’t doing traditional UI at all.
The results have been fantastic. Thank you for this awesome library. I love it.
Thanks for all this! I used Blitz a while ago for a product research spike around composing HTML to be rendered directly in a terminal with kitty or iterm's image protocol:
I guess you've reviewed a few layout systems, do you have a strong view re. which one is the platonic best, i.e. we can ignore the practical considerations of matching CSS just because it's very popular
The one from PanGUI (https://pangui.io/blog/05-layout-rework-and-benchmarks/) looks impressive. It seems to combine a lot of the power/flexibility from CSS with the performance of simpler systems. It's not open source though, so it's hard to evaluate properly.
One thing I would love to see is CSS gain new unit which represents "a proportion of free space" (after fixed-size things have been sized) similar to fr units from CSS Grid but usable for properties like width/height and that would disable the "automatic minimum/content based size" that causes so many of the performance pitfalls with CSS layout.
I think this could make CSS layout both faster and more intuitive for 90% of layouts. And you could retain the existing properties for advanced layouts and backwards compatibility.
Flutter's blog post "constraints go down, sizes go up" [0] is the classic that I would recommend to anyone trying to understand UI layout. It doesn't cover every possible approach, but it applies to most of them including CSS. If you combine with a rule of thumb for keeping layout fast: "content-based sizing XOR flexible sizing" then you're well on your way to making a good layout system.
I used it in https://fschutt.github.io/printpdf for the HTML-to-PDF layout, just as a note. It is very useful, thanks for your work. Good luck on Blitz.
I would be interested in something like Apple's constraint layout system. Nested flexboxes and grids can do a lot, but I kinda fell in love after seeing constraint layout. Even how window resizing is represented as a constraint with a certain priority too!
Came here to say the same thing. I feel like I’ve done my homework on CSS grid and CSS flex but no matter how much I use it, it will likely never become intuitive. Autolayout was love at first sight, and continued being a joy to use as long as I had the privilege of using it.
I know the CSS people were painted into a box by legacy, but the design of both grid and flex honestly seem like the products of uniquely deranged minds. Unfathomable. Something like WPF’s grid is just as powerful as CSS grid but it doesn’t give you a mental disorder trying to understand it.
CSS grid and flexbox are very intuitive to me now, because I fell in love with them too before meeting constraint layout. But that may be because I was still young-ish when learning them. These days, it's starting to get harder for me to pick up new things...
My opinion is that no one should re-implement CSS layout orimitives and algorithms. Those are rather unique in how (by necessity and quirks if history) awkward, stange and bolted on they are.
Well, hang on, there are several different layout algorithms in CSS, right? They keep the old ones for backwards compatibility, and they have to interoperate which makes things more complicated; but flexbox and grid are relatively new and quite nice.
The people saying CSS is unfit for UI have probably never actually built a good UI in anything, and also realistically don't even know how to use CSS.
Flexbox on its own is a simple and very capable algorithm that you can use anywhere. You can do a lot with flexbox alone (see Yoga: www.yogalayout.dev) so it's a great place to start. Taffy supports a few more layouts (block, grid) which have their own separate use cases but flexbox is enough for most things.
I used to teach a CSS to college freshman class a decade and a half ago.
An assignment that I had that they always seemed to enjoy was picking a stadium scoreboard (I initially forced Fenway park but loosened it up in later years) and recreating it responsively exclusively in html markup and hand coded CSS (JS only allowed to pass arrays). Had to go through all 3 major media queries.
That assignment was in week 4 out of 15. 95% of the kids came in with no CSS knowledge at that time.
If you learned CSS through the aforementioned frameworks that abstract it into a mishmash of barely recognizable selector abbreviations I totally understand why you would think that it was complex and unapproachable. But once you understand positioning and the box model selector by selector sky's the limit.
Blame bootstrap for the nature of today's HEADER ROW BLOCK BLOCK BLOCK ROW BLOCK BLOCK ROW state of web design. CSS has very little to do with that.
They mentioned Fenway Park, which is a baseball stadium. Baseball scoreboards are quite complex with a lot of detailed stats, similar to cricket scoreboards.
that's TAL-U-NO-LX in the screenshot, right? Bit self-defeating as an example. That UI is a skin. Fixed bitmap, every knob position and hitbox hardcoded, window can't be resized at all. I don't know offhand whether TAL is on vstgui or juce, but it doesn't much matter, with juce you write resized() by hand and chop up a rectangle with removeFromTop/removeFromLeft until you run out of controls. Either way there's no layout algorithm in there. It's what you end up with when you don't have one...
Photoshop is a strange pick too. The extension layer was CEP, which is literally Chromium, and UXP that replaced it ships flexbox. There's a browser version now as well.
> And when they started moving to more and more web tech, they couldn't even get the most trivial of the app's layouts correctly
Nothing in that post complains about layout. It's all regressions in usability.
What you are referring to as "layouts" is not what everyone else is talking about. In the context of this entire thread "layout" is the algorithms which decide the size and position of UI elements.
> In the context of this entire thread "layout" is the algorithms which decide the size and position of UI elements.
And yet the apparently amazing layout algorithms in CsS haven't lead to people easily creating actual complex layouts, and all CSS frameworks re-implement the same dozen or so trivial components.
The few companies that manage to do something complex do that at gereat expense and over untold man-hours of engineering.
There's absolutely nothing complex about the layout in that Cubase screenshot. It's likely mostly (if not fully) manually positioned which you can do with CSS. The rendering is more complex because a lot of it would need to be represented as images/SVGs to render all those lines at least somewhat efficiently.
The thread you linked kind of touches on that, too, by pointing out that sometimes you need to drop down to handling layout+rendering yourself. Doesn't matter if it's a desktop or web app. It is actually the best option to do sometimes because it can be less hacky and more performant.
Somehow "there's nothing complex" and "rendering" or something, and there are no layouts in CSS even close to the complexity of this layout. Except perhaps a few examples or useless stuff like "let's render Mona Lisa using CSS only".
And if you try to layout this many elements, the browser will just sit down and cry.
<strike>This project IMO should admit it's taken a lot of it's inspiration from Clay, a C layout immediate mode UI library: https://github.com/nicbarker/clay/</strike>
EDIT: Was wrong, see reply to this comment, need my coffee...still not a good excuse
This project predates Clay by several years. Clay's earliest commit was 2024. Taffy was forked from https://github.com/vislyhq/stretch in 2022, and Stretch's first commit was 2019.
The real inspiration is https://github.com/react/yoga (as used by React Native). Stretch was originally a Rust port/rewrite of Yoga.
I maintain Taffy: AMA.
I am currently in the process of building a wider browser engine / GUI toolkit on top of it (https://github.com/dioxuslabs/blitz). As part of that I am implementing a lot of the messier parts of CSS layout (floats, etc), and also grinding on fixing all the WPT tests which we track here: https://blitz.is/status/wpt/css/css-flexbox.
The vision is a complete standalone implementation of the web layout algorithms that can be easily embedded (with individual algorithms enabled/disabled on a pay what you use basis), and which can also be part of a modular ecosystem of browser engine components that make it easier for people to create new browser engines.
Beyond Blitz, some notable users are:
- Servo which uses it only for CSS Grid
- Zed which uses it via it's GPUI toolkit.
I used this for an internal project I can’t talk about, but it was a lifesaver. It allowed me to drop a really powerful layout system into a project that wasn’t doing traditional UI at all.
The results have been fantastic. Thank you for this awesome library. I love it.
Thanks for all this! I used Blitz a while ago for a product research spike around composing HTML to be rendered directly in a terminal with kitty or iterm's image protocol:
https://www.npmjs.com/package/kittyhtml
https://github.com/kkukshtel/kittyhtml
I guess you've reviewed a few layout systems, do you have a strong view re. which one is the platonic best, i.e. we can ignore the practical considerations of matching CSS just because it's very popular
The one from PanGUI (https://pangui.io/blog/05-layout-rework-and-benchmarks/) looks impressive. It seems to combine a lot of the power/flexibility from CSS with the performance of simpler systems. It's not open source though, so it's hard to evaluate properly.
One thing I would love to see is CSS gain new unit which represents "a proportion of free space" (after fixed-size things have been sized) similar to fr units from CSS Grid but usable for properties like width/height and that would disable the "automatic minimum/content based size" that causes so many of the performance pitfalls with CSS layout.
I think this could make CSS layout both faster and more intuitive for 90% of layouts. And you could retain the existing properties for advanced layouts and backwards compatibility.
Flutter's blog post "constraints go down, sizes go up" [0] is the classic that I would recommend to anyone trying to understand UI layout. It doesn't cover every possible approach, but it applies to most of them including CSS. If you combine with a rule of thumb for keeping layout fast: "content-based sizing XOR flexible sizing" then you're well on your way to making a good layout system.
[0]: https://medium.com/flutter-community/flutter-the-advanced-la...
I think Bevy uses it too, right?
Correct. Takumi (https://github.com/kane50613/takumi) which a JSX -> image generator might also be worth highlighting.
Floats? A fan of pain, are we?
Unfortunately 73% of websites use floats, so if you want to render the web then you have to support them!
I used it in https://fschutt.github.io/printpdf for the HTML-to-PDF layout, just as a note. It is very useful, thanks for your work. Good luck on Blitz.
I would be interested in something like Apple's constraint layout system. Nested flexboxes and grids can do a lot, but I kinda fell in love after seeing constraint layout. Even how window resizing is represented as a constraint with a certain priority too!
https://github.com/dylanede/cassowary-rs but it's not that great on performance once you have like 1000+ constraints (used that library last in 2018 / 2019? maybe it has improved). I think https://github.com/christolliday/limn used it way back then.
Ratatui (TUI) uses cassowary layout with a faster underlying library.
Came here to say the same thing. I feel like I’ve done my homework on CSS grid and CSS flex but no matter how much I use it, it will likely never become intuitive. Autolayout was love at first sight, and continued being a joy to use as long as I had the privilege of using it.
I know the CSS people were painted into a box by legacy, but the design of both grid and flex honestly seem like the products of uniquely deranged minds. Unfathomable. Something like WPF’s grid is just as powerful as CSS grid but it doesn’t give you a mental disorder trying to understand it.
CSS grid and flexbox are very intuitive to me now, because I fell in love with them too before meeting constraint layout. But that may be because I was still young-ish when learning them. These days, it's starting to get harder for me to pick up new things...
I believe there are several crates (and other languages too) inspired by the original cassowary paper, don't know how mature they are though.
Closely-related tangent: for an amazing resource showing how to leverage CSS from first principles, see https://every-layout.dev
An unfortunate name for certain audiences in the UK!
> an offensive word for someone who comes from Wales, or whose family comes from Wales
https://dictionary.cambridge.org/dictionary/english/taffy
Not that unfortunate:
https://www.walesonline.co.uk/news/wales-news/theres-still-m...
Why is that?
The river Taff flows through Cardiff, and 'taffy' was used as a derogatory term for Welsh people from this origin.
I can't pretend I've heard anyone use it since the 80s.
I'm in my late twenties, grew up in the south west. This is my first time hearing about this term
This library can be used to build no_std guis on embedded hardware (microcontrollers with KBs of ram). It is that lightweight and fast.
My opinion is that no one should re-implement CSS layout orimitives and algorithms. Those are rather unique in how (by necessity and quirks if history) awkward, stange and bolted on they are.
Explore other layout ideas. E.g. https://stackoverflow.com/questions/53911631/gui-layout-algo...
Well, hang on, there are several different layout algorithms in CSS, right? They keep the old ones for backwards compatibility, and they have to interoperate which makes things more complicated; but flexbox and grid are relatively new and quite nice.
The people saying CSS is unfit for UI have probably never actually built a good UI in anything, and also realistically don't even know how to use CSS.
Flexbox on its own is a simple and very capable algorithm that you can use anywhere. You can do a lot with flexbox alone (see Yoga: www.yogalayout.dev) so it's a great place to start. Taffy supports a few more layouts (block, grid) which have their own separate use cases but flexbox is enough for most things.
People pretending CSS is a good fit for complex layouts have never yried to build complex layouts in CSS.
Open any actual complex software from Photoshop and Cubase and weep https://x.com/dmitriid/status/1424052288205856773
There's a reason all the CSS frameworks endlessly recreate the same dozen-or-so trivial components and never dare touch layouts.
I used to teach a CSS to college freshman class a decade and a half ago.
An assignment that I had that they always seemed to enjoy was picking a stadium scoreboard (I initially forced Fenway park but loosened it up in later years) and recreating it responsively exclusively in html markup and hand coded CSS (JS only allowed to pass arrays). Had to go through all 3 major media queries.
That assignment was in week 4 out of 15. 95% of the kids came in with no CSS knowledge at that time.
If you learned CSS through the aforementioned frameworks that abstract it into a mishmash of barely recognizable selector abbreviations I totally understand why you would think that it was complex and unapproachable. But once you understand positioning and the box model selector by selector sky's the limit.
Blame bootstrap for the nature of today's HEADER ROW BLOCK BLOCK BLOCK ROW BLOCK BLOCK ROW state of web design. CSS has very little to do with that.
Edit: sorry for the run on sentences.
> picking a stadium scoreboard
The one that has two big numbers and two team names? That big complex layout?
They mentioned Fenway Park, which is a baseball stadium. Baseball scoreboards are quite complex with a lot of detailed stats, similar to cricket scoreboards.
that's TAL-U-NO-LX in the screenshot, right? Bit self-defeating as an example. That UI is a skin. Fixed bitmap, every knob position and hitbox hardcoded, window can't be resized at all. I don't know offhand whether TAL is on vstgui or juce, but it doesn't much matter, with juce you write resized() by hand and chop up a rectangle with removeFromTop/removeFromLeft until you run out of controls. Either way there's no layout algorithm in there. It's what you end up with when you don't have one...
Photoshop is a strange pick too. The extension layer was CEP, which is literally Chromium, and UXP that replaced it ships flexbox. There's a browser version now as well.
No negativity, but I feel biased towards CSS ;)
> that's TAL-U-NO-LX in the screenshot, right?
There's also Cubase behind it ;)
> Photoshop is a strange pick too. The extension layer was CEP
As we all know, Photoshop is just the extension layer.
Edit. And when they started moving to more and more web tech, they couldn't even get the most trivial of the app's layouts correctly: https://unsung.aresluna.org/photoshops-challenges-with-focus...
> And when they started moving to more and more web tech, they couldn't even get the most trivial of the app's layouts correctly
Nothing in that post complains about layout. It's all regressions in usability.
What you are referring to as "layouts" is not what everyone else is talking about. In the context of this entire thread "layout" is the algorithms which decide the size and position of UI elements.
> Nothing in that post complains about layout.
You can literally see the screenshots in the post
> In the context of this entire thread "layout" is the algorithms which decide the size and position of UI elements.
And yet the apparently amazing layout algorithms in CsS haven't lead to people easily creating actual complex layouts, and all CSS frameworks re-implement the same dozen or so trivial components.
The few companies that manage to do something complex do that at gereat expense and over untold man-hours of engineering.
There's absolutely nothing complex about the layout in that Cubase screenshot. It's likely mostly (if not fully) manually positioned which you can do with CSS. The rendering is more complex because a lot of it would need to be represented as images/SVGs to render all those lines at least somewhat efficiently.
The thread you linked kind of touches on that, too, by pointing out that sometimes you need to drop down to handling layout+rendering yourself. Doesn't matter if it's a desktop or web app. It is actually the best option to do sometimes because it can be less hacky and more performant.
Somehow "there's nothing complex" and "rendering" or something, and there are no layouts in CSS even close to the complexity of this layout. Except perhaps a few examples or useless stuff like "let's render Mona Lisa using CSS only".
And if you try to layout this many elements, the browser will just sit down and cry.
What are all the systems you’ve built good UIs in that are worse than HTML/CSS?
I side with your opinion. CSS is bad for UI layout (maybe good enough for text-flows idk)
... opens the SO link
yeah there's no answer to it (even if someone does, it would likely be closed by 5 others)
There are Python bindings via the stretchable library.
https://github.com/mortencombat/stretchable
having some screenshots or screen recordings is always nice for... UI libraries
<strike>This project IMO should admit it's taken a lot of it's inspiration from Clay, a C layout immediate mode UI library: https://github.com/nicbarker/clay/</strike>
EDIT: Was wrong, see reply to this comment, need my coffee...still not a good excuse
This project predates Clay by several years. Clay's earliest commit was 2024. Taffy was forked from https://github.com/vislyhq/stretch in 2022, and Stretch's first commit was 2019.
The real inspiration is https://github.com/react/yoga (as used by React Native). Stretch was originally a Rust port/rewrite of Yoga.
An associated project: https://github.com/DioxusLabs/anyrender does take a lot of inspiration from Clay's "drawing commands"