Philip Walton
banner
philipwalton.com
Philip Walton
@philipwalton.com
1.5K followers 200 following 30 posts
Engineering lead @ Google working on Chrome and the Web. I occasionally blog at: https://philipwalton.com
Posts Media Videos Starter Packs
Pinned
📢 New post: The State of ES5 on the Web.

For years, we defaulted to transpiling to ES5 in order to support IE. But is that still necessary?

I took a look at the data to find out, and I'll just say that the results were *actually* quite surprising! 🙀

philipwalton.com/articles/the...
The State of ES5 on the Web
Should web developers and JavaScript library authors still transpile their code to ES5? This post looks at what the data suggests based on what popular libraries, tools, and websites are doing
philipwalton.com
Reposted by Philip Walton
View Transitions are now in all browsers! They also landed in React! developer.chrome.com/blog/view-tr...
Reposted by Philip Walton
Chrome for Android can now help users adopt passkeys more seamlessly.

If a user signs in with a saved password , your website can request that an associated password manager (in many cases on Chrome is Google Password Manager) creates a passkey automatically.

developer.chrome.com/blog/automat...
Automatic passkey creation in Chrome for Android  |  Blog  |  Chrome for Developers
Chrome for Android can now automatically create passkeys after password sign-in, helping users transition to passkeys with less friction.
developer.chrome.com
Reposted by Philip Walton
Bramus @bram.us · 15d
A lot has happened since Chrome shipped Same-Document View Transitions in 2023.

In 2024 we shipped Cross-Document VTs, added refinements such as `view-transition-class` and VT Types, and also welcomed Safari in adding VT support.

And this year … well, I wrote a post summing it all up.
What's new in view transitions (2025 update)  |  Blog  |  Chrome for Developers
An overview of what changed for View Transitions in 2025
developer.chrome.com
Reposted by Philip Walton
If we started Chrome Dev Summit again, would you be interested in it?

(huh - apparently can't do polls here...), Please reply, Yes or No, or any other answer in between.
Reposted by Philip Walton
✅ Baseline now has full feature coverage, making it easier to know which web platform features are ready to use.

Build the next wave of Baseline-powered tools and compete for $10,000 in prizes → goo.gle/424SBWc
Reposted by Philip Walton
Announcing our public preview of Chrome DevTools MCP! Experience the full power of DevTools in your AI coding agent→ goo.gle/4pDE6Tk

With Chrome DevTools MCP, your AI agent can run performance traces, inspect the DOM, & perform real-time debugging of your web pages.
Reposted by Philip Walton
Before, you needed a plugin to use Baseline semantics in your Browserslist queries. Now you don't!

Just give it a target like `baseline widely available` and it'll work out of the box

Available in [email protected] and later

web.dev/blog/browser...
Browserslist now supports Baseline  |  Blog  |  web.dev
Browserslist has added support for Baseline queries. Find out what that could mean for your developer workflow.
web.dev
Reposted by Philip Walton
Reposted by Philip Walton
Scoped View Transitions are ready for testing in Chrome!

SVTs expose el.startViewTransition() on HTML elements. The element creates a scope for the transition, ∴ the transition pseudo-elements are affected by ancestor clips and transforms. Multiple SVTs on separate elements can run *concurrently*.
github.com
Reposted by Philip Walton
🎉 Happy 30-month anniversary to Container Queries – in every browser since Feb, 2023. It was supposed to be impossible, but here we are!

Why 2.5 years? Nothing will change tomorrow, but Baseline uses this milestone to signal confidence a feature has gained "wide" support.

youtu.be/bhHV0rQ3-CQ
I know, I'm shocked as well!
Totally agree.

I'm not aware that it's a thing that has ever actually happened (though admittedly it would be hard to know if it did). But it's definitely something people are concerned could happen.

Here's one example (and I've heard others express similar concerns): bsky.app/profile/zach...
Let’s talk about why Baseline browser compatibility doesn’t tell a complete story about whether or not a feature can be used “safely” by developers.
But IMO anyone who understands how to use progressive enhancement is likely not going to be confused or dissuaded by Baseline labels.

The primary audience for Baseline labels are people that *don't* fully understand progressive enhancement and aren't actively looking to try out new features.
The specific concern I've heard is that adding Baseline labels to blog posts and reference documentation will scare people off from using "limited availability" features, even if those features can easily be used as progressive enhancements now...
If you want to find out what Baseline target makes the most sense for your site, there are a number of tools to help you determine that: bsky.app/profile/deve...

And if you work at a company that doesn't have a browser support policy, talk to them about Baseline! #WhatsMyBaseline
What new web features are your users actually ready for? Stop guessing. 🔮

Baseline helps you make data-driven decisions so you can ship the right features at the right time. Learn more and find your target with #WhatsMyBaselinegoo.gle/whats-my-baseline
Using Baseline 2023 as my browser support target means I can safely adopt TONS of great features, including:

- :has()
- Container Queries
- CSS Nesting
- linear() easing

Any many more: webstatus.dev?q=baseline_d...
Web Platform Status
webstatus.dev
I believe this will lead to FASTER feature adoption on the web, not slower.

I also bet there are many features you can safely use now that you may not realize. For example, on my personal website, 98.2% of my users are on browsers that support all of Baseline 2023.

Here's what my data looks like:
BUT, if your company has a browser support policy, the decision is simple.

This is why I'm excited about Baseline.

Baseline makes it easier for companies to decide on a browser support policy. And with Baseline data now exposed in so many tools and resources, devs can easily follow that policy.
In this situation, most devs will give up. Or worse, many won't even try at all because they don't want the hassle.

I've seen this play out many times, even with features that have been available for 5+ YEARS!

Unfortunately, if a feature is not already in the codebase, it will face resistance.
Even if you convince your immediate teammates, is that enough? Do you need sign-off from a manager? Your CTO? Who is the final decision maker?

And what if your code breaks a customer, will it get reverted and then you'll just end up having to rewrite it anyway?
Here's the scenario:

You get assigned a ticket, research a solution, and find a new Web API that does exactly what you need. But in the PR your teammates ask:

- Are you sure we can use this?
- Did you check browser support?
- Is this used anywhere else?

Now you’re on the hook to justify it.
In my experience, one of the main reasons devs don't use new web features is NOT lack of browser support, it's because their company doesn't have a clear browser support policy.

Without a clear policy, the path of least resistance is to just NOT adopt any new features, even widely available ones.
I know some people in the web community are concerned that Baseline will discourage devs from using new features—or anything not "Widely Available".

Personally, I'm not worried about that at all. If anything, I think Baseline will speed up new feature adoption!

Here's why 🧵
Reposted by Philip Walton
What new web features are your users actually ready for? Stop guessing. 🔮

Baseline helps you make data-driven decisions so you can ship the right features at the right time. Learn more and find your target with #WhatsMyBaselinegoo.gle/whats-my-baseline
TBH my significant other is questionable at times. When we first met she told me she likes hiking. Later she clarified that she "likes hiking, just not up hill".