better media query now?

[benjclark]

@media (update: fast)

Chrome: 113 (May 2023)
Firefox: 102 (June 2022)
Safari: 17 (September 2023)
Edge: 113 (May 2023)
Opera: 99 (May 2023)

Maybe this is a better media query to use now. What you think @andykirk ?

https://caniuse.com/mdn-css_at-rules_media_update

[andykirk]

Hi, thanks for this. Amazing - somehow I hadn't become aware of this.
I haven't looked in it properly or tested it, but should it perhaps be declared as:

<link rel="stylesheet" href="mq-test.css" media="
    only print,
    only all and (update: none),
    only all and (update: slow),
    only all and (update: fast)
">

to catch all supporting browsers regardless of what the browser state / setting is in place?

I can add this to the list, it would be a good 'latest' cut.
FYI I've started wrapping main blocks of styles in @supports blocks to cut the CSS more specifically, but this new addition would still be useful.

Thanks

[benjclark]

Thanks @andykirk

That's interesting to hear you have switched over to using @supports. We had been doing some thinking on that as well and were thinking of the following as a possible implementation of CTM:

@import 'core-experience';

// :not - Chrome 88, Firefox 84, Edge 88, Safari 9
// aspect-ratio - Chrome 88, Firefox 89, Edge 88, Safari 15
// margin-block-start - Chrome 69, Firefox 41, Edge 79, Safari 12.1
// gap - Chrome 57, Firefox 52, Edge 16, Safari 10.1
// display: grid - Chrome 55, Firefox 52, Edge 16, Safari 10.1
// CSS variables - Chrome 49, Firefox 31, Edge 16, Safari 10
// object fit - Chrome 32, Firefox 36, Edge 79, Safari 10
// display: flex - Chrome 21, Firefox 28, Edge 12, Safari 9
@supports
(selector(:not(.foo))) and
(aspect-ratio: 1 / 1) and
(margin-block-start: 1rem) and
(gap: 1rem) and
(display: grid) and
(--css: variables) and
(object-fit: cover) and
(display: flex) {

	:root {
		--ctm: true;
	}

	@import 'enhanced-experience';
}

However when I tested that implementation at scale I got some confusing results which suggested that the implementation did not work correctly for a proportion of our users on browsers that should cut the mustard.

[andykirk]

Thanks. I don't enough websites at scale to be able to look into this, but to my mind that's a lot @supports declarations - maybe that's part of the reason it's not working as expected?

I haven't fully "switched over" either, I've just started to experiment. I still use a 'cut' on the HTML <link> element to clear away as much old stuff as possible, but in an effort to use more "modern" CSS I find I'm having to progressively enhance individual patterns with @supports.
This worked ok to start with by as more and more new features come on board (and depending on the project) sometimes I just want to have a simple 'clean slate' with the CSS and not worry about lots of @supports blocks, so I just pick the one I want to use that has the LEAST support and use that. Everything else gets cut.

For example, I'm looking at setting my threshold based on Container Queries (the game-changer for me), so I'll be looking at:

@supports (contain: inline-size) {
    /* All my other CSS here */
}

All other features I want to use have greater support, so I can safely assume they'll work as well. (Though I always test of course).

Hope that helps.