Is HTML 5 by Apple really HTML 5?

(Ta notka jest także dostępna po polsku)

Apple recently released a number of demos, which they call HTML 5 demos. In this post, I’d like to analyze whether these demos are really HTML 5 or not. I am not going into ideological stuff here (but, to be honest, I do agree with Chris Blizzard’s point of view) – I’m going to check only the technological side of these demo pages.

One thing before we begin. Please note that the “long story short” sentences at the end of each paragraph relate to what I think is really demoed on each page, not to the formal presence of HTML 5 tags. For example, if a page uses HTML 5 section tags (and most of them do), but the demo itself is actually about style transitions, I do not consider it an HTML 5 demo. With this in mind, let’s start.

Video – indeed uses HTML 5 <video> tag, embedding an h.264 video file. Perspective and masking effects are not part of HTML 5, they are possible thanks to Apple’s experimental extensions to the CSS standard. So, this is indeed an HTML 5 demo, but not all the cool stuff here is actually HTML 5.
Long story short, HTML 5: yes, CSS 3: not really, Apple’s proprietary CSS extensions: yes.

Typography – HTML 5 has nothing to do with font embedding. Font embedding is standard CSS 2 (though only recently widely implemented by browser vendors). Horizontal slider is made out of plain old HTML 4 elements (mainly divs), instead of standard HTML 5 <input type=range> element, which is actually supported by Safari. Transparency works thanks to the widely supported CSS 3 Color Module opacity property. Rotation is powered by Apple’s experimental -webkit-transform property, which is actually supported by other browser vendors with their own prefixes (-moz-transform in Firefox 3.6 and -o-transform in latest Operas). Text shadow is applied through the text-shadow property from CSS 3 Text Module. It is also supported by Mozilla and Opera. No HTML 5 here other than <nav> and <section> elements, used throughout the demo site (though, there are lots of HTML4 <div>s there, too). You could make a basically identical page with plain old HTML 4, all the good stuff is, in fact, CSS 3 or experimental additions to CSS 3.
Long story short, HTML 5: not really, CSS 3: a bit, CSS 2: yes, Apple’s proprietary CSS extensions: yes.

Gallery – the only HTML 5 elements here, apart from <nav> and <section>, are <figure> elements, containg the image and prev/next buttons. All the cool stuff is actually made of Apple’s experimental CSS transforms and transitions (other browsers do support some or most of the same transforms and transitions with different vendor prefixes, i.e. Opera has -o-transition instead of -webkit-transition). While cool, these things are not standard yet, and never will be part of any HTML version – as they are extensions to CSS.
Long story short, HTML 5: a bit, CSS 3: no, Apple’s proprietary CSS extensions: yes.

Transitions – are all about the same above-mentioned CSS transforms and transitions. HTML 5 is only used in the navigation part (the links starting off each transition are inside a <section> element, and the header is indeed an HTML 5 <header> element). The real part of the demo – the images that are transformed through CSS, are in plain old <div>s, though. All the coolness thanks to proprietary extensions to CSS.
Long story short, HTML 5: not really, CSS 3: no, Apple’s proprietary CSS extensions: yes.

Audio – a real HTML 5 demo, uses <audio> and <canvas> HTML 5 elements. The song is in the proprietary and patent-encumbered MP4 format, though.
Long story short, HTML 5: yes. Whoohoo!

360° – a JavaScript script cycles through many images of the iPod touches as you move your mouse. Nicely done, but the only thing here that was not possible a few years ago is touchscreen compatibility thanks to Apple’s proprietary events souch as ontouchstart. If you ignore the touchscreen-related events, you can make an identical demo even in piece-of-crap browsers like IE 6 with little effort. So, as the touch events are the only really new thing here, it seems that this is in fact a demonstration of these iPod/iPad/iPhone-related touch events, not of any HTML 5 features.
Long story short, HTML 5: no, CSS 3: no, Apple’s proprietary events: yes.

VR – lots of Apple’s proprietary experimental CSS transforms and transitions shown here plus some JavaScript, but not much of HTML 5.
Long story short, HTML 5: not really, CSS 3: no, Apple’s proprietary CSS extensions: yes.

Apple says:

The demos [...] show how the latest version of Apple’s Safari web browser, new Macs, and new Apple mobile devices all support the capabilities of HTML5, CSS3, and JavaScript.

As you can see, with some exceptions (video/audio and canvas) and some marginal features outside of the core of each demo (navigation and sectioning), the real objective of these demos is to show Apple proprietary features, mostly CSS extensions. To be fair to the Cupertino company, some of them are pushed by Apple for standarization in the W3C, which is a good thing. Still, it does not make them standards at this moment, and once they become standards, they might look a bit or a lot diffrent.

There’s nothing inherently wrong in the demos themselves (and, as always with Apple, they are cool eye candy), but calling them “HTML 5″ – while they do not show a lot of real HTML 5 features – and “standards” – while they’re mostly Apple’s proprietary non-standard extensions – seems to me slightly insincere. What is shown here is actually the great potential of the WebKit rendering engine. If they called it “Apple WebKit demos”, that would be correct and honest.

Post Scriptum for buzzword lovers: Of course, some people (like PPK) are trying to make a buzzword out of “HTML 5″, with meaning shifted from “HTML – the markup language and related APIs” to “all the cool new stuff without Flash”. If you’re one of those people, feel free to agree with Apple on this, and disagree with me.

PS #2. Am I an Apple hater? I wrote this on my MacBook… ;-)

Ile HTML 5 w HTML 5 – co właściwie pokazało Apple?

(This post is also available in English)

Apple udostępniło ostatnio kilka przykładów, które nazywa “demonstracjami możliwości HTML 5″. W tej notce chciałbym sprawdzić, czy faktycznie demonstrowane są tutaj możliwości HTML 5, czy może czegoś innego. Nie zamierzam tu zagłębiać się w ideologię (choć, szczerze mówiąc, całkowicie zgadzam się tutaj z Chrisem Blizzardem) – chcę się skupić wyłącznie na kwestiach technicznych.

Jeden drobiazg, zanim zaczniemy. Każde podsumowujące zdanie “krótko mówiąc” dotyczy tego, co moim zdaniem jest demonstrowane na danej stronie, a nie formalnej obecności znaczników HTML 5 w kodzie. Przykładowo, jeśli strona stosuje znaczniki sekcji HTML 5 (a większość z nich to robi), ale demo dotyczy tak naprawdę przejść (tranzycji) stylów, nie uważam jej za demo HTML 5. Mając to na uwadze – zacznijmy.

Video – faktycznie używa znacznika <video> HTML 5 do osadzenia pliku wideo w formacie h.264. Natomiast perspektywa i efekty maskowania nie są częścią HTML 5 – umożliwiają je eksperymentalne rozszerzenia CSS Apple’a. Tak więc jest to demo HTML 5, ale nie wszystkie fajne rzeczy w nim zawarte są częścią HTML 5.
Krótko mówiąc, HTML 5: tak, CSS 3: nie bardzo, rozszerzenia CSS Apple’a: tak.

Typography – HTML 5 nie ma nic wspólnego z osadzaniem czcionek. Osadzanie czcionek zostało opisane w specyfikacji CSS 2 (choć dopiero od niedawna jest to szerzej obsługiwane przez przeglądarki). Suwak poziomy został tutaj zbudowany ze starych elementów HTML 4 (głównie divów), nie wykorzystano tu standardowego elementu <input type=range> HTML 5, który jest obsługiwany przez Safari.
Przezroczystość działa dzięki szeroko dziś obsługiwanej własności opacity z CSS 3 Color Module. Rotacje umożliwia eksperymentalna własność CSS Apple’a -webkit-transform, która tak naprawdę ma swoje odpowiedniki w innych przeglądarkach – z innymi prefiksami producenta (-moz-transform w Firefoksie 3.6 i -o-transform w nowych Operach). Cień pod tekstem dołożony został przez własność text-shadow z CSS 3 Text Module. Jest to także obsługiwane przez Mozillę i Operę. Z wyjątkiem elementów <nav> i <section>, stosowanych we wszystkich stronach z tej grupy, nie ma tu nic z HTML 5 (mamy za to sporo <div>-ów z HTML 4). Można więc zrobić stronę wyglądającą i zachowującą się identycznie w starym dobrym HTML 4. Wszystkie bajery tutaj to tak naprawdę CSS 3 lub eksperymentalne rozszerzenia CSS Apple’a.
Krótko mówiąc, HTML 5: nie bardzo, CSS 3: trochę, CSS 2: tak, rozszerzenia CSS Apple’a: tak.

