Bramus
@bram.us
Chrome DevRel at Google (CSS + Web UI + DevTools). CSSWG Member. PADI Divemaster. Blogs at bram.us. Lives in Belgium.
They also allow you to group and isolate your code for those specific transitions using the `:active-view-transition-type()` selector.
I’m heavily relying on View Transition Types on page-transitions.style. The CSS is leveraging the types to isolate the styles for each type of transition.
I’m heavily relying on View Transition Types on page-transitions.style. The CSS is leveraging the types to isolate the styles for each type of transition.
November 24, 2025 at 9:25 AM
They also allow you to group and isolate your code for those specific transitions using the `:active-view-transition-type()` selector.
I’m heavily relying on View Transition Types on page-transitions.style. The CSS is leveraging the types to isolate the styles for each type of transition.
I’m heavily relying on View Transition Types on page-transitions.style. The CSS is leveraging the types to isolate the styles for each type of transition.
Here’s why I’m excited about View Transition Types: directional transitions.
Imagine clicking the next or previous page in a pagination sequence. Depending on whether you are going up or down the sequence, you might want to slide the contents in a different direction.
Imagine clicking the next or previous page in a pagination sequence. Depending on whether you are going up or down the sequence, you might want to slide the contents in a different direction.
November 24, 2025 at 9:25 AM
Here’s why I’m excited about View Transition Types: directional transitions.
Imagine clicking the next or previous page in a pagination sequence. Depending on whether you are going up or down the sequence, you might want to slide the contents in a different direction.
Imagine clicking the next or previous page in a pagination sequence. Depending on whether you are going up or down the sequence, you might want to slide the contents in a different direction.
JPEG XL in Chromium update:
“[...] we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance.”
groups.google.com/a/chromium.o...
“[...] we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance.”
groups.google.com/a/chromium.o...
November 22, 2025 at 7:57 AM
JPEG XL in Chromium update:
“[...] we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance.”
groups.google.com/a/chromium.o...
“[...] we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance.”
groups.google.com/a/chromium.o...
November 21, 2025 at 12:24 PM
Another upcoming change that might go unnoticed: Starting with Chrome 144, Anchor Positioning is going to be transform-aware.
From then on, anchoring will resolve against the bounding box of the transformed anchor.
Demo: codepen.io/bramus/pen/p...
From then on, anchoring will resolve against the bounding box of the transformed anchor.
Demo: codepen.io/bramus/pen/p...
November 20, 2025 at 9:59 AM
Another upcoming change that might go unnoticed: Starting with Chrome 144, Anchor Positioning is going to be transform-aware.
From then on, anchoring will resolve against the bounding box of the transformed anchor.
Demo: codepen.io/bramus/pen/p...
From then on, anchoring will resolve against the bounding box of the transformed anchor.
Demo: codepen.io/bramus/pen/p...
Here’s a recording of this “Two-Phase View Transition” concept.
The flow goes like this:
- Click a link
- VT into the loading screen
- Fetch the data of the new page in the background
- VT into the new page
The flow goes like this:
- Click a link
- VT into the loading screen
- Fetch the data of the new page in the background
- VT into the new page
November 19, 2025 at 10:06 AM
Here’s a recording of this “Two-Phase View Transition” concept.
The flow goes like this:
- Click a link
- VT into the loading screen
- Fetch the data of the new page in the background
- VT into the new page
The flow goes like this:
- Click a link
- VT into the loading screen
- Fetch the data of the new page in the background
- VT into the new page
That method itself would also be useful, in addition to `<input type=emoji>` :)
The reason I’m thinking of separate input is for the pattern in the screenshot. Clicking + allows you to pick _any_ emoji, on top of the predefined set. By having a dedicated input, you also get change events and stuff.
The reason I’m thinking of separate input is for the pattern in the screenshot. Clicking + allows you to pick _any_ emoji, on top of the predefined set. By having a dedicated input, you also get change events and stuff.
November 17, 2025 at 11:08 AM
That method itself would also be useful, in addition to `<input type=emoji>` :)
The reason I’m thinking of separate input is for the pattern in the screenshot. Clicking + allows you to pick _any_ emoji, on top of the predefined set. By having a dedicated input, you also get change events and stuff.
The reason I’m thinking of separate input is for the pattern in the screenshot. Clicking + allows you to pick _any_ emoji, on top of the predefined set. By having a dedicated input, you also get change events and stuff.
For limited options, the custom select would be a good solution indeed.
The thing I am thinking of is this one right here: on top of a set of predefined options, you can also chose _any_ emoji.
Instead of having to build your own emoji picker, it’d be nice to just trigger the native one.
The thing I am thinking of is this one right here: on top of a set of predefined options, you can also chose _any_ emoji.
Instead of having to build your own emoji picker, it’d be nice to just trigger the native one.
November 17, 2025 at 11:04 AM
For limited options, the custom select would be a good solution indeed.
The thing I am thinking of is this one right here: on top of a set of predefined options, you can also chose _any_ emoji.
Instead of having to build your own emoji picker, it’d be nice to just trigger the native one.
The thing I am thinking of is this one right here: on top of a set of predefined options, you can also chose _any_ emoji.
Instead of having to build your own emoji picker, it’d be nice to just trigger the native one.
This is the use case I am thinking of: a reaction picker with a predefined predefined set of options (custom select, or a popover) that also allows you to chose _any_ emoji on top.
Clicking that + would trigger the emoji picker.
Clicking that + would trigger the emoji picker.
November 17, 2025 at 11:02 AM
This is the use case I am thinking of: a reaction picker with a predefined predefined set of options (custom select, or a popover) that also allows you to chose _any_ emoji on top.
Clicking that + would trigger the emoji picker.
Clicking that + would trigger the emoji picker.
AFIK many reaction pickers offer a set of fixed choices, and can allow picking an emoji from the whole set.
See this Google Chat screenshot. I think that + icon there could be an `<input type=emoji>`, triggering the native emoji picker.
I think custom emoji are a related but separate problem.
See this Google Chat screenshot. I think that + icon there could be an `<input type=emoji>`, triggering the native emoji picker.
I think custom emoji are a related but separate problem.
November 17, 2025 at 10:56 AM
AFIK many reaction pickers offer a set of fixed choices, and can allow picking an emoji from the whole set.
See this Google Chat screenshot. I think that + icon there could be an `<input type=emoji>`, triggering the native emoji picker.
I think custom emoji are a related but separate problem.
See this Google Chat screenshot. I think that + icon there could be an `<input type=emoji>`, triggering the native emoji picker.
I think custom emoji are a related but separate problem.
The UI I’m thinking of is this one here, in which you provide your own reaction widget with some default options, but want to allow all emoji reactions by clicking the + button.
Upon clicking that button, the native emoji picker would get shown.
Upon clicking that button, the native emoji picker would get shown.
November 17, 2025 at 10:50 AM
The UI I’m thinking of is this one here, in which you provide your own reaction widget with some default options, but want to allow all emoji reactions by clicking the + button.
Upon clicking that button, the native emoji picker would get shown.
Upon clicking that button, the native emoji picker would get shown.
Kinda like that.
The UI I’m thinking of is something like this here, in which there is a list of pre-defined recations, but hitting that + icon allows you to pick a custom one. Clicking the + would trigger the emoji picker.
The UI I’m thinking of is something like this here, in which there is a list of pre-defined recations, but hitting that + icon allows you to pick a custom one. Clicking the + would trigger the emoji picker.
November 17, 2025 at 10:43 AM
Kinda like that.
The UI I’m thinking of is something like this here, in which there is a list of pre-defined recations, but hitting that + icon allows you to pick a custom one. Clicking the + would trigger the emoji picker.
The UI I’m thinking of is something like this here, in which there is a list of pre-defined recations, but hitting that + icon allows you to pick a custom one. Clicking the + would trigger the emoji picker.
Here’s before and after screenshots of Chrome DevTools showing a trace of the view-transitions.chrome.dev/cards/spa-au... demo.
From Chrome 144.0.7512.0 onwards, the `::view-transition-group(*)` animations run¹ on the compositor! Yay! 🎉
(¹ When their `width` and `height` don’t change)
From Chrome 144.0.7512.0 onwards, the `::view-transition-group(*)` animations run¹ on the compositor! Yay! 🎉
(¹ When their `width` and `height` don’t change)
November 13, 2025 at 11:25 AM
Here’s before and after screenshots of Chrome DevTools showing a trace of the view-transitions.chrome.dev/cards/spa-au... demo.
From Chrome 144.0.7512.0 onwards, the `::view-transition-group(*)` animations run¹ on the compositor! Yay! 🎉
(¹ When their `width` and `height` don’t change)
From Chrome 144.0.7512.0 onwards, the `::view-transition-group(*)` animations run¹ on the compositor! Yay! 🎉
(¹ When their `width` and `height` don’t change)
So, you can probably see where this is headed: In Chrome 144.0.7512.0 (current Canary) we have extended the check to check whether the `width` or `height` actually change or not.
💡 If they don’t change, then we don’t need Layout, so then we don’t need to force it on the Main Thread.
💡 If they don’t change, then we don’t need Layout, so then we don’t need to force it on the Main Thread.
November 13, 2025 at 11:25 AM
So, you can probably see where this is headed: In Chrome 144.0.7512.0 (current Canary) we have extended the check to check whether the `width` or `height` actually change or not.
💡 If they don’t change, then we don’t need Layout, so then we don’t need to force it on the Main Thread.
💡 If they don’t change, then we don’t need Layout, so then we don’t need to force it on the Main Thread.
Taking a step back: to determine if an animation can run on the compositor or not, Blink (Chrome’s engine) does a bunch of checks.
One of those is a check for the presence of `width` or `height` in the keyframes. If you are animating those, the animation is forced to run on the Main Thread.
One of those is a check for the presence of `width` or `height` in the keyframes. If you are animating those, the animation is forced to run on the Main Thread.
November 13, 2025 at 11:25 AM
Taking a step back: to determine if an animation can run on the compositor or not, Blink (Chrome’s engine) does a bunch of checks.
One of those is a check for the presence of `width` or `height` in the keyframes. If you are animating those, the animation is forced to run on the Main Thread.
One of those is a check for the presence of `width` or `height` in the keyframes. If you are animating those, the animation is forced to run on the Main Thread.
VS Code pro-tip: check the `@id:chat.disableAIFeatures` setting.
(It’s more getting in the way than helping me, so better to just get rid of it all together)
(It’s more getting in the way than helping me, so better to just get rid of it all together)
November 6, 2025 at 3:54 PM
VS Code pro-tip: check the `@id:chat.disableAIFeatures` setting.
(It’s more getting in the way than helping me, so better to just get rid of it all together)
(It’s more getting in the way than helping me, so better to just get rid of it all together)
October 24, 2025 at 9:07 PM
Here are before and after screenshots of a page on my blog that has a CodePen embed.
Because I don’t have a CSP violations reporting endpoint set up (like most websites), there’s no CSP-noise on the console 😊
Because I don’t have a CSP violations reporting endpoint set up (like most websites), there’s no CSP-noise on the console 😊
October 24, 2025 at 12:21 PM
Here are before and after screenshots of a page on my blog that has a CodePen embed.
Because I don’t have a CSP violations reporting endpoint set up (like most websites), there’s no CSP-noise on the console 😊
Because I don’t have a CSP violations reporting endpoint set up (like most websites), there’s no CSP-noise on the console 😊
The code for the demo is attached to this post. Yes, it’s that easy!
You can try it out yourself in Chrome Canary with the experimental Web Platform Features Flag enabled: codepen.io/bramus/pen/q...
The feature is expected to ship to Chrome Stable in Chrome 144.
You can try it out yourself in Chrome Canary with the experimental Web Platform Features Flag enabled: codepen.io/bramus/pen/q...
The feature is expected to ship to Chrome Stable in Chrome 144.
October 22, 2025 at 4:48 PM
The code for the demo is attached to this post. Yes, it’s that easy!
You can try it out yourself in Chrome Canary with the experimental Web Platform Features Flag enabled: codepen.io/bramus/pen/q...
The feature is expected to ship to Chrome Stable in Chrome 144.
You can try it out yourself in Chrome Canary with the experimental Web Platform Features Flag enabled: codepen.io/bramus/pen/q...
The feature is expected to ship to Chrome Stable in Chrome 144.
There’s a new type of CSS scroll-state query coming: “scrolled”.
This one remembers the last direction you scrolled into, which you can use to build “hidey bars”: when scrolling down (or having scrolled down), the hidey bar hides itself. When then scrolling back up, the hidey bar reveals itself.
This one remembers the last direction you scrolled into, which you can use to build “hidey bars”: when scrolling down (or having scrolled down), the hidey bar hides itself. When then scrolling back up, the hidey bar reveals itself.
October 22, 2025 at 4:48 PM
There’s a new type of CSS scroll-state query coming: “scrolled”.
This one remembers the last direction you scrolled into, which you can use to build “hidey bars”: when scrolling down (or having scrolled down), the hidey bar hides itself. When then scrolling back up, the hidey bar reveals itself.
This one remembers the last direction you scrolled into, which you can use to build “hidey bars”: when scrolling down (or having scrolled down), the hidey bar hides itself. When then scrolling back up, the hidey bar reveals itself.
With View Transitions now being Baseline Newly available, and the View Transition API consisting of various features, it can be confusing to know what is supported in which browser versions.
To help with that, I created this VT Feature Explorer (powered by View Transitions)
web.dev/blog/same-do...
To help with that, I created this VT Feature Explorer (powered by View Transitions)
web.dev/blog/same-do...
October 16, 2025 at 6:38 PM
With View Transitions now being Baseline Newly available, and the View Transition API consisting of various features, it can be confusing to know what is supported in which browser versions.
To help with that, I created this VT Feature Explorer (powered by View Transitions)
web.dev/blog/same-do...
To help with that, I created this VT Feature Explorer (powered by View Transitions)
web.dev/blog/same-do...
I am currently in Milan (Italy) for CodeMotion, where I’ll be giving a talk tomorrow afternoon.
As you might have guessed/expected, I’ll be spreading the word on View Transitions 😊
As you might have guessed/expected, I’ll be spreading the word on View Transitions 😊
October 13, 2025 at 2:06 PM
I am currently in Milan (Italy) for CodeMotion, where I’ll be giving a talk tomorrow afternoon.
As you might have guessed/expected, I’ll be spreading the word on View Transitions 😊
As you might have guessed/expected, I’ll be spreading the word on View Transitions 😊
At #fronteers #DarkMode, @utilitybend.com proposed the HTML Element.
It unlocks the multi-handle range slider, a pattern you might have already seen when picking a price-range.
Feedback Form (with links to the explainer and demos): docs.google.com/forms/u/0/d/...
It unlocks the multi-handle range slider, a pattern you might have already seen when picking a price-range.
Feedback Form (with links to the explainer and demos): docs.google.com/forms/u/0/d/...
October 3, 2025 at 4:24 PM
At #fronteers #DarkMode, @utilitybend.com proposed the HTML Element.
It unlocks the multi-handle range slider, a pattern you might have already seen when picking a price-range.
Feedback Form (with links to the explainer and demos): docs.google.com/forms/u/0/d/...
It unlocks the multi-handle range slider, a pattern you might have already seen when picking a price-range.
Feedback Form (with links to the explainer and demos): docs.google.com/forms/u/0/d/...