Wpadki i wypadki #1

Jak Comandeer lata temu napisał, tak dzisiaj zrobi (i wcale nie jest to spowodowane jutrzejszym egzaminem – wcale). Oto przed Państwem 1. numer Wpadek i wypadków!

• Swego czasu (w wakacje – tak, wiem, zapłon) T-Mobile nachalnie reklamowało się jako najlepsza sieć w Polsce. W tym celu nawet sobie kupili odpowiednią domenę – najlepszasiec.pl. I tu zonk: najlepszasiec.pl nie działa. Adres ten zwraca piękny błąd związany z brakiem takiego adresu… Czyżby T-Mobile wywaliło miliony na telewizyjną reklamę nieistniejącej strony? Ależ nie! www.najlepszasiec.pl działa! Zero przekierowań, nic – po prostu jedno działa, drugie nie. Osobiście nie wpisuję www od dobrych 3 lat. Sorry, T-Mobile, ale nie zachwycacie. I zamiast jakoś wykorzystać taką fajną domenę, przekierowujecie na brzydki adres http://www.t-mobile-trendy.pl/najlepsza_siec.html. Ja się pytam – po co?
• Wpadkę zaliczył też nie tak dawno portal AntyWeb.pl. Od dawna mam ich wrzuconych w czytnik RSS i od czasu do czasu zdarzy mi się wejść na ich stronę. Pewnego razu zobaczyłem coś strasznego. Jak widać, dobrze ustawiony cache to wciąż rzadkość na stronach internetowych.

• Jeszcze straszniejszą rzecz można spotkać na stronie Okinet.pl. Komunikat o cookies na całą stronę, mimo że ładny, to subtelna przesada w stosowaniu bezsensownego prawa. No i oczywiście przycisk do zamknięcia tego cuda łamie wszystkie dobre praktyki:

  <a href="javascript:void(0)" onclick="cookiesPopupDissable()" class="oki-button-popup-close fright"> </a>

• Środowisko SEO się oburza, że Google może nie indeksować zakładek i jako przykład jest podana strona, która połowę treści ukrywa przy pomocy… display: none;. Serio? Poprawne zakładki robi się tak, żeby były widoczne dla AT. Do tego celu wykorzystać można technikę .visuallyhidden, [role=tablist] + odpowiednie podlinkowanie i stylowanie przez :target. Takie cudeńko może działać i bez JS, przy odpowiednim ostylowaniu. Oczywiście na przykładowej stronie nie ma z tego nic. Ba, przy wyłączonym JS de facto strona nie ma treści. Poza tym – czemu Google ma indeksować wszystkie zakładki, skoro po wejściu na stronę tylko jedna z nich jest widoczna, a cała reszta chamsko ukryta? To nie jest problem Google, moi drodzy SEO-wcy, to problem Waszego podejścia do spraw dostępności!

