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."

▲ philipwalton 2 hours ago | parent | next [-]

> 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.

▲

surround 2 hours ago | parent | next [-]

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..."

https://github.com/GoogleChrome/modern-web-guidance/blob/mai...

But yes, the skills do document compatibility and fallbacks well.

▲

philipwalton an hour ago | parent [-]

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.

	▲	cma 21 minutes ago \| parent [-]
		I think I can guess from corporate incentives why Chrome supports fetchLater and some others don't.

▲

hatthew 32 minutes ago | parent | prev [-]

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).

▲ hackingonempty an hour ago | parent | prev [-]

How about details/summary?