 You can now specify a crop area when using GetDisplayMedia to capture the current tab. Media query syntax can now be written using mathematical comparison operators. Shared element transitions start a new origin trial. And there's plenty more. I'm Pete LaPage. Let's dive in and see what's new for developers in Chrome 104. GetDisplayMedia makes it possible to create a video stream from the current tab. But there are times when you don't want the whole tab. You only want a small portion of it. Until now, the only way to do that was to manually crop each frame. With Region Capture, a web app can define the specific area of the screen that it wants to share. For example, Google Slides could allow you to share the current slide and no need to switch to the presenter view. To use it, select the element to share. Then create a crop target based on that element. Next, start screen sharing by calling GetDisplayMedia. That prompts the user for permission to share their screen. Then call track.crop2 and pass the crop target created earlier. More details and a demo about Region Capture are on developer.chrome.com. Media queries are critical to responsive design, allowing you to define specific styles for different size viewports. But unless you use them every single day, the syntax can be a little confusing. Chrome 104 adds support for media queries level 4 syntax and evaluation, allowing you to write media queries using ordinary mathematical comparison operators. So instead of something like this to indicate a viewport between 400 and 600 pixels, it can be written like this. In addition to making media queries less verbose, the new syntax can be more accurate. The min and max queries are inclusive. For example, min width 400 px, test for a width of 400 pixels or greater. The new syntax allows you to be more explicit about what you mean. It's already supported in Firefox and there's a post CSS plugin that will rewrite the new syntax to the old syntax, ensuring browser compatibility. Check out Rachel's article on developer.chrome.com for more details. Platform specific apps typically have smooth transitions between different views. They look beautiful, they keep the user in context, and they help the experience to feel more performant. Whereas on the web, a full navigation means a momentary blank screen. For a single page app, it can be better, but transitions are still hard. Shared element transitions starts a new origin trial in Chrome 104, allowing you to provide smooth transitions, regardless of whether transitions are cross document or intra document. Here's a rough example of how transitions work for a single page app. In the navigate function, get the new page content. Check if transitions are supported. If not, update the page without the transition. Then create a transition and start it, letting the API know when the DOM change is complete. Under the hood, shared element transitions use CSS animations. So you can change from a fade in effect to slide in or whatever you want. And I've just scratched the surface. So check out Jake's video, bringing page transitions to the web. Of course, there's plenty more. When cookies are set with an explicit expires or max age attribute, the value will now be capped to no more than 400 days. There are enhancements to the multi-screen window placement API. And the overflow clip margin property specifies how far an element's content is allowed to paint before being clipped. All the details, including links, stocks, and specs are in the post linked in the description. Hit the subscribe button now so that you don't miss any of the latest Chrome DevTools videos, GUI challenges, HTTP203, and more. I'm Pete LaPage, and as soon as Chrome 105 is released, you're right here to tell you what's new in Chrome.