Bootstrap 4 i menu responsywne


13 lutego 2017 / Michał Kortas


Bootstrap 4 wciąż leży w powijakach, jednak z rosnącą nadzieją na finalne wydanie. Na blogu Bootstrapa znajdują się informacje o gotowości do wydania pierwszej bety, a co za tym idzie, nie powinny już pojawiać się żadne większe aktualizacje, nie licząc oczywiście bug-fixów. Myślę, że w tym wypadku mogę już w miarę bezpiecznie zacząć publikować krótkie poradniki związane z tymże frameworkiem. Całość dostępna będzie pod specjalnie wydzielonym tagiem Bootstrap 4. Czytaj dalej Bootstrap 4 i menu responsywne


Tagi:


[Wskazówka] Element „datalist” w formularzach HTML


12 lutego 2016 / Michał Kortas


Na forum webroad.pl pojawił się z pozoru prosty, lecz ciekawy temat, który chciałbym krótko poruszyć w to piątkowe popołudnie. Otóż jeden z Czytelników bloga zapytał o pomoc we wdrożeniu czegoś w rodzaju uzupełniania treści w kontrolkach formularzy (autocomplete) za pomocą jQuery.

Owszem, można zrobić to za pomocą jQuery. W sumie czego nie można?

Ważniejsze jest jednak pytanie – Ale po co?

Podpowiedzi w input’ach w HTML5

HTML5 zawiera w sobie ciekawy element <datalist>, który działa bardzo podobnie do natywnych podpowiedzi ostatnio wpisanych fraz w kontrolkach formularzy, z tą różnicą, że sami możemy zasugerować przeglądarce, co dokładnie ma podpowiedzieć.

Zobacz demo DATALIST

Spójrz na poniższą implementację <datalist> w kodzie HTML.

Aby odnieść się do niej w polu tekstowym, czy liście rozwijanej, wystarczy użyć następującego kodu…

… gdzie parametr list będzie wskazywał na identyfikator przygotowanej listy.

Kontrolki z <datalist> w praktyce

Efektem tego prostego kodu, będzie pole, umożliwiające wpisanie wartości.

DATALIST przed wpisaniem danych

Lub wybranie proponowanych odpowiedzi z listy.

Lista rozwijana w DATALIST

Dopasowane podpowiedzi w DATALIST

Aby sprawdzić działanie powyższego przykładu, zamieszczam go do podglądu.

Zobacz demo DATALIST

Dostępność funkcji w przeglądarkach

Praktycznie rzecz biorąc, wszystkie nowsze wersje popularnych przeglądarek wspierają <datalist>. Więcej szczegółów znajdziesz na stronie caniuse.com/#feat=datalist.


Tagi:


Własny styl CSS dla elementu „file” w formularzu


30 grudnia 2015 / Michał Kortas


Formularz

Czy przycisk wybierania pliku musi wyglądać zupełnie inaczej w każdej z przeglądarek?

Takie pytanie otrzymałem we wczesnej fazie projektowania interfejsu aplikacji webowej. Oczywiście osoba, która je zadała, nie musiała wiedzieć, że wygląd ten narzuca z góry silnik przeglądarki. Postanowiłem jednak wyjść na przeciw temu zagadnieniu i przygotowałem krótki kod niwelujący różnice.

Zobacz DEMO Czytaj dalej Własny styl CSS dla elementu „file” w formularzu


Tagi:


[Wskazówka] Rozmiary względem obszaru roboczego: vw, vh, vmax, vmin


4 maja 2015 / Michał Kortas


Czy kiedykolwiek zastanawiałeś się, w jaki sposób ustawić rozmiar elementu na stronie dokładnie względem okna przeglądarki? Ilekroć razy chciałeś użyć do tego Javascriptu? Jeżeli na oba pytania odpowiedziałeś sobie wynikiem większym niż zero, zapoznaj się z poniższą wskazówką.

W dzisiejszym wpisie zademonstruję Ci w jaki sposób odnosić się do rozmiarów elementów względem okna przeglądarki (viewport). Pomocne będą Ci w tym jednostki vw, vh, vmax i vmin, czyli tak zwane Viewport Units. Bieżące wsparcie dla nich przez najpopularniejsze przeglądarki możesz zweryfikować na stronie caniuse.com. Stan na dzień dzisiejszy prezentuję poniżej.

Wsparcie dla Viewport Units

Wsparcie dla Viewport Units dzięki http://caniuse.com/

Viewport width i viewport height

Ogólnie rzecz biorąc 1vh jest równy 1% wysokości obszaru roboczego ekranu, tak samo jak 1vw – z tym, że w tym przypadku mówimy o 1% szerokości. Z tej własności wynika, że w przypadku obszaru roboczego ekranu o szerokości 1000px wartość dla 1vw jest równa: 1% x 1000px = 10px.

