search

gss / engine

GSS engine
http://gss.github.io
MIT License
2.87k stars 103 forks source link

Order of members in constraint declaration matters. Why? #199

Open oslego opened 9 years ago

oslego commented 9 years ago

According to the docs, the constraints are two-way. Yet the order in which members are declared seems to matter.

For example:

#logo[top] == #container[top] + 64;

yields a different result from 

#container[top] + 64 == #logo[top];

The latter yields the expected layout, but it is far less readable and intuitive than the former. I've seen this swapped order in examples in the docs as well. Why is this?

Live example: http://codepen.io/oslego/pen/WvqKXq

andering commented 8 years ago

I can't explain you why, while i don't have deep understanding of GSS algorithms. But i guess it has connection with how things are calculated, because its still math with order.

GSS obviously don't know where is #container[top], so if you add : #container[top] == ::window[top], it will behave equally.

qm3ster commented 8 years ago

You'll notice that in the first case the #containter has top: -64px This is caused by neither of the two elements having any vertical constraints to the reference frame. They are underqualified. The order of operations indeed changes because it doesn't affect performance, considering you could write constructs like .a[top]-.b[top]=.b[bottom]-.c[top]. Finally, if you look even closer, you will see that the solution is actually correct, since the #container is not only presumably but physically at top: -64px, relative to the window, and #logo is top: 64px from it. Setting #logo[top] to be 0 in developer tools clearly indicates the effect.