Csswg-drafts: Dynamic values support?

[gernotpokorny]

As soon as you want to do something like this in css you have to do it in JS:

set the width of an element (element A) to the height of another element (element B). If element B's height does increase element A's width should increase too. In other words a binding.

That is kind of pointless that you have to do that in JS, because the css should define the styling of the page. Furthermore css already has dynamic values that depend on another elements size (eg. width:80%;)´. In conclusion I guess there is no reason to not support the requested feature.

Using JS for that task means you have to write excessive code for what would be a one-liner in css, taking a performance hit and that your styling code ends up unnecessarily in different places.

You might ask "where is this useful". There are so many scenarios where you want something like that, just to give you an idea:

<input type="button"> height depends on the font-size within the buttons text (no static height desired)
then you want <input type="range"> height to be equal to the <input type="button"> height at all times. This is currently simply not possible within CSS AFAIK JS is required for such tasks.

[tabatkins]

Unfortunately, this sort of thing isn't possible in general. Lots of properties depend on each other, both within a single element and especially between elements, with the between-element dependencies often being quite complex. Introducing more dependencies into this graph can easily make the entire thing intractable; even when there is a unique solution (rather than zero or multiple possible solutions), it's often not obtainable thru the efficient layout algorithms we use today, instead requiring a more generic constraint-satisfying search algorithm, which can run into exponential time blow-ups.

The JS you write is less of a performance hit than what would happen if we recast the entire style system to handle this sort of thing. ^_^

[gernotpokorny]

I have a hard time to imagine that the performance would be worse when coded natively then in JS. Furthermore it works pretty well in QML. QML is by the way the only language where I saw this feature so far.

Excessive code splitted amongst different files also becomes troublesome at some point ;)

So there is no intention to provide this feature anytime soon in CSS?

[frivoal]

It's not really a matter of JavaScript vs native code. When you do it for your own case in JS, you can specialize the code to deal with only what matters in your page. If it has to be baked in the engine, it has to deal with all cases. Some cases can be handled simply, but the general solution for the kind of thing you described is very slow. Therefore, it can be fast if you do it yourself, and it cannot if the browsers do.

[frivoal]

So there is no intention to provide this feature anytime soon in CSS?

Given that in order to solve it, we would have to throw away most of how CSS works and replace it with a constraint solver, no.

[bkardell]

@gernotpokorny it's not that it would be slower natively than if written in JavaScript if they were implementing the exact same thing, it's that they aren't. Tab is explaining things about differences in how CSS works vs what people do with JavaScript. In the latter, you more or less say precisely what should happen and when and specifically to which things. He was trying to explain why that is a very difficult problem in CSS by contrast rather than compare performance characteristics of C vs JavaScript.. If that helps at all

[tabatkins]

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