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
Now that flexbox gap is landing in Chromium 85, I created a demo for it.
In said demo I wanted to show a warning on top, in case the browser does not support flexbox gap, using @supports
(A more Real World use-case might be to implement a fallback – using margin – in case flexbox gap is not supported)
I tried this:
.warning {
display: block;
}
/* Hide warning in case browser supports flexbox gap */@supports (display: flex) and (gap:1em) {
.warning {
display: none;
}
}
In Chromium < 85 – which does not support flexbox gap – the warning is hidden, this because both conditions are evaluated separately:
Does Chromium < 85 support display: flex? yes
Does Chromium < 85 support gap: 1em? yes (with CSS Grid)
Looking at the spec there does not seem to be a way to combine these conditions (or it could be I'm overlooking something?). Since the use of parens do not really have influence on the combination of the supports-conditions, I was thinking of something like this:
Now that flexbox
gap
is landing in Chromium 85, I created a demo for it.In said demo I wanted to show a warning on top, in case the browser does not support flexbox gap, using
@supports
(A more Real World use-case might be to implement a fallback – using
margin
– in case flexbox gap is not supported)I tried this:
In Chromium < 85 – which does not support flexbox gap – the warning is hidden, this because both conditions are evaluated separately:
display: flex
? yesgap: 1em
? yes (with CSS Grid)Looking at the spec there does not seem to be a way to combine these conditions (or it could be I'm overlooking something?). Since the use of parens do not really have influence on the combination of the
supports-condition
s, I was thinking of something like this:Here the browser should check if supports both these properties, when both applied.
Would this be a feasible addition to the spec?
The text was updated successfully, but these errors were encountered: