To validate or not to validate – that is the question!


4 stycznia 2015 / Comandeer


Walidator

Walidator w działaniu

Swego czasu najwyższym zaszczytem dla każdego webmastera był znaczek (X)HTML valid, dowodzący niepodważalnej znajomości wszelkiego rodzaju dziwactw zawartych w specyfikacji czy też zapamiętania długiej listy zdeprecjonowanych elementów/atrybutów. Ale czasy się zmieniły…

DTD – Deprecated Tool of Doom

Czy ktoś jeszcze pamięta stare, dobre DOCTYPE dla HTML 4 lub – o zgrozo! – dla XHTML 1.0?

Przerażające i nic niemówiące rzędy literek, których jedynym celem było… zapewnianie zgodności z wszechwiedzącym walidatorem. Tak naprawdę ta linijka nie robiła nic oprócz tego (ok, był jeszcze tryb quirks, ale to już w ogóle stare dzieje…) i do dzisiaj nie robi. Nic zatem dziwnego, że HTML 5 pozbywa się tej głupoty całkowicie i zostawia nas z prostym:

Ale jak to – jakim cudem taki króciutki zapis może zastąpić tak rozwlekłą deklarację, w której jest nawet element oznaczający zgodność ze standardem ISO (tak, jest takowy!)? Otóż bardzo prosto – żadna przeglądarka nigdy nie używała DTD… Zgodnie ze specyfikacją HTML 4, powstałą w czasach SGML-a i rodzącego się boomu na XML, parsowanie HTML-a powinno przebiegać następująco:

  • poszukujemy DOCTYPE
  • jeśli go nie ma, uruchamiamy tryb quirks (aka tryb IE5)
  • jeśli jest, szukamy adresu do pliku DTD
  • pobieramy plik DTD
  • parsujemy plik zgodnie z zasadami DTD
  • cieszymy się sparsowaną stroną (albo i nie)

Niby proste i logiczne, prawda? Ale punkt 4. powinien każdemu webdevowi dać do myślenia – wszak to pewny DDOS. Miliony przeglądarek na świecie ślące w tej samej sekundzie zapytania na nasz serwer tylko po to, żeby dowiedzieć się jak sparsować stronę… Przerażające i całkowicie niepraktyczne. Tak bardzo niepraktyczne, że żadna przeglądarka nigdy nie pobiera żadnego DTD. Ba, nigdy nawet nie parsuje według zasad narzuconych przez ten plik. Po prostu przeglądarka ma sobie zapisanych kilka zasad, według których wszystko działa i tyle.

Co więcej, każda przeglądarka robi wszystko, żeby wyświetlić nawet te strony, które ewidentnie łamią wszelkie logiczne zasady konstrukcji poprawnego kodu. Problemem większym od niezgodności stron z objawioną prawdą DTD okazał się zatem… brak standaryzacji mechanizmu poprawiania błędów na stronach w przeglądarkach, który to specyfikacja HTML 5 naprawia. Tym samym ostatnie pozostałości po pradawnych DTD zniknęły, ustępując miejsca sensownym mechanizmom, takim jak RelaxNG. No prawie zniknęły…

Nie-walidator

Jedynym miejscem, w którym DTD jest wciąż faktycznie używane to walidator W3C. Prastara świątynia stron zgodnych ze standardami pozostała niewzruszona na dobrą nowinę HTML 5 i wciąż próbuje wszystkim wmówić, że reguły zapisane w DTD są tym, czego oczekujemy od Sieci. Czy aby na pewno?

Na szczęście niedoskonałość tej techniki została zauważona i powstał lepszy walidator, szybko zaadaptowany przez W3C, który nie jest walidatorem.

It’s an automated thing which checks stuff for you that’d otherwise be really tedious for you to check manually. So it helps you. Maybe it should be called the Nu Help-You Checker.„http://html5doctor.com/html5-check-it-before-you-wreck-it-with-miketm-smith/”

Tak, najnowszy walidator nie jest walidatorem, ale sprawdzaczem zgodności ze specyfikacją. Oznacza to mniej więcej tyle, że to, co specyfikacja uznała za błąd, walidator też za takowy uzna. Tylko tyle i aż tyle.

Nie-walidator, a rzeczywistość

Pomyślmy nad sensownymi powodami wymuszania pełnej zgodności strony ze specyfikacją:

  • chcemy sprawdzić czy przypadkiem nie zamknęliśmy jakichś znaczników źle lub nie zrobiliśmy literówki w nazwie atrybutu
  • potrzebujemy zgodności z normą WCAG 2.0 (choć to tak nie do końca, bo ta norma wymusza jedynie syntaktyczną poprawność)
  • ktoś nam kazał zrobić dokument zgodny ze specyfikacją
  • chcemy być fajni

Więcej sensownych powodów wymyślić nie potrafię. Dwa pierwsze są ze sobą ściśle zespolone i jeśli używam do czegoś nie-walidatora, to właśnie do sprawdzania poprawności syntaktycznej. Dwa kolejne… cóż, szefa zawsze można zmienić, a fajność naprawdę nie zależy od żółtego znaczka walidatora (serio!).

Obecnie, przy istnieniu żywej specyfikacji HTML, nie-walidator musi być nieustannie uzupełniany, co i tak nie rozwiązuje problemu. A co z np. Web Components, które z założenia nie będą występować w specyfikacji? Co z niestandardowymi atrybutami (które obecnie mogą być zgodne ze specyfikacją, przy wykorzystaniu tzw. datasetów)? Co z targetowaniem specyficznych platform? Co z ARIA w HTML 4? Takie przykłady można mnożyć.

Obecny nie-walidator i tak jest domyślnie zbyt upierdliwy, czepiając się wszystkich nieznanych sobie atrybutów i elementów, co sprawia, że w przypadku wspomnianych już Web Components jest po prostu nieużywalny. Na szczęście pozwala filtrować rzucane przez siebie błędy i wybrać jedynie te, które naprawdę nas interesują.

Ale i tak to nie jest wystarczające… Bo obecnie inicjalny HTML często nie ma nic wspólnego z generowanym drzewkiem DOM strony, nie wspominając już o Shadow DOM, który ma całkowicie odrębne zasady parsowania! Jak sprawdzać poprawność tych elementów? I czy w ogóle ma to jakikolwiek sens?

Precz z walidacją!

Walidacja musi odejść! Jej czas się już skończył – DTD umarło, a wraz z nim ścisłe ograniczenia parsowania HTML-a i innych pochodnych SGML-a. Te zasady i tak zawsze były tylko teoretyczne.

Sprawdzanie zgodności ze specyfikacją ma zastosowanie tylko dla dokumentów, które z założenia mają być z nią zgodne, co dotyczy większości stron internetowych w Sieci, lecz niekoniecznie aplikacji (internetowych i nie tylko). Co więcej – zgodność ze specyfikacją HTML 5 nie oznacza zgodności ze specyfikacją HTML 4 (inna rzecz, że nie ma żadnego sensownego powodu, żeby wciąż HTML 4 używać), więc w zależności od DOCTYPE możemy otrzymać całkowicie różne wyniki.

Nowy walidator powinien rozumieć składnię HTML 5 i rozpoznawać elementy poprawne syntaktyczne i, jeśli taka jest nasza wola, oznaczać elementy nie występujące w specyfikacji HTML 5. Nie powinien jednak wymuszać na nas czegoś, czego nie potrzebujemy (inna rzecz, że jeśli HTML 5 na coś pozwala, a my i tak robimy świadomie niezgodnie ze specyfikacją, to nie ma to zbytniego sensu – patrz: customowe atrybuty mimo istnienia datasetów).

Czego potrzebujemy? Tego, co obecnie ma JS pod postacią ESLinta: modularnego systemu sprawdzania poprawności stron, który nie dość, że będzie sprawdzał to, co rzeczywiście jest nam potrzebne, ale będzie umiał sobie radzić z dynamicznymi stronami. Nie ukrywam, że czymś fantastycznym byłaby modularna wersja Kwality (który to niestety zdechł pewien czas temu) i prawdę mówiąc pracuję nad takim narzędziem.

Przestańmy być w końcu niewolnikami walidacji i zacznijmy ją traktować jak normalne narzędzie, od którego nasz rozum developera jest zawsze ważniejszy.

Warto poczytać:


Tagi:


Jak pisać deklaracje CSS? Czyli o kolejności właściwości.


22 listopada 2014 / Mr.Mr


Sposoby pisania deklaracji w języku CSSMożemy wyróżnić trzy sposoby pisania deklaracji CSS (a konkretnie segregowania właściwości). Pierwszy sposób zakłada grupowanie par właściwość-wartość na zasadzie ich ważności. Drugi opiera się o segregacji alfabetycznej, trzeci zaś to mówiąc krótko sposób opierający się o brak sposobu… Który z nich jest najlepszy?

Continue reading Jak pisać deklaracje CSS? Czyli o kolejności właściwości.


Tagi:


Dokąd zmierza CSS?


19 października 2014 / Mr.Mr


dokąd zmierza cssIm więcej czytam o tym jak powinno się tworzyć kaskadowe arkusze stylów tym więcej myśle w bardziej ogólnych kategoriach o tym czym jest CSS i czym mógłby być. Nie da się ukryć, że CSS jest technologią prostą, pewnie zbyt prostą jak na współczesne potrzeby i dodatkowo zmienia się relatywnie wolno. Właściwie wszystko to co wymyślamy w kwestii różnorakich metodologii i technologii (np. preprocesorów) jest odpowiedzią na bolączki CSS i, mówiąc wprost, na jego braki. Jeśli się dobrze zastanowić to można z łatwością dojść do wniosku, że język arkuszy stylów nie przystaje do potrzeb współczesnego web design’u. Wiele osób może być tym zaskoczona bo przecież dzisiejsi deweloperzy tworzą rzeczy wręcz niewiarygodne, wielke serwisy internetowe i aplikacje o skomplikowanej strukturze front end’u to codzienność dla każdego użytkownika internetu, ale zapewne nikt nigdy nie zastanawiał się jak to wszystko powstaje i co jest używane do tego by takie serwisy mogły istnieć. Jeśli wziąć to wszystko pod uwagę od razu rodzi się pytanie: dokąd CSS powinien zmierzać?

Continue reading Dokąd zmierza CSS?


Tagi:


Wskazówka – Rozciąganie elementów blokowych na 100% szerokości, wewnątrz elementów z marginesem wewnętrznym


20 września 2014 / Mr.Mr


ściskanie cytrynyCzasami proste problemy są najbardziej irytujące. Dlatego właśnie uruchomiliśmy nasz cykl szybkich wskazówek, które mogą pomóc Wam szybciej uporać się z męczącymi 'bugami’ i problemami. Dzisiaj zajmiemy się prostą, ale czasami złośliwą sprawą – rozciąganiem elementów blokowych na 100% szerokości wewnątrz elementów z marginesem wewnętrznym.

Continue reading Wskazówka – Rozciąganie elementów blokowych na 100% szerokości, wewnątrz elementów z marginesem wewnętrznym


Tagi:


Informacja o autorze jako przykład BEM i OOCSS


2 sierpnia 2014 / Michał Załęcki


screenshot_00119Wiadomo, że przykład kodu tłumaczy pewne zagadnienie lepiej niż sucha teoria. Poniższy elementu interfejsu został stworzony na potrzeby Bydgoszcz Web Development Meetup #4 jako demo do mojej prezentacji o dobrych praktykach CSS, BEM i OOCSS. W kodzie zastosowane jest kilka ciekawych podejść m. in. logiczne grupowanie selektorów [  ]. Podstawowymi zaletami takiego rozwiązania jest duża przenośność, przynajmniej częściowe rozdzielenie selektorów używanych w CSS od tych, z których korzystamy w JavaScript oraz duża czytelność kodu – szczególnie ważna gdy nad jednym projektem pracuje więcej developerów.

HTML

SCSS

Struktura całego projektu może niektórym wydać się skomplikowana, ale niesie ze sobą szereg zalet, które rosną proporcjonalnie do wielkości projektu. Podejście jest diametralnie różne od tego, które proponuje SMACSS. Bardziej od samych elementów, których dotyczy CSS ważniejsze są warstwy abstrakcji.

screenshot_00118

Poniższy kod dotyczy wyłącznie komponentu informacji o autorze, pełen kod znajduje się w repozytorium na GitHub.

Starsze wersje IE mają problem z animacjami SVG realizowanymi w CSS. Zachowanie ikon po najechaniu możemy zmienić wykorzystując wykrywanie funkcjonalności dzięki Modernizr i to, że nadaje on stosowaną klasę elementowi html.

JavaScript

Kodu JavaScript nie ma zbyt wiele. Po inicjalizacji WOW.js nadajemy ścieżką odpowiednie atrybuty tak by można było je następnie animować po najechaniu na ikony portali społecznościowych. Ostatnim elementem jest wykrycie czy użytkownik posiada ekran dotykowy i dostosowanie zachowania jednego z elementów.

Przydatne materiały

 


Tagi:


Wskazówka: Wyrównywanie wysokości kolumn na 100% strony


28 lipca 2014 / Michał Kortas


Wyrównywanie wysokości kolumn Jakiś czas temu projektowałem szablon zaplecza administracyjnego, składającego się z dwóch i trzech kolumn. Ze względów czysto wizualnych oraz zaleceń klienta, kolumny te miały być w każdym możliwym przypadku wyrównane względem siebie, wypełniając 100% wysokości witryny. Problem ten rozwiązałem w dość prosty sposób, wykorzystując pseudo-element  :before , który w tym krótkim przykładzie Wam zaprezentuję.

Struktura HTML

Przygotujmy sobie plik HTML witryny z trzema kolumnami. Po prawej i lewej stronie sidebary na menu i różnego rodzaju widżety, a po środku miejsce na treść.

Podstawowe style CSS

Kolumny należy teraz odpowiednio ostylować. Zrobimy to za pomocą poniższego kodu.

OK, efekt jest zbliżony do takiej wizualizacji:

Brak wyrównania

Kolumny dostosowują się do treści, co w przypadku, kiedy jest ona nierównomierna, wygląda mało estetycznie. Za moment jednak sobie z tym poradzimy, wykorzystując pseudo-element :before z CSS.

Pseudo-element :before

Dla każdej kolumny stworzymy osobną „wyimaginowaną” warstwę, która znajdować się będzie wizualnie pod spodem każdej z nich. Wykorzystując pozycjonowanie absolutne, umiejscowimy je w odpowiednich miejscach witryny, nadając im kolor i szerokość identyczne z kolumnami-matkami. Myślę, że następujący kod wszystko Wam wyjaśni.

Dzięki z-index: -1; osiągnęliśmy wspomniane już umiejscowienie dopełnienia poniżej warstw właściwych. Należy pamiętać, że jeśli pierwszy sidebar jest szeroki na 20%, to kolejna kolumna (w tym przypadku to .content) powinna być przesunięta w lewo właśnie o te 20%. Kolumna trzecia przesuwana jest natomiast o sumę szerokości kolumny pierwszej i drugiej. Obecny schemat kolumn powinien być od tej pory taki jak poniżej.

Kolumny wysokie na 100%

Podsumowanie

Nie jestem pewien, czy ten sposób jest najbardziej efektywny, ale na pewno rozwiązuję problem, z którym się borykałem. Jeżeli znacie inne rozwiązania, podzielcie się nimi w komentarzach pod wpisem.

Zobacz ten przykład online


Tagi:


Nakładające się na siebie tła przy przewijaniu strony w CSS3


25 lipca 2014 / Michał Kortas


CSS3 LogoOd jakiegoś czasu zauważyłem (pewnie nie tylko ja) rosnący trend na budowanie witryn internetowych w stylu „one page”. Jest to ciekawe rozwiązanie kiedy chcemy zaprezentować klientom nasz produkt czy też zaprojektować swoje portfolio. Widziałem już kilka szablonów, które przy przewijaniu ich scrollem przedstawiają bardzo ładny efekt nakładania się na siebie teł poszczególnych sekcji witryny, przy czym każde z nich pozostaje nieruchomo w miejscu.

Nie wiem czy domyślacie się o czym mowa, dlatego już teraz przedstawię wam demo dla tego tutorialu.

Zobacz przykład on-line

Struktura HTML

Zacznijmy od przygotowania prostej strony HTML, która zawierać w sobie będzie cztery oddzielne sekcje ( .content ) informacyjne, oddzielone od siebie blokiem separatora ( .separator ).

Kod CSS

Dobrze, a więc na początek do naszego arkusza stylów dopiszmy następujący, startowy kod.

Separator pomiędzy sekcjami powinien (przynajmniej trochę) odróżniać się od reszty.

Dla każdej sekcji musimy przypisać osobne tło. Przyjęliśmy, że będą to cztery bloki, tak więc dyle deklaracji musimy zamieścić w arkuszu. Tło musi być wystarczająco duże, aby zakryć cały kontener. Oczywiście zostanie ono dopasowane automatycznie dzięki późniejszej właściwości CSS ( background-size ), ale tak czy inaczej rozmiar obrazka musi być dość duży, aby nie stracił on na jakości.

Na koniec część najważniejsza. Style dla sekcji z treścią.

Kluczowym elementem jest linia #6:

Właściwość ta kotwiczy tło danego elementu w miejscu podczas przewijania ekranu.

Podsumowanie

W taki oto prosty sposób, korzystając jedynie z zalet CSSa stworzyliśmy ciekawy efekt. Powyższy tutorial jest tylko prostym przykładem. Zdaję sobie jednak sprawę, że za jego pomocą można przygotować jeszcze lepsze efekty wizualne naszej witryny.

Zobacz przykład on-line


Tagi:


Micro Relacja: Bydgoszcz Web Development Meetup #4 + prezentacja


24 lipca 2014 / Michał Załęcki


highres_339750322.jpegKolejne, już czwarte, spotkanie Bydgoszcz Web Development Meetup za nami. Miałem przyjemność poprowadzić jedną z trzech prezentacji, która dotyczyła dobrych praktyk CSS, BEM, OOCSS na przykładzie inuit.css. Obok mnie prezentacje przeprowadzili Sebastian Małyska (Przychodzi tester do developera) oraz Michał Kowalkowski (O backwi.re i prowadzeniu startupu w Chinach). Na zakończenie Lightning Talks, podczas których m. in. pośmiałem się (braku)logiki operatorów porównania w JavaScript przy operacjach na i null, Paulina Rhone zaprosiła nas na spotkania Geek Girls Carrots oraz opowiedziała o tej organizacji.  Jakub Czaplicki, twórca popularnej aplikacji Sprawdź lekarza opowiedział o ciekawej historii swojej aplikacji.

Prezentacja

Prezentacja dotyczy dobrych praktyk CSS, BEM i OOCSS.


Tagi:


„Przesuwane tabelki” – czyli sposób na responsywność tabel na stronie internetowej


16 lipca 2014 / Mr.Mr


