You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For a project I'm working on, I'm exploring how the CSS Paint API could be used to help solve contrast readability & accessibility problems by implementing a pixel-level "Dodge / Burn" effect ( https://en.wikipedia.org/wiki/Dodging_and_burning ) so that no matter what background a font overlays, the background dodges/burns itself or the area right behind it or something like that (nominally through the paint server provided by a PaintWorklet?) to provide sufficient contrast with the letterforms in the text and the nearby-ish pixels in the background image. I'm somewhat familiar with the concept of paint servers in SVG, and I thought I heard Houdini described as something like that (-ish), just addressable on a pixel/subpixel basis. In the end, I'd like to end up with some kind of rule like:
Some cursory research/tinkering has dashed my hopes that this can be done with the CSS Paint API alone (at least in its current state) because the context passed to the registered paint function doesn't allow the pixels to be read via the provided context because the Pixel Manipulation parts of the rendering context aren't provided (among other things I would probably need to edge-detect the letterforms). I haven't given up: I'm still imagining using the Paint API to go the "last mile" I was just wondering if anyone had any good ideas or advice to supplement my "area behind" approach below:
Clone the element and all its computed styles and stuff it in an SVG <foreignObject>
Read the SVG into a canvas (? can that even be done?), turn off the alpha on the text and store it as BackgroundPixelMap
Turn off the background alpha and store the result as TextPixelMap
Turn off the background alpha, run the text through an edge detection filter and store the image as TextEdgePixelMap
Take the intersection of Backround and TextEdge and for each pixel in Text, either "Dodge" (turn up lightness) or "Burn" as necessary it to meet the minimum contrast specified as AdjustedBackground
Composite AdjustedBackground on top of Background and ... hopefully that would work as something that could be assigned to the context in paint?
Is this viable at all? Or are there better ways to use Houdini/Paint or something? I feel like if it worked, it could be a really neat little "one-shot" trick to solving a lot of accessibility problems because it offers a "scalpel" instead of the "hammer" approaches (e.g. "put a big hideous background behind the text", "put an ugly text-shadow behind all the text, even the letters that don't have contrast problems") that are hard to sell to designers.
Thank you so much for all your work on this API: I've really enjoyed reading the specs that have been written and I'm excited for the future of this API on the Web.
The text was updated successfully, but these errors were encountered:
Just for giggles: I got some hocus-pocus rough version of what I described above working(ish).
It's some real Mickey-Mouse code that would probably make you dumber if you read it, but FWIW with 86% of websites failing basic contrast standards it would be interesting to see some CSS WG pick up the challenge of adding a spec like font-contrast-minimum: 4.5 5px (where 5px is the radius for the dodge/burn). I know it's probably not easy, but it could really help people with low vision by making these adjustments an "easier sell" to designers. The only other options we have now (that I'm aware of, at least) are putting big blocks and indiscriminant text-shadows behind our text that damage brand/creative assets. I don't know if the Houdini spec could play a role in helping that out or whatever. It's really interesting, thanks again for all your hard work - can't wait to see what we can do with this: especially to help people with low vision.
Closing this. I still think it would be great to have a way to have UAs preclude contrast problems in an easy declarative way, not sure which WG would handle something like that.
https://drafts.css-houdini.org/css-paint-api-1/
For a project I'm working on, I'm exploring how the CSS Paint API could be used to help solve contrast readability & accessibility problems by implementing a pixel-level "Dodge / Burn" effect ( https://en.wikipedia.org/wiki/Dodging_and_burning ) so that no matter what background a font overlays, the background dodges/burns itself or the area right behind it or something like that (nominally through the paint server provided by a PaintWorklet?) to provide sufficient contrast with the letterforms in the text and the nearby-ish pixels in the background image. I'm somewhat familiar with the concept of paint servers in SVG, and I thought I heard Houdini described as something like that (-ish), just addressable on a pixel/subpixel basis. In the end, I'd like to end up with some kind of rule like:
background-image: paint(minimum-contrast, 4.5, 'mypicture.jpg')
Some cursory research/tinkering has dashed my hopes that this can be done with the CSS Paint API alone (at least in its current state) because the context passed to the registered paint function doesn't allow the pixels to be read via the provided context because the
Pixel Manipulation
parts of the rendering context aren't provided (among other things I would probably need to edge-detect the letterforms). I haven't given up: I'm still imagining using the Paint API to go the "last mile" I was just wondering if anyone had any good ideas or advice to supplement my "area behind" approach below:<foreignObject>
BackgroundPixelMap
TextPixelMap
TextEdgePixelMap
Backround
andTextEdge
and for each pixel inText
, either "Dodge" (turn up lightness) or "Burn" as necessary it to meet the minimum contrast specified asAdjustedBackground
AdjustedBackground
on top ofBackground
and ... hopefully that would work as something that could be assigned to the context inpaint
?Is this viable at all? Or are there better ways to use Houdini/Paint or something? I feel like if it worked, it could be a really neat little "one-shot" trick to solving a lot of accessibility problems because it offers a "scalpel" instead of the "hammer" approaches (e.g. "put a big hideous background behind the text", "put an ugly text-shadow behind all the text, even the letters that don't have contrast problems") that are hard to sell to designers.
Thank you so much for all your work on this API: I've really enjoyed reading the specs that have been written and I'm excited for the future of this API on the Web.
The text was updated successfully, but these errors were encountered: