Innan karriären hoppade in i utvecklingen gjorde jag en massa rörlig grafik i After Effects. Men även med den bakgrunden tyckte jag fortfarande att animering på webben var ganska förbryllande.
Videografik designas inom ett specifikt förhållande och exporteras sedan ut. Gjort! Men det finns inga "exportinställningar" på webben. Vi trycker bara ut koden i världen och våra animationer måste anpassas till vilken enhet de än landar på.
Så låt oss prata responsiv animation! Hur närmar vi oss bäst animering på den vilda vilda webben? Vi kommer att täcka några allmänna tillvägagångssätt, några GSAP-specifika tips och några rörelseprinciper. Låt oss börja med lite inramning...
Hur kommer denna animation att användas?
Zach Sauciers artikel om responsiv animation rekommenderar att du tar ett steg tillbaka för att tänka på det slutliga resultatet innan du hoppar in i koden.
Kommer animeringen att vara en modul som upprepas i flera delar av din applikation? Behöver den skalas överhuvudtaget? Att ha detta i åtanke kan hjälpa till att bestämma metoden för vilken en animation ska skalas och hindra dig från att slösa bort ansträngning.
Detta är ett bra råd. A stor en del av att designa responsiv animering är att veta om och hur den animeringen behöver skalas, och sedan välja rätt tillvägagångssätt från början.
De flesta animationer faller inom följande kategorier:
- Fast: Animationer för saker som ikoner eller laddare som behåller samma storlek och bildförhållande på alla enheter. Inget att oroa sig för här! Hårdkoda några pixelvärden där och fortsätt med din dag.
- Vätska: Animationer som behöver anpassas flytande över olika enheter. De flesta layoutanimationer faller inom denna kategori.
- Målinriktad: Animationer som är specifika för en viss enhet eller skärmstorlek, eller ändras avsevärt vid en viss brytpunkt, till exempel animeringar endast för skrivbordet eller interaktioner som förlitar sig på enhetsspecifik interaktion, som beröring eller hovring.
Flytande och riktade animationer kräver olika sätt att tänka och lösningar. Låt oss ta en titt…
Flytande animation
As Andy bell säger: Var webbläsarens mentor, inte dess mikrohanterare – ge webbläsaren några solida regler och tips och låt den sedan fatta rätt beslut för de personer som besöker den.
(Här är bilderna från den presentationen.)
Flytande animering handlar om att låta webbläsaren göra det hårda arbetet. Många animationer kan enkelt anpassas till olika sammanhang bara genom att använda rätt enheter från början. Om du ändrar storleken på denna penna kan du se att animationen använder visningsenheter skalas smidigt när webbläsaren justerar:
Den lila rutan ändrar till och med bredd vid olika brytpunkter, men eftersom vi använder procentsatser för att flytta den, skalas animeringen också med den.
Animerande layoutegenskaper som left och top kan orsaka layoutomsvängningar och skakig "jävla" animering, så håll dig till transformationer och opacitet där det är möjligt.
Vi är dock inte bara begränsade till dessa enheter – låt oss ta en titt på några andra möjligheter.
SVG-enheter
En av de saker jag älskar med att arbeta med SVG är att vi kan använda SVG-användarenheter för animering som är lyhörda direkt. Ledtråden finns i namnet egentligen - Skalbar Vektorgrafik. I SVG-land är alla element plottade på specifika koordinater. SVG-utrymme är som en oändlig bit av millimeterpapper där vi kan ordna element. De viewBox definierar måtten på det millimeterpapper vi kan se.
viewBox="0 0 100 50”I nästa demo, vår SVG viewBox is 100 enheter breda och 50 enheter hög. Detta betyder om vi animerar elementet genom 100 enheter längs x-axeln, kommer den alltid att röra sig med hela bredden av sin överordnade SVG, oavsett hur stor eller liten den SVG är! Ge demot en storleksändring för att se.
Att animera ett underordnat element baserat på en överordnad containers bredd är ett litet trick i HTML-land. Fram till nu har vi varit tvungna att ta tag i förälderns bredd med JavaScript, vilket är tillräckligt enkelt när du animerar from en förvandlad position, men lite krångligare när du animerar to någonstans som du kan se i följande demo. Om din slutpunkt är en transformerad position och du ändrar storlek på skärmen, måste du justera den positionen manuellt. Stökigt... 🤔
Om du justerar värden när du ändrar storlek, kom ihåg att avstudsa, eller till och med aktivera funktionen efter att webbläsaren har ändrat storlek. Ändra storlek på lyssnare avfyrar massor av händelser varje sekund, så att uppdatera egenskaper för varje händelse är mycket arbete för webbläsaren.
Men den här animerade fartbulten kommer snart att vara ett minne blott! Trumrulle tack... 🥁
Containerenheter! Härliga grejer. När jag skriver detta fungerar de bara i Chrome och Safari – men när du läser det här kanske vi har Firefox också. Kolla in dem i aktion i nästa demo. Titta på de där små killarna går! Är inte det spännande, animation som är relativt till föräldraelementen!
Den här webbläsarens stöddata kommer från Kan jag använda, som har mer detaljer. En siffra indikerar att webbläsaren stöder funktionen i den versionen och uppåt.
Desktop
| krom | firefox | IE | kant | Safari |
|---|---|---|---|---|
| 105 | Nej | Nej | 105 | 16.0 |
Mobil / surfplatta
| Android Chrome | Android Firefox | Android | iOS Safari |
|---|---|---|---|
| 106 | Nej | 106 | 16.0 |
Flytande layoutövergångar med FLIP
Som vi nämnde tidigare, i SVG-land är varje element snyggt placerat på ett rutnät och verkligen lätt att flytta runt på ett responsivt sätt. I HTML-land är det mycket mer komplext. För att bygga responsiva layouter använder vi oss av ett gäng olika positioneringsmetoder och layoutsystem. En av de största svårigheterna med att animera på webben är det mycket ändringar i layouten är omöjliga att animera. Kanske måste ett element flyttas från position relative till fixed, eller så måste några barn till en flexbehållare smidigt blandas runt visningsporten. Kanske måste ett element till och med ändras och flyttas till en helt ny position i DOM.
Knepigt va?
Väl. FLIP-tekniken är här för att rädda dagen; det gör att vi enkelt kan animera dessa omöjliga saker. Grundförutsättningen är:
- Förnamn: Ta tag i startpositionen för elementen som är involverade i övergången.
- Efternamn: Flytta elementen och ta den slutliga positionen.
- Invertera: Räkna ut förändringarna mellan det första och sista tillståndet och tillämpa transformationer för att invertera elementen tillbaka till deras ursprungliga position. Detta gör att det ser ut som om elementen fortfarande finns i först position men det är de faktiskt inte.
- Spela: Ta bort de inverterade transformationerna och animera till deras förfalskade först staten till sista tillstånd.
Här är en demo som använder GSAP:s FLIP-plugin som gör allt det tunga lyftet åt dig!
Om du vill förstå lite mer om vaniljimplementeringen, gå till Paul Lewis blogginlägg — han är hjärnan bakom FLIP-tekniken.
Flytande skalning SVG
Du fick mig... det här är inte verkligen ett animationstips. Men att ställa in scenen korrekt är absolut nödvändigt för bra animation! SVG skalar superfint som standard, men vi kan styra hur det skalas ytterligare med preserveAspectRatio, vilket är väldigt praktiskt när SVG-elementets bildförhållande och viewBox bildförhållandet är olika. Det fungerar ungefär på samma sätt som background-position och background-size fastigheter i CSS. Deklarationen består av ett anpassningsvärde (background-position) Och en Möt or Skiva referens (background-size).
När det gäller dessa Meet and Slice-referenser — slice är som background size: coveroch meet är som background-size: contain.
preserveAspectRatio="MidYMax slice"— Rikta in mot mitten av x-axeln, botten av y-axeln, och skala upp för att täcka hela vyporten.preserveAspectRatio="MinYMin meet"— Rikta in till vänster om x-axeln, toppen av y-axeln, och skala upp samtidigt som du behåller helaviewBoxsynliga.
Tom Miller tar detta ett steg längre genom att använda overflow: visible i CSS och ett innehållande element för att avslöja "stage left" och "stage right" samtidigt som höjden begränsas:
För responsiva SVG-animationer kan det vara praktiskt att använda SVG-vyrutan för att skapa en vy som beskärs och skalas under en viss webbläsarbredd, samtidigt som du avslöjar mer av SVG-animeringen till höger och vänster när webbläsaren är bredare än så. tröskel. Vi kan uppnå detta genom att lägga till overflow synligt på SVG och slå ihop det med en
max-heightomslag för att förhindra att SVG skalas för mycket vertikalt.
Flytande skalande duk
Canvas är mycket mer prestanda för komplexa animationer med Föremål av rörliga delar än att animera SVG eller HTML DOM, men det är också mer komplext. Du måste arbeta för dessa prestationsvinster! Till skillnad från SVG som har underbara lyhörda enheter och skalas ur lådan, måste bossas runt och mikrostyras lite.
Jag gillar att ställa in min så att det fungerar ungefär på samma sätt som SVG (jag kan vara partisk) med ett härligt enhetssystem att arbeta inom och ett fast bildförhållande. måste också ritas om varje gång något ändras, så kom ihåg att fördröja omritningen tills webbläsaren har ändrat storlek, eller hoppa av!
George Francis satte också ihop detta härligt litet bibliotek som låter dig definiera en Canvas viewBox attribut och preserveAspectRatio — precis som SVG!
Riktad animation
Du kan ibland behöva ta en mindre flytande och mer riktad inställning till din animation. Mobila enheter har mycket mindre fastigheter och mindre animationsjuice prestandamässigt än en stationär dator. Så det är vettigt att visa reducerad animering till mobilanvändare, eventuellt till och med ingen animering:
Ibland är den bästa responsiva animationen för mobil ingen animation alls! För mobil UX, prioritera att låta användaren snabbt konsumera innehåll jämfört med att vänta på att animationer ska slutföra. Mobilanimationer bör förbättra innehåll, navigering och interaktioner snarare än att fördröja det. Eric van Holtz
För att göra detta kan vi använda mediafrågor för att rikta in oss på specifika visningsportstorlekar precis som vi gör när vi stylar med CSS! Här är en enkel demo som visar en CSS-animation som hanteras med hjälp av mediafrågor och en GSAP-animation som hanteras med gsap.matchMedia():
Enkelheten i denna demo döljer en massa magi! JavaScript-animationer kräver lite mer installation och rensning för att fungera korrekt på endast en specifik skärmstorlek. Jag har sett skräck i det förflutna där folk bara har gömt animationen från visning i CSS med opacity: 0, men animationen tuffar fortfarande iväg i bakgrunden och använder resurser. 😱
Om skärmstorleken inte stämmer överens längre, måste animationen dödas och släppas för sophämtning, och de element som påverkas av animeringen måste rensas från alla rörelseintroducerade inline-stilar för att förhindra konflikter med annan stil. Fram till gsap.matchMedia(), det här var en krånglig process. Vi var tvungna att hålla reda på varje animation och hantera allt detta manuellt.
gsap.matchMedia() istället låter dig enkelt stoppa in din animationskod i en funktion som bara körs när en viss media fråga tändstickor. Sedan, när det inte längre matchar, alla GSAP-animationer och ScrollTriggers i den funktionen återställs automatiskt. Mediefrågan som animationerna visas i gör allt det hårda arbetet åt dig. Det är i GSAP 3.11.0 och det är en game changer!
Vi är inte bara begränsade till skärmstorlekar heller. Det är en massor av mediafunktioner där ute att haka på!
(prefers-reduced-motion) /* find out if the user would prefer less animation */
(orientation: portrait) /* check the user's device orientation */
(max-resolution: 300dpi) /* check the pixel density of the device */I följande demo har vi lagt till en check för prefers-reduced-motion så att alla användare som tycker att animation är förvirrande inte blir besvärade av saker som susar runt.
Och kolla in Tom Millers andra roliga demo där han använder enhetens bildförhållande för att justera animeringen:
Tänker utanför boxen, bortom skärmstorlekar
Det finns mer att tänka på responsiv animering än bara skärmstorlekar. Olika enheter tillåter olika interaktioner, och det är lätt att hamna i lite härva när man inte tänker på det. Om du skapar hovringstillstånd i CSS kan du använda hover mediafunktion för att testa om användarens primär inmatningsmekanism kan sväva över element.
@media (hover: hover) {
/* CSS hover state here */
}Några råd från Jake Whiteley:
Ofta baserar vi våra animationer på webbläsarens bredd, vilket gör det naiva antagandet att datoranvändare vill ha hovringstillstånd. Jag har personligen haft många problem tidigare där jag skulle byta till skrivbordslayout >1024px, men kan göra beröringsdetektering i JS – vilket leder till en missmatchning där layouten var för stationära datorer, men JS var för mobiler. Nuförtiden lutar jag mig mot svävaren och pekaren för att säkerställa paritet och hantera ipad-proffs eller fönsterytor (vilket kan ändra pekarens typ beroende på om locket är nere eller inte)
/* any touch device: */
(hover: none) and (pointer: coarse)
/* iPad Pro */
(hover: none) and (pointer: coarse) and (min-width: 1024px)Jag kommer sedan att slå ihop mina CSS-layoutfrågor och mina JavaScript-frågor så jag överväger inmatningsenheten som den primära faktorn uppburen efter bredd, snarare än tvärtom.
ScrollTrigger-tips
Om du använder GSAP ScrollTrigger-plugin, det finns ett praktiskt litet verktyg som du kan ansluta till för att enkelt urskilja enhetens beröringsfunktioner: ScrollTrigger.isTouch.
0- inte röra (endast pekare/mus)1- endast beröring enhet (som en telefon)2– enheten kan acceptera Rör ingång och muspekare (som Windows-surfplattor)
if (ScrollTrigger.isTouch) {
// any touch-capable device...
}
// or get more specific:
if (ScrollTrigger.isTouch === 1) {
// touch-only device
}Ett annat tips för responsiv rullningsutlöst animering...
Följande demo nedan flyttar ett bildgalleri horisontellt, men bredden ändras beroende på skärmstorlek. Om du ändrar storlek på skärmen när du är halvvägs genom en skrubbad animering kan du sluta med trasiga animationer och inaktuella värden. Detta är ett vanligt farthinder, men ett som är lätt att lösa! Lägg in beräkningen som är beroende av skärmstorleken i ett funktionellt värde och ställ in invalidateOnRefresh:true. På så sätt kommer ScrollTrigger att beräkna om det värdet åt dig när webbläsaren ändrar storlek.
Bonus GSAP nörd tips!
På mobila enheter visas och döljs vanligtvis webbläsarens adressfält när du rullar. Detta räknas som en resize-händelse och avfyrar en ScrollTrigger.refresh(). Detta kanske inte är idealiskt eftersom det kan orsaka hopp i din animation. GSAP 3.10 har lagts till ignoreMobileResize. Det påverkar inte hur webbläsarfältet beter sig, men det förhindrar ScrollTrigger.refresh() från att skjuta för små vertikala storlekar på enheter som endast berörs.
ScrollTrigger.config({
ignoreMobileResize: true
});Rörelseprinciper
Jag tänkte ge dig några bästa metoder att tänka på när du arbetar med rörelse på webben.
Avstånd och lättnad
En liten men viktig sak som är lätt att glömma med responsiv animering är förhållandet mellan hastighet, momentum och avstånd! Bra animation bör efterlikna den verkliga världen att känna sig trovärdig, och det tar längre tid i den verkliga världen att tillryggalägga ett större avstånd. Var uppmärksam på avståndet som din animation färdas och se till att varaktigheten och lättnaderna som används är rimliga i sammanhang med andra animationer.
Du kan också ofta tillämpa mer dramatiska lättnader på element med längre resor för att visa den ökade farten:
För vissa användningsfall kan det vara bra att justera varaktigheten mer dynamiskt baserat på skärmens bredd. I nästa demo använder vi oss av gsap.utils för att klämma fast värdet får vi tillbaka från strömmen window.innerWidth inom ett rimligt intervall, sedan mappar vi det numret till en varaktighet.
Avstånd och kvantitet
En annan sak att tänka på är avståndet och mängden element vid olika skärmstorlekar. Citerar Steven Shaw:
Om du har någon form av miljöanimation (parallax, moln, träd, konfetti, dekorationer, etc) som är placerade runt fönstret, se till att de skalar och/eller justerar mängden beroende på skärmstorlek. Stora skärmar behöver förmodligen fler element utspridda, medan små skärmar bara behöver ett fåtal för samma effekt.
Jag älskar hur Opher Vishnia tänker på animation som en scen. Att lägga till och ta bort element behöver inte bara vara en formalitet, det kan vara en del av den övergripande koreografin.
När man designar responsiva animeringar är utmaningen inte hur man kan stoppa in samma innehåll i visningsporten så att det "passar", utan snarare hur man kurerar uppsättningen av befintligt innehåll så att det kommunicerar samma avsikt. Det innebär att man gör ett medvetet val av vilket innehåll som ska läggas till och vilket som ska tas bort. Vanligtvis i animationsvärlden dyker saker inte bara in eller ut ur ramen. Det är vettigt att tänka på element som att gå in i eller ut ur "scenen" och animera den övergången på ett sätt som ger visuell och tematisk mening.
Och det är mycket. Om du har fler responsiva animationstips, lägg dem i kommentarsfältet. Om det är något supernyttigt lägger jag till det i detta kompendium med information!
Tillägg
Ytterligare en anteckning från Tom Miller när jag förberedde den här artikeln:
Jag är förmodligen för sent med det här tipset för din responsiva animationsartikel, men jag rekommenderar starkt "slutför alla animationer innan du bygger". Jag håller för närvarande på att eftermontera några webbplatsanimationer med "mobilversioner". Tack och lov för
gsap.matchMedia… men jag önskar verkligen att vi hade vetat att det skulle finnas separata mobila layouter/animationer från början.
Jag tror att vi alla uppskattar att det här tipset om att "planera framåt" kom i absolut sista minuten. Tack, Tom, och lycka till med de eftermonteringarna.
