Pique - standardy sieciowe » CSS

Jak poprawnie budować rozwijaną nawigację

Krzysztof Danek — Thu, 24 Jun 2010 20:15:06 +0000

Po pierwsze – rozwijane menu nawigacyjne były złym pomysłem 10 lat temu i są tym bardziej złym pomysłem teraz. Kto próbował użyć takiej nawigacji na ekranie dotykowym, gdzie nie istnieje koncepcja :hover, ten świetnie wie o czym mówię. Chciałem to zaznaczyć na samym początku – jeśli możecie, nie używajcie w ogóle menu rozwijanych!

Do rzeczy. Ten wpis nie ma na celu szczegółowego omówienia technik budowania rozwijanych menu nawigacyjnych. Chcę tylko zwrócić uwagę na jeden konkretny aspekt.

Problem – `display: none;`

Bardzo często widzę, taką strukturę CSSa do ukrywania/chowania menu.
#nav li { float: left; position: relative; height: 30px; } #nav li ul { display: none; position: absolute; top: 30px; left: 0; } #nav li:hover ul { display: block; }

To działa, ale ma jedną zasadniczą wadę – domyślnie wszystkie linki w podmenu są ukryte przed wyszukiwarkami, czytnikami ekranu itd. Według mnie display: none; powinno być tylko używane w połączeniu z JavaScriptem, o ile chcemy zachować dostępność treści.

Rozwiązanie: `left: -999em;`

Lepszym rozwiązaniem jest użyć minusowego pozycjonowania elementów:
#nav li ul { position: absolute; top: 30px; left: -999em; } #nav li:hover ul { left: 0; }

Efekt taki sam, a nagle i roboty będą łapać Wasze linki i użytkownicy korzystający z klawiatury będa mogli nawigować po waszej stronie (przynajmniej w teorii, w praktyce wymaga to jeszcze trochę zachodu, żeby uczynić rozwijaną nawigację w pełni dostępną z klawiatury).

Nowa odsłona IE PNG Fix

Krzysztof Danek — Thu, 17 Jul 2008 13:10:39 +0000

IE6 nie wybiera się na zasłużoną emeryturę w najbliższej przyszłości. Codzienna udręka z tą przeglądarką stała się właśnie odrobinę wygodniejsza.

Powstała nowa wersja popularnego narzędzia IE PNG Fix, autorstwa Twin Helix Design. Służy ono do włączania obsługi kanałów alpha w obrazkach zapisanych w formacie PNG.

Nowa wersja 2.0 alpha 1 ma dwie nowe, rewelacyjne funkcje, niedostępne wg mojej wiedzy w innych rozwiązaniach. Udostępniono obsługę dwóch właściwości CSS: background-position i background-repeat. Mam szczerą nadzieję, że ten skrypt podoła ciężkim warunkom bojowym codziennej pracy i będzie można go swobodnie używać do momentu, gdy IE6 przestanie mieć znaczenie (koło 2011 roku, jak tak dalej pójdzie z tempem konwersji).

min-width w Internet Explorer przy pomocy expression

Krzysztof Danek — Wed, 08 Nov 2006 12:11:57 +0000

Jeden z projektów, nad którym obecnie pracuję wymaga zastosowania właściwości min-width. Istnieje kilka rozwiązań tego problemu, jedne mniej, inne bardziej intuicyjne. Ze względu na pozycjonowanie absolutne, minusowe marginesy i sporą ilość floatowanych elementów postanowiłem, zamiast czysto CSSowego rozwiązania , zastosować expression. Wszystkie przykłady, które znalazłem w Internecie, sprowadzają się do następującego wyrażenia:

body { width:expression(document.body.clientWidth < 750? "750px": "auto" ); }

Proste, nie? Nie byłem jednak zbyt zdziwiony, gdy to nie zadziałało…

Na całe szczęście po raz kolejny z pomocą przyszedł niezastąpiony Peter-Paul Koch. W artykule document.body and doctype switching znalazłem następujący fragment:

