Przejdź do zawartości

Acid3

Z Wikipedii, wolnej encyklopedii
Acid3
Ilustracja
zrzut ekranu
Typ strony

test standardów webowych

Data powstania

3 marca 2008

Autor

Ian Hickson

Właściciel

Web Standards Project

Rejestracja

nie

Strona internetowa

Acid3 – test z serii Acid, który ma pomóc przeglądarkom internetowym w spełnieniu standardów internetowych wyznaczanych przez organizację W3C.

Test był opracowywany w ramach organizacji Web Standards Project (WaSP) od kwietnia 2007, a oficjalnie wydany 3 marca 2008[1]. Głównym twórcą Acid3 był Ian Hickson, który przygotowywał również poprzednią wersję – Acid2[2][3].

Przebieg testu

[edytuj | edytuj kod]

Acid3 przebiega nieco inaczej niż jego poprzednik. Składa się on z wielu mniejszych podtestów, które są uruchamiane zaraz po wejściu na stronę, a wyniki podawane są na bieżąco. Stąd łatwiej można ocenić, ile z testowanych właściwości nie działa jeszcze zgodnie ze standardami.

Zgodnie z zaleceniami twórców, testy powinny być przeprowadzane przy standardowych ustawieniach przeglądarki, czyli takich, które posiadałby użytkownik, który nie chciał, bądź nie potrafił niczego zmienić po jej zainstalowaniu.

Aby przeglądarka przeszła test w całości, nie tylko musi osiągnąć wynik 100/100, ale także animacja powinna przebiegać płynnie, a po zakończeniu poszczególnych podtestów strona powinna wyglądać identycznie (co do piksela) jak strona wzorcowa oglądana w tej samej przeglądarce. Sama strona wzorcowa może jednak wyglądać nieco inaczej w różnych przeglądarkach ze względu na różnice w rasteryzacji fontów.

Wymagana płynność animacji została określona na ok. 30 fps (33 ms na test)[4]. Można to zweryfikować oglądając szczegółowy raport wydajności i błędów. W tym celu, po zakończeniu testu, należy przytrzymać klawisz ⇧ Shift i kliknąć myszką na A (w słowie Acid).

Testowane elementy

[edytuj | edytuj kod]

Poprzedni test sprawdzał standardy, które mają większe znaczenie w statycznych stronach. Obecny ma na celu sprawdzenie zdolności przeglądarek do wyświetlania i tworzenia dynamicznych stron według powszechnie przyjętych standardów tj. obiektowego modelu dokumentu (DOM) na poziomie 2 (DOM Level 2) i standardu dla dynamicznych skryptów wykonywanych po stronie użytkownika – ECMAScript.

Dodatkowo testowane są również niektóre z elementów innych standardów uznanych przez twórców testu za szczególnie przydatne do tworzenia dynamicznych stron Web 2.0[5], tj.

  • zagnieżdżania dodatkowych elementów według standardu HTML4 (<object>, <iframe> itp.)
  • 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’, parowanie 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 będzie odnosił się arkusz CSS
  • Data URL, czyli zagnieżdżanie specjalnie zakodowanych informacji (np. obrazków) w adresie URL
  • SVG (animacje, fonty itp.)

Elementy, które można sprawdzić jedynie poprzez porównanie ze stroną wzorcową:

  • CSS2.x – pobieranie fontów
  • CSS3 – cienie tekstu

Możliwość pobierania fontów jest testowana za pomocą niestandardowego fontu TrueType „Ahem”, w którym większość znaków, to po prostu zamalowany kwadrat. Za pomocą tego fontu w prawym górnym rogu ekranu wyświetlana jest litera X. Kolor tła jest ustawiony na różowy, a znaków na biały, dlatego jeśli font nie zostanie prawidłowo pobrany, to w rogu pojawi się biała litera X na różowym tle, a w przeciwnym wypadku tło będzie zasłonięte przez znak.

Natomiast cień powinien być widoczny dla tekstu „Acid3”, który jest narysowany dużym stopniem pisma.

Podział na podtesty

[edytuj | edytuj kod]

Acid3 został podzielony na 100 podtestów podzielonych z kolei 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 się formularzy i tabel HTML, podczas przetwarzania przez skrypty oraz DOM2 HTML
  • Bucket 5: Testy pochodzące z zawodów Acid3 Competition (SVG, HTML, SMIL, Unicode, ...)
  • Bucket 6: ECMAScript

Wynik testów w poszczególnych przeglądarkach

[edytuj | edytuj kod]

Wartość licznika procentowego opiera się na liczbie zdanych podtestów. Oznacza to, że niektóre przeglądarki mogą mieć większy wynik w teście, a jednocześnie nie będzie to oznaczać, że są bardziej odpowiednie dla dynamicznych stron serwisów Web 2.0 (mogą np. przejść więcej mniej istotnych testów).

Pierwsza zapowiedź przejścia wszystkich testów padała w zapowiedzi Opery[6]. Testowa wersja ich silnika WinGogi/LinGogi została jednak wydana 28 marca 2008[7]. Było to dzień po tym, jak twórcy WebKit wydali pierwszą publiczną wersję przeglądarki, która potrafiła przejść test w sensie zgodności ze standardami (wynik 100/100)[8]. Jednak (podobnie jak w wersji Opery) parę podtestów wciąż działało zbyt wolno, by cały test był w pełni udany.

17 września 2011 Ian Hickson oraz Håkon Wium Lie ogłosili, że niektóre testy Acid3 związane z fontami SVG, animacjami SMIL w SVG i paroma innymi zostały wyłączone[9]. Zmiany te spowodowały, że część przeglądarek, które miały wówczas problemy z tymi testami, zaczęły przechodzić cały test Acid3 w sensie zgodności z testowanymi standardami (m.in. Internet Explorer oraz Firefox). Jak tłumaczył Ian Hickson, zmiany były spowodowane koniecznością wprowadzenia zmian w samych standardach.

Zestawienie wyników procentowych

[edytuj | edytuj kod]
Legenda:
0-45 46-70 71-90 91-99 100
Wersja Typ wersji Data wydania Wynik[a] Komentarz
Safari (Mac OS X 10.4.3+, Windows XP i Vista)
5.0 stabilna 2010-06-08 100 Test 69 wciąż wykonuje się zbyt wolno.
4.0.2 stabilna 2009-07-08 100 Test 69 wciąż wykonuje się zbyt wolno.
3.1.2 przestarzała 2008-06-19 75
Google Chrome (Windows, Linux, Mac OS X)
11.0.696 przestarzała 2011-04-27 100 Test 26 wykonuje się zbyt wolno.
10.0.648 przestarzała 2011-03-08 100 Test 69 wykonuje się zbyt wolno.
8.0.552 przestarzała 2010-12-03 100 Test 71 wykonuje się zbyt wolno.
6.0.472 przestarzała 2010-09-07 100
5.0.375 przestarzała 2010-06-08 100 Test 69 wciąż wykonuje się zbyt wolno.
4.0.302 przestarzała 2009-12-04 100 Test 69 wykonuje się zbyt wolno.
2.0.172 przestarzała 2009-05-21 100 Wciąż pojawia się komunikat „LINKTEST FAILED”.
1.0.154 przestarzała 2008-12-11 79
Opera (Windows, Linux, Mac OS X)
11.61 stabilna 2012-01-23 100 Testy 26, 69 i 71 wykonują się zbyt wolno.
10.60 przestarzała 2010-07-01 100 Test 69 wykonuje się zbyt wolno.
9.64 przestarzała 2009-03-03 85 Działa także w starych wersjach Windows (od 95)
Firefox (Windows, Linux, Mac OS X)
89.0 stabilna 2021-06-01 93
88.0.1 stabilna 2021-05-05 97
52.2.1 ESR (64-bit i 32-bit) stabilna 2017-06-29 98 lub 99 [1]

Wynik zmienny zależny od kolejnych przeładowań strony. Możliwy antywzorzec projektowy „system z wyścigami”. Często nie przechodzi testu 72, nie przechodzi w ogóle testu 35.

10.0.2 stabilna 2012-02-16 100

Test 26 wykonuje się za wolno.

7.0 przestarzała 2011-09-27 100
4.0 przestarzała 2011-03-22 97 Nie przechodzi testów: 77-79.
3.6.10 przestarzała 2010-09-15 94 Nie przechodzi testów: 71 i 75-79.
2.0.0.20 przestarzała 2008-12-18 52 Działa także w starych wersjach Windows (od 98)
Konqueror (Windows, Linux z KDE)
4.8.2 stabilna 2012-04-04 92
Internet Explorer (Windows)
9.0.8112.16421 stabilna 2011-10-11 100 Test 26 wykonuje się zbyt wolno, są problemy z testem 69.
8.0.6001.18702 stabilna 2009-03-19 23
7.0.5730.13 przestarzała 2007-10-26 12
6.0.2800 przestarzała 2002-09-09 11 Działa także w starych wersjach Windows (od 98)

Graficzne wyniki testu

[edytuj | edytuj kod]
Silnik Wyniki testu różnych wersji
­Wersja z okresu wydania Acid3 ­Najnowsza, stabilna wersja
(pierwsza z wynikiem 100/100)
­Najnowszej wersja robocza
(tam gdzie stabilna nie przeszła testu)
WebKit
Safari 3.0.4

Safari 4.0.2

Chromium 55.0.2883.87 - dwie różowe pionowe
linie w górnym prawym rogu,
nieobecne we wzorcu.
Presto
Opera 9.27

