& selector and css priorities

[jtousek]

input{
  width: 100px;
  &[type=text]{
    width: 200px;
  }
}

=>

input[type=text] { width:200px; }
input { width:100px; }

That is wrong, because in cases like this, the last value takes the priority. I've tried to implemented some sort of buffer to stop the "input[type=text] { width:200px; }" and send it out after "input { width:100px; }". I'm not very sure about it's effectivity but it works.

Implementation:

    // parse and compile buffer
    function parse($str = null) {
        if ($str) $this->buffer = $str;

        $this->env = array();
        $this->expandStack = array();
        $this->count = 0;
        $this->line = 1;

        $this->buffer = $this->removeComments($this->buffer);
        $this->push(); // set up global scope
        $this->set('__tags', array('')); // equivalent to 1 in tag multiplication

        // trim whitespace on head
        if (preg_match('/^\s+/', $this->buffer, $m)) {
            $this->line  += substr_count($m[0], "\n");
            $this->buffer = ltrim($this->buffer);
        }

    while (false !== ($compiled = $this->chunk())) {
      if (!is_string($compiled))$compiled = '';
      if (!isset($buffer[$this->level-1])) $buffer[$this->level-1] = '';
      $buffer[$this->level-1] .= $compiled;
      if (isset($buffer[$this->level])) {
        $buffer[$this->level-1] .= $buffer[$this->level];
        unset($buffer[$this->level]);
      }
    }

        if ($this->count != strlen($this->buffer)) $this->throwParseError();

        if (count($this->env) > 1)
            throw new exception('parse error: unclosed block');

        //print_r($this->env);
        return $buffer[0];
    }

[leafo]

Are you sure about the last value taking priority in this case?
As far as I know the more specific one always has the highest precedence regardless of order. In all of the browsers I have access to (chromium + ff) it works properly without a fix.

[jtousek]

Well there was some reason why i needed this, I just can remember the exact case right now. I'll post it here when I find the issue.

[ktauber]

I also think that it would be much better to preserve the order. Who knows what side-effect the changed order may have. Keeping the order avoids problems.

BTW it there a reason for the changed order? Or is it simply an implementation side-effect?

[jtousek]

it's just side-effect, there was no reason to change it but it seems there is no problem with that...

[WraithKenny]

It'd only be a problem if the rules had the same specificity. Not sure that's possible with that markup.

[AccessViolationEnjoyer]

I believe that the Ruby implementation of LESS gives the last value precedence. This is actually needed for writing a clearfix mixin where the clearfix class needs to be reset to display:block; from display:inline-block; (hasLayout).