Re: [css-cascade] Allowing @import to be conditional on @supports queries

Currently Sass compiles according to the lowest common denominator for
maximum browser support. But there are some browser features that would let
us compile to more correct and/or more compact output. However, there's not
an efficient way for people to gracefully degrade their stylesheets without
doing user agent detection on the server side.

Some examples:

* Sass currently gives an error for expressions that involve incompatible
units, but we could instead output a calc() expression automatically.
* Sass can emulate @extend without exponential explosions involving complex
selectors if we can rely on :matches() being present.

If we had this, instead, Sass could output several stylesheets and emit the
@import rules to pull in the backwards compatible rules for the less modern
browsers.

Chris

On Thu, Jan 15, 2015 at 4:35 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> Right now, @import can only be made conditional on Media Queries, by
> putting a media query after the URL in the rule.
>
> However, it would also be useful to let it be conditional on the
> result of an @supports query.  That way, for example, one could send
> some small, compact code using modern features, and if an @supports
> query returns false, instead @import larger, more complicated code
> (perhaps generated by a preprocessor from your base code) to do the
> styling instead.  This avoids having to send both sets of styles to
> most people; only down-level browses would have to spend the
> additional bandwidth.
>
> I propose that we allow this by adding a
> "supports(<supports-condition>)" function to the end @import grammar,
> like:
>
> ```
> @import [ <url> | <string> ] [ <media-query-list> ||
> supports(<supports-condition>) ]? ;
> ```
>
> In other words, you can supply a media condition and/or a supports
> condition.  If we add more conditional rules, we can add more to this
> clause as well.
>
> Thoughts?
>
> ~TJ
>
>