• Ostatnimi czasy cenzuruje się moje komentarze. Zdziwiło mnie jednak gdy na pewnym blogu rozmowa nagle się urwała. Nie posądzam bynajmniej nikogo o to, że celowo mój koment został usunięty w odmęty zapomnienia, niemniej – chciałbym skończyć, co zacząłem. Dlatego też zamieszczam swój (obszerny) komentarz tutaj:

  Pragmatyczne osiągnięcia są takie, że ta mikrosemantyka jest głównie na użytek wyszukiwarek.

  No to to nie jest żadne osiągnięcie w stosunku do mikroformatów czy DC 😉 Wszystkie 3 formaty Google czyta, co widać na przykładzie (widzę, że coś zmienili w parsowaniu mikroformatów – trza będzie poprawić). Co więcej, mikroformaty mają de facto natywne wsparcie (wszystkie [rel] są mikroformatami; [rel=nofollow] czy [rel=author] są standaryzowane jako mikroformaty!) a DC jest oficjalnym standardem ISO. Czym jest Schema.org? Pokazówką siły Google – niczym więcej. Żadna przeglądarka nie implementuje Microdata API, bo okazało się, że jest niekompatybilne z istniejącymi interfejsami DOM. Tym samym microdata jest serwowana tylko dla Google (nie oszukujmy się). A co nam daje microdata ponad mikroformaty? Teoretycznie daje całkowicie abstrakcyjną strukturę, pozwalającą opisać każdy typ danych. Problem polega na tym, że to już słyszeliśmy i od lat było: RDF → RDFa. Microdata natomiast tworzy dziwnego potworka ściśle zespolonego z HTML, którego nijak nie można wyabstrahować jako zewnętrzne metadane. Co więcej, opisanie prostych rzeczy jest o wiele bardziej skomplikowane, niźli zdanie się na mikroformaty. Owszem, microdata zyskuje, gdy musimy opisać bardziej skomplikowane struktury danych, ale praktycznie nikt ich do tego nie używa (łącznie z autorem książki, który w taki sposób opisuje 2 elementy strony – nazwę książki i swoje nazwisko) – zatem mamy do czynienia z rozwiązaniem teoretycznie fantastycznym, którego nikt nie umie (nie chce?) wykorzystać poprawnie w praktyce. W większości zastosowań lepsze efekty uzyskałoby się przy użyciu RDFa.

  …nieobsługiwany w żadnym (nawet najnowszym) MSIE ani w Android browser (w sumie ok. 20% rynku), o czym dowiadujemy się w książce.

  Ok, ale 20% rynku oznacza, że 80% rynku skorzysta z tej technologii. Mamy do wyboru albo Web Audio API + fallback do audio (co razem ma penetrację na poziomie ok. 95% rynku), albo Flasha, który nie działa na całym rynku mobilnym, nieustannie się powiększającym. Co więcej, na Androidzie przecież Web Audio API działa, w Chrome. Osobiście dawno nie widziałem, żeby ktoś używał Androidowego browsera – większość obecnie działa na Chrome, gdzie ta technologia już jest.

  Obecnie jest to ok. 3%; to więcej niż użytkowników iOSa na WWW

  To jedynie pogratulować Apple 😉 Widzę, że IE8 ciut ostatnio skoczyła popularność. Niemniej wciąż to jest na tyle mało, że myśląc w kategoriach Progressive Enhancement czy też – w tym wypadku raczej trafniejszym – graceful degradation, obsługa tego typu browserów nie powinna nastręczać trudności. A jeśli chodzi o bardziej skomplikowane webappy, to takie wsparcie po prostu nie ma sensu (patrz: Google, które wspiera jedynie IE10 i IE11).

  Chodzi o problemy ze stylowaniem, brak obsługi na wielu platformach, a nawet wycofywanie się z obsługi przy kolejnej wersji przeglądarki (patrz iOS).

  To, co zrobiło iOS, to po prostu jakieś nieporozumienie… Co do problemów ze stylowaniem: nigdy nie dało się sensownie ostylować pól formularza, więc przełomem nie jest, że nadal się nie da 😉 Chociaż te nowe elementy formularzy wcale nie są takie nie do ruszenia. Najłatwiej je stylować, wiedząc czym jest Shadow DOM i tzw. „parts” elementów (tutaj kłania się głównie Blink i Webkit). W lisku koncepcja Shadow DOM istnieje, ale nie jest jeszcze eksponowana (tzn. jest, ale wciąż jako eksperymentalny feature) – niemniej sposób stylowania tych elementów formularzy jest taka sama. Co więcej, myśląc znów w kategorii PE, lepiej jest mi zaserwować input[type=number] (+ [pattern="[0-9]+"] dla iOS) i wymusić choćby w części przeglądarek UI do wpisywania liczb (dla mobilnych to jest szczególnie ważna różnica przecież, bo układ klawiatury ekranowej dla pól liczbowych jest całkowicie inny!) niźli dostarczyć zwykłe pole tekstowe wszystkim przeglądarkom. Jako fallback, można zastosować ograniczenia zakresów znaków w JS. W ostateczności i tak przecież złapie to walidacja po stronie serwera. Tutaj chodzi jedynie o UX. Największe problemy są związane z typami pól dotyczącymi czasu i dat. De facto tutaj są faktyczne problemy ze stylowaniem, ale jak się uprzeć, to to też można przezwyciężyć.

  No więc całe ostrze krytyki zasadza się w tym, że nie są opisane w ten sam sposób – np. wg standardu HTML5 znacznik header może wystąpić w każdym section, a w ARIA role=banner może wystąpić na całej stronie co najwyżej raz

  Jeśli wyjmiemy z WAI-ARIA główne landmarks, to tak – różnica jest kolosalna. Ale wystarczy wejść ciut głębiej w to, co oferuje ARIA, żeby te różnice starannie się zatarły. Czym innym jest bowiem nagłówek sekcji a czym innym nagłówek strony. Tym samym section → [role=region], article → [role=article], article > header → [role=group] (najprawdopodobniej). Im bardziej wczytujemy się w definicje, tym stają się one bardziej rozmyte… No bo co to znaczy w [role=region] „A large perceivable section of a web page or document, that is important enough to be included in a page summary”? No w sumie nic… Znaczy dokładnie to samo, co „any other independent item of content” w definicji znacznika article w specyfikacji HTML5. Samo oznaczenie głównego nagłówka strony, stopki i głównej treści nic nie daje jeśli chodzi o dostępność. Prawdziwe piekło rozpętuje się właśnie przy tych małych elementach, które niby nie znaczą a znaczą (patrz: implementacja autocomplete czy choćby poprawne zrobienie prostego tooltipu). ARIA jest opisana w ten sam nic niemówiący sposób, jak specyfikacja HTML5. Jedyna różnica jest taka, że opisuje to wszystko na jeszcze wyższym poziomie abstrakcji (bo nie może używać żadnych znaczników jako kontekstu!).

  Co do problemów w IE8: jeśli musimy go wspierać, to równie dobrze możemy używać nowych znaczników z HTML5 (dodając do nich np [role]) a problemy ze stylowaniem rozwiązywać po prostu przy pomocy HTML5 Shiv, a jeśli uważamy to za jakieś voodoo, to zawsze zostaje technika typu header > div, gdzie stylujemy właśnie div a nie header.

  Często mówi się że te znaczniki wprowadzono na podstawie badań – autor książki zdecydowanie temu zaprzecza, i ma powody.

  Myślałem, że temat jest już dawno zamknięty, po tym jak bodaj w 2012 Hixie sam przyznał, że te znaczniki zostały wymyślone przez WHATWG (a głównie przez niego)… Wszyscy przeszli nad tym do porządku dziennego i tyle. Nie można zapominać, że w chwili, gdy powstawał HTML5 (rok 2005), Sieć mierzyła się z przerażającym widmem XHTML 2.0. Wówczas header był wybawieniem od ul[href] i wszędobylskich XML namespaces.

  Często spotykanym wzorcem w Internecie jest wzorzec post+komentarze; HTML5 niestety nie ma jednoznacznego tagowania na tę okoliczność.

  A ARIA ma? 😉 Skończymy najprawdopodobniej z [role=article] > [role=group], co znaczy dokładnie tyle samo (czyli nic ;)). article > article wygląda przynajmniej bardziej sensownie (przywodzi na myśl analogię do gazety, gdzie odpowiedzią na artykuł jest… no właśnie, artykuł).

  Wyszukiwarki od dawna atakują warstwę semantyczną zamiast poprzestawać tylko na przetwarzaniu znaków. O semantyce w Internecie mówi się głównie w kontekście wyszukiwarek.

  Wyszukiwarki jedynie reużywają semantyki, która w domyśle jest przeznaczona dla użytkownika. Sam wcześniej tak dużo pisałeś o ARIA – to właśnie przecież czytniki ekranowe najwięcej zyskują na poprawnej semantyce HTML! Bo ponad semantyką leżą dostępność i użyteczność, których jest fundamentem. Natomiast stwierdzenie, że nie trzeba dbać o standardy przy pisaniu stron, bo Google i tak znajdzie, to jak splunięcie userowi w twarz i powiedzenie z uśmiechem Przepraszam, ale ta strona ma być po prostu popularna, żebym nabił kabzę; ty jesteś tylko skutkiem ubocznym.

  Oj, przy takim podejściu to książki, blogi i fora o HTML5 w ogóle nie są potrzebne. Mnie jednak interesuje również i to, co o specyfikacji ma do powiedzenia świat webmasterów praktyków – a pod tym względem książka się wyróżnia (dużo wartościowych cytatów z grup dyskusyjnych), widać że autor śledzi wątki na bieżąco.

  Sam jestem autorem tutorialu o HTML5 (który zostanie ciut poprawiony dzięki tej dyskusji ;)) i także śledzę grupy dyskusyjne (niestety, chyba te mniej popularne, bo np doskonałą ideę Web Intents zabito), więc mam wrażenie, że moje słowa też można zaliczyć do słów praktyków. Po prostu nie zgadzam się absolutnie ze sposobem, w jaki autor patrzy na HTML5. Wydaje mi się, że w wielu miejscach nagina rzeczywistość (choćby przechodząc obok PE czy graceful degradation) i ciut sensacjonalizuje (no choćby sam tytuł książki ;)).

  Krytyka krytyki krytyki krytyki HTML5 na blogu WebKrytyka – so deep.

• Ogłoszenie parafialne: tajny projekt powstaje, ale żeby nie było, że nic nie robię, to zdradzę co to jest. Otóż zapewne niektórzy pamiętają jeszcze Kwality.Polip.com. Było to narzędzie do sprawdzania jakości kodu. Niestety, było już dość leciwe i nie obsługiwało HTML5. Co więcej – zniknęło. Dlatego też pomyślałem, że przecież WebKrytyk, jako strona zajmująca się tylko i wyłącznie jakością stron (chociaż teraz lepiej byłoby powiedzieć: Sieci), powinien udostępniać narzędzie podobne, przystające do dzisiejszych realiów! Tym sposobem zrodził się Auditr – projekt modularnego i automatycznego audytora stron. Jego sposób budowy pozwalałby każdemu zainteresowanu napisać i dodać do niego swój własny test (yay, community project!).

  Co więcej, najważniejszym punktem systemu miał być system pomocy, dokładnie opisujący każdy test… Ostatecznie go nie będzie – zamiast tego powstanie Kompendium WebKrytyka. Na początku nie będzie tam zapewne zbyt wiele materiałów, jednak na pewno będą się sukcesywnie pojawiać i będą piętnować najczęstsze błędy, przewijające się pomiędzy recenzjami poszczególnych stron. Oprócz tego pojawią się też artykuły i inne materiały dotyczące najlepszych obecnie praktyk webmasterskich. Myślę, że Kompendium ma szansę się pojawić w swojej podstawowej formie nawet szybciej niż Auditr…

  Co się obecnie dzieje z Auditrem? Rozwinął się na tyle, że przechodzi pierwszą w swym życiu refaktoryzację (czytaj: wkurzyłem się i wywaliłem ¾ kodu). Z racji tego, że ostatnio rzeczywistość mnie nie rozpieszcza, może to potrwać. Niemniej odpalanie testów działa (ale już obsługa ich błędów nie). Zatem – bliżej niż dalej.

  Przepraszam wszystkich, którzy z niecierpliwością czekają na ten projekt. Pojawi się! I wraz z Kompendium będzie kamieniem milowym, który spokojnie można będzie nazwać WebKrytykiem 2.0.

• Ogłoszenie parafialne 2: skoro już zmjany idom, to w tym tygodniu pojawi się wpis łamiący dotychczasowe konwenanse (i to bardziej niż ten!). Mam nadzieję, że będzie warto czekać!

Tyle na dziś… Chciałbym się dowiedzieć co sądzicie o pomyśle Kompendium i czy Wpadki i wypadki ujdą w tłoku. Zachęcam do dyskusji w komentarzach ↓. WebKrytyk się zmienia (w końcu!) i mam nadzieję, że będzie to zmiana na lepsze.