Rendered at 17:23:46 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
surround 21 hours ago [-]
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:
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
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."
onion2k 9 hours ago [-]
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
That's fine though. Progressive enhancement, adding features to a site when they're available but still offering a working site when they're not, is how we should build web sites. That way they work for the user's device rather than the developer's opinion of what the web should do.
Working that way completely removes the decision about whether or not to use a feature because it doesn't work for some people, and moves it to a decision about whether or not it's worth adding for the users on browsers that can use it. In the past that was a real development effort cost, but today where AI writes the code the effort is much, much lower.
If you're using AI to make something but still using heuristics designed to save coding time then you really need to rethink your mental model of how to decide what gets built.
Websites created today should all use server-loaded content for the first render, small page sizes, a sub-1s loading time, progress enhancement for features, and WCAG 3.1 AAA accessibility (maybe.. at least AA though) because doing that isn't any more effort than not doing it.
embedding-shape 5 hours ago [-]
> That's fine though. Progressive enhancement, adding features to a site when they're available but still offering a working site when they're not, is how we should build web sites.
Alright, that's fine and dandy. Is this the actual results of using this skill though that is being advertised here? Is it asking the agent to also make sure it's "Progressive enhancement" so the same stuff more or less works in Firefox and Safari?
If not, your whole point is kind of moot, as you have someone from Google trying to get people to write websites that'll look and/or work differently in Chrome compared to other browsers.
atopal 4 hours ago [-]
Not only is it asking the agent, the guides themselves spell out how to make a fallback work in unsupported browsers. That's not just Firefox and Safari, if it's a Chrome only feature older versions of Chrome might not support it either. Here's an example: https://github.com/GoogleChrome/modern-web-guidance-src/blob...
Unless you have specified something different, by default the skill assumes you are targeting Baseline Widely Available, which means everything has to work in all major browsers from at least 2.5 years ago.
kevin_nisbet 1 hours ago [-]
I tried the skill as an experiment, and while it did give a suggestion that had poor support, it also suggested the library version as fallback (using Temporal). So if that's universally applied it might not be so unreasonable, but I don't do much frontend dev to know whether it's worth the risk or not.
onion2k 3 hours ago [-]
Progressive enhancement isn't new. It's a concept from the days of IE and Netscape, and it's how we should all have been building website for the past 3 decades.
philipwalton 20 hours ago [-]
> 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:
To be clear, the skills document 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.
In most of these cases a cross-browser fallback is also documented.
lelandfe 17 hours ago [-]
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?
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 only with some opt-in for the courageous. I don't know that I'd even enable it.
> 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?
You have causality reversed here. If you need to detect if the page was loaded in the foreground or background, it is nuanced and (relatively) complex. Therefore it's good for your agent not to just assume document.visibilityState is all it needs to check, or you're going to be getting seemingly impossible log entries pretty quickly.
lelandfe 13 hours ago [-]
Tree, forest.
You're making this into a false binary which is wrong (the alternative to adopting Limited Availability features is not "document.visibilityState is all it needs to check"). But responding to my one example is also going to cause us to miss the point I'm making entirely.
surround 20 hours ago [-]
The line between documenting and instructing is blurry in many cases. For example, these statements are meant to document best practices to the agent, but they sound like instructions:
"DO use fetchLater()..."
"Your own code MUST call fetchLater() directly..."
But yes, the skills do document compatibility and fallbacks well.
philipwalton 20 hours ago [-]
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.
The mental model we've been using on the team is:
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?
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: https://nicj.net/beaconing-in-practice/
And lots of companies actually are already using `fetchLater()` in production now because of its increased reliability.
embedding-shape 4 hours ago [-]
Maybe this mental model of yours need to include how difficult it'd be to implement your own version of the suggested API to make it actually cross-platform.
In the case of fetchLater, judging by https://nicj.net/beaconing-in-practice-fetchlater/ (which I think you intended to link actually) since I haven't come across it before, it could be implemented with fetchLater, events and a timeout, perhaps 10 LOC or so? If that's the case, then it almost never makes sense to use Chrome's own fetchLater, rather than those ~10 LOC so it's actually web-friendly instead of just Chrome friendly.
As a side-note, I'm getting increasingly wary about all the new JS APIs that seemingly gets added to our standards ONLY because they have ads/tracking interests. Used to be the people who participated in standards discussions for their ads/tracking interests came up with proper use cases and kept quiet about their erosion of privacy, but seems the mask is fully off today and we're just making browser engines for the ads companies now, yay.
17 hours ago [-]
cma 19 hours ago [-]
I think I can guess from corporate incentives why Chrome supports fetchLater and some others don't.
Regarding corporate incentives: I was involved in the design of this API, so I know the history. It was proposed many years ago as a solution to make it easier for RUM analytics providers to measure Core Web Vitals metrics that needed to account for more than just page load (e.g. layout shifts and slow interactions can happen any time, not just during page load).
The RUM providers we worked with were reluctant to wait until page unload to send telemetry data because it resulted in too many lost beacons, so what they do instead is send beacons every few seconds with the most up-to-date payload.
The `fetchLater()` API enables them to send just one beacon, which is good for users and also reduces their server load.
ricardobeat 17 hours ago [-]
Why was 'fetchLater' chosen over a reliable way to trigger fetch from 'unload' or a similar event, or inversely, adding a 'sendLater' option to sendBeacon? Feels like a bolted-on API for a very specific use case, when the same thing could be built from better primitives?
It's a bit sad that browsers now have two different, "standard" APIs created entirely for the purpose of user tracking, as if things weren't already bloated enough.
Spot-on amazing linking exactly to the relevant discussion.
I’m really glad to see this not evolve into a flame war as well.
hatthew 19 hours ago [-]
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).
Arubis 2 hours ago [-]
The proportion of sites that I have to swap out of Firefox to use has gone from "every couple of weeks" to "multiple times weekly" lately, mostly among clearly AI-coauthored sites. I wonder if this is part of why.
Cthulhu_ 7 hours ago [-]
I've looked up a few on MDN and they're all listed as experimental, so while they may work in Chrome they're not web standards; I hope everyone prompts their agents to avoid experimental features. That said I'm disappointed this tool seems to recommend using them anyway.
atopal 4 hours ago [-]
Unless you have specified something else, Modern Web Guidance assumes that you are targeting Baseline Widely Available, meaning all major browsers going back 2.5 years. Everything has to either be a progressive enhancement or have a fallback that works in those browsers. Otherwise you have to explicitly ask for that feature. This is a policy that was worked out with Microsoft Edge and Mozilla Firefox, who are also contributing to the skill.
tgv 4 hours ago [-]
It's proposed by a Google team. That privacy data isn't going to fly to their data stores by itself. So of course they want to thwart Firefox and Safari.
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).
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.
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 https://googlechrome.github.io/modern-web-guidance-src/skill..." and it will fetch the index, then navigate to the most relevant documents - no MCP or npm or installation required at all.
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.
We'll make this happen. :)
kohukohunui 21 hours ago [-]
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.
jph00 22 hours ago [-]
If you rename that file to "llms.txt" it'll be a bit more discoverable.
kinlan 21 hours ago [-]
yeah that's fair. the infrastructure we are on isn't the most flexible (we will soon move to a newer more custom platform but that's a little way a way)
nico 22 hours ago [-]
> That way I don't have to install anything at all
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)
It’s like storing pointers/links instead of the contents
paulirish 22 hours ago [-]
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).
But yeah.. big corpus of valuable context × minimal agent footprint = happy place.
mtrovo 21 hours ago [-]
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.
Havoc 11 hours ago [-]
That was my first thought too…why are we distributing text via package managers
MustafaYenler 2 hours ago [-]
[flagged]
trvz 22 hours ago [-]
What’s the point of modern Javascript without over complicating things?
advisedwang 22 hours ago [-]
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]"
philipwalton 22 hours ago [-]
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.
phendrenad2 15 hours ago [-]
They back it because they have no choice. We have no real independent browsers in 2026. And it's sad that the fact that we don't have independent browsers is being twisted into proof that Google doesn't have much power.
troupo 19 hours ago [-]
That's why it seems to skip the most egregious of Chrome-only APIs and focuses on areas where there's large cross-browser agreement.
Also Mozilla only joined in the last few weeks, so they haven't yet had a big influence on the project (though I expect they will going forward).
incrudible 8 hours ago [-]
I have a bridge to sell you.
philwelch 7 hours ago [-]
Edge is just a rebranded Chrome. “Cross browser” except it’s different skins of Chrome, what a joke.
jefftk 6 hours ago [-]
Firefox is not a skin of Chrome; it has the only browser engine in common use that's not descended from KHTML.
0o777 22 hours ago [-]
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.
No Netsurf. I guess thats why you also switched off access on google search pages too because unless a browser is bigger than 1G its not a real browser?
xnx 22 hours ago [-]
Not my opinion, but I do wonder if sharing from a different repo would feel more neutral.
tonymet 19 hours ago [-]
Let the best API win. why hold them back?
girvo 17 hours ago [-]
Because Google/Chrome should’ve been split up under antitrust grounds, instead of the “too hard let’s not bother” judgment they ended up with.
Amazing! I'm just writing an article about how Alex Russell's quote about 'React being a legacy technology' got, unfortunately, totally ignored.
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!
Thank you!
nchmy 16 hours ago [-]
I'm not sure that's just a quote. He's written and said tens of thousands of words on the topic!
15 hours ago [-]
bakkoting 15 hours ago [-]
> If you spot something wrong or weird, give us a holler!
But how? Hopefully filing an issue on the modern-web-guidance-src repo is the right place? Anyway I filed one for using fromBase64 and toBase64 instead of atob and btoa.
But since you're all in on agents anyway you should consider having one look through at least all of the JS, DOM, and HTML spec commits in the last 3-5 years and automatically triaging any that are clear improvements and are not used by agents. Would be pretty straightforward.
---
Btw, I think it would be very helpful to automatically provide versions of this depending on what browsers you're targeting. I don't want to use anything that hasn't been available in all evergreen browsers for at least a year, for example; I think most developers have a similar standard, or at the very least don't want to use the bleeding edge. And while it is _possible_ to get that from your repo, it takes some effort, either writing a script or letting the agent use its own judgement for every feature. That's work you could do on your end and save the rest of us from needing to.
> Btw, I think it would be very helpful to automatically provide versions of this depending on what browsers you're targeting.
This should work today (though not exactly in the way you describe). The skill tells the agent how to interpret guides based on browser support signals it gets from context (e.g. the prompt itself, or AGENTS.md).
> This should work today (though not exactly in the way you describe). The skill tells the agent how to interpret guides based on browser support signals it gets from context (e.g. the prompt itself, or AGENTS.md).
Right, my point is that I don't want to spend a bunch of time and tokens loading the skills and having the agent reason through whether they apply based on browser support. I want that to be automated so that it only loads in the first place those things that are actually applicable. Having a prose description is not a substitute for automation; it is almost always better to do things mechanically rather than asking the agent to do it, in cases where it is possible to do mechanically.
I think this matters even if you're at Google and tokens are free but it _definitely_ matters for the rest of us.
philipwalton 12 hours ago [-]
If your feature use policy is that you will never use any feature unless it's supported in at least X, Y, and Z browsers, then yes something like this would be possible. But most sites don't have a policy like that.
Most sites are willing to use some features as a progressive enhancement, whereas other features they won't even consider using unless it's in 99+% of their users' browsers.
And unfortunately there's no easy way to make that decision for users on a feature-by-feature basis, because it all depends on what use case they're trying to accomplish, and what will happen if the feature is not available (given that particular use case).
So our approach is to (1) explain in the guide how to implement the use case with the modern feature, (2) explain why the modern feature is the preferred solution (e.g. what the user benefit is), and then (3) explain how to implement a fallback solution if the feature is not available.
I think we could potentially experiment with some version of what you're describing, like a config option where we only surface guides that have robust, widely-available fallbacks, and where we have high confidence that it makes sense for the majority of sites to be following the recommendations in the guide.
I'll raise it with the team.
bakkoting 11 hours ago [-]
> But most sites don't have a policy like that.
My experience differs from yours. It's true that there is some tiny fraction of features where it makes sense to do progressive enhancement, but for most sites and almost all features this does not make sense: the burden of testing and maintaining a site that effectively has multiple versions depending on what browser you're using is simply not worth it. For typical dev teams outside of Google/Meta/similar, the right thing (and the overwhelmingly common thing) is to target the intersection of features available on your supported browsers and not make any behavior conditional. I'm not interested in any guides that need fallbacks on any of the browsers I target and I expect the same is true of the typical dev team outside Google.
1shooner 13 hours ago [-]
Couldn't this be a simple deterministic build from the provider rather than mass replication of inference for essentially every user?
The more "legacy code" is getting written everyday the more the web will be forced to remain backwards compatible...
iantpe 3 hours ago [-]
After my research, I found that if you want to use this skill, it's best to specify the range of browsers you want to support in the AGENTS.md / CLAUDE.md of the repository (e.g., "Only use the Baseline Widely Available feature"), and keep the experimental features disabled by default. This way you can avoid some worrying issues.
internet2000 20 hours ago [-]
NO THANK YOU. Do not want my agents to contribute to the Chrome monoculture. Chrome is the new IE6.
tonymet 19 hours ago [-]
no it's not. they publish the APIs. IE was bad because ActiveX was proprietary and private.
zahlman 7 hours ago [-]
> Browsers natively handle a lot of what used to take 50 lines of JS (or a dependency): `CSS.highlights` for text range highlighting without <span>s everywhere
I tried to look this up and found https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S... but the example depends on JS. How are you meant to statically specify highlighted ranges without the <span> markup? If I'm syntax-highlighting code on a blog, it's seems a lot more practical to just use the old <span> system than to encode a list of character ranges in a JS array and loop to assign highlights. Plus it doesn't require the reader to run JS.
phyzix5761 23 hours ago [-]
"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.
paulirish 23 hours ago [-]
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.
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.
noosphr 20 hours ago [-]
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.
I've not read text with such a high fraction of AI slop in a while. The heady days of a year ago.
soon_to_be_sb 13 hours ago [-]
Jesus! what a horrible idea!
Are you in the business of selling tokens/electricity/gpus by any chance? Then good for you!
But terrible for everyone else....
noosphr 13 hours ago [-]
Yes, just like compilation was.
soon_to_be_sb 13 hours ago [-]
[flagged]
jstanley 6 hours ago [-]
You want to recompile the entire binary even though you only changed a few lines of code and it's obvious which instructions need to change? How wasteful.
soon_to_be_sb 4 hours ago [-]
Tell me how much the cost difference between recompiling and hand modifying the binary is...I ll wait.
jstanley 4 hours ago [-]
Exactly. And in the future the cost difference between re-generating the source and hand-editing the source will likewise tend towards zero.
soon_to_be_sb 3 hours ago [-]
That is an uncertain future, and the other guy was talking about 2026
Even then it might be risky due to losing undocumented/untested behaviors that has been added to the software.
noosphr 2 hours ago [-]
I was talking about 1996 when I first started programming.
You can tell because I said 1996.
aidos 21 hours ago [-]
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.
natorion 23 hours ago [-]
Best practices are not dead if they result in better user experience. The focus is less on developer ergonomics though - true that.
jefftk 6 hours ago [-]
This is mostly best practices for making websites work better, not for pretty HTML.
sublinear 22 hours ago [-]
The "modern web primitives" are also not even necessarily the "best practice".
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.
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".
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!
zeroq 21 hours ago [-]
Exactly.
I've recently finished a browser game specifically targeting an old iPad Air 1 we had lying around the house.
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.
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.
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.
Don't be a fashion driven developer. :)
brlewis 23 hours ago [-]
>Pretty soon no one is going to read any of the code AI produces and that's a scary thought.
Ugh it is Uncle Bob, not going to torture AI with this guy.
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.
vik0 22 hours ago [-]
>>Pretty soon no one is going to read any of the code AI produces and that's a scary thought.
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.
zahlman 7 hours ago [-]
> 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.
Sure, I've seen the video before and remember many of the arguments. I don't agree with everything in Bob's approach, but I certainly agree with what he says about the value of looking at the code.
But that doesn't at all mean that people will do it.
drawfloat 21 hours ago [-]
Why don't you just quote them then? Or quote whatever the LLM you used gave.
brlewis 17 hours ago [-]
Uncle Bob Martin and Matt Pocock discuss the risks of relying on AI agents without human oversight, emphasizing that unchecked code can lead to significant technical issues:
- Accumulated Technical Debt: Uncle Bob notes that agents often leave behind "dog doo" (messy code) (05:13-05:18). If you don't clean it, the code becomes progressively worse as you build on it (11:06-11:10).
- Loss of Agent Coherence: When code quality degrades, agents struggle to maintain direction (11:13-11:16). They may enter a loop of inadvertently breaking existing features while attempting to fix new ones, eventually leading to them failing entirely or giving up (11:22-12:04).
- The "Trapped" Trajectory: Matt Pocock highlights the risk of a session's "trajectory" (23:18-23:45). Without intervention, an agent's initial messy approach or misaligned focus will continue throughout the entire session, reinforcing poor patterns instead of correcting them (23:35-24:00).
- Hidden Hallucinations: Even though agents are fast, they are still prone to hallucinations and misalignment (25:09-25:18). Relying on them blindly without deterministic tools or human spot checks risks incorporating silent, logic-breaking bugs into the architecture (09:08-09:19).
zahlman 7 hours ago [-]
Your comment got flagged and killed; I don't know whether automated systems attempt to detect AI-generated comments. I vouched for you because the content was explicitly solicited.
stronglikedan 2 hours ago [-]
just tell the AI to use best practices when writing code /s
merelydev 7 hours ago [-]
> Coding agents often default to older patterns because LLM training data contains vast amounts of legacy code. This often leads them to generate bloated JavaScript for tasks that now have native, high-performance web platform solutions.
The main problem I see is that it will be extremely hard for new frameworks, languages to take off if everyone is using AI to code. It can lead to a future where all new programming languages and frameworks will be developed by LLM providers because only they, can train them with synthetic data.
deflator 3 hours ago [-]
I don't know about this concern for new frameworks
With LLMs improving, they will might need less example code to work with new frameworks decently
With LLM usage becoming ubiquitous for coding, framework developers will likely start making lots of curated, high-quality synthetic examples specifically for LLM training data usage as their main documentation effort
halflife 23 hours ago [-]
Finally.
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.
SoftTalker 18 hours ago [-]
Remeber, the features you don't use are the ones you don't have to support, or scramble to replace when they are deprecated.
Keep your effing websites simple.
zahlman 6 hours ago [-]
In my book, new "baseline" CSS features that handle common design tasks count as simpler (and more user-friendly) than involving JavaScript to set them up, even if it's "vanilla" JS. The user's browser should as much as possible be treating my content as data rather than code and just doing fancy rendering on it, as long as I'm not explicitly trying to show the user a cool program. The browser may be huge, but it's only one thing that has to be huge for the benefit of every site.
(I have much the same instinct about the UNIX philosophy. Bash is not too big. Shell programs should be even bigger so that query programs can be smaller — because otherwise they grow huge lists of options that largely overlap, for things like table formatting, and provide an inconsistent UX.)
sick_of_slop 18 hours ago [-]
[dead]
hackersnooze1 4 hours ago [-]
I feel like you can get 90% of the same result by saying “use modern javascript and css”. This feels like its more just google pushing their browser features that other browsers arent implementing
codepoet80 19 hours ago [-]
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?
flossly 14 hours ago [-]
I prefer to have my templates in a compiled language: not passing a map of strings to a string with interpolation points, but actually "just code" by which I define HTML builders by combining templates/layouts/components in that same "just code".
Like HtmlFlow (Java/Kotlin) or kotlinx.html.
I pick Tailwind and Alpine.js to go with this approach because: I want to be SSR-first (with small JS-based improvements where they matter most) so NOT and SPA, i want the styling to be close to the HTML code that's being styled (no need to match between CSS definition and usage), and I also prefer to keep my tiny bits of JS close to the HTML it deals with (Alpine makes that easy and provides a clear path for implementing 99% of my JS needs).
Like everyone, LLMs code it for me :) But the result is easy to reason about for myself and my LLM. Little vanilla JS. No jQuery. Mostly just some HTML-bound Alpine instructions. And Tailwind everywhere. This way I can look at one place to see how it works: or CTRL-click my way to it.
fumar 22 hours ago [-]
I added this a few months ago and Claude Doctor has not removed it. It must be working and getting use.
pyrolistical 20 hours ago [-]
I asked my agent to look at that list and only apply things that work on chrome, Firefox, safari iOS and safari macos
Came up with a good list for my project
dflock 9 hours ago [-]
I've been using this skill with Claude on a new project and it's nice, but it's quite expensive, token wise. It's ~$5 per use, on my codebase, which seems fairly high to me. This is according to the crappy stats in the claude usage thing, so not sure how accurate that is.
karlgustav 7 hours ago [-]
[flagged]
reedlaw 22 hours ago [-]
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.
paulirish 22 hours ago [-]
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).
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..
seige 13 hours ago [-]
Just here to voice this again. I ran it on my project and it found 3 issues. There are far more :)
dallen33 20 hours ago [-]
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!
paulirish 15 hours ago [-]
<3
gabrieledarrigo 22 hours ago [-]
That's pretty cool!
On the other hand, a bit sad: programming nowadays is just arranging a bunch of Markdown files, possibly generated by another bunch of models.
Not so exciting, in the end.
adzm 20 hours ago [-]
I find this very useful as a human as well
hackerbrother 15 hours ago [-]
Couldn't this be handled with a deterministic linter?
duskdozer 9 hours ago [-]
Deterministic linters don't use any tokens.
ggregoire 17 hours ago [-]
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
a barely coherent ramble by a Microsoft engineer feat. an exquisite conflation of React/using libs like lodash or moment.js/the idea of frameworks, casually dropping false dichotomies between using React and delivering semantic HTML with progressive enhancement, drive-by smearing any use of frameworks by calling it "frameworkism" and equating it with religion, with a side of amusing bombshells like (exact quote)
> prohibiting the spread of React (and other frameworkist totems) by policy is an incredible cost savings and a helpful way to reorient teams towards delivery for users
Why do people still leave common AI tells in their writing?
zahlman 6 hours ago [-]
Because it takes effort, while the worst consequence of not doing it is people making annoyed comments on HN, apparently.
incrudible 8 hours ago [-]
It would be hard to convince me to go all in on the latest featureset of the abomination that is HTML, CSS, DOM and to a lesser degree Javascript, governed by essentially a monopoly, a single implementation that nearly everyone uses, that is so big in code size that even a swarm of LLMs would choke on it.
I want the browser to be the thinnest layer it can be, between me and my application, which is governed by me.
14 hours ago [-]
zeroq 22 hours ago [-]
What's the best way to introduce this to a Gemini chat?
paulirish 21 hours ago [-]
Gemini web? Probably simonw's strat from the top comment.
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.
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
I don't understand the reason. I thought software was supposed to be a black box when you use agents. So why care how it's implemented? Cui bono?
SoftTalker 18 hours ago [-]
> 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.
Good god.
paulirish 18 hours ago [-]
what? oh. I mean.. I wrote it all with my lil fingies, but I did pack some jargon in there. :) More plainly...
We built rigorous tests to verify this actually works, and to know when models no longer need the advice.
rewgs 17 hours ago [-]
"hill-climb" is the most aggressively LinkedIn speak I've ever encountered in the wild.
bryanrasmussen 7 hours ago [-]
User Experience - " entry/exit animations, parallax scroll, CSS scrollbar-color"
I'm getting the feeling that the user experience they want is not necessarily what I would term a good one.
ozim 8 hours ago [-]
I would rather have all this in a framework like Angular and then let agent use framework.
Of course great resource for all the others who feel they need to just go with vanilla JS.
mococa 20 hours ago [-]
More Chromish on web? No thanks.
low_tech_punk 14 hours ago [-]
I just want a single llms.txt
christophilus 14 hours ago [-]
Well, I read the title as, “Get your coding agent off.” And I thought, wow. These AI fanboys anthropomorphized the LLM a little too much here.
efields 16 hours ago [-]
Hey: this is great.
j45 22 hours ago [-]
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.
Of course, it's not perfectly implemented the same in every browser, but that's nothing new.
dazhbog 18 hours ago [-]
I ask my agent to write ES5 as I am more comfortable with it.. i need to read and maintain that slop somehow..
matthiasforstr 3 hours ago [-]
[flagged]
tonymet 20 hours ago [-]
I recommend saying "contemporary" or "suggested" for transient proposals like this. Having modern change every few years is ambiguous and cliche .
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?
"contemporary", "proposed", "suggested", "compatible" are better fit. I wouldn't dare use "advanced" because many APIs and proposals actually regress earlier behavior.
VibeBootHQ 60 minutes ago [-]
[flagged]
hezien 4 hours ago [-]
[flagged]
zhuanxyz 5 hours ago [-]
[flagged]
brodydung 14 hours ago [-]
[flagged]
TokenLat 12 hours ago [-]
[flagged]
dharmasthan 13 hours ago [-]
[flagged]
Cloudtheboi 22 hours ago [-]
[flagged]
theresanagent 21 hours ago [-]
[flagged]
xms17189 16 hours ago [-]
[flagged]
xiaoliangliang 14 hours ago [-]
[flagged]
17 hours ago [-]
k0morebi 21 hours ago [-]
[dead]
adhame 10 hours ago [-]
[flagged]
KallowayThayer 22 hours ago [-]
[flagged]
moneybunny 10 hours ago [-]
[dead]
PenguinRevolver 22 hours ago [-]
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:
https://chatgpt.com/share/6af3712a-03cc-83eb-ad1f-66dd11c886...
cyanydeez 23 hours ago [-]
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.
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.
That's fine though. Progressive enhancement, adding features to a site when they're available but still offering a working site when they're not, is how we should build web sites. That way they work for the user's device rather than the developer's opinion of what the web should do.
Working that way completely removes the decision about whether or not to use a feature because it doesn't work for some people, and moves it to a decision about whether or not it's worth adding for the users on browsers that can use it. In the past that was a real development effort cost, but today where AI writes the code the effort is much, much lower.
If you're using AI to make something but still using heuristics designed to save coding time then you really need to rethink your mental model of how to decide what gets built.
Websites created today should all use server-loaded content for the first render, small page sizes, a sub-1s loading time, progress enhancement for features, and WCAG 3.1 AAA accessibility (maybe.. at least AA though) because doing that isn't any more effort than not doing it.
Alright, that's fine and dandy. Is this the actual results of using this skill though that is being advertised here? Is it asking the agent to also make sure it's "Progressive enhancement" so the same stuff more or less works in Firefox and Safari?
If not, your whole point is kind of moot, as you have someone from Google trying to get people to write websites that'll look and/or work differently in Chrome compared to other browsers.
Unless you have specified something different, by default the skill assumes you are targeting Baseline Widely Available, which means everything has to work in all major browsers from at least 2.5 years ago.
To be clear, the skills document 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.
In most of these cases a cross-browser fallback is also documented.
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 only with some opt-in for the courageous. I don't know that I'd even enable it.
[0] https://github.com/GoogleChrome/modern-web-guidance/blob/4dd...
You have causality reversed here. If you need to detect if the page was loaded in the foreground or background, it is nuanced and (relatively) complex. Therefore it's good for your agent not to just assume document.visibilityState is all it needs to check, or you're going to be getting seemingly impossible log entries pretty quickly.
You're making this into a false binary which is wrong (the alternative to adopting Limited Availability features is not "document.visibilityState is all it needs to check"). But responding to my one example is also going to cause us to miss the point I'm making entirely.
"DO use fetchLater()..."
"Your own code MUST call fetchLater() directly..."
https://github.com/GoogleChrome/modern-web-guidance/blob/mai...
But yes, the skills do document compatibility and fallbacks well.
The mental model we've been using on the team is:
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?
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: https://nicj.net/beaconing-in-practice/
And lots of companies actually are already using `fetchLater()` in production now because of its increased reliability.
In the case of fetchLater, judging by https://nicj.net/beaconing-in-practice-fetchlater/ (which I think you intended to link actually) since I haven't come across it before, it could be implemented with fetchLater, events and a timeout, perhaps 10 LOC or so? If that's the case, then it almost never makes sense to use Chrome's own fetchLater, rather than those ~10 LOC so it's actually web-friendly instead of just Chrome friendly.
As a side-note, I'm getting increasingly wary about all the new JS APIs that seemingly gets added to our standards ONLY because they have ads/tracking interests. Used to be the people who participated in standards discussions for their ads/tracking interests came up with proper use cases and kept quiet about their erosion of privacy, but seems the mask is fully off today and we're just making browser engines for the ads companies now, yay.
Regarding corporate incentives: I was involved in the design of this API, so I know the history. It was proposed many years ago as a solution to make it easier for RUM analytics providers to measure Core Web Vitals metrics that needed to account for more than just page load (e.g. layout shifts and slow interactions can happen any time, not just during page load).
The RUM providers we worked with were reluctant to wait until page unload to send telemetry data because it resulted in too many lost beacons, so what they do instead is send beacons every few seconds with the most up-to-date payload.
The `fetchLater()` API enables them to send just one beacon, which is good for users and also reduces their server load.
It's a bit sad that browsers now have two different, "standard" APIs created entirely for the purpose of user tracking, as if things weren't already bloated enough.
I’m really glad to see this not evolve into a flame war as well.
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).
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.
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 https://googlechrome.github.io/modern-web-guidance-src/skill..." and it will fetch the index, then navigate to the most relevant documents - no MCP or npm or installation required at all.
(we could make this clearer though)
We'll make this happen. :)
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)
It’s like storing pointers/links instead of the contents
But yeah.. big corpus of valuable context × minimal agent footprint = happy place.
Also Mozilla only joined in the last few weeks, so they haven't yet had a big influence on the project (though I expect they will going forward).
https://web-platform-dx.github.io/baseline/
https://github.com/GoogleChrome/modern-web-guidance-src/blob...
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!
Thank you!
But how? Hopefully filing an issue on the modern-web-guidance-src repo is the right place? Anyway I filed one for using fromBase64 and toBase64 instead of atob and btoa.
But since you're all in on agents anyway you should consider having one look through at least all of the JS, DOM, and HTML spec commits in the last 3-5 years and automatically triaging any that are clear improvements and are not used by agents. Would be pretty straightforward.
---
Btw, I think it would be very helpful to automatically provide versions of this depending on what browsers you're targeting. I don't want to use anything that hasn't been available in all evergreen browsers for at least a year, for example; I think most developers have a similar standard, or at the very least don't want to use the bleeding edge. And while it is _possible_ to get that from your repo, it takes some effort, either writing a script or letting the agent use its own judgement for every feature. That's work you could do on your end and save the rest of us from needing to.
> Btw, I think it would be very helpful to automatically provide versions of this depending on what browsers you're targeting.
This should work today (though not exactly in the way you describe). The skill tells the agent how to interpret guides based on browser support signals it gets from context (e.g. the prompt itself, or AGENTS.md).
You can see those instructions here: https://github.com/GoogleChrome/modern-web-guidance-src/blob...
Right, my point is that I don't want to spend a bunch of time and tokens loading the skills and having the agent reason through whether they apply based on browser support. I want that to be automated so that it only loads in the first place those things that are actually applicable. Having a prose description is not a substitute for automation; it is almost always better to do things mechanically rather than asking the agent to do it, in cases where it is possible to do mechanically.
I think this matters even if you're at Google and tokens are free but it _definitely_ matters for the rest of us.
Most sites are willing to use some features as a progressive enhancement, whereas other features they won't even consider using unless it's in 99+% of their users' browsers.
And unfortunately there's no easy way to make that decision for users on a feature-by-feature basis, because it all depends on what use case they're trying to accomplish, and what will happen if the feature is not available (given that particular use case).
So our approach is to (1) explain in the guide how to implement the use case with the modern feature, (2) explain why the modern feature is the preferred solution (e.g. what the user benefit is), and then (3) explain how to implement a fallback solution if the feature is not available.
I think we could potentially experiment with some version of what you're describing, like a config option where we only surface guides that have robust, widely-available fallbacks, and where we have high confidence that it makes sense for the majority of sites to be following the recommendations in the guide.
I'll raise it with the team.
My experience differs from yours. It's true that there is some tiny fraction of features where it makes sense to do progressive enhancement, but for most sites and almost all features this does not make sense: the burden of testing and maintaining a site that effectively has multiple versions depending on what browser you're using is simply not worth it. For typical dev teams outside of Google/Meta/similar, the right thing (and the overwhelmingly common thing) is to target the intersection of features available on your supported browsers and not make any behavior conditional. I'm not interested in any guides that need fallbacks on any of the browsers I target and I expect the same is true of the typical dev team outside Google.
The more "legacy code" is getting written everyday the more the web will be forced to remain backwards compatible...
I tried to look this up and found https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S... but the example depends on JS. How are you meant to statically specify highlighted ranges without the <span> markup? If I'm syntax-highlighting code on a blog, it's seems a lot more practical to just use the old <span> system than to encode a list of character ranges in a JS array and loop to assign highlights. Plus it doesn't require the reader to run JS.
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.
https://aicoding.leaflet.pub/3majnyfydzs2y/l-quote/10.0_0-10...
Are you in the business of selling tokens/electricity/gpus by any chance? Then good for you!
But terrible for everyone else....
Even then it might be risky due to losing undocumented/untested behaviors that has been added to the software.
You can tell because I said 1996.
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.
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".
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!
I've recently finished a browser game specifically targeting an old iPad Air 1 we had lying around the house.
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.
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.
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.
Don't be a fashion driven developer. :)
This is a misconception. Have your favorite agent summarize this video for you: https://www.youtube.com/live/zcLPGC-tvgk?si=YR68aHlFESD053bh
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.
>This is a misconception. Have your favorite agent *summarize this video for you*: https://www.youtube.com/live/zcLPGC-tvgk?si=YR68aHlFESD053bh
I can't tell if you're joking here
Sure, I've seen the video before and remember many of the arguments. I don't agree with everything in Bob's approach, but I certainly agree with what he says about the value of looking at the code.
But that doesn't at all mean that people will do it.
Yes, now I can confirm I am not a crackpot when I said this: https://news.ycombinator.com/item?id=49854536
The main problem I see is that it will be extremely hard for new frameworks, languages to take off if everyone is using AI to code. It can lead to a future where all new programming languages and frameworks will be developed by LLM providers because only they, can train them with synthetic data.
With LLMs improving, they will might need less example code to work with new frameworks decently
With LLM usage becoming ubiquitous for coding, framework developers will likely start making lots of curated, high-quality synthetic examples specifically for LLM training data usage as their main documentation effort
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.
Keep your effing websites simple.
(I have much the same instinct about the UNIX philosophy. Bash is not too big. Shell programs should be even bigger so that query programs can be smaller — because otherwise they grow huge lists of options that largely overlap, for things like table formatting, and provide an inconsistent UX.)
Like HtmlFlow (Java/Kotlin) or kotlinx.html.
I pick Tailwind and Alpine.js to go with this approach because: I want to be SSR-first (with small JS-based improvements where they matter most) so NOT and SPA, i want the styling to be close to the HTML code that's being styled (no need to match between CSS definition and usage), and I also prefer to keep my tiny bits of JS close to the HTML it deals with (Alpine makes that easy and provides a clear path for implementing 99% of my JS needs).
Like everyone, LLMs code it for me :) But the result is easy to reason about for myself and my LLM. Little vanilla JS. No jQuery. Mostly just some HTML-bound Alpine instructions. And Tailwind everywhere. This way I can look at one place to see how it works: or CTRL-click my way to it.
Came up with a good list for my project
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..
On the other hand, a bit sad: programming nowadays is just arranging a bunch of Markdown files, possibly generated by another bunch of models.
Not so exciting, in the end.
https://infrequently.org/2024/11/if-not-react-then-what/
> prohibiting the spread of React (and other frameworkist totems) by policy is an incredible cost savings and a helpful way to reorient teams towards delivery for users
isn't "simple".
Why do people still leave common AI tells in their writing?
I want the browser to be the thinnest layer it can be, between me and my application, which is governed by me.
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.
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
> Create a perfect HTML contact form with address fields. Check https://developer.chrome.com/docs/modern-web-guidance/guides... — read completely, don't stop at truncation.
Good god.
We built rigorous tests to verify this actually works, and to know when models no longer need the advice.
I'm getting the feeling that the user experience they want is not necessarily what I would term a good one.
Of course great resource for all the others who feel they need to just go with vanilla JS.
Of course, it's not perfectly implemented the same in every browser, but that's nothing new.
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?
"contemporary", "proposed", "suggested", "compatible" are better fit. I wouldn't dare use "advanced" because many APIs and proposals actually regress earlier behavior.
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.