What's new in Web UI

Key Takeaways

Hi everyone and welcome to the 2026 edition of what's new in web UI. This talk has become a bit of a staple here at IO and as always there are a lot of exciting updates to talk about. I'm Yuna, a developer relations engineer who is leading efforts on web APIs that make the web feel like a more high quality experience. >> And I'm Ramus, also with Chrome Devril. And I'm focused mainly on CSS related features such as scrolling interactions, animations, and the intersection of both. And today we are very excited to talk to you about the latest updates to everything web UI. From new capabilities for view transitions to natural gesture interactions, theming capabilities, and so much more. >> For the past year, we've been focused on how can we actually improve the user experience of the web and been focusing on shipping capabilities that make the web feel a lot more high quality while making it easier for developers to build for. This shift is about more than just aesthetics. It's about how your site interacts with your users, how they scroll, how they morph between views, and how they communicate with their devices in more physical and intuitive ways. As a guide, we've identified five core UX principles that frame the ideal modern web experience. >> And those principles are these five right here. respect user preferences, implement natural interactions, provide guided navigation, maximize content, reduce noise, and adapt to the form factor. Now, we'll dig into all of these principles and what they mean in this talk. We'll show you modern UI patterns that use new APIs to meet these principles, ensuring your layouts fundamentally adapt to the user, the device, and the input methods. And if that wasn't enough, we're also going to take a look at an entirely new paradigm for web development, HTML in canvas. Some of you may have seen demos of this online, and it's huge. This allows you to bring real accessible DOM content directly into your canvas-based experiences, bridging the gap between high performance graphics and the semantic web. It's time to raise your expectations of what the web can do. So, let's get started. >> Make sure you're comfortably seated because we're about to show you a whirlwind of features. We're going to show a lot of links throughout this talk pretty quickly. So, get your phones ready to take some photos. And for every feature shown, we will include a compatibility table that looks like this. Shown at the left there is the baseline indicator. And that one indicates whether the feature is baseline widely available, newly available, or limited available. >> Browser versions when the feature became available are shown inside of the circle. If the circle is green, that means that it's available in a stable release. Orange if a feature is available in an experimental version, and red means that the browser currently has no support for that specific feature yet. So with that out of the way, let's talk about user experience on the web. >> Our first principle here is the one of the most fundamental for web usability, namely respect user preferences. This is all about building trust and improving accessibility by adapting to your user system level choices. Whether that's honoring light or darks or automatically toning down animations when the user has requested reduced motion. And rather than requiring users to locate some obscure preferences menu somewhere, your website should already automatically adapt to their existing operating system settings. And even though these concepts feel elemental and we've been talking about them for years now, there are actually a few new APIs out there that make this dynamic personalization easier to build for. For example, the light dark function, contrast color, and style queries. Let's take a look at an example. In this demo, you see a few cards with different themes within the same global design system. In light mode, they use shadows as an elevation mechanism to make them appear above the rest of the page. In dark mode, the shadows are removed and instead we see a neon border with a lighter background to show the elevation. And you can see the emulation of light and dark here being set in DevTools. This is a common approach in design systems, but it's still relatively complex to build today. But like Brahmis mentioned, there are a few new APIs that are making this much easier. So, let's get started with the first piece here, and that's an API that I'm really happy to see land, which is contrast color. This API recently shipped in Chrome as a part of Interop 2026, making it baseline newly available in all modern browsers. Contrast color is a CSS function that takes the value of a background color and returns either black or white depending on which has higher contrast against the input color value based on the WCAG2 algorithm. It's currently limited to this contrast algorithm, but we hope that developers will have more options in the future. The function is also currently limited to outputting black or white, but in a minute we're show we'll show you how to combine contrast color with style queries to really expand your color palette. The next piece of the puzzle here is the light dark function. And this function is a CSS utility that allows you to specify two different color values. One for light mode and one for dark mode. And this all within a single declaration. By providing the light value as the first argument and the dark one as a second argument, the browser automatically selects which color to use based on the current color scheme. And a recent spec change to light dark extends it by also accepting images. Instead of passing into color values, you now can pass in two image values, one for light and one for dark. And this change is set to land soon in Chrome 150. But if you already want to use this type of capability today, there is an alternative solution. >> Yes, and that solution relies on two other CSS capabilities. CSS custom functions and style queries. When combined, you can create custom light dark functions that work with any type of value. To make this work, you first need to store the color scheme value in a custom property like d- scheme as shown here on the left. By default, this is set to light, but when the operating system is set to dark, the value is set to dark. Then inside the custom function shown here on the right, you can conditionally set the result to either the light or dark argument. By default, this is set to the light value. But again, when d- scheme now is set to dark, the dark value is used. And this is done using a style query. Finally, similarly to how you would call the native light dark function, you can now call your custom light dark function without any limitation on the type of value that you use. >> Now, as with all container queries, you are limited to styling a child based on a parents value. But if you want to style the element itself, you can throw in a third new language capability into the mix, and that is the if function. And this function gives you a way to write conditional logic right inside of a properties value. If the reported scheme is dark, the result is set to the value of the dark argument and otherwise the result is set to the light value. You can find out more details on add function and if by visiting the link or give episode 92 of a CSS podcast a listen. And if you haven't heard of the CSS podcast, definitely check it out. You might hear some familiar voices. So, getting back to the original demo, let's combine all of these modern CSS capabilities, contrast, color, style queries, and light, dark, and bring them all back to customize our elevation style and color palettes. So, here you can see that the elevation mechanism works using a function too, swapping between the shadow or neon glow depending on the color scheme using the light dark function. The theme colors are set up using style queries and the contrast color function is used to identify the ultimate color chosen. The result of that function is either black or white. So when you store that into a custom property, you can treat it like a boolean and use style queries shown here with the if function to map the result to any value. CSS is getting really powerful. Contrast color enables you to separate the pages color scheme from the local card theme and style queries gives you the flexibility uh in the output value. So here you can have a lighter background on a card in a dark mode or in a light mode. But assuming that you've tested all the color pairs, you'll always have proper color contrast making this theme quite dynamic. To give you even more control over your customization, the CSS working group recently resolved on adding an at supports query for at rules like at container, at property, and at function. You call it using the at rule function after at supports, placing the actual at rule string to check against browser support like at function inside of it. A final detail when visiting this demo and one that some of you will never even notice is that this page respects the user's font size preference as set through the accessibility features of the operating system. It's a simple tweak but one with a large impact because recent data shows that over 30% of both user of users both on Android and iOS have changed their default font size in the system settings. Now to add this functionality to your website, there is a new metatag named text scale and it's available in Chrome 146. If you set the value to scale, you tell the browser that your site can handle these increased font sizes. And when applied, the font size of the HTML element is then determined by the operating system. So there is no need for you to set up a base font size. And if you then use lengths with relative units like m and rem, those computed pixel values are then based off of that base font size. So to test this all out while building your website, there is an option in dev tools to emulate this. Um you can find it in the rendering tab and then use the drop down to change the value. >> Okay, now that we've talked about personalization and gone over some new architectural primitives in CSS, let's move on to our next principle, implementing natural interactions. And by natural, we mean that you should make interactions feel intuitive and physical, not robotic. Motion should be meaningful, and the animation should originate from the point of interaction and use a physics-based easing. The goal here is to create tactile experiences that feel as natural as a native app. But what exactly does that look like? And how are we making it easier for you to build these experiences? The first UX pro tip in this area is to use natural easings and physics where you can. Here's an example of a dialogue that combines a few techniques to achieve a nice natural effect. While we don't yet have true spring animation effects and easings on the web, this demo uses the linear easing function to approximate a bouncy animation. This code might not look very human readable, but it allows a nice bounce effect with a slight overshoot by letting you customize an easing curve by providing an unlimited number of values, typically between zero and one. But you can also build tools to make this easier for yourself. For example, I built this quick linear easing generator to help me wrap my head around using the linear easing function and configure it with the language that other tools use for physics like stiffness, damping, mass, and velocity. The next thing you might notice with this demo are the entry and exit animations. The dialogue here nicely slides up when it gets shown and it slides back down when it gets hidden. And this is done using at starting style to set the pre-animation styles and then the open attribute on the dialogue to set the target styles. And the animation itself is done with CSS transitions and allow discrete. For more details on this as well as like general best practices on timings and easings, go check out my talk from last year which is called oo I hit the wrong button here. Yes, which is called web animations today and tomorrow. The talk covers starting style transitions, CSS animations and view transitions. And another nice detail in this demo here is the staggered entry effect of the content inside of the dialogue. And this is done using the sibling fun sibling index function which returns a number that is equal to the position of the element within its ancestor subree. So it's a number that counts up from one to however many siblings there are. And here that sibling index is multiplied by 0.0. 05 seconds to create the staggered delay on the animations. >> Another piece that you may have noticed here in this demo is that it uses a modal dialogue. And here is what that modal dialogue might look like in a real world context. When you show a dialogue modally, you get a few key benefits. First, when the dialogue is open, the rest of the page is inert and focus is automatically managed. On state changes, screen readers can also correctly identify and describe the UI. As of Chrome 134, the dialogue element has adopted some of the nicities of popover, including declarative light dismiss. This means that by using closed by equals any when a user clicks outside of a dialogue or hits the escape key or uses a back gesture, it will close without any additional scripting required. This is a very nice addition that prevents folks from reaching for a popover when really semantically they should be using a dialogue. So now you can get all of these nice benefits for native browser native UI, declarative light dismiss supported with native entry and exit animations, and it's all done in your CSS right along with the rest of your styling logic. >> Finally, one last detail to highlight here are the beveled corners. And this effect used to require you to clip the element in CSS, which meant that you lost access to things like shadows and outside borders. But now we have a CSS property that makes this much simpler, namely corner shape. And corner shape does what it sounds like it does. It lets you change the shape of the corners of any element. And where before you could only do rounded corners, now there's a lot more options, including scoop, bevel, notch, and even the popular squirrel. And to use this, you you still set the radius with border radius, but now you get so many more options. And the values are animatable as well. And this is just like one of these nice little things that make your UI feel much more unique and also can be a nice progressive enhancement from rounded corners. >> Yes, natural interactions are just the start of what you can do on the web to make your applications feel more high quality. And the next evolution of that is really thinking about guiding the user journey, helping them maintain context and understand the application's flow. In a digital space, users don't get the benefit of physical cues like walls, doors, or depth of field when they navigate. Without these, it's all just a series of flat pages connected through a single URL bar. Disorienting page reloads, losing your place when you hit the back button, and the jarring disconnect of staring at a blank screen while a new page loads all make for poor user experiences. And the sad thing is, we've all just kind of grown used to this. But it doesn't have to be this way. We've been working hard on making animation transitions smoother, upgrading view transitions, shipping new declarative streaming and routing capabilities, and even providing new primitives for helping your user navigate within your page scroller. >> Yes, and view transitions are the perfect tool to create these seamless transitions. And it's a feature that just keeps getting better over time. Back in 2021, we announced the first prototype for what eventually became known as same document view transitions, a feature that is now baseline widely available since 2025. And we expect a cross document counterpart, which lets you run a view transition between two different documents to also be available in every browser engine this year thanks to interop 2026. Now, don't let this browser support table stop you from adopting view transitions today. Google search, for example, is already heavily relying on view transitions and they are treating it as a progressive enhancement. And here's one of their experiments that uses view transitions links linked to gestures when the bottom sheet is getting dragged. Instead of having the view transition animation sticks forward using wall clock time, they are instead controlled by a drag gesture. And furthermore, the search team has also optimized these animations so that they can be hardware accelerated. Pretty sweet, right? >> I like this a lot. It's pretty cool. So to let you easily build advanced interactions like this yourself, my colleague Brahmis here has created a convenient utility library called the view transitions toolkit. This toolkit contains a bunch of helper functions for creating view transitions interactions. For example, one of the functions provided by the toolkit is a function to optimize a key frame for a view transition group pseudo. When applied, the group pseudo animates using a scale and translate animation instead of the default width and height animation created by the browser, enabling you to build hardware accelerated view transitions. The result is an animation that isn't subject to jank whenever the main thread gets blocked. Another set of functions from the toolkit are the play, pause, and scrub functions. If you use those in, let's say, scroll event listeners, you can build a scroll driven view transition like the one shown in this demo. You can get really creative with this. Combined with pointer down, pointer move, pointer up, you can build a dragable view transition. Or maybe you want to sync a view transition with a video playing. Why not? That's all possible. So check out the toolkits homepage for more demos to inspire you and documentation to explore. A new sub feature of view transitions and one that I personally find very exciting is the addition of element scoped view transitions. And instead of starting a view transition that covers the entire document, you can now start a view transition on a sub tree of the DOM while keeping the rest of the page interactive. Yes, you are hearing this right. After four years of talking about it, we got all the necessary foundations in place, got all the details sorted, and we have shipped this in Chrome 147. And this demo right here extensively relies on element scope due transitions. When adding one of the cards to the selection list, a scope transition is started on only the sidebar, meaning that I can still hover and interact with the other cards while the animation is running. Or when filtering the list of items, a scope due transition is started only on the grid, while other elements such as a navigation bar and the drop downs also remain interactive. To start an element scope due transition, it's really easy. Instead of calling document start view transition, you now call start view transition on a specific element. And the result here is a view transition that runs in isolation. It only scans that sub tree with a view uh with for elements with a view transition name. And the resulting view transition pseudo gets injected only onto the scope the scope route itself without blocking the rest of the page. And additionally, the group pseudos are automatically nested and the overflow of the enclosing group children pseudo is clipped when needed. What enables this isolation? Yeah, this is a big deal. Honestly, what enables this isolation is the effective application of view transition scope all to the scope route for the duration of the transition. And this is done automatically for you when starting a scoped view transition on an element. This declaration ensures that view transition name values don't bleed out of the scope root subree and it also prevents an element from being captured by an outer view transition. This allows for multiple view transitions to run at the same time as well as the nesting of view transitions. So while the items in these lists are getting shuffled, you can also swap the lists themselves, which is pretty cool. Scope view transitions are perfect for micro interactions and inpage staple morphing, giving the user more context when there is a visual change. This is a great way to enhance the usability of your application while also elevating how it looks and feels. These are the little things that make a big difference. And it's so much easier to do this now with view transitions, especially scope view transitions and a little bit of CSS. It really does feel like magic sometimes. Check out our article on developer.chrome.com for more information about element scope view transitions. >> And we're not done with view transitions yet. Something that Chrome engineering is prototyping right now is a feature called two-phase view transitions. And these allow you to immediately kick off a cross document view transition without waiting for the new DOM to be ready. And to do this, the two-phase view transition will first transition into any kind of intermediary UI such as a skeleton screen or a loading spinner before proceeding with the cross document transition. Now, the API is still under heavy development, but if you can't wait to get a feel of it, you can try it in Chrome Canary with the experimental web platform features flag enabled and check out the link for more info. Of course, >> these are so many great updates. I've definitely wanted that for a while. Another way to provide guided navigation for your users is by using scroll driven animations. A feature that landed in Chrome in 2023 and is on its way to becoming interoperable thanks to Interop 2026. To jog your memory with scroll driven animations, the animation's progress is linked to the scroll position of a scroll container. This means that as you scroll up or down, the animation scrubs forward or backward in direct response. You can use this for effects like a parallax background images or reading indicators that fill in as you scroll. And this feature is directly improving performance for some of our partners already like Cyosu who cited that they were able to improve performance and decrease the main thread cost of handling scroll events by 73% by using scroll driven animations. New in Chrome 145 are scroll triggered animations. And these are timebased animations that trigger when entering or exiting a specific scroll range. And scroll triggered animations are great for building scrollytelling experiences as they transform a passive reading habit into an immersive interactive journey that keeps user physically engaged with the narrative. And we see this type of experiences all over the web. And now because yes we built this into CSS you can say goodbye to intersection observer or any third party library for this type of effect. And the underlying mechanism here are timeline triggers which are either active or inactive. In this code snippet the trigger-t is created and it's using a view timeline with two ranges. Now when I flip on the visualizer it becomes a bit more obvious what's to happening. Um the first range is the activation range and it determines when the trigger should become active. And then the second range is the active range which determines how long it should remain active. And this trigger is then used as the animation trigger for a regular CSS animation. And here the animation is set to play forwards when the trigger becomes active and the animation will play backwards when the trigger no longer is active. To learn more about scroll triggered animations, the activation and active ranges, or to check out some more demos, go find our article on developer.chrome.com. >> Another common pattern to help users keep track of where they are in a page is this so-called scroll spy. This pattern popularized by Bootstrap automatically updates the navigation links based on the user's scroll position to indicate which link is currently active in the scroll port. Typically, this has been implemented in JavaScript, but as of Chrome 140, you can do this with just two lines of CSS. Similar to the JavaScript implementation, you start off with a set of inpage links that link to specific subsections of your DOM through ids, but instead of throwing a bunch of JavaScript at it, you enable the scroll spy by setting scroll target group to auto. Whenever one of those sections is visible inside of its scroll port, the Arya current on the corresponding link is automatically set to true and they get the target current pseudo class applied to them, which allows you to style them however you want. With target current as a styling hook, you can pretty much do anything like adding a little anchored pointer to guide users or simply styling the typography of the active section. When offering guidance for inpage navigations, it can also be useful to use smooth scrolling. You can do this in CSS with scroll behavior smooth or you can also use JavaScript scroll into view. And new to scroll into view is an option named container. If you set it to nurse, it only scrolls a target element scroller instead of bubbling up through all ancestor scrollers. And in this demo here, you can see it in action. Whenever I press one of the dots, it calls scroll into view. But as you can see, it also scrolls vertically, which is pretty much disorienting. Now, when I flip on the nearest option, you can see that it now only scrolls a horizontal scroller, which results in a much better experience. And speaking of scrolling to view, again, a new addition to the platform and one that is available now in Chrome is that all programmatic scroll methods now return promises, so you can await them. And here's a demo. The element is first scroll into view after which a highlight effect is added to it. And with that, it's a wrap for this third principle on guided navigation. On to the fourth one. >> And this one is all about reducing noise and clutter. One thing that can ruin an otherwise awesome web experience is just too much clutter. Even if you've done everything else right, awesome morphing transitions and beautiful theming. If I see a content blocking popup when I first land on your page, there's a pretty decent chance that I'll just click away. And this is a big problem on the web. So, this principle is focused around a more focused user experience, pun intended. Prioritize the user's content by eliminating visual clutter and application borders. Avoid intrusive pop-ups and banners that obscure the screen. And use layered UI patterns for secondary content. There's a lot that you can do here. And the first one is one of my current favorite progressive enhancements that I immediately shipped on my personal blog when it became available. And that would be the new scroll state query named scrolled. And this state query lets you detect the direction of the most recent relative scroll. For example, if you last scroll towards the bottom of a scroller, the reported value would be bottom or the logical variant block ends. And this scrolled state query allows you to build a pattern that we like to call the hidey bar. when you are scrolling or half scroll towards the end of the page, you want the header or navigation bar to to hide itself, but only when you're scrolling back up the page again, you want the header to reveal itself again. And the code behind this demo looks like this. First, it sets up a scroll state container on the HTML element. Now, by default, the header is visible, but when you scroll down, it gets placed out of view using that scrolled state query. And lastly, the animation part is handled by a regular CSS transition. Another example of how to optimize the content area for users is to move secondary content and actions behind layered UI. And these could be dialogues, offscreen menus, tool tips, and additional for additional context and more. But we also need to make sure that we build these things right. And even just purely visually, there is a lot of considerations that are involved in getting it right. So take a look at this tool tip. In this example, we have an anchor position popover which repositions itself based on its fallback position and its position in the viewport using anchored container queries. When the tool tip is open above the invoker, it animates bottom up from the source. When it is open below the invoker, it animates top down. But that's not the only change we see. The arrow that visually connects the tool tip and its invoker also changes position and direction. This arrow is created using the new shape and border shape APIs. To create the arrow at the bottom center, it looks a little something like this, which like the linear easing function is a little hard to wrap your brain around. So to help me build the code for this demo, I also vibecoded a tool to produce the output shape that I expected for the border shape. This is just a visualizer for how much you can do with shape and border shape. It lets you change the visual geometric border of any element and remain responsive. Border shape is really powerful. You can create all sorts of shapes, not just at the corners like corner shape, but anywhere inset or outset and have the border, outline, shadows, all visually aligned. Something that you couldn't do with clipping masks and goes way beyond what you can do with just corner shape. And as a bonus, as of Chrome 149, another neat thing that you can do with shape is use it as a value for the shape outside property. So you can create organic geometric non- rectangular UIs and boxes which content can float against. And it's supports animation both in shape and shape outside. >> I like this. Now when an uh when maximizing the content of a big data table, you also want to respect the guided navigation principle. And a common approach for this is to make use of a sticky positioning for a sticky column and a sticky top row. But if you ever try this, it doesn't work. Um that is because either the column or either the row here will only be sticky. So it's one of both. And this is because position sticky only looked up the nearest ancestor scroller for the sticky container. Now, if that scroller only scroll on one axis, like here it's only scrolling horizontally, that would prevent the stickiness on the other axis from working. Now, a recent change to CSS makes this now possible as position sticky can now track two different scorers, one for each axis, and this change is available for testing in Chrome 148. The visual outcome is a sticky first column and sticky first row that now work as expected. the first column sticks to the left of the page and the top uh in the top row there sticks to the top of the page. Now, one thing to note here that in order to make this work properly is don't just set overflow x on the wrapping element to scroll or auto because the overflow y will then also compute to auto. So, you would end up with a 2D scroller. The thing you must do here is explicitly set the other the other axis to clip its contents and then it'll work. What we often overlook as web developers is the form factor from which our users access our websites or apps. So our final principle is all about adapting to that form factor. We design on a desktop, code on a desktop, and resize the window to appear smaller on a desktop while we test our mobile designs. And this gets us part of the way there, but it doesn't really cover everything. And one thing that it doesn't quite cover is the modality with which users interact with the UI. So on desktop that might be a keyboard or a mouse. But on mobile devices that is often usually through touch. And while on a desktop we're used to clicking on a little button to open and close a menu, on a mobile device looking for that little icon button just becomes cumbersome when we're so used to being able to swipe something open and closed. Layouts should fundamentally adapt to the device and input method too. Whether that's a virtual keyboard that's open or even just to touch target sizes. And currently building a gesture-driven interface is a hassle to implement on the web. You need to add a bunch of event listes for both the mouse but also the touch interactions. But then those sometimes compete with the native scroll gestures. So you need to figure that out as well. And then some more code to build in scroll momentum and snapping back again. It's a lot of code and a very uncanny result. But now we have a new API in the works that is making all of this a lot easier and it's called overcroll gestures. It leverages the existing principles of scrolling and overflow areas and it allows you to declaratively create gesture-driven interfaces that feel as natural and intuitive on the web as they would on any app you use. And one of the benefits of using overcroll areas over adding these event listeners is that it is that this API works with any input method touch or scroll and it feels native to the platform you're using it on. >> Let's take a look at a common example, an overlay menu. You click a button to open and close it, but on touch devices, it should just be easy to swipe it closed. The activation mechanism here is via an HTML attribute, but given that this API is a work in progress, the exact code might change over time as the feature progresses. First, the container needs to be identified as supporting overcroll areas by adding the overcroll container attribute. Then you would use a command like toggle overcroll on a button like so to trigger the toggle open event. The button requirement is also something that is currently in discussion but enables the input to be accessibly tied to an event invoking element. You would then connect this to an element inside of the overcroll container using its ID in this case menu and the command for attribute. Command invokers are really powerful and it's a pattern that I like seeing expand to new web platform capabilities. Finally, with a bit of CSS, you can position the overcroll elements. So here, the menu is positioned to the left of the content. So that's really it for the core of how to make this work. Now the overcroll API will take care of the rest. We have a light dismissible swipeable modal menu that can be triggered either from a button or from a user's scroller swipe. So, it's pretty dynamic. And in case you're wondering, yes, this API also comes with a few JavaScript life cycle events, including events for when the overcroll interaction start, changes, ends, or is canled. And this allows you to create more complex interactions. The API is still a work in progress, but we're excited to hear your feedback on it as it evolves. So, if you want to participate in the conversation, head over to open UI and peruse the open issues, providing your thoughts online or join us in person. >> And if you thought that all of that new CSS and HTML was gamechanging, then hold on to your hats because this next feature is one of those rare moments where a new capability really shifts the paradigm of what you can do on the web. If you've ever built anything in an HTML canvas, whether that's a shader with WebGL or even an infographic, then you know that the canvas is essentially a black box to the browser. It's not parsible by the page that it lives within. But now, for the first time ever, you can have real DOM content inside of the canvas with the new HTML and canvas API. Yes, this means real elements in your canvas that are searchable, accessible, selectable, translatable, and inspectable. And that also means that everything that we just walked through in this talk is also available in canvas. This means that you can create entirely new types of UI where you no longer need a DOM overlay for accessible content or you can create forms within a canvas. You can apply WebGL filters to text that you can interact with as they're real UI elements and you can keep that text highlightable, copy pasteable, and even preserve forms that work with built-in browser features like autofill. The community has already been creating some incredibly creative demos with HTML and canvas like this 3D web page by Santiago Colombato and these fun wobbly button effects by West Boss. Popular libraries like 3JS also have already implemented native support for HTML and canvas primitives too. This feature is a big one. It means an entirely new way of building web experiences that fuses shaders and semantics. Even a simple button or slider like this one can be taken to the next level. The possibilities really are endless. From 3D web UI to incredibly detailed shader effects and interactions to making your 3D game accessible and translatable by the browser, we've got a bunch of demos from our team live now on chrome.dev/htmlincvas where you can try it out yourself. >> Let's take a look at some code to get you started with HTML and canvas. The first thing you need to do is to set the layout sub tree property on the canvas element you're painting into. And this causes the browser to be aware of the content inside of the canvas element. It lays them out, set them up for hit testing, and exposes them to systems like accessibility and other browser features. Now, putting the element in the markup is not enough though. Inside of the paint event, you need to draw the element in the canvas by calling draw element image. And the result you get back from this is a transform, which you then write back to the styles of the element. There are equivalent methods for WebGL and WebGPU to paint these elements into textures as there are so many more things you can do with it. This API is definitely worth checking out and getting your hands on because it is so cool. You can learn more about it from this virtual session on HTML and canvas by our colleague Thomas. And as Yuna mentioned, be sure to check out chrome.dev/html andvas for more demos. Before we wrap things up here, there are a few additional features that are so good, we wanted to give them their own little moment here at IO. So, let's do a lightning round. Who doesn't love a lightning round? Are you ready? Promise. >> Yes. The first feature we want to highlight here is the DOM state preserving move. When you move an element in the DOM using insert before, you are performing a destructive action. For example, moving a playing video in an iframe using insert before they reload and they lose their state completely. And that changes with move before which got added to Chrome in Chrome 133. You use it exactly like insert before. But the key difference is that it keeps the content alive during the move. So this means that videos keep playing, iframes don't reload, CSS animations don't restart, and input fields keep their focus as you are reparenting them in the DOM. Another neat feature coming to Chrome soon is fit text. This capability unlocks the ability to precisely fit lines of text to the exact width of their containing element. This feature dynamically scales the font size itself, ensuring these text lines are seamlessly aligned with both the left and right edges of the container. In this case, we're using the grow value to allow the lines of text to increase in size to have a visually balanced and justified appearance through size scaling rather than just flowing onto the beginning of the next line. Next up is text box. And this property lets you tailor the spuff the space above and below the text. Designed to help you center text vertically. The textbox trim property specifies which side to trim, above, below, or both. and the textbox edge property specifies the metrics to use for that trimming. >> A feature that was built by Microsoft, shout out to the Edge team, and that is available in Chrome 149 are gap decorations. These allow you to style the gaps in container layouts like grid and flexbox. No more messing with borders or pseudo elements to style the rules between the rows and columns anymore. Instead, you can use the row rule and column rule properties to do so. You can give them a width, a color, an inset, a style, and so on. Check out the new blog post on developer.chrome.com from their team to learn more. Onto scroll bars. As of Chrome 145, the viewport units are now scroll bar aware, so you can say goodbye to unnecessary horizontal scroll bars when using a value like 100 VW. lengths using the VW now automatically subtract the size of the vertical scroll bar but only under the condition when a scroll bar or its cutter is guaranteed to be visible on the root element and you can force this scroll bar by setting overflow Y on scroll on the root or reserve space for it using a scroll bar gutter stable declaration and of course the same applies to VH lengths with a horizontal scroll bar as well as the large small and dynamic viewport units. Lastly, pseudo elements are finally getting exposed properly in JavaScript. JavaScript events like click now expose an extra property with information about the pseudo element that triggered the event. If you read the value of the event pseudo target, you get back a CSS pseudoelement instance or null if there was no pseudo element involved. You can also get access to pseudoelements using element.seudo. I'm happy this is finally coming to the web. And that's it for this lightning round. Yes. So that's it for this lightning round. The features we mentioned here are only a selection. You can expect many more features to come to Chrome throughout the year because our engineers keep pushing the web forwards and currently they are actively prototyping features such as a native menu element, filterable select elements, responsively sized iframes and tweaks to scroll access locking and so on. So yeah, there's a lot more good stuff coming your way this year. >> Yes, it's such an exciting time to be a web developer. You can create well pretty much anything these days. So, when in doubt, remember the principles that we just went over and remember how much you can do with the web. Respect user preferences, implement natural interactions, provide guided navigation, maximize content, reduce noise, and adapt to the form factor. >> And speaking of the times, we would be remiss not to mention the tooling we've been working on to make it easier for you to adopt these latest and greatest modern web capabilities. And that's why we just announced modern web guidance. It's a curated collection of skills, tools, and AI ready documentation that injects Chrome's web platform knowledge directly into your AI workflow. >> These guides are internally tested, benchmarked, and adhere to modern best practices. They integrate with baseline data and include all dedicated fallback recommendations. So your agent can implement modern CSS, HTML, and JavaScript in a way that is compatible across browsers without you having to do all of the research yourself for every new feature. This is just going to save a lot of time for everyone. I think and as usual, to learn more about modern web guidance, check out the link here or the video on the Chrome for Developers YouTube channel. I know that that was a lot of links and resources that you might want to dig into now after this talk. So, let's wrap it up. >> We are very aware that we throughout this talk, we've shown you a ton of resources to dig into here. But that's only because the modern web gives us so much to work with. So, there's so much to love about we can build today. And the best part is you already have the tools to create these amazing experiences faster than ever. So, take these resources, get out there, and go make some magic. Yes, we can't wait to see what you build. Thank you so much.