Gallery – poza <nav> i <section> z HTML 5 mamy tu tylko elementy <figure>, zawierające obrazki i przyciski prev/next. Ponownie, wszystkie bajery zapewniane są przez eksperymentalne rozszerzenia CSS Apple’a – transformacje (transforms) i efekty przejścia (transitions). Inne przeglądarki również to obsługują, ale z innymi prefiksami w nazwie, tj. Opera ma np. -o-transition w miejsce -webkit-transition. Fajnie to wygląda, ale nie jest to jeszcze ustandaryzowane i nigdy nie będzie częścią żadnej wersji HTML – jako że to rozszerzenia CSS.
Krótko mówiąc, HTML 5: trochę, CSS 3: nie, rozszerzenia CSS Apple’a: tak.

Transitions – to demko również dotyczy przejść i transformacji. HTML 5 używany jest tylko do nawigacji (linki odpalające przejścia są zawarte w elemencie <section>, a nagłówek – w HTML 5 <header>). Istotna część demonstracji – obrazki przekształcane przez CSS – siedzą w starych, dobrych <div>-ach. Wszystkie bajery pochodzą z rozszerzeń CSS Apple’a.
Krótko mówiąc, HTML 5: trochę, CSS 3: nie, rozszerzenia CSS Apple’a: tak.

Audio – w końcu prawdziwe demo HTML 5, używające elementów <audio> i <canvas> z HTML 5. Piosenka jest we własnościowym formacie MP4.
Krótko mówiąc, HTML 5: tak. Hurra!

360° – skrypt w języku JavaScript przełącza pomiędzy kolejnymi zdjęciami iPodów touch podczas przeciągania myszą. Fajnie zrobione, ale jedyna nowa rzecz tutaj, której nie można było zrobić dawniej, to zgodność z ekranami dotykowymi dzięki zdarzeniom takm jak ontouchstart, które są niestandardowym rozszerzeniem DOM Apple’a. Pomijając zdarzenia dla ekranów dotykowych, można przy niewielkim wysiłku zrobić identyczne demo działające nawet w badziewnych przeglądarkach jak IE 6. Jako że jedyną nowością są tu właśnie te zdarzenia dotykowe dla iPoda/iPada/iPhone’a, wydaje się, że właśnie ich pokazanie było celem tej demonstracji, a nie HTML 5.
Krótko mówiąc, HTML 5: nie, CSS 3: nie, własne zdarzenia Apple’a: tak.

VR – wiele różnych transformacji i przejść z eksperymentalnych rozszerzeń CSS Apple’a plus trochę JavaScriptu, ale niespecjalnie dużo HTML 5.
Krótko mówiąc, HTML 5: nie bardzo, CSS 3: nie, rozszerzenia CSS Apple’a: tak.

Apple mówi:

Te demonstracje [...] pokazują, w jaki sposób najnowsza wersja przeglądarki Safari Apple’a, nowe Macintoshe i nowe urządzenia przenośne Apple’a obsługują funkcjonalności HTML5, CSS3 i JavaScriptu.

