- From: Marc J. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Jul 2022 17:38:59 +0000
- To: public-css-archive@w3.org
I'm starting to look at the current CSS standard options to define specific colors for SVG2 (in Inkscape), and the complete disappearance of fallback in color(), or of any fallback mechanism, is puzzling me a lot: Our use case could be something like « I'm making a SVG poster/art for print which I'd also like people to be able to see in rec2020 on their computers, but of course it should display fine if your screen only supports sRGB », and looking at what to put in the `fill="..."` attribute (or equivalently `style="fill:..."`) I see nothing like what I currently have in [SVG11](https://www.w3.org/TR/SVG11/single-page.html#painting-SpecifyingPaint) : I can now only specify `<color>` for one context. Given that --my-profile cannot be guaranteed to exist for people viewing the file if I don't embed the whole icc in base64 in the svg, using it directly (without fallback) seems impossible, so all that's left possible seem to be defining all colors in the file in xyz or lab and handling any color profile operations with non-standard attributes (something like `fill="lab(...)" inkscape:orig-fill="icc-color(...) #00ff00"`). This would be a huge issue for interoperability and conversions, as we would, ideally, like to be able to export "standard" svg to .sla (Scribus) or to pdf with the expected color profiles without relying on nonstandard attributes (and while using the color profile, to not lose ink information). The assumption (in #5931) that I could use media queries implicitly suggest that I should give all my colors unique identifiers and a CSS chunk defining them all in all contexts (also I don't recall a media query for "this icc file exists on the system") instead of being able to name them in the attributes which, I guess, could potentially work (?), but would be a pain for file size as well as for parsers exporting to other formats. I understand that thinking about color-mix and color-adjust is harder with the existence of fallback colors but I don't understand what they were replaced with, conceptually… the simplest for me would be to suggest that non-loadable icc make colors go IACVT, and either that `<color>` is replaced with `<color-list>` (or `<color> = <absolute-color-base> | currentcolor | <system-color> | <device-cmyk()> , <color>?`) and that the first computable displayable value in the list is the actual color; or that I could deal with a non very satisfying `<rect style="fill:#0f0;fill:color(--my-profile, ...)">` where the last valid value might prevail, but can't work with the fill xml attribute... -- GitHub Notification of comment by mclegrand Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6129#issuecomment-1191761344 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 July 2022 17:39:01 UTC