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
fallback to a solid-color image, when the image at the specified url can’t be downloaded or decoded
automatically respect the image orientation specified in the image’s metadata
spec fixes many long standing issues with CSS images:
a simplified syntax for image spriting that doesn't require 3 different CSS properties: background-image: image('sprites.svg#xywh=40,0,20,20');. This is a similar syntax as is used in object-view-box. Would be wonderful to finally have parity for background and foreground images. This also opens up the use of background-size and background-position for actual sizing and positioning of these images instead of dealing with the spriting.
ability to create a solid color image like this: background-image: image(red); instead of hacking a gradient like this: linear-gradient(red, red). Is good for devs because it's less repetition in the code and for browser vendors i'm guessing this would allow a path to a separate algorithm for just rendering a solid colored image.
Proper image fall-backs which url() can't do. When the image at the specified url can’t be downloaded or decoded, fallback to another image or color. This could lead to less background colors that are never seen being painted behind images.
automatically respect the image orientation specified in the image’s metadata.
FYI: the above are all from images-4 but the CSSWG is already looking at expanding image() in images-5 for things like background video (w3c/csswg-drafts#6732) and @image-manipulation (w3c/csswg-drafts#6807)
Description
Was proposed last year too by @jsnkuhn
spec fixes many long standing issues with CSS images:
a simplified syntax for image spriting that doesn't require 3 different CSS properties: background-image: image('sprites.svg#xywh=40,0,20,20');. This is a similar syntax as is used in object-view-box. Would be wonderful to finally have parity for background and foreground images. This also opens up the use of background-size and background-position for actual sizing and positioning of these images instead of dealing with the spriting.
ability to create a solid color image like this: background-image: image(red); instead of hacking a gradient like this: linear-gradient(red, red). Is good for devs because it's less repetition in the code and for browser vendors i'm guessing this would allow a path to a separate algorithm for just rendering a solid colored image.
Proper image fall-backs which url() can't do. When the image at the specified url can’t be downloaded or decoded, fallback to another image or color. This could lead to less background colors that are never seen being painted behind images.
automatically respect the image orientation specified in the image’s metadata.
FYI: the above are all from images-4 but the CSSWG is already looking at expanding image() in images-5 for things like background video (w3c/csswg-drafts#6732) and @image-manipulation (w3c/csswg-drafts#6807)
more detailed explainer: https://12daysofweb.dev/2022/css-image/
Tests
https://wpt.fyi/results/?label=master&label=experimental&aligned&view=subtest&q=css-image-fallbacks
Standards Positions
Mozilla: mozilla/standards-positions#856
Browser bug reports
Polls & Surveys
https://2023.stateofcss.com/en-US/features/
are aware: 2876
have used: 1418
Workarounds
There is a postCSS plugin for image()
https://github.com/valtlai/postcss-color-image
Specification
https://drafts.csswg.org/css-images-4/#image-notation
Additional Signals
No response
The text was updated successfully, but these errors were encountered: