Fallback for Container Queries

[Serator]

What version of @tailwindcss/container-queries are you using?

v0.1.0

What version of Node.js are you using?

What browser are you using?

Chrome 109.0.5414.75

What operating system are you using?

Windows 10

Reproduction repository

https://play.tailwindcss.com/ksciGipiQh

Describe your issue

I would like to add a fallback option in case Container Queries are not supported.
supports-[container-type:_inline-size]:@lg/someName:modern_styles & @lg:fallback_styles looks like a good choice for this purpose. The problem is that the styles @lg: override the supports-... styles.

The workaround may be !important or supports-[not..., but this solution is not always possible.

[adriannecris]

Have you use a polyfill? Either use https://github.com/ausi/cq-prolyfill or https://github.com/GoogleChromeLabs/container-query-polyfill

then add some conditions on the _app.js

if (typeof window !== 'undefined') {
  const supportsContainerQueries = "container" in document.documentElement.style;
  if (!supportsContainerQueries) {
    import("container-query-polyfill")
  }
}

[Serator]

No, because we would like to see the result immediately in the first frame. In the case of polyfill, you must first determine the availability of the feature, make calculations, and only then apply the workaround. Perhaps the current polyfills work somehow differently.

The problem described in this issue is not so relevant for us anymore, since CQs are already supported by all major browsers, but if I understand it correctly, this problem is much more complicated, since we have a preset order of classes according to the Tailwind design and it just needs to be taken into account.

Feel free to close this issue if Tailwind's design does not suggest a solution.

[reinink]

Hey! Yeah, this is a tricky problem, because it's hard to know which utility should take precedence. I think there is an argument to be made that if you're using the supports modifier then that should always win, but I'm not 100% certain that's true for all situations. Using the important modifier feels like a reasonable workaround here as well, but I also like your "not supports" solution.

I think if this was my project I would add two entries to the supports key in my config for these two situations:

module.exports = {
  theme: {
    supports: {
      cq: 'container-type: inline-size',
      'not-cq': 'not(container-type: inline-size)',
    },
  },
}

That way you can at least write shorter versions of these where these utilities never collide, since one will only ever be active.

<div class="supports-cq:@[768px]/someName:bg-green-400 supports-not-cq:md:bg-red-400">
  <!-- ... -->
</div>

Admittedly the not-cq naming isn't great, so maybe you can come up with something better there hah.

Thanks for sharing this feedback either way. The purpose of this plugin was really to provide us with a way to start messing around with container queries in Tailwind CSS with the hope that some day it can be merged into Tailwind core. I suspect we'll end up solving this specificity issue at that time.

[Serator]

`not-cq' makes sense, thanks!