3 ms·
Before that can happen, we'll get WebASM + WebGL interfaces (efficiently) in our browser. I expect an explosion of alternate layout mechanisms to arise from tha
by jerf 7y ago
Before that can happen, we'll get WebASM + WebGL interfaces (efficiently) in our browser. I expect an explosion of alternate layout mechanisms to arise from that. They won't be very good at first, but they may end up somewhere neat.
- c-smile 7y ago> I expect an explosion of alternate layout mechanisms. No need WebASM for that. Just one CSS property: div { flow: custom [funcname/url(of-layoout-controller)]; } + single function funcname() that will replace children and report min/max intrinsic sizes.
- Sophistifunk 7y agoWait, is this real? What's it called, so I can google it?
- SahAssar 7y agoI'm guessing he's talking about https://developer.mozilla.org/en-US/docs/Web/Houdini https://developer.mozilla.org/en-US/docs/Web/Houdini
- sdegutis 7y agoBuilding on top of WebGL would mean completely custom renderers that have to reimplement everything else too, such as scrolling and context menus and text selection. This has been tried dozens and dozens of times by big players, and never works out.
- Sophistifunk 7y agoWhat we need to do custom layout in browsers properly without the need to give up all the nice builtins like font rendering and scrolling and a11y, is simply the ability to measure text properly.