supports variant compiles function syntax incorrectly

[adamwathan]

What version of Tailwind CSS are you using?

v3 and v4

Reproduction URL

https://play.tailwindcss.com/ySYgzSn5FT

Describe your issue

Classes like supports-[font-format(opentype)]:grid generate invalid CSS, because we currently assume that supports values that don't contain : are a CSS property and we insert a variable at the end in an attempt to make the query valid:

@supports (font-format(opentype): var(--tw)) {
  .supports-\[font-format\(opentype\)\]\:grid {
    display: grid;
  }
}

This isn't a crazy complicated thing to fix but there are a number of test cases to consider:

supports-[font-format(opentype)]:grid
supports-[content:"("]:grid
supports-[(display:grid)_and_font-format(opentype)]:grid

[brandonmcconnell]

One solution here could be to explicitly detect and ignore known function syntaxes, as it appears to be a very finite and set concrete list:

• font-format()
• font-tech()
• selector()

Doing it this way and not arbitrarily matching a string(…) pattern would also avoid matching for all strings where some others are valid non-function syntax (e.g. and|or|not).

---

UPDATE: In my related PR #13596, I opted to support the hyphen character in supports checks, which appears to fix the issue and resolve the cases you mentioned with one exception (details below) and add support for custom properties the same way we currently support native ones.

• supports-[display] ➞ @supports (display: var(--tw)) ✅
• supports-[--test] ➞ @supports (--test: var(--tw)) ✅

[brandonmcconnell]

Thoughts for the future — it could be helpful to set up extensions to the supports rule to support each of the function syntaxes in the future, e.g.:

• supports-font-format-[opentype]
• supports-font-selector-[h2>p]

⚠️ This still wouldn't account for the present use case of using them inline, which is the immediate need

[brandonmcconnell]

@adamwathan I opened PR #13596, which should resolve this issue. It does not fix the supports-[content:"("]:grid test you mentioned, but as that does not appear to be directly related to the supports-variant effort and is more related to the parser itself, I would prefer to handle that case in a separate PR.

You can see here that this was an issue before: https://play.tailwindcss.com/M7FOiImx9l

I confirmed that example (supports-[content:"("]:grid) doesn't reach the test, so it would appear to be filtered out by the parser. supports-[content:"test"]:grid works, indicating that the parenthesis is the other example is problematic. I'll take a deeper look at how the parser handles quoted strings inside arbitrary values and see if something is missing there.

[adamwathan]

Reopening so we fix this in v3 as well.

[brandonmcconnell]

@adamwathan #13605 should fix this for v3

[adamwathan]

Closing this one since it's fixed in v4. Doesn't appear fixed in v3 oddly in my testing even though apparently #13605 fixed it but whatever.