Ikke alt skal polyfilles
Hvis en feature er kosmetisk eller kun forbedrer polish, er det ofte bedre bare at lade ældre browsere få en simplere oplevelse. Polyfills og alternative implementationer giver mest mening, når det handler om noget mere centralt i interaktionen.
Scroll-driven animation er fx et sted, hvor man kan overveje ekstra hjælp. Enten ved hjælp af en polyfill* eller ved at implementere en JS-baseret løsning via eksempelvis GSAP.
<script src="https://flackr.github.io/scroll-timeline/dist/scroll-timeline.js"></script>* Polyfill er kode, der implementerer features i ældre browsere, som ikke har understøttelse. Det kan være en JavaScript-baseret løsning, der efterligner funktionaliteten af featuren, så brugere med ældre browsere stadig kan få en lignende oplevelse. Typisk indlejrer man bare en script-tag, der peger på polyfill'ens URL, og så sørger den for at tilføje den manglende funktionalitet.
if (!CSS.supports('animation-timeline: scroll()')) { // GSAP-version eller en anden fallback}Eksempel på alternativ implementering: Scroll-Driven Animation
Her er pointen ikke, at man altid skal importere noget ekstra. Pointen er, at man aktivt vælger strategi ud fra, hvor vigtig effekten er.
Et godt spørgsmål er derfor ikke kun “kan vi få det til at virke?”, men også “er det vigtigt nok til at vi bør få det til at virke overalt?”.
Praktisk tommelfingerregel
Features som text-box, text-wrap: pretty og appearance: base-select er ofte gode kandidater til ren progressive enhancement. Features der styrer mere central adfærd, som fx scroll-linked animation eller mere avancerede transitions, er oftere steder hvor du må vælge mellem fallback, alternativ teknik eller bevidst fravalg.