- From: Daniel Holbert <dholbert@mozilla.com>
- Date: Mon, 09 Feb 2015 18:38:38 -0800
- To: Peter Salas <psalas@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: www-style list <www-style@w3.org>
On 02/09/2015 04:14 PM, Peter Salas wrote: > Instead of trying to carve out cases in these new algorithms where the height doesn't depend at all on the content, we could carve out the cases where it only depends on the content. In other words, I think that ignoring percentage heights should be the exception, rather than the rule. If we were going in that direction, I'm not sure I understand the point of singling out cases where the height *only* depends on the content. Why stop there? e.g. if we have a scenario where e.g. a container's size depends on its contents plus one other factor, and you say we should allow percent-resolution, then I don't see why we'd change our behavior to block percent-resolution when that other factor goes away (or shrink its influence to 0px via a transition or something). Anyway -- as I noted in "SUGGESTION" else-thread[1] (the latter part of that message), I think I'm currently leaning in the opposite direction -- reducing the cases where percent resolution is allowed -- for performance & consistency reasons. I suspect (?) the traditional CSS percent-handling behavior (treating % values as 'auto' if the container depends on their size) is partly intended to avoid the need for multi-pass layout, and the resulting exponential blowup in deeply-nested situations. Whenever a container has to layout its children twice (once for measuring, once to let them resolve their final percent sizes), there's a potential for painful perf effects when things are deeply nested. Even if this wasn't an explicit goal when CSS percent-handling was being designed, it's at least a happy side-effect of the rules, and it's an important thing to keep in mind when thinking about tweaking things & how to apply this to new layout modes. ~Daniel [1] https://lists.w3.org/Archives/Public/www-style/2015Feb/0213.html
Received on Tuesday, 10 February 2015 02:39:09 UTC