Czyli jeżeli ustawisz wysokość i szerokość kontenera <div>  w ten sposób:

Otrzymasz następujący efekt:

50vh i 50vw

Jednostki vh i vw używać możesz nie tylko dla wartości własności width czy height, ale i choćby dla określania rozmiaru fontu na stronie.

Przy zmianie rozmiarów okna font będzie dopasowywał się do wskazanej wartości.

Viewport minimum i viewport maximum

W tym wypadku wartość będzie dopasowywała się automatycznie, w zależności, której opcji użyjemy.

Wartość 1vmin jest równa mniejszej z wartości 1vh lub 1vw, natomiast 1vmax wybierze sobie większą wartość ze zbioru {1vh, 1vw}.

Sprawdźmy to w praktyce.

Ustaw dla kontenera następujący kod CSS:

Taki styl zapewni nam to, że w przypadku ekranu pionowego <div>  przyjmie szerokość i wysokość połowy krótszego boku obszaru roboczego (czyli szerokość).

Vertical viewport

Jeśli jednak zamienimy orientację ekranu na horyzontalną, wartości dopasują się wprawdzie również do krótszej krawędzi obszaru roboczego, ale w tym przypadku będzie nią już wysokość.

Horizontal viewport

Zakończenie

Zachęcam Cię do testowania i dzielenia się z nami swoimi uwagami.

A może stworzyłeś już projekt, gdzie wykorzystałeś już viewport units?


Tagi:


Prosty preloader CSS3 bez użycia Javascriptu


1 maja 2015 / Michał Kortas


Tworząc aplikacje przeglądarkowe powinniśmy zrobić wszystko, aby użytkownicy korzystający z nich czuli jak największy komfort. Powinno zależeć nam na dobrej optymalizacji skryptów, jak najmniejszej liczbie przeładowań strony oraz prostocie i intuicyjności interfejsu. Nawet jeżeli klient końcowy musi czekać, powinniśmy go o tym informować. Informacja, niezależnie od tego jaka jest, znacznie lepiej wpływa na wewnętrzny spokój aniżeli jej zupełny brak, okraszony białym ekranem przeglądarki obliczającej coś w tle. Z tego więc powodu pokażę Ci jak stworzyć prosty preloader, korzystający tylko i wyłącznie z możliwości CSS3. Do jego działania nie będzie więc potrzebna włączona obsługa Javascriptu, co jest naprawdę (uwierzcie) mile widziane.

Zobacz działanie preloadera na poniższym wideo.

Kod HTML loadera

  1. Utwórz kontener o klasie loader .
  2. Umieść w nim kilka niedużych ikon lub innych elementów (np. <div>). Ja użyłem do tego 6 identycznych sygnetów z loga WEBroad.pl

sygnets-webroad

Kod CSS loadera

Najpierw ostyluj kontener loader . Oczywiście pozostawiam Ci pełną dowolność. Ja akurat chciałem ustawić go w centrum ekranu z efektem cienia wewnętrznego.

Zajmijmy się teraz ikonkami preloadera. Pokażę Ci w jaki sposób wprawić je w ruch, tak aby spadały z góry, zatrzymywały się na chwilę na środku swojej drogi i w końcu chowały się za dolną krawędzią obszaru ograniczonego przez rodzica.

Stwórz nową animację w CSS3 o nazwie loader .

Jeżeli przypiszemy ją do każdej ikonki otrzymamy efekt spadania ale niestety w równej kolejności, co nie wygląda tak efektownie.

Dla urozmaicenia przygotowałem więc różne style dla co czwartego obiektu. Będzie je różnić tylko i wyłącznie opóźnienie wykonywania animacji. Dzięki temu najpierw „ruszy” ikona pierwsza i w ustalonych odstępach pozostałe.

Dostępność

// Akapit został dodany po dyskusji, która zrodziła się w komentarzach. Dziękuję za odzew.

Aby zapewnić dobrą dostępność powyższego rozwiązania, powinniśmy dodać do kontenera .loader  dodatkowe atrybuty:

[role] + [aria-labelledby]

Podsumowanie

Otrzymaliśmy ładny efekt preloadera, który możemy wdrożyć do naszych przyszłych i obecnych projektów. Zachęcam do modyfikacji i podzielenia się nią w komentarzach.

W powyższym przykładzie, dla zmniejszenia ilości kodu nie używałem w tworzeniu animacji przedrostków dla przeglądarek. Pamiętaj, aby je dodać w końcowym projekcie, jeżeli są potrzebne.

Zobacz DEMO


Tagi:


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?

Czytaj dalej 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ć?

Czytaj dalej Dokąd zmierza CSS?


Tagi: