- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Aug 2018 18:23:21 +0000
- To: public-css-archive@w3.org
As an example: flexbox layout has some special rules for intelligently handling elements with an intrinsic aspect ratio, like images, so they can flex one of their dimensions and still end up with their other dimension keeping the aspect ratio when possible. That one tiny case of handling two interwoven constraints on a single element, along with the flexing constraints of the rest of the flex items, was rather complex to put together in the spec, and it's a very limited case. In the more general case, this gets (a) dramatically more complicated, and (b) as I said before, there is often **zero** or **multiple** valid solutions to the set of constraints. (For example, two elements both defined to have their width equal to the other's width. *Any* width suffices as a valid solution; which do you choose?) Any particular constraint solver will have *some* way of dealing with these situations, with their own trade-offs, but there's no general-purpose algorithm that'll work for all cases. And more importantly, as I and others have stated, the only way to solve these sorts of systems *is* with a generic constraint-solving algorithm, and these sorts of algorithms are *dramatically* slower than the more constrained layout algorithms that we define today. Allowing constraints in the system would slow down all page layout significantly, for everyone. That said, [Houdini Custom Layout](https://drafts.css-houdini.org/css-layout-api/) lets you define your own layout manager for an element. That can do whatever you want, including implementing a constraint-system layout. (The Chrome implementor, @bfgeek, even has a simple example of such a layout system working on our implementation!) This works because the scope of it is limited to the children/descendants of the element; it doesn't infect the rest of the page with the possibility of dealing with constraints, so our existing layout methods can continue to work as normal. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2965#issuecomment-410337143 using your GitHub account
Received on Friday, 3 August 2018 18:23:27 UTC