Opera 10.0
Gecko
Firefox 2.0.0.12

Firefox 13.0.1
KHTML
Konqueror 4.0.2
Trident
Internet Explorer 7.0

Internet Explorer 10.0

Rozwój Acid3 i jego wpływ na rozwój przeglądarek

[edytuj | edytuj kod]

Prace nad pierwszą wersją testu

[edytuj | edytuj kod]

Ian Hickson rozpoczął prace nad Acid3 już w kwietniu 2007, jednak prace postępowały powoli. W grudniu 2007 prace zostały wznowione, a szersze informacje o nich zostały podane 10 stycznia 2008 w blogach przez Anne van Kesteren[10] i Dustina Brewer[11]. W tym czasie zestaw był osiągalny pod wiele mówiącym adresem: „http://www.hixie.ch/tests/evil/acid/003/NOT_READY_PLEASE_DO_NOT_USE.html” (...jeszcze nie gotowy, proszę nie używać). To nie powstrzymało jednak szerokiego zainteresowania ze strony społeczności programistów internetowych.

14 stycznia 2008 wciąż brakowało jeszcze 16 ze stu planowanych podtestów, stąd najpierw na blogu Iana Hicksona[12], a potem także na stronie WaSP[13] ogłoszono konkurs na dopisanie pozostałych 16 podtestów.

Poniżej wymienieni programiści mają swój udział w budowaniu ostatecznej wersji testu Acid3, właśnie poprzez udział we wspomnianym 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

[edytuj | edytuj kod]

Wpływ Acid3 na rozwój przeglądarek internetowych okazał się znaczący jeszcze przed jego oficjalnym wydaniem. Dla przykładu silnik przeglądarek internetowych WebKit, w ciągu mniej niż miesiąca uzyskał wzrost liczby zdanych podtestów z 60 do 87[14].

Jak określał to główny twórca testu, Ian Hickson, pierwszą wersję Acid3 uznano za „wystarczająco stabilną”, by można było jej używać[14]. Hickson przewidywał początkowo, że po paru miesiącach wyniki przeglądarek będą zbliżać się do wyniku 100/100, a programiści zaczną zgłaszać błędy w podtestach.

Tymczasem 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. Jednocześnie programiści faktycznie wraz ze zbliżaniem się do setki zaczęli zgłaszać błędy w teście. 26 marca 2008 Hickson ogłosił na swoim blogu, że część ze zgłaszanych uwag była zasadna i wprowadził odpowiednie poprawki w kilku podtestach, a część z nich zaktualizował[15]. Jeszcze tego samego dnia programista Apple znalazł błąd w podteście związanym z SVG i pomógł go naprawić[16]. Błąd ten wiązał się z mylną interpretacją specyfikacji i dlatego Opera przechodząc ten podtest w starej wersji, również zachowywała się nieprawidłowo. Dwa dni później 29 marca 2008 Ian opisał dodatkowy problem i drobną zmianę w podteście dotyczącym sztucznego fontu „Ahem”, który jednak dotyczył tylko Maca, a więc nie zmienia wyniku Opery. Problem był powiązany z antyaliasingiem czcionek, który zmieniał wielkość znaku, który zasłaniał wówczas część obramowania, co twórcy Safari próbowali ominąć poprzez wyłączenie antyaliasingu tego fontu[17].

Parę dni później Hickson zmienił jeszcze jeden podtest (nr 26), który jest jednym z testów badających wydajność przeglądarki. Zmiana ma ułatwić miarodajne testowanie przeglądarek na różnych komputerach. Wyjaśnił także, co miał na myśli pisząc, że animacja musi być płynna. Mianowicie żaden z testów nie może trwać dłużej niż 33 ms, przy czym według Hicksona tak naprawdę tylko wspomniany podtest nr 26 powinien zajmować znaczącą ilość czasu. To wszystko przy założeniu, że dane są pobierane z cache'u przeglądarki, a więc przy ponownym uruchomieniu testu. Jednak w związku z tym, że standardy nie określają ściśle wydajności, wynik liczbowy 100/100 jest wystarczający do przejścia testu w sensie zgodności ze standardami[4].

  1. Wynik liczbowy może być inny przy ponownym uruchomieniu testu i jest to zalecane działanie. Wynika to z tego, że niektóre podtesty przy pobieraniu danych z cache'u mogą trwać krócej niż za pierwszym razem. Ponowne uruchomienie testu ma uniezależnić wyniki od sprawności połączenia z serwerem zewnętrznym. Stąd też dla programistów naprawiających błędy istotniejsze od wyniku liczbowego mogą być szczegółowe komunikaty widoczne w raporcie (patrz Przebieg testu).

Przypisy

[edytuj | edytuj kod]

Linki zewnętrzne

[edytuj | edytuj kod]