Tab Atkins Jr.

There's nothing wrong with it on the Syntax side; you can't mix declarations with *style rules* (except with special circumstances, like Nesting), but you can mix either with at-rules. (You'll...

> is there any easy way to do that without copying all the logic for and/or/not? Unfortunately not, you gotta just write out the full grammar. It's mostly copy-pasting tho.

The syntax as described makes it slightly impossible to say "else be IACVT" in some cases. (For these examples, I'm gonna assume we use `:` between the condition and value,...

> hy not simply make the last argument mandatory and allow empty values (just like var())? That's possible, I just find it less clear to read. I don't really like...

> If that’s not an option, I'd rather introduce a different separator than a whole keyword. Actually, let me state this better: this isn't about the separator. The issue is...

> By the time you get to the first value, you know what your separator is, so there’s no ambiguity in if(style(...), foo, bar). urgh, i really wouldn't want `if(style(...);...

> If we use a different character to separate the condition from the values (say ? or :), then if(style(...) ? foo, bar) is ambiguous: It's not ambiguous - as...

Just double-checking my understanding here - it seems that this isn't *similar to* `@extend`, but rather *is* `@extend`, right? You're asking for a `foo` selector to be treated like a...

Sure, those are all important open questions for anything like this. Besides those, tho, I was just checking my understanding that it's otherwise identical, and not subtly different in a...

I do like @mirisuzanne's suggestion of handling this functionality as a predefined mixin. We'd have to be pretty deliberate about the set of styles we define, so it's something I'd...