Jak widać, z kilkoma wyjątkami (video/audio i canvas) i mniej istotnymi częściami poza sercem każdego demo (nawigacja i sekcje), głównym ich celem wydaje się tutaj pokazanie własnych, niestandardowych funkcjonalności Apple’a, głównie rozszerzeń CSS. Owszem, część z nich Apple przekazało do W3C i są one obecnie standaryzowane, co jest istotnym plusem. Niemniej jednak, nie są one standardem na chwilę obecną, a kiedy już zostaną ustandaryzowane, mogą wyglądać nieco lub bardzo inaczej.

W samych demkach nie ma nic złego (i, jak zawsze u Apple’a, wyglądają super), ale nazywanie ich “demonstracjami HTML 5″ – kiedy nie pokazują wiele z HTML 5 – i “demonstracjami standardów”, podczas gdy prezentują głównie niestandardowe rozszerzenia Apple’a – wydaje mi się trochę nieuczciwe. Co tutaj widać, to wielki potencjał silnika WebKit. Określenie tych stron “Demonstracją możliwości Apple WebKit” byłoby więc bardziej zgodne z rzeczywistością.

PS. Oczywiście, niektórzy (jak PPK) chcą uczynić z “HTML 5″ tzw. buzzword, który nie ma znaczyć już “HTML – język znakowania oraz powiązane API”, tylko “wszystkie fajne nowe rzeczy bez Flasha”. Jeśli do nich należysz, masz prawo zgodzić się tutaj z Apple, a nie ze mną.

PS #2. Czy jestem wrogiem Apple? Napisałem tę notkę na MacBooku… ;-)

Ogg Theora czy h.264 – co wybrali użytkownicy w Polsce

Język HTML 5 wprowadził znacznik <video>, służący do osadzania filmów na stronach internetowych. W pierwotnej wersji specyfikacji znalazł się format Ogg z kodekiem Theora, wskutek protestów m. in. Apple aktualna robocza wersja specyfikacji nie określa formatu wideo.

Przeglądarki z silnikiem Gecko (w tym Firefox 3.5+), a także Opera (aktualnie w wersji beta 10.50) i Google Chrome (od wersji 3, także w opensource’owej wersji – Chromium) obsługują Ogg Theora. Format h.264 z kolei obsługuje jedynie Apple Safari (od wersji 3.2) i Google Chrome (od wersji 3, tylko oficjalne wydania komercyjne Google).

Zobaczmy, jak wsparcie dla obu formatów oraz znacznika <video> HTML5 wygląda pośród polskich użytkowników WWW. Poniżej wykorzystałem dane z najnowszej edycji rankingu gemiusTraffic (za tydzień 15-21.02.10). W danych tych pominięto niektóre przeglądarki w wersjach testowych, w szczególności nie zawierają one liczby użytkowników Firefoksa pre-3.7 i Safari 4.x (gdzie x>0), ale wpływ tego ograniczenia na ogólny błąd w tym zestawieniu jest niewielki.

Jak więc to wygląda?

Liczba odsłon Udział % Ogg H.264
Wszystkie odsłony 7382509245 100
Firefox 3.5 2433559952 32,96 T N
Firefox 3.6 545454889 7,39 T N
Opera 10.50 4622237 0,06 T N
Chrome 3 9653886 0,13 T T
Chrome 4 345356590 4,68 T T
Chrome 5 5791210 0,08 T T
Safari 3.2 1314478 0,02 N T
Safari 4.0 29105252 0,39 N T
Obsługa <video> 3374858494 45,71
Wszystkie Ogg 3344438764 45,3
Wszystkie H.264 391221416 5,3

Przeglądarki obsługujące w ogóle znacznik <video> z HTML 5 generują więc już 45,71% odsłon wszystkich serwisów monitorowanych przez Gemius. Przeglądarki obsługujące HTML 5 oraz format h.264 – jedynie 5,3%, natomiast przeglądarki obsługujące HTML 5 i Ogg Theora – 45,3%.

Wraz z migracją użytkowników do nowszych wersji przeglądarek (w szczególności – z Firefoksa 3.0 do 3.6) oraz po wydaniu finalnej Opery 10.50, udział HTML5+Ogg Theora powinien przekroczyć połowę użytkowników – dzisiaj liczba użytkowników brandów (grup) przeglądarek, których najnowsze wersje obsługują otwarte wideo, przekracza 2/3.

Wkrótce więc zdecydowanej większości użytkowników będzie można serwować filmy bez konieczności korzystania z niestabilnych wtyczek (co gwarantuje nam HTML 5) i bez konieczności ponoszenia opłat licencyjnych (co zapewnia otwarte wideo – format Ogg Theora). Użytkownicy przeglądarek internetowych w Polsce wybrali te, które obsługują lub będą wkrótce obsługiwać otwarty format wideo. Każdy, kto poważnie zajmuje się kwestią multimediów w sieci, powinien zwrócić na to uwagę.

Powtórzmy jeszcze raz: już prawie połowie użytkowników w Polsce można serwować wideo bez konieczności instalowania przez nich wtyczek, jednocześnie zapewniając sobie (czy też własnej firmie) niezależność od producentów wtyczek (Adobe Flash) i opłat licencyjnych (h.264). 1

Widownia dla Theory już jest, czas na dostawców treści! :)


1) Użytkownikom pozostałych przeglądarek można serwować te same filmy w formacie Ogg Theora przy użyciu wtyczek (XiphQT, aplet Javy Cortado) lub Video for Everybody.

HTML 5: przesyłanie wielu plików jednocześnie

Dotychczas, chcąc umożliwić użytkownikowi przesłanie wielu plików przy pomocy formularza HTML, webmasterzy musieli posiłkować się albo apletami Flasha (takimi jak SWFUpload czy Uploadify), albo wstawić wiele elementów input. To drugie rozwiązanie było niewygodne dla użytkownika, ponieważ musiał on każdy plik wybrać w osobnym oknie wyboru pliku. Tak robiło się to do tej pory w HTML 4.01:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Upload plików - pojedynczy</title>
<form method="post" enctype="multipart/form-data" action="upload.php">
  <fieldset>
    <legend>Prześlij pliki</legend>
      <label>Dodaj plik 1: 
        <input type="file" name="files[]">
      </label><br>
      <label>Dodaj plik 2: 
        <input type="file" name="files[]">
      </label><br>
      <label>Dodaj plik 3: 
        <input type="file" name="files[]">
      </label><br>
      <label>Dodaj plik 4: 
        <input type="file" name="files[]">
      </label><br>
      <!-- itd... -->
      <input type="submit">
    </fieldset>
</form>

Niezbyt to wygodne, jeśli chcemy załadować np. kilka zdjęć z naszej ostatniej wycieczki w góry…

Gecko 1.9.2 (dostępne m. in. w nadchodzącym Firefoksie 3.6) oraz nowsze wersje przeglądarek opartych na silniku WebKit obsługują atrybut multiple elementu <input> z atrybutem type="file". Atrybut ten pozwala do jednego inputa wstawić wiele plików. Powyższy kod upraszcza się więc w HTML 5 do takiej postaci:

<!DOCTYPE html>
<meta charset="UTF-8">
<title>Upload wielu plików</title>
<form method="post" enctype="multipart/form-data" action="upload.php">
  <fieldset>
    <legend>Prześlij pliki</legend>
    <label>Dodaj pliki:
      <input type="file" multiple name="files[]">
    </label><br>
    <input type="submit">
  </fieldset>
</form>

Po kliknięciu “Przeglądaj” użytkownikowi wyświetli się systemowa wybieraczka plików, pozwalająca zaznaczyć wiele plików (z wciśniętym klawiszem Ctrl, Shift, lub poprzez odpowiednie zaznaczenie myszą). Po stronie serwera nic się nie zmienia, przesłane pliki traktowane są tak samo, jakby były przesłane z kilku osobnych, a nie jednego wspólnego inputa.

Tak więc np. kod w PHP operujący na tablicy $_FILES w ogóle nie musi być modyfikowany po przejściu na input z atrybutem multiple (jeśli korzystaliśmy do tej pory z wielu inputów o tej samej “tablicowej” nazwie).

HTML 5 po raz kolejny rozwiązuje problem, który irytował webmasterów od niepamiętnych czasów. Teraz czekamy już tylko na Operę i Microsoft… :)

PS. Na razie aplety w rodzaju SWFUpload pozostają niezastąpione, jeśli chcemy użytkownikowi np. pokazywać pasek postępu podczas przesyłania plików. Wkrótce jednak flashowe protezy zupełnie stracą rację bytu – W3C pracuje nad specyfikacją FileUpload, która umożliwi przesyłanie plików poprzez XMLHttpRequest.

CSS Transitions, czyli efekty przejścia w CSS

W wersji Firefoksa obecnie oznaczanej jako 3.7 pojawi się wsparcie dla efektów przejścia (ang. transitions) w CSS. Czym są efekty przejścia? W momencie zmiany stanu danego elementu (np. zmiany pseudoklasy, jak :hover, albo zmiany stylu wywołanej np. z poziomu JavaScriptu) wskazane własności CSS zmienią swe wartości w sposób płynny, a nie skokowy.

CSS Transitions pojawiły się najpierw w silniku WebKit, a od niedawna obsługuje je także silnik Gecko 1.9.3. Apple zgłosiło specyfikację CSS Transitions do konsorcjum W3C; ma ona obecnie status „Working Draft” (wersji roboczej).

Jak to wygląda?

Tutaj znajdziecie prosty przykład (potrzebny jest testowy nightly-build Firefoksa z mozilla-central lub w miarę nowe Safari lub Chrome).

Jak tego używać?

Specyfikacja definiuje własności:

transition-property
określa, jaka własność stylu ma podlegać efektowi przejścia
transition-duration
określa, jak długo ma trwać ten efekt
transition-timing-function
określa przyspieszenie lub spowolnienie animacji
transition-delay
określa opóźnienie z jakim ma zacząć się efekt
transition
skrót dla wszystkich pozostałych własności

Omówmy je pokrótce.

transition-property

Podajemy tutaj, jaka własność (lub jakie własności) mają być animowane. Jeśli nie określimy tej własności, lub podamy tu słowo kluczowe all, animowane będą wszystkie własności CSS, które tylko da się animować. Wartość none wyłącza efekty przejścia.

Przykład:

transition-property: color;

transition-duration

Tutaj podajemy czas trwania przejścia.

Przykład:

transition-duration: 5s;

Ta animacja będzie trwała 5 sekund.

transition-timing-function

Własność ta pozwala animacji zwalniać lub przyspieszać w trakcie jej trwania. Do określenia tych zmian wykorzystywane są sześcienne krzywe Béziera.

Dopuszczalne wartości to cubic-bezier(x2, y2, x3, y3), gdzie x2 i y2 oraz x3 i y3 to odpowiednio współrzędne punktów kontrolnych P2 i P3 krzywej (punkty P0 i P1są ustalone jako (0, 0) i (1, 1)).

Kilka szczególnie przydatnych wartości uzyskało także wygodne do zapamiętania aliasy:

Słowo kluczowe Odpowiednik cubic-bezier
ease cubic-bezier(0.25, 0.1, 0.25, 1.0)
linear cubic-bezier(0.0, 0.0, 1.0, 1.0)
ease-in cubic-bezier(0.42, 0, 1.0, 1.0)
ease-out cubic-bezier(0, 0, 0.58, 1.0)
ease-in-out cubic-bezier(0.42, 0, 0.58, 1.0)

Wartość linear oznacza po prostu liniową zmianę wartości, czyli tempo animacji będzie jednostajne. Pozostałe wartości z powyższej tabeli sprawiają, że animacja zwolni lub przyspieszy na początku lub na końcu.

Przykład:

transition-timing-function: linear;

transition-delay