Responsywne tabele na stronach internetowychZapewnienie użytkownikom urządzeń mobilnych wygodnego i szybkiego przeglądania stron internetowych to dzisiaj już standardowy wymóg. Responsive Web Design to jeden z fundamentów współczesnej sieci, a rosnąca ilość użytkowników tabletów i smartphone’ów zmusza nas do tego by nie zapominać o użytkownikach tychże urządzeń. O ile technologia poszła na tyle do przodu, że RWD stało się możliwe i w podstawach nawet relatywnie łatwe do implementacji to jednak pozostał jeden element HTML, który jakby nie zauważał tych zmian… tabelki. To najczęściej one powodują problemy na stronach mobilnych, ale i na to jest sposób!

Continue reading „Przesuwane tabelki” – czyli sposób na responsywność tabel na stronie internetowej


Tagi:


SVG: optymalizacja i przygotowanie plików


2 czerwca 2014 / Michał Załęcki


svg-optymalizacjaPliki SVG (Scalable Vector Graphics) w dobie wszechobecnych smartfonów i innych urządzeń o ekranach z wysokim ppi powinny być standardem, ale nadal ze świecą szukać przykładów ich zastosowania w komercyjnych produktach. Po części jest to wina mało świadomych deweloperów, nadal bardzo popularny jest mit o słabym wsparciu dla SVG. Jeżeli zależy nam na wsparciu IE8 nic(?) nie stoi na przeszkodzie by zainteresować się np. SVGeezy.

Z mojego doświadczenia wynika, że plik SVG, w zależności od tego jak bardzo jest złożony, może być zawsze zmniejszony o kilkadziesiąt procent. Dla ikony złożonej z 5-6 elementów jest to nawet 60-70%. Jak to możliwe?

(Nie)czysty SVG

Winna leży po stronie edytorów. Za przykład weźmy opensourcowy Inkscape i logo WEBroad. Ikona 60×64 w formacie Inkscape SVG to 3 850b.

Inkscape umożliwia również zapis do czystego SVG. Rozmiar takiego pliku to już 2 663b. Niby lepiej, ale jak podejrzymy źródło zobaczymy wiele zbędnego kodu. Jak się okazuje „czysty” to pojęcie względne.

Pierwszą czynnością jaką możemy zrobić to ręcznie wyczyścić taki kod. Wymagany jest jedynie atrybut xmlns dla elementu svg oraz przydatne będą również jego rozmiary oraz opcjonalnie viewBox. Istnieją jednak narzędzia, które oferują automatyczne optymalizowanie jednego lub wielu plików.

SVGO

SVGO to proste i co najważniejsze skuteczne narzędzie obsługiwane z poziomu konsoli, oparte na Node.js. Instalacja i sposób korzystania z narzędzia jest opisany w repozytorium projektu, przejdźmy do efektów.

Zoptymalizowane za pomocą SVGO logo WEBroad to już tylko 1 022b. Prawie 4-krotnie mniej niż pierwotnie! Kod taki jest jednak uciążliwy przy dalszej pracy np. podczas animacji na poszczególnych ścieżkach.

Korzystając z opcji  --pretty możemy wygenerować „ładnie” sformatowany plik o niewiele większym rozmiarze 1 079b.

Iconizr

Iconizr to bardziej rozbudowane narzędzie pozwalające m. in. na łączenie plików svg i zmniejszenie w ten sposób ilości zapytań do serwera. Iconizr napisany został w PHP i poza dostępem z konsoli oferuje możliwość optymalizacji plików SVG z poziomu przeglądarki. Poza samym plikiem SVG otrzymujemy również kod CSS/SCSS. Efekt jest co najmniej zadowalający.

iconizr

Plik SVG:

Plik CSS:

Jeżeli chodzi o samo wykorzystanie plików SVG to Chris Coyier w artykule Using SVG przedstawił już większość sposobów pracy z grafiką wektorową. Jeżeli znacie jakieś ciekawe przykłady zastosowania SVG to dajcie nam znać w komentarzach.


Tagi: