W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2020

Re: [csswg-drafts] [mediaqueries-5] Draft text for in-gamut MQ, see #5045 (#5523)

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Wed, 30 Sep 2020 08:11:36 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-701235855-1601453494-sysbot+gh@w3.org>
I think the write up is clear and precise, so it gives a clear understanding of how this works.

However, I think it's missing an explanation of why you'd want to use this, and what kind of situations it's for. The reason I think this may be important is that I suspect this is an easy thing to misunderstand, and to use when you didn't need to, or to fail to notice that it could be applicable to problems you have.

If I'm understanding things correctly, most of the time, the right way to deal with out of gamut colors is not to use this, and instead to reach for [rendering-intent](https://drafts.csswg.org/css-color-4/#descdef-color-profile-rendering-intent). This would be a more specialized tool, that you'd typically use when developing something like a photo editor or something of the sort, where you'd want to display a bright color as a warning if some of the colors end up out of gamut or something. But if it's that, I'm not completely sure why you'd want to check against the gamut of the output device. Checking against so selected target color space that you intent to save your edited image into would make more sense to me. More over, if that's the case, I'd guess this would be most useful not just with raw colors whose value you specify directly, but with colors process through one or more layers of the `color-adjust()` function for colors-5. The syntax description suggests you can do that, but the examples don't show case it.

The fogra39 input being checked against a high-end 7 color printer output almost makes sense as a use case, as that would let you soft-proof something before printing it, showing clear warnings if something would go off. But I don't think that would quite work either, given that as far as I know, CSS User Agents (at least mainstream ones known as browsers) never render to a printer with a specific color space, but always render to PDF, which by itself doesn't have a clearly bounded color space, and so the answer of the query would always be true. Maybe I am misunderstanding this too and it would actually work for some reason that escapes me, or maybe it would indeed only work in a not-a-browser CSS-UA, but then it should be called out in order not to lure people into thinking it would work in browsers while in reality it wouldn't.

Also, whether it's for soft proofing or for image editing, it also feels it would be very useful if in addition to be able to test single colors, you could pass an `<<image>>`, and get to know if any part of the image would be out of gamut.

Depending on what the actual use cases are, I wonder if the fact that you cannot test whether a color / image is in gamut after having been through a [css filter](https://drafts.fxtf.org/filter-effects/#FilterProperty) may be limiting. Whether that's a sign that I don't understand the use cases, or that this is an incomplete tool, I don't know.

Either way, even though I feel I understand **how** it works, I am reasonably confused as to the applicability of this feature. I think we need to have a bit of a description of what this is or isn't for, and to change or expand the examples to relate them not just to the calculation itself, but to actual situations you'd want to use this in.

GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/5523#issuecomment-701235855 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 September 2020 08:11:38 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:17 UTC