Whew boy, Safari 16 is officially out in the wild and it packs in a bunch of features, some new and exciting (Subgrid! Container Queries! Font Palettes!) and others we’ve been waiting on for better cross-browser support (Motion Path! Overscroll Behavior! AVIF!). I imagine Jen Simmons typing cheerfully writing out all of the new goodies in the roundup announcement.
Just gonna drop in the new CSS features from the release notes:
Added size queries support for Container Queries. Chrome started supporting it in Version 105, so all we need is Firefox to join the party to get The Big Three™ covered.
Added support for Container Query Units.These units go hand-in-hand with Container Queries. Once again, we need Firefox.
Added support for Subgrid. Now it’s Safari and Firefox with support coverage. The good news is that Chrome is currently developing it as well.
Added support for animatable Grids. Very cool! Chrome has always had some implementation of this and Firefox started supporting it back in 2019.
There are quite a few nice updates to Safari’s developer tools, too. We’ve got a Flexbox inspector, a Timelines tab (with an experimental screenshots timeline), and Container Queries info, to name a few. There’s a full 32-minute video that walks through everything, too.
I thought Safari 15 was a pretty killer release, but 16 is pretty epic in comparison. I know there’s a “Safari is the new Internet Explorer” vibe in some circles, but I’m happy to see big jumps like this and appreciate all the forward momentum. Go Safari Team!
This is a nice update from Manuel Rego Casasnovas. Igalia has this idea to sort of crowd-source important web platform features that need to get worked on (that’s the sort of work they do). They call it Open Prioritization. The “winner” of that (the one with the most-pledged dollars) is what they’ll do. That turned out to be :focus-visible support in WebKit (Safari). As I write, people have pledged $ 29,337.13 of the $ 35,000 goal, so not bad!
That choice was made in January 2021, and as Manuel was writing in June 2021, it’s basically done because it shipped in Safari Technical Preview 125 meaning it’s in Apple’s hands now. Pretty nice speed for a web feature, and a great one since it will highly encourage proper focus styles rather than that bummer situation where people remove focus styles for aesthetic reasons, hurting accessibility.
And, bonus!
In addition, the WPT test suite has been improved counting now ~40 tests for this feature. Also in January neither Firefox or Chrome were using :focus-visible on the UA style sheet, however they both use it there nowadays. Thus, doing the implementation on WebKit has helped to move forward this feature on different places.
In this week’s roundup, WebKit’s prefixed autofill becomes a standard, the pointer cursor is for more than just links, and browsers are jumping on board to delay videos set to autoplay until they’re in view… plus more! Let’s jump right into it.
CSS ::-webkit-autofill has become a standard feature
Chrome, Safari, and pretty much every other modern web browser except Firefox (more on that later) have supported the CSS :-webkit-autofill pseudo-class for many years. This selector matches form fields that have been autofilled by the browser. Websites can use this feature to style autofilled fields in CSS (with some limitations) and detect such fields in JavaScript.
let autofilled = document.querySelectorAll(":-webkit-autofill");
There currently does not exist a standard autocomplete or autofill event that would fire when the browser autofills a form field, but you can listen to the input event on the web form and then check if any of its fields match the :-webkit-autofill selector.
The HTML Standard has now standardized this feature by adding :autofill (and :-webkit-autofill as an alias) to the list of pseudo-classes that match HTML elements. This pseudo-class will also be added to the CSS Selectors module.
The :autofill and :-webkit-autofill pseudo-classes must match <input> elements that have been autofilled by the user agent. These pseudo-classes must stop matching if the user edits the autofilled field.
Following standardization, both pseudo-classes have been implemented in Firefox and are expected to ship in Firefox 86 later this month.
You can use CSS Grid to define spacing in buttons and links
In the article “Let’s Bring Spacer GIFs Back!” Josh W. Comeau argues for using a “spacer” <span> element instead of a simple CSS margin to define the spacing between the icon and text of a button component.
In our home-button example, should the margin go on the back-arrow, or the text? It doesn’t feel to me like either element should “own” the space. It’s a distinct layout concern.
CSS Grid is an alternative to such spacer elements. For example, the “Link to issue” link in CSS-Tricks’s newsletter section contains two non-breaking spaces ( ) to increase the spacing between the emoji character and text, but the link could instead be turned into a simple grid layout to gain finer control over the spacing via the gap property.
Websites agree that the pointer cursor is not just for links
The CSS Basic User Interface module defines the CSS cursor property, which allows websites to change the type of cursor that is displayed when the user hovers specific elements. The specification has the following to say about the property’s pointer value:
The cursor is a pointer that indicates a link. … User agents must apply cursor: pointer to hyperlinks. … Authors should use pointer on links and may use on other interactive elements.
Accordingly, browsers display the pointer cursor (rendered as a hand) on links and the default cursor (rendered as an arrow) on buttons. However, most websites (including Wikipedia) don’t agree with this default style and apply cursor: pointer to other interactive elements, such as buttons and checkboxes, as well.
Another interactive element for which it makes sense to use the pointer cursor is the <summary> element (the “toggle button” for opening and closing the parent <details> element).
Browsers delay autoplay until the video comes into view
Compared to modern video formats, animated GIF images are up to “twice as expensive in energy use.” For that reason, browsers have relaxed their video autoplay policies (some time ago) to encourage websites to switch from GIFs to silent or muted videos.
<!-- a basic re-implementation of a GIF using <video> --> <video autoplay loop muted playsinline src="meme.mp4"></video>
If you’re using <video muted autoplay>, don’t worry about pausing such videos when they’re no longer visible in the viewport (e.g., using an Intersection Observer). All major browsers (except Firefox) already perform this optimization by default:
<video autoplay> elements will only begin playing when visible on-screen such as when they are scrolled into the viewport, made visible through CSS, and inserted into the DOM.
Chrome introduces three new @font-face descriptors
Different browsers and operating systems sometimes use different font metrics even when rendering the same font. These differences affect the vertical position of text, which is especially noticeable on large headings.
Similarly, the different font metrics of a web font and its fallback font can cause a layout shift when the fonts are swapped during page load.
To help websites avoid layout shift and create interoperable text layouts, Chrome recently added the following three new CSS @font-face descriptors for overriding the font’s default metrics:
ascent-override (ascent is the height above the baseline)
descent-override (descent is the depth below the baseline)
line-gap-override
@font-face { font-family: Roboto; /* Merriweather Sans has 125.875px ascent * and 35px descent at 128px font size. */ ascent-override: calc(125.875 / 128 * 100%); descent-override: calc(35 / 128 * 100%); src: local(Roboto-Regular); }
The following video shows how overriding the ascent and descent metrics of the fallback font (Roboto) to match the same metrics of the web font (Merriweather Sans) can avoid layout shift when swapping between these two fonts.
A surprisingly common response when asking people about things they’d fix about anything in CSS, is to improve the handling of viewport units.
One thing that comes up often is how they relate to scrollbars. For example, if an element is sized to 100vw and stretches edge-to-edge, that’s fine so long as the page doesn’t have a vertical scrollbar. If it does have a vertical scrollbar, then 100vw is too wide, and the presence of that vertical scrollbar triggers a horizontal scrollbar because viewport units don’t have an elegant/optional way of handling that. So you might be hiding overflow on the body when you otherwise wouldn’t need to, for example. (Demo)
Another scenario involves mobile browsers. You might use viewport units to help you position a fixed footer along the bottom of the screen. But then browser chrome might come up (e.g. navigation, keyboard, etc), and it may cover the footer, because the mobile browser doesn’t consider anything changed about the viewport size.
On the left, the browser navigation bar (considered browser chrome) is covering up the footer making it appear that the footer is beyond 100vh when it is not. On the right, the -webkit-fill-available property is being used rather than viewport units to fix the problem.
And a solution of sorts:
body { min-height: 100vh; /* mobile viewport bug fix */ min-height: -webkit-fill-available; }
Does this really work? […] I’ve had no problems with any of the tests I’ve run and I’m using this method in production right now. But I did receive a number of responses to my tweet pointing to other possible problems with using this (the effects of rotating devices, Chrome not completely ignoring the property, etc.)
It would be better to get some real cross-browser solution for this someday, but I don’t see any issues using this as an improvement. It’s weird to use a vendor-prefixed property as a progressive enhancement, but hey, the world is weird.
