3 ms·
> The reason they're slow is that they're also extremely complex and slow operations. In that case it seems that we need something new to replace CSS for layou
by ux-app 13y ago
> The reason they're slow is that they're also extremely complex and slow operations.
In that case it seems that we need something new to replace CSS for layout.
Or maybe a 'strict mode' equivalent for CSS where styling is separated from layout. In this mode rules that affect style (bold, font etc) cannot affect container dimensions. This mode would include a subset of rules that affect only layout (position, width, height etc).
This would presumably greatly reduce the impact of the parse/dom traversal/paint cycle of CSS.
- untog 13y agoIn this mode rules that affect style (bold, font etc) But bold and font would affect the width of the text which would affect text flow and possibly affect whether the container ought to grow and shrink or whether it ought to provide scroll bars... No change is simple, in that sense.
- _greim_ 13y ago> In that case it seems that we need something new to replace CSS for layout There's so much that CSS (and browsers in general) do that we take for granted, which is good in one sense but bad since you can't dip below those abstractions and grapple with the layout engine (or garbage collector, or HTML parser, or selector engine) at a low level. You get the whole ball of wax and all that stuff runs all the time, even if you don't actually need it. In my view this is essentially what separates HTML apps from native ones.
- spyder 13y agoSo we need asm.css? :)
- wwweston 13y agoI totally think CSS layout could use some improvements, but isn't the separation you're talking about here already pretty strong? I'm struggling to think of an example of a situation where text styles affect layout on containers where dimensions are anything other than 'auto'. And any situation at all where text styles affect positioning.