If you use a DOCTYPE that puts Explorer 6 in standards compliant mode, some properties of document.body are reassigned to document.documentElement.

Jednym słowem – jeśli używacie DOCTYPE to minimalną szerokość w IE przy pomocy expression można uzyskać następująco:

body { width:expression(document.documentElement.clientWidth < 750? "750px": "auto" ); }

Uwaga: Internet Explorer w wersji 5 będzie jednak działał tylko dla pierwszej wersji jak rozumiem. Jeśli musicie wspierać tą przeglądarkę, to proponuję zastosować osobny arkusz dla tej wersji IE i użyć komentarzy warunkowych

Testowanie obsługi selektorów CSS w przeglądarkach

Krzysztof Danek — Fri, 13 Oct 2006 06:48:28 +0000

W serwisie CSS3 Info zamieszczono zbiór testów napisanych w JavaScript przez Nielsa Leenheera. Pozwalają one określić, jakie selektory CSS obsługuje nasza przeglądarka.

Poniżej krótkie zestawienie dla przeglądarek, które udało mi się przetestować do tej pory.

Przeglądarka	Selektory ^[1]	Testy ^[2]
Internet Explorer 6.0	10	243
Internet Explorer 7.0 RC1	13	272
Opera 9.01	24	290
Safari 2.0.3	28	299
Firefox 1.5.0.5	36	315

^[1] – ilość selektorów obsługiwanych ze wszystkich 43 badanych
^[2] – ilość testów zaliczonych z 513 wszystkich testów

Jak widać Firefox 1.5 zdecydowanie prowadzi, co nie było dla mnie wielkim zaskoczeniem. Niestety, zmartwił mnie poziom obsługi oferowany przez najnowszą wersję IE…

Poniżej trochę bardziej szczegółowy rozkład:

Selektor	IE6	IE7	Opera 9	Safari 2	Firefox 1.5
*	tak	tak	tak	tak	tak
E	tak	tak	tak	tak	tak
.class	nie	tak	tak	tak	tak
#id	tak	tak	tak	tak	tak
E F	tak	tak	tak	tak	tak
E > F	nie	tak	tak	tak	tak
E + F	nie	tak	tak	tak	tak
E[attribute]	nie	nie	tak	tak	tak
E[attribute=value]	nie	tak	nie	tak	tak
E[attribute~=value]	nie	nie	tak	tak	tak
E[attribute\|=value]	nie	nie	tak	tak	tak
:first-child	nie	nie	tak	tak	tak
:link	tak	tak	tak	tak	tak
:visited	tak	tak	tak	tak	tak
:lang()	nie	nie	nie	nie	tak
:before	nie	nie	tak	tak	tak
::before	nie	nie	tak	tak	tak
:after	nie	nie	tak	tak	tak
::after	nie	nie	tak	tak	tak
:first-letter	tak	tak	tak	tak	tak
::first-letter	tak	nie	tak	tak	tak
:first-line	tak	tak	tak	tak	tak
::first-line	tak	nie	tak	tak	tak
E[attribute^=value]	nie	nie	nie	tak	tak
E[attribute$=value]	nie	nie	nie	tak	tak
E[attribute*=value]	nie	nie	tak	tak	tak
E ~ F	nie	tak	tak	nie	tak
:root	nie	nie	nie	tak	tak
:last-child	nie	nie	nie	nie	tak
:only-child	nie	nie	nie	nie	tak
:nth-child()	nie	nie	nie	nie	nie
:nth-last-child()	nie	nie	nie	nie	nie
:first-of-type	nie	nie	nie	nie	nie
:last-of-type	nie	nie	nie	nie	nie
:only-of-type	nie	nie	nie	nie	nie
:nth-of-type()	nie	nie	nie	nie	nie
:nth-last-of-type()	nie	nie	nie	nie	nie
:empty	nie	nie	nie	nie	tak
:not()	nie	nie	nie	tak	tak
:target	nie	nie	nie	tak	tak
:enabled	nie	nie	tak	nie	tak
:disabled	nie	nie	tak	nie	tak
:checked	nie	nie	tak	nie	tak

