Acid3 – Test przeglądarek internetowych
Acid3 to test z serii Acid, który został stworzony w celu pomocy przeglądarkom internetowym w dostosowaniu się do standardów internetowych ustalanych przez organizację W3C. Opracowywany był w ramach organizacji Web Standards Project (WaSP) od kwietnia 2007 roku, a oficjalnie zaprezentowany 3 marca 2008 roku. Głównym autorem Acid3 jest Ian Hickson, który również pracował nad wcześniejszą wersją – Acid2.
Przebieg testu
Test Acid3 różni się od swojego poprzednika. Składa się z wielu mniejszych podtestów, które są uruchamiane natychmiast po załadowaniu strony, a wyniki są wyświetlane na bieżąco. Dzięki temu łatwiej ocenić, które z testowanych funkcji nie działają jeszcze zgodnie z przyjętymi standardami.
Według zaleceń twórców, testy powinny być przeprowadzane przy domyślnych ustawieniach przeglądarki, tak aby użytkownik, który nie wprowadzał żadnych zmian po instalacji, mógł uzyskać wiarygodne wyniki.
Aby przeglądarka mogła zaliczyć test, musi osiągnąć wynik 100/100, a także animacje muszą przebiegać płynnie. Po zakończeniu wszystkich podtestów strona powinna wyglądać dokładnie tak samo (co do piksela) jak strona wzorcowa otwarta w tej samej przeglądarce. Warto zaznaczyć, że strona wzorcowa może wyglądać nieco inaczej w różnych przeglądarkach z powodu różnic w rasteryzacji czcionek.
Wymagana płynność animacji ustalono na poziomie około 30 fps (33 ms na test). Można to zweryfikować, przeglądając szczegółowy raport wydajności i błędów. Po zakończeniu testu należy przytrzymać klawisz ⇧ Shift i kliknąć myszą na literę A w słowie Acid.
Testowane elementy
Poprzednia wersja testu koncentrowała się na standardach istotnych dla statycznych stron, podczas gdy Acid3 sprawdza zdolności przeglądarek do wyświetlania i tworzenia dynamicznych stron zgodnie z powszechnie akceptowanymi standardami, takimi jak obiektowy model dokumentu (DOM) na poziomie 2 (DOM Level 2) oraz standard dla dynamicznych skryptów po stronie klienta – ECMAScript.
Dodatkowo testowane są elementy innych standardów, które twórcy uznali za przydatne do budowy dynamicznych stron Web 2.0, takie jak:
- zagnieżdżanie dodatkowych elementów według standardu HTML4 (
- prawidłowa obsługa protokołu HTTP (Content-Type, 404 itp.)
- elementy XHTML 1.0
- CSS
- CSS2 (@font-face)
- CSS2.1 (’inline-block’, ‘pre-wrap’, itp.)
- CSS2 i CSS3 – selektory (:lang, :nth-child(), łączenie selektorów, dynamiczne zmiany selektorów itp.)
- CSS3 – kolory (rgba(), hsla() itp.)
- CSS3 – interfejs użytkownika (’cursor’)
- Media Queries, czyli możliwość szczegółowego wyboru medium, do którego odnosi się arkusz CSS
- Data URL, czyli zagnieżdżanie specjalnie zakodowanych informacji (np. obrazków) w adresie URL
- SVG (animacje, fonty itp.)
Niektóre elementy mogą być sprawdzone jedynie poprzez porównanie ze stroną wzorcową:
- CSS2.x – pobieranie fontów
- CSS3 – cienie tekstu
Pobieranie fontów testowane jest za pomocą niestandardowego fontu TrueType „Ahem”, w którym większość znaków to zamalowane kwadraty. W prawym górnym rogu ekranu wyświetlana jest litera X. Tło ustawione jest na różowy kolor, a znaki na biały. W przypadku nieprawidłowego pobrania fontu, w rogu pojawi się biała litera X na różowym tle. W przeciwnym razie tło zostanie zakryte przez znak.
Cień powinien być widoczny dla tekstu „Acid3”, który jest napisany dużą czcionką.
Podział na podtesty
Acid3 składa się z 100 podtestów podzielonych na 6 grup, zwanych „wiadrami” (ang. buckets):
- Bucket 1: DOM Traversal, DOM Range, HTTP
- Bucket 2: DOM2 Core, DOM2 Events
- Bucket 3: DOM2 Views, DOM2 Style, selektory i Media Queries
- Bucket 4: Zachowanie formularzy i tabel HTML w kontekście skryptów oraz DOM2 HTML
- Bucket 5: Testy z Acid3 Competition (SVG, HTML, SMIL, Unicode, …)
- Bucket 6: ECMAScript
Wynik testów w poszczególnych przeglądarkach
Wynik procentowy opiera się na liczbie zdanych podtestów. Oznacza to, że niektóre przeglądarki mogą uzyskać wyższy wynik, ale niekoniecznie oznacza to, że są lepiej przystosowane do dynamicznych stron Web 2.0 (mogą na przykład przejść więcej mniej istotnych testów).
Pierwsza zapowiedź pełnego przejścia testu miała miejsce w przypadku przeglądarki Opera. Testowa wersja ich silnika WinGogi/LinGogi została wydana 28 marca 2008 roku, dzień po tym, jak twórcy WebKit zaprezentowali pierwszą publiczną wersję przeglądarki, która mogła przejść test w kontekście zgodności ze standardami (wynik 100/100). Niemniej jednak, podobnie jak w przypadku Opery, kilka podtestów działało zbyt wolno, aby test mógł być uznany za w pełni udany.
17 września 2011 roku Ian Hickson oraz Håkon Wium Lie ogłosili, że niektóre testy związane z fontami SVG, animacjami SMIL w SVG oraz innymi zostały wyłączone. Te zmiany spowodowały, że część przeglądarek, które miały z tym problem, zaczęły przechodzić cały test Acid3 w zakresie zgodności z testowanymi standardami (m.in. Internet Explorer i Firefox). Hickson tłumaczył, że zmiany były konieczne ze względu na potrzebę aktualizacji samych standardów.
Zestawienie wyników procentowych
Graficzne wyniki testu
Rozwój Acid3 i jego wpływ na przeglądarki
Prace nad pierwszą wersją testu
Ian Hickson rozpoczął prace nad Acid3 w kwietniu 2007 roku, jednak postęp był wolny. W grudniu 2007 roku prace zostały wznowione, a więcej informacji na ten temat opublikowano 10 stycznia 2008 roku na blogach Anne van Kesteren i Dustina Brewera. W tym czasie zestaw był dostępny pod adresem: „http://www.hixie.ch/tests/evil/acid/003/NOT_READY_PLEASE_DO_NOT_USE.html” (jeszcze niegotowy, proszę nie używać). Mimo to, wzbudził on szerokie zainteresowanie wśród społeczności programistów internetowych.
14 stycznia 2008 roku brakowało jeszcze 16 z 100 planowanych podtestów, dlatego najpierw na blogu Iana Hicksona, a następnie na stronie WaSP ogłoszono konkurs na dopisanie tych podtestów.
Poniżej wymienieni programiści przyczynili się do budowy ostatecznej wersji testu Acid3 poprzez udział w tym konkursie:
- Sylvain Pasche – test 66-67 (DOM),
- David Chan – test 68 (UTF-16),
- Simon Pieters i Anne van Kesteren – test 71 (analiza składniowa HTML),
- Jonas Sicking i Garret Smith – test 72 (dynamiczne modyfikacje węzłów tekstowych stylów blokowych),
- Jonas Sicking – test 73 (zagnieżdżone zdarzenia),
- Erik Dahlstrom – test 74-78 (SVG i SMIL),
- Cameron McCormack – test 79 (fonty SVG).
Rozwój przeglądarek i zmiany w teście
Wpływ Acid3 na rozwój przeglądarek internetowych był znaczący jeszcze przed jego oficjalnym wydaniem. Na przykład silnik przeglądarek internetowych WebKit w ciągu mniej niż miesiąca poprawił liczbę zdanych podtestów z 60 do 87.
Jak określił główny autor testu, Ian Hickson, pierwsza wersja Acid3 była „wystarczająco stabilna”, by mogła być wykorzystywana. Hickson przewidywał, że po kilku miesiącach wyniki przeglądarek zbliżą się do wyniku 100/100, a programiści zaczną zgłaszać błędy w podtestach.
Już po niecałym miesiącu od premiery testu programiści Opery i Apple (Safari) ogłosili, że robocze wersje ich przeglądarek przechodzą test. Równocześnie programiści zaczęli zgłaszać błędy w testach, co skutkowało poprawkami w kilku podtestach. 26 marca 2008 roku Hickson ogłosił na swoim blogu, że część zgłaszanych uwag była uzasadniona i wprowadził odpowiednie poprawki oraz aktualizacje w kilku podtestach. Tego samego dnia programista Apple zidentyfikował błąd w podteście związanym z SVG i pomógł w jego naprawie. Błąd ten wynikał z błędnej interpretacji specyfikacji, co powodowało, że Opera również przechodziła ten podtest w sposób nieprawidłowy. Dwa dni później, 29 marca 2008 roku, Ian opisał dodatkowy problem i wprowadził drobną zmianę w podteście dotyczącym sztucznego fontu „Ahem”, która dotyczyła tylko systemu Mac, więc nie wpłynęła na wynik Opery. Problem był związany z antyaliasingiem czcionek, co powodowało, że znak zasłaniał część obramowania, a twórcy Safari starali się to obejść, wyłączając antyaliasing tego fontu.
Kilka dni później Hickson wprowadził zmiany w podteście nr 26, który bada wydajność przeglądarki. Zmiana miała na celu ułatwienie miarodajnego testowania przeglądarek na różnych komputerach. Wyjaśnił również, że animacja musi być płynna, co oznacza, że żaden z testów nie powinien trwać dłużej niż 33 ms, przy czym według Hicksona tylko wspomniany podtest nr 26 powinien zajmować znaczną ilość czasu. To wszystko przy założeniu, że dane są ładowane z pamięci podręcznej przeglądarki podczas ponownego uruchomienia testu. Jednakże, ponieważ standardy nie określają ściśle wydajności, wynik 100/100 jest wystarczający do pozytywnego zaliczenia testu w kontekście zgodności z standardami.