Feature request: support custom media queries

[parcel-bundler]

Feature request: support custom media queries

[devongovett]

Yeah. We have a drafts option in the API for this, which is where the option to enable nesting is. I think we could put this in there as well.

One other question I had from reading the spec is whether the @custom-media declaration needs to come before it is used, or if something like this is valid:

@media (--modern) and (width > 1024px) {
  .a { color: green; }
}

@custom-media --modern (color), (hover);

If that's the case, we'll need a two pass system for transforming rather than doing it during parsing.

[devongovett]

Looked into it. There are some complicated corner cases here. For example:

@custom-media --color-print print and (color);
@custom-media --color-screen screen and (color);

@media (--color-print) or (--color-screen) {}

This would need to become two media queries since media types cannot be combined in a single query:

@media print and (color), screen and (color) {}

And if an and were used instead, the queries would need to be nested:

@custom-media --not-print not print and (color);
@custom-media --not-screen not screen and (color);

@media (--not-print) and (--not-screen) {}

to:

@media not print and (color) {
  @media not screen and (color) {}
}

In the general case, rules within the media query may even need to be duplicated:

@custom-media --not-print not print and (color);
@custom-media --not-screen not screen and (color);

@media ((script) or ((--not-print) and (--not-screen))) {
  .a {
    color: green;
  }
}

would need to become:

@media (script) {
  .a {
    color: green;
  }
}

@media not print and (color) {
  @media not screen and (color) {
    .a {
      color: green;
    }
  }
}

This seems quite difficult to implement. The PostCSS plugin doesn't seem to do it correctly either. I might simply error on boolean logic with media types for now. Not sure how widely used that will be. The common case (e.g. open props) is to use media conditions rather than media types, which can be done with a simple substitution.

[devongovett]

Makes sense. Do you know what the state of that spec is? How close is it to being done, and/or how likely is the syntax to change at this point?

[yoshuawuyts]

Ohh, I wish I did! The fact that it's being used as prominently as it is in open-props (made by chrome devrel folks) has me feeling somewhat optimistic about how far along it is.

Maybe the actual transform in parcel-css could be exposed behind a feature flag (e.g. unstable_custom_media) until the spec is elevated beyond the "working draft" stage?

[yoshuawuyts]

One other question I had from reading the spec is whether the @custom-media declaration needs to come before it is used, or if something like this is valid:

Afaict all test cases for the PostCSS plugin define @custom-media before it's used. I think we should follow that behavior for now, in part to be compatible with postcss, but also because allowing use-before-declare semantics is backwards compatible ¹. Which luckily is also the simpler variant to implement.

Footnotes

1. If we allow it without the spec specifically stating this is allowed, we could run into compatibility issues with the actual browser implementations later on too. ↩

[devongovett]

Makes sense. I filed an issue on the spec to get it clarified as well: w3c/csswg-drafts#6956

[onetrev]

Hey @devongovett, you can use @import with custom-media queries if add postcss-import to your config. You mentioned in #60 that @import would be problem so this solution seems too easy. There are probably other complexities, but I thought I should note this for others just in case. :)

Either way, it would be nice for support this to built in so it "just worked". Until / unless this Chromium issue adds support for @custom-media this spec looks to be moribund so maybe it doesn't matter, which is a shame since it's so useful.