Overriding hoisted variables

[cbchouinard]

I would like to have your opinions on the behaviour we should support when overriding a hoisted variables.

Codepen example: http://codepen.io/cbchouinard/pen/OPggJb

Since I'm explicitly overriding the varY variable within the .large-box ruleset, I personally would find it more intuitive if later reference to that variable within the same scope and reference to the variable from nested scope would use the override variable and not the original one.

In other words, I would expect the height of .inner-box to have a constraint of 130px and not 65px since varY was override in its parent scope. I would also expect the .large-box height to be equal to 130px since I override the value within that scope.

  varY == 65;

  .container {

    .small-box {
      varX: == 200;
      width: == varX;
      height: == varY;
      center-x: == ::window[center-x];
    }

    .large-box {
      &varY == 130;
      varX: == 400;
      width: == varX;
      height: == varY;
      center-x: == ::window[center-x];

      .inner-box {
        height: == varY;
      }

    }

The strange thing is that if I do:

.inner-box {
        height: == ^varY;
      }

then the height of .inner-box will be of 130px. Since we're saying that hoisting is traversing the parent' scopes to search for a variable, it is a bit confusing that we don't get the value of the direct parent of .inner-box.

[Inviz]

Currently explicitly scoped variables like &varY dont "capture" nested hoisted variables. If we do otherwise, then using variables with the same name as css property will hoist a lot.

e.g.

width == 200;
.large-box {
   width: == width; // won't work, evalutes to &width == &width
}

Basically, when you explicitly use scope like &varY it's a "property". When you don't, it's "variable".

[cbchouinard]

Could we prevent declaring variable with the same names as CSS properties?

[Inviz]

CCSS parser doesnt know about css properties. It's a tradeoff to keep things simple. More than that we're planning to have custom css things too.

[paulyoung]

I think we're saying that we need a mechanism to prevent hoisting to allow things like this:

.container {
  font-size: == 16;

  .featured {
    font-size: == 20;

    .heading {
      font-size: == 24;
    }
  }
}

in which case, we'd just use &font-size: == in all places instead of font-size: ==?

[Inviz]

I think we have consensus that current hoisting rules are quite predictable. font-size: == is equal to &font-size == and will not cause hoisting for this variable, since it has explicit scope.