CSS parsing error for media queries

[jh3y]

🐛 bug report

This is valid CSS:

@media (not(hover)) {
  body {
    background: red;
  }
}

Yet, the Parcel CSS transformer throws an error about it.

@parcel/transformer-css: Unexpected token Function("not")

🎛 Configuration (.babelrc, package.json, cli command)

Default.

🤔 Expected Behavior

It compiles the CSS that is valid.

😯 Current Behavior

It fails on an error that isn't an error.

🔦 Context

It's another issue I've had where the CSS transformer has caused me an issue. In this case, I can't use an imported package because the transformer doesn't like it.

[jh3y]

Again. It would be ideal if there was a way to say "Hey @parcel/transformer-css, don't try and process this file.". Because in some cases it causes more issues and prompts weird workarounds or me looking for a different tool entirely.

[devongovett]

I believe this actually is invalid. The whitespace after not is significant in this case, because it changes from parsing as a function to parsing as a keyword. Here's a test page: https://codepen.io/devongovett/pen/qBoQZQW (works in Chrome Canary or Firefox).

[jh3y]

This example is lifted straight out of MDN and doesn't work with the transformer

@media (not(hover)) { /* … */ }

https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries#negating_a_feature_with_not

Could be an error in the documentation for which I can get fixed. Either way, it would be great if there was a way to escape files that might contain these things. As it brings everything to a halt. I'm importing external libs that contain code with this in and because I can't tell Parcel to not process the file getting imported, I have to use unpkg or inline the styles somehow via JavaScript so it doesn't bring everything else to a halt.

It's the same for new CSS features which aren't yet supported by Parcel. We are kinda held to the transformer's cadence which isn't ideal with the number of new features coming down the pipeline for CSS. I'm currently having to write my "new" CSS in JavaScript and inject it into the head manually.

[devongovett]

Yep, that's a bug in the MDN docs. That doesn't work in any browser.

The way to work around this is the errorRecovery option. This skips over invalid rules entirely, just like browsers. Add this to your package.json:

{
  "@parcel/transformer-css": {
    "errorRecovery": true
  }
}

In this case, that is the correct solution since the rule is invalid and would not apply in any browser. For other future CSS features such as unknown at rules and selectors, we can try to preserve them as is (within reason). For example, parcel-bundler/lightningcss@bbb64b7 does this for unknown functional pseudo classes such as shared element transitions. These will now warn rather than error until we implement them properly. I will try to do this for unknown at rules next, but this is harder.

[jh3y]

Awesome! 👍

Yeah, that errorRecovery is what I'm after 🙌 I've hit a couple of points where I think this is going to help a bunch. Shared element transitions were one, as was scroll-timeline.

A way of working around @layer imports would be sweet so we can do vendor layering. I opened an issue for that here.

Thanks for this! 👏 🙏

[jh3y]

Ahh, I tried that errorRecovery trick 🤔

Importing an npm module style broke it

@import 'npm:98.css';

using

"@parcel/transformer-css": {
    "errorRecovery": true
  },

With transformer version 2.6.2 yields the same error about not.

[devongovett]

errorRecovery was added in 2.7.0.

[jh3y]

Sweet. I'll make the update 👍

[devongovett]

Going to close this one then. I think your other issue parcel-bundler/lightningcss#227 covers the remaining cases.