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
Currently, you provide a single value when registering size and color presets, which means it's not possible to provide fallback values for older browsers or devices.
It's also important to note that in the case of color this is not a problem that will go away as browsers are updated. A device with a screen that doesn't support the Display-P3 color space will always work best with a fallback in good ol' rgb() or hex even if the browser understands color(). (more on this below)
What is your proposed solution?
Allow registration of multiple values for a preset, and output all of them. This way, browsers and devices that don't or can't use newer values for whatever reason will still get a reasonable facsimile of the experience as designed:
This is very simple, but it wouldn't work well for color spaces, since browsers that understand color() running on a device that only has an SRGB gamut will attempt to map a Display P3 value to SRGB instead of falling back to the SRGB value. That may end up being a color that is ugly at best or makes content illegible at worst, which is obviously not ideal when a preselected SRGB version of the color is available.
A potential way to work around this would be supporting an object for colors that specifies the color space, then outputs the additional spaces in color-gamut media queries:
What problem does this address?
Currently, you provide a single value when registering size and color presets, which means it's not possible to provide fallback values for older browsers or devices.
In this example, browsers without support for
clamp()
would not have any spacing or font size value applied for thesm
/10
presets.In practice, support for
clamp()
is closely aligned with support for custom properties so this isn't a widespread problem right now, but anyone who wants to use newer CSS features like expanded color spaces, relative viewport units and container units is unable to provide a reasonable fallback using progressive enhancement.It's also important to note that in the case of color this is not a problem that will go away as browsers are updated. A device with a screen that doesn't support the Display-P3 color space will always work best with a fallback in good ol' rgb() or hex even if the browser understands
color()
. (more on this below)What is your proposed solution?
Allow registration of multiple values for a preset, and output all of them. This way, browsers and devices that don't or can't use newer values for whatever reason will still get a reasonable facsimile of the experience as designed:
This is very simple, but it wouldn't work well for color spaces, since browsers that understand
color()
running on a device that only has an SRGB gamut will attempt to map a Display P3 value to SRGB instead of falling back to the SRGB value. That may end up being a color that is ugly at best or makes content illegible at worst, which is obviously not ideal when a preselected SRGB version of the color is available.A potential way to work around this would be supporting an object for colors that specifies the color space, then outputs the additional spaces in
color-gamut
media queries:(The color stuff may be best as a separate issue.)
The text was updated successfully, but these errors were encountered: