anyone think 【tag:before{&:hover{color:red}}】 should compiles to 【tag:hover:before{color:red}】?

[xieranmaya]

I'm using LESS today and I wrote a LESS spinet like this:

div:before{
    content:'css generated content';
    color:green;
    &:hover{
        color:red;
    }
}

and it compiles to

div:before {
    content:'css generated content';
    color: green;
}
div:before:hover {
    color: red;
}

and this can't work, but it's intuitive....
you can see this question:
http://stackoverflow.com/questions/5777210/how-to-write-hover-condition-for-abefore-and-aafter

so, do you think that the above LESS code should compiles to

div:before {
    content:'css generated content';
    color: green;
}
div:hover:before {
    color: red;
}

and it's works in browser
which means

div:before{
    &:hover{
    }
}

should compile to

div:hover:before

mind the

:hover and :before

's order

[seven-phases-max]

but it's intuitive....

Well, perhaps. But (usually) it's not compiler's job to guess user intentions and depending on such guesswork to change its own rules (in other words "automatically fix errors for you"). So in this particular case I'm afraid that if you want a different order you need to write it in this different order (even if it won't look very compact), e.g.:

div {
    &:before {
        content: 'css generated content';
        color:   green;
    }
    &:hover:before {
        color:   red;
    }
}

See also #1075.

[lukeapage]

Does it make any difference? If not why do people care what its compiled
too?

[matthew-dean]

@lukeapage A generated block (div:before) doesn't have a hover state. It's a sub-element and created via CSS, so it doesn't receive events (e.g. div:before:hover never occurs). But, of course the main div does, and you can generate a block in that main div based on it's hover state (div:hover:before).

@xieranmaya As a general rule, Less doesn't have awareness of what the CSS is, just how the code is written. So div:before:hover == div:blerg:flooglem to the parser. Changing the rules of parsing based on what you write can get messy quick and adds a heap to the parsing logic.

[lukeapage]

I think this should be covered by the issue about selecting a parent for & e.g. if you could do

div {
  :before {
     content:'css generated content';
     color:green;
     &(1):hover&(2){
        color:red;
     }
  }
}

it would be one way of solving the issue.(though in this case @seven-phases-max suggestion would be better

I presume it is feasible that although at the moment generated elements don't get hover events, that they could in the future? If so we don't want to make this change as we would then have to then make a breaking change to revert it back.

[radium-v]

If we're going against the W3C spec, there's this:

One pseudo-element may be appended to the last simple selector in a chain, in which case the style information applies to a subpart of each subject. (http://www.w3.org/TR/CSS21/selector.html#selector-syntax)

It's slightly different in the CSS3 proposed spec though:

Only one pseudo-element may appear per selector, and if present it must appear after the sequence of simple selectors that represents the subjects of the selector. Note: A future version of this specification may allow multiple pseudo-elements per selector. (http://www.w3.org/TR/2009/PR-css3-selectors-20091215/#pseudo-elements)

To me, it doesn't make sense to accommodate for this, since the compiler will just do what you tell it to:

div {
  &:before {
    content: 'css generated content';
    color: green;
  }

  &:hover {
    &:before {
      color:red;
    }
  }
}

[lukeapage]

am I right in thinking this particular bug can be closed, e.g. better handling of & is covered by other bugs?

[matthew-dean]

Yes, in the way this issue is written, Less doesn't need to reorder psuedo-elements.