- From: softworkz via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jul 2024 22:59:37 +0000
- To: public-css-archive@w3.org
@svgeesus - Thanks for your comment. I think there are a few misunderstandings, please let me clarify: First of all, there no "we" and no "them". There isn't any "their" site that we want to change. Also there's not "another site using the exact same style sheets", because it's all and only about our own web application with every single line of CSS written by ourselves. This is not about changing any 3rd party sites or content like as your answer tries to imply. > Being able to affect all CSS colors but not images or video also accects the default color matching that they have (assuming a relative colorimetric rendering intent in the images). Of course there can be cases where such color matching exists, but in our case there is none - and that's probably the majority of cases. Anyway, in the end it is up to the web developers to decide whether they want to break such matching or to determine that there isn't any matching that needs to be preserved. It is unclear to me whom you are intending to protect from whom to be doing "something problematic" (like causing color mismatch). A web developer has full control over everything anyway. They can make all colors white if they want. Or black. And they can also make colors mismatch as much as they like to. The web colors API doesn't prevent them from doing that and that's really not the point of such API either. A good API provides rich abillities to developers, allowing them to do what they need to do in a useful and convenient way - of course making it easy and natural to achieve correct results without deep knowledge, but also not be limited based on assumptions that may apply sometimes but other times not. > If you are mixing HDR and SDR content and your SDR colors are coming out too bright, then it seems that the issue is that your compositor is not mapping CSS 'white' to the HDR media white but instead to some brighter one. I would look there first. It seems I've done an awful job in explaining and I apologize for that. I'll try to be a bit more specific: We are developing a (well-known) media organization/presentation/playback software with clients for more than two dozen different platforms ranging from mobile to desktop computers to SBCs to gaming consoles, smart tvs, settop boxes, sticks/dongles etc. - most of them driven by the same HtmlJs UI core, surrounded by platform-specific implementations for many features - a prominent one being video playback, for which we often have a native video player which is overlaid by an html rendering surface which is made transparent during video playback where it is rendering its controls on top of the video. The video color presentation is on an totally different path and independent from the html and its css colors. Let's forget about HDR for a moment, it's just been distracting from the core subject which isn't specific to HDR, just emphasized in those cases. The UI has a number of different themes for display, some dark and some light ones but always the same set and the same css color values (for all platforms). When looking at dark themes on mobile or desktop OS/apps, you'll notice that the text color is usually full white (FFFFFF) and the background dark but quite a bit away from full black. It seems to have turned out as the most ergonomic and eye-friendly way, but I never dug deeper into this subject other than the empirical discovery that even a just moderately dimmed white doesn't make a good dark-theme text color on a desktop pc for example. That's why the themes are using FFFFFF (or close to that) as text color for dark theme. But when the same UI is shown on TV displays (or OLEDs with high brightness/contrast), users are often complaining that the text (and other elements) are "too bright" and it's not comfortably viewable. It very much depends on the individual setup - sometimes it's just fine, sometimes just a little and other times really too steep. ## Now the question: how can this be dealt with? My results and conclusions were these: - The images that are shown as part ofr the html ui are of no concern - they're fine to view on all platforms/devices as they usually don't have any larger contiguous areas of max-white color => Images should not be affected by a color/brightness adaption - CSS filters for brightness or luminance can't help here because - It is not possible to apply CSS filters to CSS colors only while excluding other DOM content (like images) - it would need to be applied to the whole html surface which can be 4k and devices are often too underpowered to do this - The results are odd and wrong-looking because we only want to reduce the brightness of the brightest parts but without changing dark and mid-range colors - It would be great to have a CSS API which allows to specify transfer-functions in some way that allows the manipulation of CSS colors - While writing this, I realize that I probably shouldn't have written "Global". By "Global" I meant to express that it applies to all CSS colors, but I still meant it to be limited to the CSS scope to which it is applied. I didn't mean it to be "global" in a way that it's outside of CSS (like a browser setting or so) -- GitHub Notification of comment by softworkz Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10262#issuecomment-2221664496 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 July 2024 22:59:38 UTC