BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.5.8//EN
CALSCALE:GREGORIAN
LAST-MODIFIED:20260219T070840Z
BEGIN:VTIMEZONE
TZID:Asia/Tokyo
X-MICROSOFT-CDO-TZID:20
BEGIN:STANDARD
DTSTART:20241116T233000
TZOFFSETFROM:+0900
TZOFFSETTO:+0900
TZNAME:JST
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:95b89f3d-1494-4f0e-9968-53fdf15945dc
DTSTAMP:20260219T070840Z
SUMMARY:Accelerating the adoption of modern web features\, and migrating aw
 ay from outdated approaches
DTSTART;TZID=Asia/Tokyo:20251112T083000
DTEND;TZID=Asia/Tokyo:20251112T093000
DESCRIPTION:https://www.w3.org/events/meetings/95b89f3d-1494-4f0e-9968-53fd
 f15945dc/\n\nThe web platform's evolution is often faster than developer p
 ractices. This lag creates a two-part problem that slows the adoption of m
 odern APIs and leaves unnecessary bloat on the web:\n\n1. **The "sticky po
 lyfill" problem**: A feature (e.g.\, `IntersectionObserver`) becomes Basel
 ine\, but developers continue to ship unnecessary polyfills and fallbacks 
 for it\, sometimes for years. The `IntersectionObserver` polyfill\, for ex
 ample\, still gets over 2.1 million weekly downloads despite the feature b
 eing Baseline for over 6.5 years.\n\n2. **The "reluctant adoption" problem
 **: A new\, powerful feature (e.g.\, the `Scheduler` API) is available\, b
 ut because it is not yet Baseline\, developers may be reluctant to use it\
 , even when robust polyfills and fallback strategies exist. Those strategi
 es should be easily discoverable to developers and integrated with their t
 ools.\n\nBoth problems hold back the web and share a common root: the lack
  of a structured\, machine-readable data source that maps "old ways" (spec
 ific polyfill packages\, legacy patterns) to their "new way" modern API co
 unterparts.\n\nThis session proposes we create one.\n\nIf tooling (IDEs\, 
 linters\, framework CLIs\, browser DevTools) had a "Rosetta Stone" dataset
 \, it could\, for example:\n\n- Detect the `IntersectionObserver` polyfill
 \, query this dataset\, see the native API is Baseline\, and confidently r
 ecommend removing the polyfill.\n- See a use case for the `Scheduler` API\
 , query the dataset\, and suggest a progressive enhancement strategy that 
 safely encourages immediate adoption.\n\n**Goal(s):**\nThis session is a w
 orking discussion to brainstorm this dataset: what it should contain\, whe
 re it could live\, and how we can collaborate to build and maintain it to 
 accelerate the entire web forward.\n\nAgenda\n\n**Materials:**\n- [Session
  proposal on GitHub](https://github.com/w3c/tpac2025-breakouts/issues/76)
STATUS:CONFIRMED
CREATED:20251028T131711Z
LAST-MODIFIED:20260219T070840Z
SEQUENCE:3
ORGANIZER;CN=W3C Calendar;PARTSTAT=ACCEPTED;ROLE=NON-PARTICIPANT:mailto:nor
 eply@w3.org
LOCATION:Floor 5 - 505
CATEGORIES:TPAC 2025,Breakout Sessions
END:VEVENT
END:VCALENDAR
