✨ Can I Use integration for language service

[itsezc]

Description

Add support for "Can I Use" (https://caniuse.com/) with inline documentation for classes highlighting the following:

• Description of the feature
• % of Global population
• Notes and issues

[0Miles]

Design RFC — three data-source options for Can I Use integration

The decision blockers are license, bundle size, and freshness cadence. Resolved by picking a data source.

Option 1 — bundle `caniuse-lite` (recommended)

The same dataset Browserslist + Autoprefixer use.

• License: CC-BY-4.0 (permissive; just needs attribution in docs/UI)
• Size: ~360KB unminified JSON, ~80KB after pruning to features Master CSS cares about (CSS properties + at-rules + selectors)
• Freshness: refreshed weekly via npm; we just bump the dep
• Loads as a static `Map<string, CompatData>` at `@master/css-language-service` startup

Wire-up:

// language-service hover handler
const compat = caniuse.feature('css-grid')
hoverContents.push({ kind: 'markdown', value: renderCompatTable(compat) })

Option 2 — fetch from caniuse.com at runtime

• No bundle cost
• Requires network — language servers should be offline-friendly. Big DX downgrade
• Caniuse doesn't ship a stable public API; scraping is brittle

Option 3 — curated subset (logical-properties, view-transitions, container-queries, color-mix, oklch, etc.)

• Bundle size minimal (~5KB)
• Lose breadth; user can't get info on properties we didn't curate

Recommendation

Go with Option 1, scoped to language-service only. This package is already a heavy dev-time dep (LSP server, css-tree, vscode-uri); +80KB is noise. End-user runtimes (`@master/css`, `@master/css-runtime`) don't load it.

Implementation sketch

1. Add `caniuse-lite` as devDep + runtime dep of `@master/css-language-service`
2. Build-time prune: `scripts/prune-caniuse.ts` walks `config/rules.ts` keys, emits a smaller JSON with only the features Master CSS knows about
3. New `utils/render-compat-tooltip.ts` formats a markdown table per browser
4. Hover handler in `language-service/src/feature/inspect-syntax.ts` calls it and appends to existing hover content
5. Disable behind `settings.compatibility = false` for users who don't want it

Estimated work: ~1.5 days. Happy to draft.

Outstanding question for maintainer: should the compat tooltip respect a user-configured `browserslist` so warnings for unsupported targets are highlighted? My vote: yes, opt-in via setting.