Specificity doesn't translate correctly with nested & selector

[paulyoung]

Seeing an issue with 1.0.0.rc1 where selector specificity doesn't translate correctly.

e.g.

a {
  font-size: == 16;

  &.b {
    font-size: == 24;
  }
}

An element with classes a and b has a font-size of 16. If I add !strong to .b then it works

This behaves correctly:

a {
  font-size: == 16;
} 

a.b {
  font-size: == 24;
}

So it appears that the issue is when using a nested & selector.

[Inviz]

Currently specificity is ignored. The thing I'm working now will perhaps help us implement specificity support. And we'll need to sort by lineno when we have parser support that.

The issue you're talking about would actually be something else - inconsistent constraint order. Indeed both cases should be equal. I'll add it to the test suite.

Cassowary doesnt play very well with constraint ordering, so even if there was no issue, adding a condition would lead to a situation where cassowary can't insert one constrain "before" another without removing that another first (and rebuilding cassowary indecies which is slow).

I asked Alex Russell about how would we better handle inserting constraints at specific place in a constraint list, and he said

1. You probably cant help it
2. Cassowary is meant to be used with strengths and weights

[cbchouinard]

The following codepen illustrates that its not the specificity nor the order that wins. I think this could be confusing.

http://codepen.io/cbchouinard/pen/jEwNja

Could we add weights on constraints base on selectors' specificities? Within a given ruleset the order could prevail but otherwise the selectors specificity (with associated weight) would make sure the intent of the user are taken into account in the solving.

Also, by adding weights on constraints based on selector, we will be able to support specifities of the domains if other than html.

[Inviz]

If it was easy, we'd add it. I tried adding weights automatically and many specs and demos start to have issues, because they dont expect it.

[Inviz]

More than that, cassowary does not give very strong guarantees on weights when you mutate the cassowary system. So adding weights opts it in for better constraint sorting, but if you've got incorrect order for some reason (resizing layouts from big to small and back), it will stick the wrong way and it will be even more difficult to make sense.

[Inviz]

Another thing: Try removing left edge from @h, so

@h  |-(#constraints)-(#gss)-(#cassowary)-| in(::window) gap(20);

becomes

@h (#constraints)-(#gss)-(#cassowary)-| in(::window) gap(20);

and it'll be 200px. I hope this shows that it's not really a trivial issue. See what happens? Cassowary chose 350, because it helped it to closer satisfy the grid constraints. Order is not the only thing is taken into account

Cassowary has its own ways to resolve conflicts, and the easiest way to avoid them is to add !weak (strength) or !medium50 (weight) to ones you don't need