oklab and oklch non-percentage values for lightness not supported in Safari 16.0 on iPhone 12

[rsstiglitz]

Bug description

Safari 16.0 on iPhone 12 does not seem to support normal number values for the lightness entry in oklch and oklab functions when at the same time using a variable in the / opacity addition. @csstools/postcss-oklab-function is not accounting for that when using oklch and oklab with a / var(--opacity) opacity suffix and using the options {"preserve": true} because it inserts this supports rule:

@supports (color: oklab(0% 0 0)) {
  /* ... */
}

This leads to this example not being polyfilled:

span {
  color: oklch(0.5 0.5 0 / var(--opacity));
}

Three different ways to fix this, either adjust the supports rule to @supports (color: oklab(0 0 0)) (without the percentage symbol; it works, I tried it), but this might break other environments which support only numbers and no percentage (are there any). Or, and I don't know if postcss plugins are able to do this, convert decimals in oklab and oklch functions to percentage values.

Third option is to make two supports rules, one with the percentage symbol and one without it.

Source CSS

span {
  color: oklch(0.5 0.5 0 / var(--opacity));
}

Expected CSS

/* Either */

span {
  color: rgba(186, 0, 94, var(--opacity));
}

@supports (color: color(display-p3 0 0 0)) {
  span {
    color: color(display-p3 0.68273 0 0.36343 / var(--opacity));
  }
}

@supports (color: oklab(0 0 0)) {
  span {
    color: oklch(0.5 0.5 0 / var(--opacity));
  }
}

/* Or */

span {
  color: rgba(186, 0, 94, var(--opacity));
}

@supports (color: color(display-p3 0 0 0)) {
  span {
    color: color(display-p3 0.68273 0 0.36343 / var(--opacity));
  }
}

@supports (color: oklab(0% 0 0)) {
  span {
    color: oklch(50% 0.5 0 / var(--opacity));
  }
}

Actual CSS

span {
  color: rgba(186, 0, 94, var(--opacity));
}

@supports (color: color(display-p3 0 0 0)) {
  span {
    color: color(display-p3 0.68273 0 0.36343 / var(--opacity));
  }
}

@supports (color: oklab(0% 0 0)) {
  span {
    color: oklch(0.5 0.5 0 / var(--opacity));
  }
}

Does it happen with npx @csstools/csstools-cli <plugin-name> minimal-example.css?

Yes

Debug output

No response

Extra config

No response

What plugin are you experiencing this issue on?

PostCSS OKLab Function

Plugin version

3.0.7

What OS are you experiencing this on?

macOS

Node Version

20.8.0

Validations

• Follow our Code of Conduct
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Would you like to open a PR for this bug?

• I'm willing to open a PR

[romainmenke]

Hi @rsstiglitz,

Thank you for reporting this issue and for following the template.

adjust the supports rule to @supports (color: oklab(0 0 0)) (without the percentage symbol)

This seems like a good solution.

In an older version of the CSS color specifications only one kind of value was allowed for each channel. So either a number or a percentage. This was relaxed recently to allow both in all positions.

I think all color notation @supports checks need to be updated to reflect that.

So for oklab it is fine to check for oklab(0 0 0) but this should also work : oklab(0 0% 0), note the % in the a channel.

The notations are defined here :

https://github.com/csstools/postcss-plugins/blob/850b34550bbb5ebea804ce2a107b6de976ed8dc5/plugins/postcss-progressive-custom-properties/generate/color.mjs

If you have time and want to contribute then this is good first issue.

• change the support conditions
• run the build command :

  postcss-plugins/plugins/postcss-progressive-custom-properties/package.json

  Line 47 in 850b345

  "build": "node ./generate/matchers.mjs && eslint --fix ./src/matchers.ts && rollup -c ../../rollup/default.mjs",

• update the test results :

  postcss-plugins/plugins/postcss-progressive-custom-properties/package.json

  Line 52 in 850b345

  "test:rewrite-expects": "REWRITE_EXPECTS=true node .tape.mjs"

This change will affect a number of plugins, each will need to have their test result files updated.

[rsstiglitz]

Thanks for your answer!

In an older version of the CSS color specifications only one kind of value was allowed for each channel. So either a number or a percentage. This was relaxed recently to allow both in all positions.

Ah, good to know, so indeed changing the @supports checks seems like the best solution.

Just to be clear for anyone else reading this: You can easily fix this in your codebase now by either using percentage values or I think setting preserve to false will also do it, it's just not as accurate, if you care about it.

I found this issue while working on my company's new product release (which is tomorrow), so after that I'm probably going to take some time off in general, if anyone wants to open a PR in the meantime, feel free to do so. Also, this is the GitHub account I use for work and I'm probably going to switch to my private account when doing this, so don't be confused if you see @nnmrts pop up here or in a PR; thats me! 😆

By the way: I couldn't find anything about this compatibility issue anywhere. Can I use and MDN which use the same source (browser-compat-data) don't say anything about this detail. Note that this issue only occurs on iPhone 12 Safari 16, not on newer iPhones/iOS even with the same Safari major version, as far as I know. Do you know if browser-compat-data even has the capability of displaying that fact? Because at the moment I think it treats the same iOS version as the same browser version and assumes the same support. Is it worth opening an issue there as well?

[romainmenke]

a codepen with some examples : https://codepen.io/romainmenke/pen/wvNYKmR

new WPT tests for things not yet supported in all browsers : web-platform-tests/wpt#43450

chrome bug report : https://bugs.chromium.org/p/chromium/issues/detail?id=1506549
safari bug report : https://bugs.webkit.org/show_bug.cgi?id=265577

mdn compat data issue : mdn/browser-compat-data#21404

[romainmenke]

Small update :

• Chrome and Firefox will have fixed all issues in all color functions by the next release or the one after that.
• still nothing from Safari but they are aware of the issue
• this has been merged into BCD and will be published to MDN docs shortly

I've started tracking this on cssdb as it is clearer there when it is safe to make this change.

[romainmenke]

We also need to test for this in relative color syntax