What No One Told You About Z-Index (2013) • Hacker News Board

Re: What No One Told You About Z-Index (2013)

#21

Post by david-given » Fri, Mar 11, 2016, 12:27 PM UTC

prewett wrote: post #12

pcwalton wrote: post #9

Earlier quoted context omitted.

Do you have a proposal for a system that properly integrates alpha and layering without the notion of a stacking context?

If by "stacking context" you mean "one global context," then no. But if you mean stacking contextS as described by the article, then Win32, Cocoa, Swing, Qt, wxWidgets, and probably Gtk are all examples of a system where z-index doesn't involve reading an article. I've come to the conclusion that HTML is great for content that looks like 1999. But in 2016, every time I use HTML and CSS I end up dealing with some subs…

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.

Re: What No One Told You About Z-Index (2013)

#22

Post by pcwalton » Fri, Mar 11, 2016, 4:36 PM UTC

david-given wrote: post #21

prewett wrote: post #12

Earlier quoted context omitted.

If by "stacking context" you mean "one global context," then no. But if you mean stacking contextS as described by the article, then Win32, Cocoa, Swing, Qt, wxWidgets, and probably Gtk are all examples of a system where z-index doesn't involve reading an article. I've come to the conclusion that HTML is great for content that looks like 1999. But in 2016, every time I use HTML and CSS I end up dealing with some subs…

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…

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

Re: What No One Told You About Z-Index (2013)

#23

Post by pcwalton » Fri, Mar 11, 2016, 4:38 PM UTC

iainmerrick wrote: post #19

pcwalton wrote: post #15

Earlier quoted context omitted.

Most of your comments are addressed by the fact that CSS2 was designed originally for documents, while the other widget systems never were and simply don't support that type of layout. Nowadays, with flexbox, CSS fully supports natural UI layouts too. If we adopted your suggestion of using a legacy toolkit like Win32 as the basis of a new HTML/CSS and throwing out the old, it would be much worse than HTML and CSS as…

I think several core HTML5 and CSS features actually come from Cocoa (via WebKit/Safari), notably Canvas, transforms and CSS animation. The whole stacking context business basically seems to describe WebKit's rendering model (and maybe other browsers too, but did they have hardware acceleration before Safari?). I think the W3C spec was derived from the implementation, to a greater extent than the impl being driven by…

Stacking contexts aren't about hardware acceleration. They're needed for things like opacity to work at all. (Think about the alpha blending functions when you have multiple objects stacked on top of one another.)

Re: What No One Told You About Z-Index (2013)

#24

Post by prewett » Fri, Mar 11, 2016, 7:22 PM UTC

pcwalton wrote: post #15

prewett wrote: post #12

Earlier quoted context omitted.

If by "stacking context" you mean "one global context," then no. But if you mean stacking contextS as described by the article, then Win32, Cocoa, Swing, Qt, wxWidgets, and probably Gtk are all examples of a system where z-index doesn't involve reading an article. I've come to the conclusion that HTML is great for content that looks like 1999. But in 2016, every time I use HTML and CSS I end up dealing with some subs…

Most of your comments are addressed by the fact that CSS2 was designed originally for documents, while the other widget systems never were and simply don't support that type of layout. Nowadays, with flexbox, CSS fully supports natural UI layouts too. If we adopted your suggestion of using a legacy toolkit like Win32 as the basis of a new HTML/CSS and throwing out the old, it would be much worse than HTML and CSS as…

Yeah, I think a lot of the problems are because HTML was designed for documents. But it obviously wasn't designed well. I'm not sure how to do it better, but I know that I like using real UI toolkits, and I hate fighting with HTML.

I don't know what benchmarks say about Win32, Cocoa, or Qt rendering, but I'd be surprised if they were "much worse" performance than CSS. Layout isn't great with Win32 or Cocoa, but I love Qt's Layouts (except until you figure out how to change the default margins), and Swings seem okay from what little I've used.

Win32 has had opacity since Windows 2000, Qt has opacity since about then. Cocoa has had NSView.alphaValue since OS X 10.5.

Re: What No One Told You About Z-Index (2013)

#25

Post by david-given » Fri, Mar 11, 2016, 10:57 PM UTC

pcwalton wrote: post #22

david-given wrote: post #21

Earlier quoted context omitted.

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…

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

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

Although I can't find their blog post on performance. And I've never used it, of course.

Re: What No One Told You About Z-Index (2013)

#26

Post by pcwalton » Sat, Mar 12, 2016, 6:37 PM UTC

prewett wrote: post #24

pcwalton wrote: post #15

Earlier quoted context omitted.

Most of your comments are addressed by the fact that CSS2 was designed originally for documents, while the other widget systems never were and simply don't support that type of layout. Nowadays, with flexbox, CSS fully supports natural UI layouts too. If we adopted your suggestion of using a legacy toolkit like Win32 as the basis of a new HTML/CSS and throwing out the old, it would be much worse than HTML and CSS as…

Yeah, I think a lot of the problems are because HTML was designed for documents. But it obviously wasn't designed well. I'm not sure how to do it better, but I know that I like using real UI toolkits, and I hate fighting with HTML. I don't know what benchmarks say about Win32, Cocoa, or Qt rendering, but I'd be surprised if they were "much worse" performance than CSS. Layout isn't great with Win32 or Cocoa, but I lov…

They do have much worse performance when compared to an optimized rasterizer like WebRender (disclaimer: I work on WebRender). That's because they use legacy immediate mode APIs like GDI for painting, which are a poor match for modern GPUs. By contrast, CSS is fully declarative, which allows for much better batching, global culling, etc. Native toolkits cannot fix this without breaking backwards compatibility: their programmatic CPU drawing is fundamental to how they work. The best they can be is GPU-assisted rather than GPU-accelerated.

HTML was designed well for documents overall. It's remarkable how it's "obvious" that HTML is terrible, but every single proposed document-based replacement for it has been significantly worse. Take LaTeX, for example (sometimes brought up as a system "designed right"): you basically can't do floats at all in the system. All packages that simulate them are hacks. If the Web used a system designed like that, the volume of complaints would be deafening at this point.

I'm the first to admit that CSS has a lot of problems. But they're not the problems people always cite. The core model of downward width dependencies and upward height dependencies, with floats as a first-class citizen positioned during line breaking, is sound. Where CSS went wrong is in all the complexity like margin-collapse, border-collapse, mismatched border styles, CSS 2.1 Appendix E painting order, etc. These are the biggest flaws in the design, but nobody cites them as problems: in fact, frequently authors want more and more features that don't make sense and would make CSS worse.

Re: What No One Told You About Z-Index (2013)

#27

Post by pcwalton » Sat, Mar 12, 2016, 6:44 PM UTC

david-given wrote: post #25

pcwalton wrote: post #22

Earlier quoted context omitted.

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

> 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 o…

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

Famous is slow compared to CSS when you're using it for CSS-like designs.