Jedną ze zmian dokonanych przy ostatniej migracji, którą z pewnością moi stali czytelnicy (kilku takich jest :P) zauważyli od razu, jest zmiana szablonu na na moim blogu. Nadal jest to Mystique, jednak wersja, z której korzystałem tak długo pochodziła sprzed ponad dwóch lat (pobierałem ją dziesiątego maja 2010, w momencie zakładania bloga). Teraz, po tak długim czasie zdecydowałem się jednak na pobranie najnowszej wersji. Nie było to łatwe, bo w mojej poprzedniej wersji wprowadziłem ogromną ilość modyfikacji.

Przy tej okazji udało mi się jednak przełamać i zachęcony nowym wyglądem (i częściowo nowymi możliwościami) postanowiłem dokonać aktualizacji i ponownie poprawić co nieco w szablonie. Największą robotą było przetłumaczenie całego szablonu na polski (jeśli gdzieś znaleźliście błędy w tłumaczeniu to proszę serdecznie o kontakt).

Poza tym (tak samo jak w poprzedniej wersji szablonu z której korzystałem) starałem się lekko poprawić wynikowy kod HTML. Niestety, Wordpress zbudowany jest w ten sposób, że pewne fragmenty kodu narzuca odgórnie, więc żeby je zmodyfikować musiałbym albo napisać własne wersje masy funkcji z Wordpressa albo modyfikować jego rdzeń, wykraczając z modyfikacjami poza pliki szablonu, co oznaczało by odcięcie się od aktualizacji oprogramowania, bo przy każdej z nich Wordpress nadpisywałby moje zmiany.

Jedną z wprowadzonych zmian jest przeniesienie favicon.ico z katalogu theme'u do głównego katalogu strony (root). Dlaczego? Część przeglądarek wczytując stronę za każdym razem robi dodatkowego requesta pod /favicon.ico w poszukiwaniu favicony. Dopiero gdy jej tam nie znajdzie, to podąża do lokalizacji podanej w znaczniku meta. Efekt jest prosty, mając favicon.ico w innej lokalizacji od części przeglądarek dostawałem o jedne request więcej przy każdym wywołaniu strony. Drobna poprawka, ale skoro coś może być lepsze tak małym nakładem czasu, do dlaczego tego nie zmienić?

Zrobiłem też trochę porządków w sekcji head dokumentu. Usunąłem linki do RSD, WLW, wersję Wordpressa (meta generator) i jeszcze kilka zbędnych rzeczy. Tutaj na szczęście Wordpress pozwala na modyfikację za pomocą systemu akcji (add_action(), remove_action()).

Chciałem też zmniejszyć ilość dołączanych plików CSS i JS, połączyć je w kilka więszych (bo strona generuje spore ilości requestów), ale żeby to osiągnąć musiałbym przerobić używane przez siebie pluginy oraz szablon, a nie mam ochoty tracić pracy przy każdej aktualizacji wtyczki lub co gorsza rezygnować z aktualizacji.

Tym razem zmian ściśle pod maską szablonu nie było wiele, w zasadzie tylko powyższe drobnostki i dopisanie jednego własnego widgetu.

Mam nadzieję, że szablon Wam się podoba, jeśli macie jakieś uwagi, komentujcie :)

Od dłuższego już czasu w internecie występuje ogromne poruszenie pracami nad nową, piątą, wersją HTML-a. Sam też byłem i w sumie po części nadal jestem jego entuzjastą. Miło byłoby gdyby istniał standard pozbawiony wszelkich archaizmów, który wymuszałby poprawne pisanie stron na webmasterach, a internet zmieniłby się w jedną wielką cyfrową sielankę…

Nie no. Oczywiście przesadzam, ale w tym wpisie chciałbym przestawić Wam prosty powód, dla którego tak naprawdę wejście w życie HTML-a 5 niewiele zmieni.

Co z tego, że specyfikacja zabrania używania HTML-a do opisu wyglądu strony (czyli znaczniki takie jak font itd…), że zabrania używania ramek, skoro przeglądarki nadal to wszystko obsługują.

Jako "materiał dowodowy" do tego wpisu posłuży ta prosta strona. Polecam zajrzenie w jej kod. Jest tam sieczka najgorszych znaczników z HTML4 tj. font, center, iframe…

I teraz stawiam główne pytanie: Co z tego, że specyfikacja HTML5 wymusza np. stosowanie wyłącznie CSS-a do opisu wyglądu strony, skoro przeglądarki internetowe tego nie robią?

Już teraz mamy takie przykłady: twórcy wielkich portali szczycą się, że ich strony używają HTML5. Szkoda tylko, że w większości używanie tego standardu kończy się wraz z sekcją head.

Marzy mi się, żeby przeglądarki podchodziły tak rygorystycznie do parsowania HTML-a, jak do XML-a lub jak parser do parsowania PHP. Żeby browser widząc stronę z błędem wyświetlał komunikat na ekranie. Myślę, że dopiero to zmobilizowałoby porządnie "webmasterów" do tworzenia stron zgodnych ze standardami.

Strona z DTD HTML-a piątego z działającymi frame'ami, to nie jest moje marzenie… Wygląda na to, że twórcy stron będą mogli tworzyć sieczkę, z którą będą męczyć się przeglądarki. Zmieni się tylko ilość błędów w walidatorze, o którego istnieniu większość normalnych użytkowników nie ma pojęcia (a szkoda)…