Here's a list of browser features the skills will tell your agent to use that are stable in Chrome but not supported by Firefox and Safari:<p><pre><code> CSS @function
CSS calc-size()
CSS interpolate-size
CSS corner-shape
CSS border-shape
CSS flex-wrap: balance
CSS text-fit
CSS text-decoration-skip-spaces
CSS scroll-axis-lock
CSS scroll-target-group
CSS :target-current
CSS scroll-initial-target
CSS container scroll-state queries
scrollsnapchange event
scrollsnapchanging event
HTML focusgroup
Element.startViewTransition()
CSS view-transition-scope
Interest Invokers (interestfor)
LanguageModel (Prompt API)
LanguageDetector
Translator
Summarizer API
Window.fetchLater()
Speculation Rules API
Long Animation Frames API
VisibilityStateEntry
PerformanceSoftNavigation
InteractionContentfulPaint
Connection-Allowlist
CSS url() integrity() modifier
HTML meta name="text-scale"
HTML template for
HTML processing instructions
PasswordCredential
Promise-returning scroll methods
Web App Origin Migration
Local Network Access permissions
Request.targetAddressSpace
beforeinstallprompt event
</code></pre>
To be fair, the skills also recommend ~11 features not supported by Chrome itself. And the project does seem concerned with compatibility: "Guiding models to use sensible, lightweight fallbacks."
> Here's a list of browser features the skills will tell your agent to use that are stable in Chrome but not supported by both Firefox and Safari:<p>To be clear, the skills <i>document</i> how to use these features to solve common use cases, and then they give your agent a full browser support table for any APIs mentioned that are not Baseline Widely available -- and then your agent can decide whether to use them or not, based on your site's browser support requirements.<p>In most of these cases a cross-browser fallback is also documented.
The default behavior for this "web best practices" tool which steers people away from "legacy patterns" has agents using Limited Availability features with complex and nuanced[0] fallbacks?<p>This would be deeply surprising to me, and I am the target audience for this repo. I'd expect the default here to be Widely Available <i>only</i> with some opt-in for the courageous. I don't know that I'd even enable it.<p>[0] <a href="https://github.com/GoogleChrome/modern-web-guidance/blob/4dd968349e54ca45a05dd5c818fb035c9054b022/skills/modern-web-guidance/guides/performance/detect-initial-visibility-state.md#fallback-strategies" rel="nofollow">https://github.com/GoogleChrome/modern-web-guidance/blob/4dd...</a>
The line between <i>documenting</i> and <i>instructing</i> is blurry in many cases. For example, these statements are meant to document best practices to the agent, but they sound like instructions:<p>"DO use fetchLater()..."<p>"Your own code MUST call fetchLater() directly..."<p><a href="https://github.com/GoogleChrome/modern-web-guidance/blob/main/skills/modern-web-guidance/guides/performance/full-session-analytics.md#L52-L65" rel="nofollow">https://github.com/GoogleChrome/modern-web-guidance/blob/mai...</a><p>But yes, the skills do document compatibility and fallbacks well.
Agreed the line can be blurry, but I want to stress that the goal of this project is NOT to push Chrome-only APIs on users.<p>The mental model we've been using on the team is:<p><i>If you hired an expert web development consultant to build X, what would they recommend as a best practice? When does it make sense to use the new API (because it provides real benefits) vs. when does it make sense to wait until it's available everywhere?</i><p>To use your `fetchLater()` example, this is a case where the `fetchLater()` API legitimately solves a very real problem for people trying to build accurate analytics or telemetry features, see: <a href="https://nicj.net/beaconing-in-practice/" rel="nofollow">https://nicj.net/beaconing-in-practice/</a><p>And lots of companies actually are already using `fetchLater()` in production now because of its increased reliability.
In my experience, it's difficult to suggest something to an LLM in a way that it doesn't interpret as a command, unless I explicitly list conditions (which it will take as law rather than guidance).
How about details/summary?
The details/summary features are covered in the accordion guide here: <a href="https://developer.chrome.com/docs/modern-web-guidance/guides/ui-components/accordion" rel="nofollow">https://developer.chrome.com/docs/modern-web-guidance/guides...</a><p>If you scan to the bottom of the guide under the "Fallback strategies" section, you can see the recommendations for how to deal with the aspects of details/summary that aren't Baseline widely available (e.g. mutually exclusive details).
Distribution suggestion: in addition to the npm packages you have right now, set up GitHub Pages to publish a markdown index document of the skills at <a href="https://googlechrome.github.io/modern-web-guidance-src/skills/" rel="nofollow">https://googlechrome.github.io/modern-web-guidance-src/skill...</a> (currently a 404)<p>That index page should link to plain markdown versions of all of the documents, and should be designed for search with grep to find the right answers.<p>That way I don't have to install anything at all - provided my agent has the ability to make HTTP requests I can tell it "Look for tips on <a href="https://googlechrome.github.io/modern-web-guidance-src/skills/" rel="nofollow">https://googlechrome.github.io/modern-web-guidance-src/skill...</a>" and it will fetch the index, then navigate to the most relevant documents - no MCP or npm or installation required at all.
<a href="https://developer.chrome.com/docs/modern-web-guidance/guides.md.txt" rel="nofollow">https://developer.chrome.com/docs/modern-web-guidance/guides...</a><p>(we could make this clearer though)
Aye. I like the idea, Simon. The token cost of the index is high enough I wouldn't suggest the technique for regular use but.. agree that for occasional users it should suffice.<p>We'll make this happen. :)
It looks like the markdown has cross references that assume that the cli approach is used, it would be nice to separate the content from the tooling to access.
If you rename that file to "llms.txt" it'll be a bit more discoverable.
> That way I don't have to install anything at all<p>It feels that something like this would be the holy grail of agents. A small agent that has only the minimum necessary built in knowledge. The rest, it just retrieves on the fly when it needs (+ caching)<p>It’s like storing pointers/links instead of the contents
If created properly, skills are already something like that. You have a front matter summary always available to the agent. The agent can request the full skill content on demand, which might contain additional linked documents with details about APIs and schemas being used, deeper documents about niche subtopics, scripts to help with subtasks, etc.
In reality that's pretty much what we got here. Very progressive disclosure centric. There's a 'install' command exists because the ecosystem doesn't have good cross-agent ergonomics for installing skills. (Which bums me out).<p>But yeah.. big corpus of valuable context × minimal agent footprint = happy place.
What’s the point of modern Javascript without over complicating things?
Chrome already has too much power in the browser standards world. The last thing we need is everyone's LLMs to follow Chrome team's guidance on how to do web development. This road leads back to "To view this site, please view in [DOMINANT BROWSER]"
Mozilla Firefox and Microsoft Edge are also contributors to this project, so this is a cross-browser initiative to help improve how agents build for the web.
Both Mozilla and the Google Chrome team are part of the Web Baseline project and this project. They only recommend best practices supported by Chrome, Firefox, Edge, and Safari.<p><a href="https://web-platform-dx.github.io/baseline/" rel="nofollow">https://web-platform-dx.github.io/baseline/</a>
Not my opinion, but I do wonder if sharing from a different repo would feel more neutral.
Let the best API win. why hold them back?
Calm your pitchfork, Mozilla and Edge are both part of Modern Web Guidance.<p><a href="https://github.com/GoogleChrome/modern-web-guidance-src/blob/main/GOVERNANCE.md" rel="nofollow">https://github.com/GoogleChrome/modern-web-guidance-src/blob...</a>
Is there a similar project for React? There are so much bad React code and wrong/old design patterns on the internet that surely ended in the training datasets
Remeber, the features you don't use are the ones you don't have to support, or scramble to replace when they are deprecated.<p>Keep your effing websites simple.
Amazing! I'm just writing an article about how Alex Russell's quote about 'React being a legacy technology' got, unfortunately, totally ignored.<p>And now this just fell in my lap! Some of the arguments I wanted to make seem to be provide here. Didn't have a chance to take a proper look at it, but it looks very promising and nice!<p>Thank you!
"Best Practices" are pretty much dead in the AI era. Pretty soon no one is going to read any of the code AI produces and that's a scary thought.
IMO maintainability is the next frontier. If we just allow coding agents to accrete 1k-LOC solutions to problems, the codebases run quick away from our ability to maintain _some_ level of understanding.<p>So I'll take a 1-line CSS solution over 60 lines of ResizeObserver/setTimeout business. But.. best practices for frontend isn't just the code.. it's ensuring quality UX, that keyboard navigability works, that layout doesn't shift on users.
You just regenerate the codebase, like how you do a recompile in C. Writing code is 2026 is worth as much as writing machine code was in 1996.
Once again, thank you for all the work you and the team have done to improve the web and the experience for developers working with it.
Best practices are not dead if they result in better user experience. The focus is less on developer ergonomics though - true that.
The "modern web primitives" are also not even necessarily the "best practice".<p>Browser-specific implementation gotchas tend to take about a decade to iron out for reasons that never have anything to do with code quality. Users are fickle and so are browser vendors, but that's a different topic.<p>At the end of the day, there's just no escaping lots of manual testing across device and browser combinations if your goal is a polished result and not just something that "works".<p>AI has done nothing to make this problem go away. If anything, it's made it worse because people don't even want to look at the code now!
Exactly.<p>I've recently finished a browser game specifically targeting an old iPad Air 1 we had lying around the house.<p>I had a working version after a weekend, but it took me a month to make it run smoothly on an over 10 years old mobile device. And the most recent browser available is almost 10 years old.<p>Surprisingly I didn't missed too many "modern" JS features, as these were mostly functional programming oriented which doesn't play well with optimization anyways, and the ES6 was more than enough as a programming platform.<p>Anyway, what I'm trying to say is that "the best practice" should be making your apps fast and accessible - as much as you can without having to sacrifice something you value - instead of chasing the latest and shiniest.<p>Don't be a fashion driven developer. :)
>Pretty soon no one is going to read any of the code AI produces and that's a scary thought.<p>This is a misconception. Have your favorite agent summarize this video for you: <a href="https://www.youtube.com/live/zcLPGC-tvgk?si=YR68aHlFESD053bh" rel="nofollow">https://www.youtube.com/live/zcLPGC-tvgk?si=YR68aHlFESD053bh</a>
Ugh it is Uncle Bob, not going to torture AI with this guy.<p>But the fun part is that all of the proper software engineering practices are aimed at lowering amount of context a developer has to keep in his mind. So it directly applies to agent context. Less verbose code, less tokens to burn, separation of concerns, lower chance agent breaks something unrelated etc.
>>Pretty soon no one is going to read any of the code AI produces and that's a scary thought.<p>>This is a misconception. Have your favorite agent *summarize this video for you*: <a href="https://www.youtube.com/live/zcLPGC-tvgk?si=YR68aHlFESD053bh" rel="nofollow">https://www.youtube.com/live/zcLPGC-tvgk?si=YR68aHlFESD053bh</a><p>I can't tell if you're joking here
I am not generally against using AI to reduce the amount of information you need to pay attention to, and I was not joking. There are multiple places in that interview with good articulation of the reasons why software fundamentals still matter, and what happens when you don't look at at least some of the AI-generated code.
NO THANK YOU. Do not want my agents to contribute to the Chrome monoculture. Chrome is the new IE6.
Planning to give this one a wide berth.<p>The more "legacy code" is getting written everyday the more the web will be forced to remain backwards compatible...
Finally.<p>This is exactly what I need when I need it. The amount of pull requests I reviewed with a mess of codes that can be switched to 2 lines of modern features made me write such tools myself, only half assed since I have other things to do.
I asked my agent to look at that list and only apply things that work on chrome, Firefox, safari iOS and safari macos<p>Came up with a good list for my project
I added this a few months ago and Claude Doctor has not removed it. It must be working and getting use.
I want the opposite of this. I want compatible code -- which is really hard, when there are so many eras to target. So far AI has done a great job of finding that sweet spot -- why would I want a tool that encourages the agent to write less compatible code?
I find this very useful as a human as well
That's pretty cool!<p>On the other hand, a bit sad: programming nowadays is just arranging a bunch of Markdown files, possibly generated by another bunch of models.<p>Not so exciting, in the end.
> We wanted receipts, so we invested heavily in eval infra to help us hill-climb, but also to identify when knowledge is common enough we can prune our guides.<p>Good god.
what? oh. I mean.. I wrote it all with my lil fingies, but I did pack some jargon in there. :) More plainly...<p>We built rigorous tests to verify this actually works, and to know when models no longer need the advice.
"hill-climb" is the most aggressively LinkedIn speak I've ever encountered in the wild.
Paul Irish?? There's a name I haven't though about in ages! I remember following you on Twitter and your website was full of amazing information. Hope you're doing well!
These skills look better than most, but running my code through the legacy scan only found two issues. So while I still think training beats skills, I'm sure this has its place, especially with weaker models.
Yeah. The legacy scan is tuned to 1) focus on cases where there's a clearly detectable legacy pattern and 2) avoid false-positives. This means it only overlaps with 20% of all the skill's docs. (We'll probably get it to ~50% in another month).<p>In short: I 100% understand your disappointment. :) More coming soon like finding cases to update with Promise.withResolvers, the Array iterators, Object.groupBy, URLSearchParams, etc..
More Chromish on web? No thanks.
What's the best way to introduce this to a Gemini chat?
Gemini web? Probably simonw's strat from the top comment.<p>There's a plugin for Antigravity that's listed on initial setup (yay bundleware! :) but... yeah if you're using consumer gemini, i'd switch to the Tasks mode because it's more agentic nature helps.<p>In fact I just did this and it works. :p It regular Gemini, it said it did but kinda liked :) So there it'd be<p>> Create a perfect HTML contact form with address fields. Check <a href="https://developer.chrome.com/docs/modern-web-guidance/guides.md.txt" rel="nofollow">https://developer.chrome.com/docs/modern-web-guidance/guides...</a> — read completely, don't stop at truncation.
why would you ever use gemini for coding at all
I ask my agent to write ES5 as I am more comfortable with it.. i need to read and maintain that slop somehow..
I recommend saying "contemporary" or "suggested" for transient proposals like this. Having modern change every few years is ambiguous and cliche .<p>These concepts are new, so no one knows if they are any good. They're not modern -- who knows if they will even be put to use?<p>"contemporary", "proposed", "suggested", "compatible" are better fit. I wouldn't dare use "advanced" because many APIs and proposals actually regress earlier behavior.
This is a great idea. I think while so much was being built out in the JavaScript ecosystem, awareness about the equivalent feature releases that were done to HTML, CSS, web components, and other technologies didn't keep pace.<p>Of course, it's not perfectly implemented the same in every browser, but that's nothing new.
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
I use Firefox after Chrome decided to become a bit of a pain to use on my powerful computers. I was unsure how bias the skills were for Chrome exclusive features, so I decided to ask ChatGPT to analyse the repo. I liked the answer it gave, so here it is:
<a href="https://chatgpt.com/share/6af3712a-03cc-83eb-ad1f-66dd11c886bb" rel="nofollow">https://chatgpt.com/share/6af3712a-03cc-83eb-ad1f-66dd11c886...</a>
I treat all my code as some kind of stochastic machinery. So atleast one stage, I'd just tell an agent to go through and follow the guide.<p>But I'd not inject all this fluff into the wheels of the machine because it'd just take the "average" of these practices which would be just as useless.