Please add support for referencing parent selectors: &

[mediamichael]

Referencing Parent Selector with "&" makes styling faster, removes repetition, decreases error potential, and is just awesome!

Example in SASS: "Sometimes it’s useful to use a nested rule’s parent selector in other ways than the default. For instance, you might want to have special styles for when that selector is hovered over or for when the body element has a certain class. In these cases, you can explicitly specify where the parent selector should be inserted using the & character. For example:

a { font-weight: bold; text-decoration: none; &:hover { text-decoration: underline; } body.firefox & { font-weight: normal; } }

is compiled to:

a { font-weight: bold; text-decoration: none; } a:hover { text-decoration: underline; } body.firefox a { font-weight: normal; }"

[iflan]

This has been asked for several times, so I'm thinking that it's not an unreasonable request.

One of the reasons that we haven't done things like this in the past is because it breaks away from the CSS grammar. Maybe that's not a big issue, though, since it's not like @defs would work without compilation in the first place.

There are a couple issues, though, that I think we need to work through, including:

• How does & work if the parent has multiple selectors?
• Are @defs allowed inside a rule? (I would say no, but could be convinced otherwise.)
• At what stage are the &s processed?
• How does & work in a component?

I'd like you to propose some possible ways of resolving the above questions and then we can go from there. You can either reply to this discussion, create a wiki page, or create a public Google Doc.

Thanks,

Ian

[SLaks]

& with multiple selectors should work like LESS, with combinatorial expansion. See http://blog.slaks.net/2013-09-29/less-css-secrets-of-the-ampersand/ for lots of examples. This feature is extremely useful when making interesting selectors.

[SLaks]

I think @defs should be allowed in a rule, and should create scoped names that are only visible in that rule.

I don't see any issues with & in a component; the first classname would be prefixed, as always. (if & comes before the first classname, I think it should not be prefixed).