3 ms·

Don't forget the complete absence of any kind of error reporting. Typos, syntactic errors, semantic errors are all silently swallowed. Bugs in your layout are b

Don't forget the complete absence of any kind of error reporting. Typos, syntactic errors, semantic errors are all silently swallowed. Bugs in your layout are basically impossible to diagnose without altering your layout at random and trying to reverse engineer the underlying layout algorithms. Not to mention that the layout model itself is painfully limited. The other day I tried to implement a card layout --- that is, a box containing a bunch of components all arranged in the same place, with the box itself being the maximum size of the components inside. As far as I can tell this is simply impossible in HTML without explicitly sizing your layout, which rather defeats the point. I'm currently working on a web app based on Polymer. This helps a lot, as it gives me a nice modular framework with composeable components and local namespaces, which takes a lot of the edge off some of the pain of CSS. But that just casts the pain of trying to design UIs in HTML into stark relief. ...I did once find a pure Javascript layout engine; it didn't use HTML layouts at all, and positioned everything using code (and CSS transforms). They claimed to be actually faster than stock HTML.

pcwalton 11y ago
> The other day I tried to implement a card layout It sounds like you wanted a circular dependency: widths in CSS depend on parents' widths, not children's widths. (This is important for document layouts to work at all.) > ...I did once find a pure Javascript layout engine; it didn't use HTML layouts at all, and positioned everything using code (and CSS transforms). They claimed to be actually faster than stock HTML. I've seen these pure-JS layout engines, and they are invariably much slower than the browser's implementation.
- david-given 11y ago
  > It sounds like you wanted a circular dependency: widths in CSS depend on parents' widths, not children's widths. (This is important for document layouts to work at all.) But aren't there are HTML elements everywhere where the size is determined by their content --- trivially, the P element which is showing this text. Less trivially, I've just put an explicitly sized DIV inside an unsized inline-block DIV, and the outer one is definitely sized according to its child. > I've seen these pure-JS layout engines, and they are invariably much slower than the browser's implementation. I think this is it: http://famous.org/ http://famous.org/ Although I can't find their blog post on performance. And I've never used it, of course.
  - pcwalton 11y ago
    > But aren't there are HTML elements everywhere where the size is determined by their content The height is. Not the actual width. Remember, widths are computed top-down, while heights are computed bottom-up. > Less trivially, I've just put an explicitly sized DIV inside an unsized inline-block DIV, and the outer one is definitely sized according to its child. That's because inline-block uses intrinsic width (specifically, shrink to fit width), which is computed separately from actual width in a bottom-up pass. Intrinsic width is a weird thing that is kind of a hack, and an ill-specified one to boot (although a useful one). It doesn't fundamentally change the fact that widths depend on parents' widths only. > I think this is it: http://famous.org/ http://famous.org/ Famous is slow compared to CSS when you're using it for CSS-like designs.

pcwalton 11y ago

> The other day I tried to implement a card layout It sounds like you wanted a circular dependency: widths in CSS depend on parents' widths, not children's widths. (This is important for document layouts to work at all.) > ...I did once find a pure Javascript layout engine; it didn't use HTML layouts at all, and positioned everything using code (and CSS transforms). They claimed to be actually faster than stock HTML. I've seen these pure-JS layout engines, and they are invariably much slower than the browser's implementation.

david-given 11y ago
> It sounds like you wanted a circular dependency: widths in CSS depend on parents' widths, not children's widths. (This is important for document layouts to work at all.) But aren't there are HTML elements everywhere where the size is determined by their content --- trivially, the P element which is showing this text. Less trivially, I've just put an explicitly sized DIV inside an unsized inline-block DIV, and the outer one is definitely sized according to its child. > I've seen these pure-JS layout engines, and they are invariably much slower than the browser's implementation. I think this is it: http://famous.org/ http://famous.org/ Although I can't find their blog post on performance. And I've never used it, of course.
- pcwalton 11y ago
  > But aren't there are HTML elements everywhere where the size is determined by their content The height is. Not the actual width. Remember, widths are computed top-down, while heights are computed bottom-up. > Less trivially, I've just put an explicitly sized DIV inside an unsized inline-block DIV, and the outer one is definitely sized according to its child. That's because inline-block uses intrinsic width (specifically, shrink to fit width), which is computed separately from actual width in a bottom-up pass. Intrinsic width is a weird thing that is kind of a hack, and an ill-specified one to boot (although a useful one). It doesn't fundamentally change the fact that widths depend on parents' widths only. > I think this is it: http://famous.org/ http://famous.org/ Famous is slow compared to CSS when you're using it for CSS-like designs.