Intent to Ship: CSS color space display-p3-linear

13 views
Skip to first unread message

Christopher Cameron

unread,
5:58 AM (3 hours ago) 5:58 AM
to blink-dev, Philip Jägenstedt
Hello blink-dev!

This very simple feature adds display-p3-linear as a CSS color space. This has been added to the CSS specification and has a bazillion WPT tests from:
It has been requested as a candidate for interop 2026:

More relevant to the topics close to my heart are the fact that this is a very good space for physically based rendering and high dynamic range. Adding this space to the list of canvas spaces is a separate feature over at:


Contact emails
ccam...@chromium.org

Specification
No information provided

Summary
Add display-p3-linear CSS color space

Blink component
Blink>CSS

Web Feature ID
color-function

Motivation
No information provided

Initial public proposal
No information provided

TAG review
No information provided

TAG review status
Not applicable

Risks


Interoperability and Compatibility
No information provided

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided


Debuggability
No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No

Is this feature fully tested by web-platform-tests?
No


Flag name on about://flags
No information provided

Finch feature name
No information provided

Non-finch justification
No information provided

Rollout plan
Will ship enabled for all users

Requires code in //chrome?
False

Estimated milestones

No milestones specified



Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5162372125818880?gate=4761603400663040

This intent message was generated by Chrome Platform Status.

Daniel Bratell

unread,
6:20 AM (3 hours ago) 6:20 AM
to Christopher Cameron, blink-dev, Philip Jägenstedt

The form seems fields seem to be mostly left empty. I don't think anything should be empty (though a N/A may fit some things). I have questions, but they would mostly be answered by filling in the form and re-posting it.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnfxj9fo12y5zfJ_TosXUU6LaQ6CAcRSX6nqBGnMUWvHZST9w%40mail.gmail.com.

Christopher Cameron

unread,
6:42 AM (3 hours ago) 6:42 AM
to Daniel Bratell, blink-dev, Philip Jägenstedt
Let me know what questions you have.

Indeed, almost everything is N/A (I've filled them out in the feature if you want to look).

Daniel Bratell

unread,
9:07 AM (9 minutes ago) 9:07 AM
to Christopher Cameron, blink-dev, Philip Jägenstedt

The page at https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines lists most of the things we want to know before sending a feature out into the wild wild world.

One of the main questions regards compatibility. We want what we do to end up in a web where browsers agree on how something should be rendered which is why we typically require new features to probe Mozilla and WebKit through their web standards positions (unless they have already shipped).

Another aspect of compatibility, and risk, is about web compatibility. Will this change break things? Are we really, really sure? That is why we typically require every feature to have a finch flag so that at least Google Chrome can turn off something that causes unexpected problems. 

When I say "typical", it's because no rule fits all, but then we instead need to know why a certain rule does not apply. 

You will also see that we ask for some info texts, explainer, specification, that many implementers consider obvious. Often it is not obvious for other people though, and these texts end up in official blog posts and in other external communication.

/Daniel

Reply all
Reply to author
Forward
0 new messages