Chrome 154 is in beta, bringing a huge set of capabilities across CSS, JavaScript, and Web APIs → https://goo.gle/4yq2n2I This release introduces CSS scroll-marker-group modes to simplify tabbed UI patterns, new text decoration controls, and quantum-resistant algorithms in WebCrypto. You can also test responsive iframes, options bags for WebSockets, and CORS enforcement on Background Fetch. Download the beta today to start testing your web applications against these upcoming features.
Chrome for Developers
Technology, Information and Internet
Helping you build, grow, and innovate on the web.
About us
The official Chrome for Developers LinkedIn account from Google. We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users.
- Website
-
https://developer.chrome.com/
External link for Chrome for Developers
- Industry
- Technology, Information and Internet
- Company size
- 5,001-10,000 employees
Updates
-
Chrome for Developers reposted this
Back hanging out with GDG family this Sept. I'll be teaching #modernwebguidance (goo.gle/mwg) workshop! Choose from 2 sessions. Hope to see you there! - GDG Queens (9/18) https://lnkd.in/gkqr6mvz - GDG Brooklyn (9/25) https://lnkd.in/gP-Dxenj
-
Open up your app's inner workings to AI agents with custom tools in DevTools for agents→ https://goo.gle/4r5H3x7 Write plain JavaScript to build tailored third-party tools that save tokens and bypass manual steps like login forms built for humans.
-
Chrome for Developers reposted this
🔥 It was an absolute pleasure to talk about WebMCP among other AI on the web topics with Dominic Farolino on the latest SyntaxFM! Along with the rest of the internet, Wes Bos and Scott Tolinski are heroes of mine. Thank you for hosting us! https://lnkd.in/eV763bcD
WebMCP is here (and you should care)
https://www.youtube.com/
-
Chrome for Developers reposted this
I analyzed 545 websites implementing Chrome WebMCP. Across thousands of tool definitions, two common issues stand out: 1️⃣ Too Vague (970+ tool definitions flagged): Developers write 3-word descriptions like "Search products" and parameter docs like limit: "the limit", omitting units, ranges, and formats. The browser agent has to guess what is valid, passes out-of-range numbers, and triggers runtime errors. 2️⃣ Too Verbose (~400 tool definitions flagged): The opposite extreme: stuffing schemas with internal API history, changelogs, and defensive prompt shouting ("DO NOT CALL THIS IF..."). Tools balloon to 800+ tokens each, burning thousands of tokens before the user even types, slowing down execution and wasting context. The sweet spot is finding the right level of detail. Here is the Do & Don't breakdown: Scenario 1: The Vague Definition ❌ DON'T: • 3-word description ("Search products.") • Untyped or unhelpful parameter labels (limit: "the limit") • Missing ranges, formats, and units 👉 Result: The agent has to guess syntax and ranges. It might pass limit: 5000 or "ten", crashing your handler. ✅ DO: • 1-2 sentence functional scope (what it searches & returns) • Explicit inputSchema bounds (minimum: 1, maximum: 50, default: 10) • Declared units (USD, ISO dates) 👉 Result: High-signal scope + explicit bounds = zero guesswork. Scenario 2: The Verbose Definition ❌ DON'T: • 250-word documentation essays & API history • Shouting negative prompt guardrails ("DO NOT CALL THIS IF...") • Dumping tutorial trivia into tool descriptions 👉 Result: Burns 800+ tokens per tool, and agents under load often ignore negative prompt shouting anyway. ✅ DO: • Lean 1-sentence action summary • Use enum in inputSchema instead of paragraphs of rules • Enforce constraints in your JavaScript handler, not in prompt essays 👉 Result: Drops token usage by 89% (800+ down to 85 tokens) with clear, structured choices. 💡 4 Rules for WebMCP Tool Definitions: 1. 1-2 Sentence Scope: State what it does, when to pick it, and what it returns. 2. Explicit Bounds & Types: Always set type, min/max, default, or enum constraints in inputSchema. 3. Specify Units & Formats: Never leave currency or dates ambiguous (amountUsd, ISO formats). 4. Validate in Code, Not Prompts: Handle limits and retries in your JavaScript handler, not in prompt essays. How are you balancing detail vs. token budget in your WebMCP tools? Let's discuss in the comments. Kasper Kulikowski #WebMCP #WebDevelopment #AI
-
-
Confirm page engagement states confidently using the standard UserActivation API → https://goo.gle/4r3DGqz (docs) / https://goo.gle/4r53Kl8 (demo) Browsers require that for certain operations like copying to the clipboard, starting media autoplay, activating fullscreen mode, or triggering device vibration, users must explicitly interact with the page, to prevent abusive behavior. With the UserActivation API established as a widely available baseline feature, you can now consistently evaluate interaction history – transient or sticky – to determine whether these protected APIs are allowed to execute.
-
Earlier this year, we announced our plan to shift Chrome from a four- to a two-week release cycle with the goal of delivering new features, performance improvements, and bug fixes faster. Today we're putting that plan into action with the launch of Chrome 153 on Desktop, Android, and iOS.
-
Chrome for Developers reposted this
📢 Google Chrome is moving to a 2 week release cycle! More in https://goo.gle/4r2mmSK Also, a short history on browser update frequency: • 2001: MSFT shipped IE6 & didn't release a major update for 5+ YEARS! Safari updated ~annually • 2010: Chrome commits to 6-week releases & automatic updates. (People called us crazy.) • 2021: Chrome updates to 4-week releases. (People said it was too fast.) • 2026: Chrome goes to 2-week releases. (Opinions TBD :) Release early, release often for fresher features and faster fixes... especially important with AI vuln discovery! 💪
-
Chrome for Developers reposted this
I’m excited to share that we've added a consequential hint to the WebMCP spec! Here’s what you need to know about it: For site devs: consequentialHint should be set to true when WebMCP tools may perform a high-stakes action: anything that might need explicit user permission in order to execute. If you’re going to make a purchase, send an email, or book travel, it would be beneficial to set this to true. annotations: { consequentialHint: true } For agent/model devs: the agent should regard this hint as a time to take a step back, ask for user verification- if there’s an alignment tool critic, it should be judging whether or not a consequential action is appropriate given the user’s request. The interesting thing about hints like this, unlike other web specs, is that both the site and the agent have to get it right for this to work well. If one side exposes a hint and the other doesn’t honor it, it’s not doing much. And alternatively, if the site dev doesn’t expose but the agent is looking for it… you get it. But combined, it’s powerful. It can create a safeguard against generating an action a user might not want or be expecting. And it gives more tools to developers to have precision in what should be occurring on their site. So the collective effect can keep users safer. Further reading: https://lnkd.in/eVse3Hun Remember, this is a proposed hint only. It will be adopted only if we are confident people will use it. Origin Trial feedback is important. Thanks to Johann Hofmann for the initial proposal: https://x.com/johannh And François Beaufort and Alexandra Klepper AlexandraScript@ for the docs!