CSS Scroll Snap giver websteder mulighed for at fastgøre websiden eller enhver anden rullebeholder til en bestemt rulleposition, når brugeren udfører en rullehandling. Denne funktion har været understøttet i alle moderne browsere i over to år, men mange websteder, der kunne drage fordel af det, bruger det stadig ikke.
Scroll snapping er nok mest forbundet med vandrette karruseller (se Chris's CSS-kun tilgang) og bestemte websider opdelt i fuldskærmsdias. Men hvorfor stoppe der? Jeg tror, at snapping kan forbedre rulleoplevelsen på enhver webside, der opstiller elementer i et gitter eller feed.
For eksempel viser de fleste shoppingwebsteder produkter i et gitter. Ideelt set vil brugeren gerne hoppe mellem gitterrækkerne med minimal indsats. Brugeren kan trykke på Space at rulle siden med nogenlunde én skærm (viewport-højde), men afhængigt af højden af gitterrækkerne, vil rullepositionen til sidst blive "ude af sync" med gitteret, og brugeren bliver nødt til at justere den manuelt.
Hvis vi tilføjer scroll snapping til denne side, kan brugeren konsekvent rulle til næste række med Space tast (tryk på Flytte + Space vil rulle til forrige række). Det er ret ubesværet.
Jeg tror, at scroll snapping ville være en velkommen tilføjelse til denne hjemmeside. Og det er ikke engang så kompliceret at implementere. CSS-koden, som jeg brugte til dette eksempel, er relativt enkel:
html {
scroll-snap-type: y proximity;
}
.product-item {
scroll-snap-align: start;
scroll-margin-top: 75px; /* height of web page’s sticky header */
}Du behøver ikke vente, hvis et websted, du besøger regelmæssigt, endnu ikke har tilføjet scroll snapping, og du tror, det ville forbedre din rulleoplevelse. Du kan selv tilføje scroll snapping - med brugerstile.
Tilføjelse af brugerstile til websteder
I videoen ovenfor kan du se, at jeg valgte en user.css-fil i Safaris avancerede præferencer. Denne fil er et brugertypografiark. Den indeholder CSS-stilarter, som jeg har skrevet, gemt i en lokal .css fil og føjet til Safari. Disse "brugerstile" anvendes derefter på hver webside, jeg åbner i Safari.
Chrome og Firefox tillader ikke brugere at vælge et brugertypografiark. Firefox understøttede en lignende funktion kaldet userContent.css tidligere, men den funktion blev forældet og er deaktiveret som standard i 2019. Jeg anbefaler Stylus browserudvidelse for disse to browsere (og andre Chromium-baserede browsere).
En væsentlig fordel ved Stylus er, at den giver dig mulighed for at skrive brugerstile til specifikke websteder og URL'er. Safaris brugerstilark gælder for alle hjemmesider, men det kan omgås, fx ved at bruge det nye :has() pseudo-klasse til oprette vælgere, der kun matcher bestemte websteder.
CSS Cascading-modulet definerer en Brugeroprindelse for stilarter, som brugeren tilføjer. Safaris brugerstilark tilhører denne oprindelse, men Stylus-udvidelsen injicerer brugerstile til Author Origin, hvor hjemmesidens typografiark lever. Konkret indsætter Stylus brugerstile direkte på siden via en <style> element i slutningen af <html> hvilket gør det til sidste stilark på siden. Teknisk set betyder det, at stilarter tilføjet via Stylus klassificeres som forfatterstile, da de ikke er i User Origin, men jeg vil fortsætte med at kalde dem brugerstile, fordi brugeren tilføjer dem.
Det er dog værd at holde denne sondring i tankerne, fordi den påvirker kaskaden. Når vælgerspecificiteten er ens, er en rigtig brugerstil svagere end sidens egen stil. Dette gør brugerstile til en fremragende passer til brugerstandarder. Under de samme betingelser er en stil tilføjet via Stylus stærkere end sidens stil, så Stylus kan ikke så let bruges til at definere brugerstandarder.
Hvis vi tilføjer !important til blandingen er både rigtige brugerstile og stile tilføjet via Stylus stærkere end sidens stile. Så når du vil påtvinge dine brugerstile på et websted, er det lige meget, om du bruger Safaris "Stilark"-indstilling eller Stylus-udvidelsen. Din !important stilarter vil vinde begge veje.
I næste afsnit vil jeg bruge et sæt af !important brugerstile til at gennemtvinge scroll snapping på tidslinjesiden på Twitters hjemmeside. Mit mål er at fremskynde processen med at læse min Twitter-tidslinje ved at undgå akavede rullepositioner, hvor det øverste tweet kun er delvist på skærmen.
Rul snap for Twitters tidslinje
Efter nogle eksperimenter har jeg besluttet mig for følgende CSS-kode. Disse stilarter fungerer godt i Firefox, men jeg har oplevet nogle problemer i Chrome og Safari. Jeg vil beskrive disse problemer mere detaljeret senere i artiklen, men for nu, lad os fokusere på adfærden i Firefox.
html {
scroll-snap-type: y mandatory !important;
}
/* tweets in the timeline are <article> elements */
article {
scroll-snap-align: start !important;
}
/* un-stick the sticky header and make it “snappable” as well */
[aria-label="Home timeline"] > :first-child {
position: static !important;
scroll-snap-align: start !important;
}
/* hide the “new Tweets available” floating toast notification */
[aria-label="New Tweets are available."] {
display: none !important;
}Det er nødvendigt at tilføje !important til hver erklæring, fordi alle brugerstile skal vinde over websidens egne stilarter, for at vores tilpassede scroll snapping-implementering fungerer korrekt. Jeg ville ønske det i stedet for at skrive gentagne gange !important, jeg kunne bare lægge mine brugerstile i et "vigtigt lag", men sådan en CSS-funktion findes ikke (endnu).
Se videoen nedenfor for at se mine scroll snap-brugerstile i aktion. Læg mærke til, hvordan hvert tryk på Space tasten ruller det næste sæt tweets til syne, og det første tweet i hvert sæt er justeret til den øverste kant af viewporten. Dette giver mig mulighed for at læse min tidslinje hurtigere. Når jeg skal tilbage til det forrige sæt tweets, kan jeg trykke Flytte + Space.
Det, jeg godt kan lide ved denne type scroll snapping er, at det giver mig mulighed for at forudsige, hvor langt siden vil rulle, når jeg trykker på Space. Hver rulleafstand svarer til de kombinerede højder af de synlige tweets, der er helt på skærmen. Med andre ord vil det delvist synlige tweet i bunden af skærmen flytte til toppen af skærmen, hvilket er præcis det, jeg ønsker.
Space vil rulle Daves tweet til toppen af skærmen.For at prøve mine scroll snap-brugerstile på din egen Twitter-tidslinje, følg disse trin:
- Installer Stylus forlængelse med Firefox-tilføjelser eller Chrome Webshop.
- Naviger til din Twitter-tidslinje på https://twitter.com/home.
- Klik på Stylus-ikonet i browserens værktøjslinje, og klik på "denne URL" i pop op-vinduet.
- Stylus åbner en kodeeditor i en ny browserfane. Kopier-indsæt mine scroll snap-brugerstile i editoren og tryk på knappen Gem i sidebjælken til venstre. Stilarterne vil blive anvendt på din Twitter-tidslinje med det samme (ingen grund til at genindlæse siden).
- Du kan til enhver tid opdatere stilene. Klik på Stylus-ikonet og blyantikonet for at åbne editoren igen.
Manglende evne til at tilsidesætte snapping
Min implementering af scroll snapping til Twitters tidslinje har en stor fejl. Hvis et tweet er højere end viewporten, er det umuligt at rulle siden for at afsløre den nederste del af det tweet (f.eks. hvis du vil like eller retweete det tweet), fordi browseren med kraft snapper siden for at vise toppen af tweet (eller toppen af det følgende tweet).
Alvoren af dette problem afhænger af brugerens skærm. Når du ser Twitters tidslinje på en stor skrivebordsskærm med en lille sidezoomfaktor, vil du muligvis ikke støde på nogen tweets, der er højere end viewporten.
Jeg har spurgt CSS-arbejdsgruppen, om det ville være muligt at tilføje en mekanisme, der gør det muligt for brugeren tilsidesætte browserens obligatoriske scroll snapping. Jeg skal nok nævne, at dette problem i hvert fald i teorien kunne løses ved at skifte fra mandatory til proximity snapper. Jeg har testet proximity snapping i Chrome og Firefox, og jeg fandt det inkonsekvent og forvirrende. Browseren snappede ofte, når jeg ikke havde forventet det, og omvendt. Måske forstyrrer Twitters kode proximity algoritme, browserne er stadig en smule buggy, eller måske "ruller jeg det forkert", hvis det overhovedet er muligt. Jeg ved ikke.
Men hovedårsagen til, at jeg gik med mandatory snapping er, at jeg ville undgå situationer, hvor det øverste tweet kun er delvist på skærmen efter en rulning. Den type hurtigscrollning mellem sæt tweets, som jeg har vist i videoen ovenfor, er kun mulig med mandatory snapper.
Hvis du, ligesom jeg, foretrækker det mandatory snapping, kan jeg foreslå følgende to løsninger til problemet med "høj tweet":
- Du kan åbne tweetet på sin egen side og vende tilbage til tidslinjen bagefter.
- Hvis du kun vil klikke på Like eller Retweet-knapperne, kan du Flytte-klik på tweetet for at vælge det, og tryk derefter på L at kunne lide det, eller T efterfulgt af Indtast at retweete det.
Problemer i Chrome og Safari
Mine scroll snap-brugerstile producerer mærkbart anderledes scroll snap-adfærd i Chrome, Safari og Firefox. Disse forskelle skyldes til dels den nøjagtige implementering af snapping-mekanismen overlades til browseren:
CSS Scroll Snap-modulet specificerer eller pålægger med vilje ikke nogen præcise animationer eller fysik, der bruges til at håndhæve snappositioner; dette overlades til brugeragenten.
Den aktuelle version af Safari har en fejl, der forhindrer scroll snapping i at fungere korrekt på Twitters tidslinje. jeg har rapporterede denne fejl.
I Chrome er jeg stødt på følgende problemer:
- Rulleoperationerne animerer inkonsekvent. Nogle gange er animationen langsom, nogle gange er den øjeblikkelig, og nogle gange starter den langsomt, men afbrydes derefter. Jeg fandt det irriterende.
- Rulleoperationerne animerer generelt for langsomt. Jeg udførte en test i Chrome og Firefox (20 Space trykker), og det tog mig 70 % længere tid at tilbagelægge den samme afstand på min Twitter-tidslinje i Chrome end i Firefox (18.5 sekunder i Chrome vs. 11 sekunder i Firefox).
- Når jeg scroller ved hjælp af min bærbares pegefelt, flimrer siden meget. Når jeg forsøger at rulle hurtigt ved at holde nede Space tast, ruller siden meget langsomt og svinger. Jeg formoder, at begge problemer er forårsaget af den samme algoritme. Det ser ud til, at Chrome gen-snapper med en meget høj hastighed i disse tilfælde. jeg har rapporterede denne fejl.
Disse browserfejl og forskelle mellem browsere kan være et problem for websteder, der overvejer at implementere scroll snapping. For eksempel kan en webudvikler holde sig tilbage, fordi de ikke kan lide, hvordan scroll snapping opfører sig i en bestemt browser. Browsere kan afhjælpe dette problem ved at blive mere interoperable. Faktisk er Scroll Snap et af fokusområderne i cross-browseren Interop 2022 indsats.
En anden måde, hvorpå situationen kan forbedres, er ved at introducere nye CSS-egenskaber, der ville gøre scroll-snapping mere konfigurerbar. Dette kunne omfatte varigheden af snapping-animationen, længden af nærhedsgrænsen for snapping og en mekanisme til at tilsidesætte obligatorisk snapping.
At knipse eller ikke at knipse?
Jeg har brugt mine scroll snap-brugerstile på Twitters tidslinje i et par uger, og jeg ønsker ikke at gå tilbage. Evnen til hurtigt at bladre gennem mit feed med kun Space nøglen er bare på et andet niveau.
Jeg betragter dette dog som en avanceret funktion, som sandsynligvis ikke er for alle. Der er en grund til, at jeg kun har aktiveret det på tidslinjen (/home sti) og ingen andre steder på Twitters hjemmeside. Snapping er en væsentlig ændring i, hvordan siden ruller, og det tager lidt tid at vænne sig til. Det kan fungere godt til en specifik use case, men det kan også komme i vejen og frustrere brugeren.
Hjemmesider med feeds bør derfor overveje kun at tilbyde scroll snapping som en valgfri funktion, efter nøje overvejelse og masser af test i forskellige browsere og med forskellige inputmetoder (mus, tastatur, pegefelt, touchskærm osv.).
Før du går…
Endelig anbefaler jeg stærkt at installere og prøve Stylus browserudvidelse. Webudviklere (eller nogen, der kender CSS) har magten til at style ethvert websted i deres browser. Du kan anvende mindre forbedringer og rettelser på dine yndlingswebsteder. Jeg bruger det mest til at skjule sideelementer, som jeg synes er irriterende, såsom sticky headers, video-pop-ups og stemmetælling.
Men endnu vigtigere, Stylus giver dig mulighed for hurtigt at teste nye CSS-funktioner på ethvert websted og rapportere browserfejl, hvis det er nødvendigt. Ved at gøre dette kan du være med til at gøre webplatformen lidt bedre.