Do powyższego zestawienia trzeba dodać pewien komentarz. Brak obsługi nie oznacza całkowitego braku wsparcia dla danego selektora w konkretnej przeglądarce. Oznacza to, że nie przeszedł on jednego lub kilku z kilkudziesięciu testów, sprawdzających szczególne przypadki zastosowania. Najlepiej samemu przeprowadzić testy i przeczytać szczegółowe komentarze przy każdym z nich.

Wygląd czy struktura – od czego zacząć budowę strony?

Krzysztof Danek — Tue, 01 Aug 2006 20:38:33 +0000

Jestem właśnie po lekturze świetnego artykułu Visual vs. Structural, którego autorem jest Tommy Olsson, twórca nieaktywnego już niestety bloga The Autistic Cuckoo.

Artykuł opisuje dwie przeciwstawne metody tworzenia stron internetowych:

Podejście wizualne – budowę zaczyna się od stworzenia projektu graficznego, następnie tworzy się szablony HTML, a na koniec dodaje właściwą treść
Podejście strukturalne – treść strony przetwarza się na kod HTML, główny nacisk kładąc na sensowną kolejność i znaczenie tworzonych elementów, a dopiero później dodaje się do niego warstwę graficzną

Całym sercem opowiadam się za tym drugim rozwiązaniem z kilku powodów:

Otrzymany kod HTML jest dużo bardziej przejrzysty i sensowny dzięki skupieniu się na strukturze, a nie na detalach graficznych. Oczywiście, wraz z budowaniem warstwy prezentacyjnej pojawia się konieczność dodania kolejnych elementów, jednak mogą one zostać lepiej rozmieszczone i ich ilość jest z zasady mniejsza. Ponadto łatwiej określać nazwy klas i identyfikatorów dla elementów (a to wcale nie taka oczywista kwestia), ponieważ widzimy, co konkretnie zawiera dany kontener.
Część klientów, zamawiających stronę internetową ma bardzo mgliste pojęcie o jej zawartości. Przygotowanie szablonów na pierwszym etapie projektowania pozwala zapobiec przykrym niespodziankom, gdyż klienci w tym momencie widzą dokładnie, co znajdzie się na stronie. Dużo prościej wprowadzić poprawki w treści i funkcjonalności w kodzie HTML, niż przerabiać i ciąć od nowa sporą część projektu graficznego.
Programiści są szczęśliwsi – od razu widać czy dana podstrona będzie wymagała osobnego modułu, czy też można wykorzystać któryś z obecnie istniejących. Wprowadzanie zmian w połowie projektu jest zawsze bardziej czasochłonne i kosztowe, niż gdyby były one uwzględnione od samego początku.

Niestety, w codziennej pracy napotykam wiele przeszkód, uniemożliwiających takie rozwiązanie:

Przygotowanie treści jest zajęciem czasochłonnym i wymaga od klienta zaangażowania i świadomości rezultatu, który chce się osiągnąć. Z tym w 80% przypadków nie jest za dobrze.
Dobrzy graficy, znający się na tworzeniu stron internetowych to skarb. Ci, potrafiący przygotować projekt uwzględniając gotową strukturę (opisaną w HTMLu) są prawdziwą rzadkością i przeważnie już pracują w wielkich agencjach.
Najlepiej sprzedaje się projekt graficzny, bo on przemawia do klienta.
Poza smutnym działem produkcyjnym nikogo to nie interesuje i ciężko wymusić całkowitą reorganizację sposobu pracy i kontaktów z klientem.

Jak można zauważyć – istnieją pewne problemy, które wynikają jednak nie z wad samej metody, a raczej z niedoskonałości rzeczywistości, w której musimy pracować. Mimo to mam nadzieję, że ten sposób szybko się przyjmie gdyż zdecydowanie ułatwia pracę zarówno kodera jak i programisty.