Możemy tu podać opóźnienie, z jakim wykona się animacja. Wartość równa 0 oznacza brak opóźnienia. Dozwolone są również wartości ujemne (-x), wówczas animacja zacznie się natychmiast (tak, jak przy wartości 0), ale początkowa wartość animowanej własności będzie taka, jakby przejście trwało już od |x| sekund.

Przykład:

transition-delay: 0.5s;

transition

Własność transition to skrótowy zapis wszystkich pozostałych, w kolejności: property, duration, timing function, delay. Na przykład:

transition-property: color;
transition-duration: 5s;
transition-timing-function: ease-in;
transition-delay: 2s;

można krótko zapisać jako:

transition: color 5s ease-in 2s;

Zarówno własności transition-* jak i skrótowa własność transition mogą przyjmować wiele wartości równolegle, tj. można
określić efekt przejścia np. dla własności color oraz dodatkowo inny dla width:

transition: color 5s ease-in 2s, width 3s ease-out 3s;

Jak zrobić div, który rozwinie się po najechaniu kursorem?

Bardzo prosto:

HTML:

<div id="slideDiv">witaj świecie!</div>

CSS:

#slideDiv {
  width: 5px;
  height: 20px;
  overflow: hidden;
  background: green;
  color: #fff;
  -moz-transition: width 1s linear;
  -webkit-transition: width 1s linear;
}

#slideDiv:hover {
  width: 20px;
}

Ograniczenia obecnych implementacji

Specyfikacja jest dopiero w stadium roboczym, tak więc wszystko tutaj może się jeszcze zmienić. Zarówno Gecko, jak i WebKit implementują powyższe własności w tzw. przedrostkiem producenta. Oznacza to, że obecnie żaden kod z powyższych przykładów nie zadziała, dopóki nie poprzedzimy odpowiednim przedrostkiem wszystkich omawianych własności. Dla Gecko jest to -moz-, dla WebKitu: -webkit-.

Aby nasze przejścia obecnie działały w obu tych silnikach musimy niestety napisać je dwukrotnie (albo i potrójnie, jeśli chcemy zachować na przyszłość składnię bez przedrostków). W poniższym przykładzie odnośniki będą płynnie zmieniać swój kolor w ciągu pół sekundy od najechania na nie myszą:

a {
  color: #f00;
  -moz-transition: color 0.5s linear;
  -webkit-transition: color 0.5s linear;
  transition: color 0.5s linear;
}

a:hover {
  color: #0f0;
}

W przypadku dostępu do tych własności z poziomu JavaScriptu należy pamiętać o tym, że minus przechodzi w powiększenie następującej po niej litery, tak więc
do własności efektów przejścia z poziomu JS na razie dobieramy się w Gecko przez element.style.MozTransition, a w WebKicie przez
element.style.WebkitTransition.

Nie wszystkie własności są obecnie animowane. Szerszy zakres ma na razie WebKit (obsługuje np. transformacje -webkit-transform; Gecko na dzień dzisiejszy nie pozwala na przejścia dla -moz-transform), ale wkrótce Mozilla powinna tutaj dogonić Apple. :)

Ważna sprawa: ani Gecko, ani WebKit nie animują przejść od wartości w rodzaju auto do wartości liczbowej. Zmiany tutaj odbywają się niestety skokowo.

Poprawna degradacja

Deklaracje własności transition w przeglądarkach nie obsługujących efektów przejścia (w tym obecne wersje Opery, IE, Firefox 3.6 i starsze, stare WebKity) nie powodują żadnych problemów, po prostu wymiary czy kolory elementów zmienią się w nich skokowo, tak jak bez transition.

Czy już to stosować?

Na poważnych witrynach najlepiej będzie się wstrzymać, przynajmniej do czasu względnego ustabilizowania się specyfikacji i jej implementacji.
Ale nikt nie broni dzisiaj poeksperymentować! :)

Linki

MDN

Better JavaScript docs for a better Web on MDN

Archiwum

Follow

Get every new post delivered to your Inbox.