JavaScript-animering som fungerar (del 1 av 4)

HTML är språket som webben är inbyggt i och det är typ av ett konstigt djur. Även om det ursprungligen var tänkt som ett sätt att enkelt dela akademisk information över internet, har den långsamt förvandlats för att rymma den medierika miljön vi känner och älskar. På grund av HTML: s slumpmässiga karaktär (och JavaScript, programmeringsspråket som manipulerar element i HTML och gör dem interaktiva), ibland måste vi tänka utanför lådan lite. I den här handledningsserien kommer jag att visa dig hur du gör cross-browser animation med en metod som heter spriting. Och eftersom det här är en lärande möjlighet, kommer vi att göra allt utan några externa bibliotek (som jQuery).

Detta kommer att vara en fyrdelars serie. Jag förklarar att jag skriver i del ett (den här artikeln) med några grundläggande JavaScript, men sedan i senare avgångar kommer vi att flytta in i några mellanliggande tekniker som inkapsling, händelsehantering och pekskärmstöd.

Så låt oss börja!


Vad är Animation?

Animering baseras på ett fenomen som heter persistens av syn, som i grunden säger att om din hjärna ser mycket liknande stillbilder snabbt nog, så kommer det att se ut som om det är en rörlig bild. Varje form av film eller video använder denna grundläggande teknik - många lite olika ramar visas i snabb följd för att få något att verka som att röra sig. Film körs typiskt med 24 bilder per sekund (¹), medan broadcast-tv i Nordamerika visas vid 29,97 bilder per sekund (2). Så, med andra ord, vad vi vill göra är att skapa något som visar liknande bilder mycket snabbt (flera gånger i sekundet).


Svårigheterna på webben

Det finns två huvudskäl animering är svår att använda på webben:

  1. Det första är att olika webbläsare har olika sätt att tolka HTML och JavaScript, så det som fungerar på en enhet fungerar ofta inte på någon annan. Flash fungerar bra på de flesta webbläsare, men stödet börjar sjunka för det och iOS-enheter tillåter det inte alls. Canvas har mycket potential, men Internet Explorer 8 stöder det inte. Samma gäller med Adobe Edge Animate. GIF fungerar på allt, men du kan inte styra animationen eller göra det interaktivt.
  2. Och för det andra, varje gång en bild serveras på en webbsida, görs en separat begäran mellan webbläsaren och servern. Dessa förfrågningar kan komplettera, även över en blixtsnabb internetuppkoppling, vilket gör att det finns flera bilder per sekund som inte kan hanteras.

Lösningen: Spridning

En väg runt dessa problem är att skapa ett spritark. I element som divs, vi kan ställa in en bakgrundsbild för div som kan vara större än själva elementet. Vi kan också ställa in bakgrundsställningen så att vi bestämmer exakt vilken del av den större bilden som ska visas. Ett spritark är en större bild av flera mindre bilder som vi kan flytta runt så att det kan ta plats för många små bilder. Ta en titt på exemplet nedan, med J, mascot i mitt företag Joust Multimedia:


Även om det finns tio olika bilder av J, placeras de ihop på en större PNG-fil (vi använder PNG eftersom de kan visa öppenhet). Om vi ​​har en div det är bara storleken på en av bilderna, och vi ställer in denna PNG som bakgrund, den kommer att se ut som en enda bild.

Se Hazdm på CodePen.

Även om detta verkar som mycket problem att gå igenom för att visa en bild, fixar den här metoden snygg de två problemen vi hade tidigare. Med mycket lite JavaScript (en rad!) Kan du ändra bakgrundspositionen för a div, och det fungerar på allt. Eftersom alla dessa ramar är på samma bild, kommer det bara att ta en begäran om att ladda den bilden på sidan. Så, när sidan laddas, kan den växla mellan sprites utan problem alls.

Så hur sätter vi det här för att animera lätt då? Det första steget är att skapa sprite-arket. Du kommer att vilja veta vad de sista dimensionerna av din bild ska vara, och utrymme som sprites i enlighet därmed i ett rutnät. Till exempel kommer min J-bild att vara 40px bred vid 50px lång, så jag lade upp mina sprites exakt 40px ifrån varandra horisontellt och exakt 50px åtskilda vertikalt. Det kommer troligen vara enklast om du ställer in startsprite i övre vänstra hörnet.

Då ska vi sätta upp en div med lite CSS för att se till att allt visas korrekt:

 

Och här är vår CSS för att se till att sprite visas korrekt:

 .karaktär / * * Mycket viktigt att vi anger höjden och bredden på * våra karaktärer till sprites höjd och bredd * / höjd: 50px; bredd: 40 bildpunkter; / * * Vi måste placera dem absolut så att vi kan få full kontroll över deras position inom scenen * / position: absolut; vänster: 100px; topp: 120 bildpunkter;  #j / * * Och nu ställer vi bakgrundsbilden för teckenspalten * till den första spriten (i övre vänstra hörnet) * / bakgrundsbild: url ('j.png'); background-repeat: no-repeat; bakgrundsställning: 0 0; 

Observera följande saker:

  • Vi anger bredden och höjden på div till storleken på vår sprite
  • Vi anger bakgrundsrepetitionen till 'No-repeat'
  • Vi specificerar bakgrundspositionen till '0 0'-Detta kommer att visa sprite i övre vänstra hörnet

Nu kommer det bara att ta en enda linje med JavaScript för att ändra bakgrundspositionen för att visa nästa sprite.

 document.getElementById ('j'). style.backgroundPosition = '-40px 0px';

Här väljer vi elementet (med id = 'j') och ställa in stilattributet 'BackgroundPosition'. Observera att det är stavat 'BackgroundPosition' i JavaScript, och inte som 'Background-ställning' i CSS. Observera också att i JavaScript, 'Px' krävs för både x- och y-mängden-vi kan inte bara skicka siffrorna. Och för att vi flyttar bakgrundsbilden måste vi flytta den i motsatt riktning från vad du kan förvänta dig. För att flytta till sprite till höger måste vi få bilden att flytta 40px till vänster.

Nu, om vi bara har något enkelt att utföra den här koden (som en knapp) kan vi se att ramarna ändras i åtgärd: Kassa DIsgk på Codepen.

Dessutom kanske du är intresserad av att ta en titt på källkoden för den här sidan. Den har alla exempel här med noggranna kommentarer. Och här är sprite-arket jag använder.

Nästa Upp

Vad vi har täckt i denna handledning är en bra start, men det är inte riktigt en riktig animering. I del två av denna serie kommer vi faktiskt att animera lite spring och hopp, genom att skapa loopar med de olika spritesna.

Av del fyra kommer vi att skapa mouseovers för lite robotåtgärd. Se ByGtv Codepen för en förhandsgranskning.


Slutsatser och nackdelar

Även om detta kan vara en bra metod för att animera på webben, finns det några nackdelar. För det första kan det krävas att du skapar varje enskild animationsram, vilket kan vara tidskrävande. För det andra har webbläsare inte den mest exakta timern för animering, så om det är avgörande för att din animation ska vara tidsbestämd, så kanske det inte fungerar. Slutligen har mobil Safari (används på iPhones och iPads) en "funktion" där om du har en bakgrundsbild som är antingen större än 2 MB eller större än 1024 x 1024 x 3 pixlar (eller 3 145 728 pixlar totalt), kommer den automatiskt att skala upp bild, förstöra spridningseffekten. Det betyder att riktigt stora sprites, eller animeringar med ett mycket stort antal sprites, är uteslutna. Men för enkla små animationer som du vill vara väldigt interaktiva är det här ett enkelt och bra sätt att få något som fungerar överallt.

Intressanta sidobeskrivningar

1. Innan ljudet introducerades med film var det inte riktigt en vanlig bildhastighet. Kamerorna drivs med en handväxel, så om du hade en rookie kameraman kan bildhastigheten sakta ner och påskynda oavsiktligt. På samma sätt var mindre välrenommerade teatrar berömda för att berätta för sina projektionister att vrida projektorn snabbare för att påskynda showen så att de kunde passa in i fler screenings. Det här är också därför vi stereotypt tänker på pre-sound-filmer som rör sig snabbare snabbt, de flesta filmades runt 16 till 18 fps, så när vi spelar dem idag med 24 bilder per sekund går de snabbare än de ursprungligen var avsedda för.

2. TV sändes ursprungligen vid 30 bilder i sekundet i Nordamerika, men färg-tv orsakade en glitch när den visades vid den hastigheten. Ingenjörer fann ut att de kunde fixa det genom att sänka bildhastigheten med 0,1%, varför den nu är inställd på 29,97 fps. Utöver alla de otroliga tekniska problemen som är inblandade i att konvertera en film i 24 bilder per sekund för att visa på tv vid 29,97 fps, har visning av tv på en snabbare fps haft en intressant effekt på allmänheten. Många som tittade på "The Hobbit" på 48 fps rapporterade att den ökade bildhastigheten gjorde att filmen var "billigare", trots att den var mycket högre kvalitet än en vanlig film, bara för att de hade vuxit för att associera snabbare bildräntor med att titta på något på tv.