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

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"

(externalities in terms of environmental impact and resource usage (water, electricity, etc) usage driving up costs for everyone else).

Could you maybe tie it back to majority control? Alphabet is one company because it actually has a controlling stake over Google, YouTube, Android, etc. Whereas Vanguard is just a minority shareholder in Google.

> And even if you could do it, you would then create a perverse incentive for the government, because then breaking up those large companies into smaller ones would reduce tax revenue. When you should just break them up to begin with and actually solve the problem.

The idea is that you wouldn't need to government to actively break up companies, they'd do it themselves (or get outcompeted). I will admit that this is very much unproven theory though (but I'd certainly be interested in people investigating the theory more formally if nothing else).

A progressive tax would, no? You could explicitly tax larger entities more.

Definitely a cool idea. I guess time will tell whether lifting it into the language proves itself as worth it.

Yes, it's new engine separate to Webkit/Blink/Gecko/Servo/Ladybird/etc

> Just curious on your thoughts about how Webkit was architected then, I guess it's not a modular system where you can separate out things like "Localstorage" support?

Honestly, I'm not super-familiar with Webkit's architecture. It's a huge codebase, and it's also C++ which is always pretty intimidating. I believe Webkit is more modular than most of the others, but Blitz goes quite extreme into modularity:

- The core is not coupled to the HTML parser

- The core is not coupled to the networking

- The core is not coupled to the rendering backend

- The core is not coupled to the windowing/input layer

- The core is not coupled to the JS/scripting engine

- The style engine (Stylo - shared with Servo and Firefox) is mostly implemented as a library which can be used independently

- The layout engine is mostly implemented in two libraries which can be used independently of the rest of the engine (Taffy for Flexbox/Grid/Block layout and Parley for Text/Inline layout)

So, yes I'd hope that it will be possible to individually opt-in to features like localstorage (once we implement them), but it goes a bit further than that.

Don't disagree with you there.

> London can’t even work out how to properly ventilate their underground rail network.

This seems unrelated. It's not an energy problem: it's a problem with lack of space in the tunnels and lack of places to build ventilation shafts due to the issue not being considered 100 years ago when the tunnels were built.

> Or people can melt in the summers and freeze in the winters. Because that is exactly what “renewables” have been delivering.

I think this has very little to do with renewables. In particular, solar is perfect for reducing "melt in summer" cases (it's almost always sunny when it's hot) (and I'm not sure where has freeze in winter problems).

The issue seems to be more that weather has gotten hotter, and infrastructure needs to change in response to that (inevitably slow and expensive).

Totally agree.

Not sure if you're involved in the development / spec process for WebDriver Bidi, but the big limitation atm is that it has almost no support for the devtool inspection use cases served by the Chrome Devtools Protocol (CDP) and the Firefox Devtools Protocol (FDP).

The Servo and Ladybird browsers both have FDP implementations (and Blitz has an in-progress CDP implementation) for this reason. But we'd all love to switch to a single standardised protocol if it had the requisite support.

(if kitesurf does upstream their patches then presumably we'll get a CDP-based automation API as part of that)

(I wasn't involved in building kitesurf, but I am informed that they intend to open source and upstream their patches)