Kwestie dostępności nie są ignorowane tylko przez początkujących koderów, ale również przez pseudo ekspertów, którzy nieświadomi swojego braku wiedzy przez lata powtarzali te same błędy. Osobiście przyznaję, że w pewnych aspektach sam byłem zupełnym laikiem.

Strony internetowe to medium przeznaczone dla wszystkich. Nie mówię tutaj o grupie docelowej danej aplikacji, ale równości w dostępie poprzez dowolne kanały bez względu na stopień niepełnosprawności. Niestety już na samym początku projekt strony ma spore wady. Nie każda strona internetowa musi spełniać regulacje dostępu, ale świetnie jeśli tak właśnie jest. Ileż to dyrektyw, ustaw i protokołów stworzyły światowe organizacje, państwowe rządu i inne podmioty, a ile stron jest dostępnych, nawet w nikłym stopniu?

Prawdą jest to, że niewidomy nie potrzebuje Facebooka czy YouTube’a do szczęścia, ale skoro giganci mają gdzieś niepełnosprawnych użytkowników to taki właśnie przykład dają pozostałym twórcom w sieci. Następnie strony internetowe budowane są przy pomocy przestarzałych technik, mają niesemantyczną strukturę, nie przechodzą walidacji, pomijając ułatwienia dostępu, jak kontrast, wielkość czcionki i wiele innych.

Strony internetowe wyświetlane są nie tylko na monitorze, ale czasem drukowane czy czytane na głos. Jak wtedy zachowuje się twoja ultra nowoczesna aplikacja, wspierana przez AJAX i setki linii JavaScriptu? Prawdopodobnie tego nie sprawdziłeś, bo przecież niewidomy, niedowidzący, niesłyszący i inni niepełnosprawni nie skorzystają z twojego serwisu, nawet jeśli chcieliby.

Najgorzej jest ze wszystkimi stronami rządowymi i publicznymi. Żal się robi, kiedy widzisz, jak publiczne pieniądze są marnotrawione na oryginalne, ale jakże niedostępne serwisy ministerstw, urzędów i masy innych podmiotów, których zadaniem jest wsparcie obywateli. Jeśli niepełnosprawny użytkownik nie załatwi sprawy urzędowej przez internet to pewnie ktoś, go przyjmie w przystosowanym do jego inwalidztwa urzędzie. Oczywiście.

Gdyby tylko takie błahe z pozoru sprawy były proste, jak wiele czasy zostałoby na podróże koleją, zakupy online, płatności mobilne czy znalezienie ulubionego programu w telewizji, bo przecież te rzeczy są dostępne w sieci od dawna i dla każdego.

Idea

Pomysł w prosty sposób wykorzystuje nowe selektory CSS3. Dołączenie do strony stylów, które pozwalają na łatwe wykrycie pustych elementów, znaczników z brakującymi lub niewłaściwymi atrybutami jest teraz banalne.

Poprzez kilka reguł CSS dowiesz się, które obrazki mają pusty atrybut alt lub nie mają go wcale. Analogicznie z tabelami i pustymi komórkami albo podsumowaniami zawartości z atrybutów summary.

Sposób na znalezienie w kodzie przestarzałych znaczników typu font, center lub innych rzeczy, które często umykają naszej uwadze. Najlepsze z tego wszystkiego jest to, że w podobny sposób stworzysz style ukierunkowane na twoje kryteria.

Podobnie jak dowolnie tworzysz arkusze stylów resetujące domyślne style przeglądarek, tak teraz stwórz zestaw pomocny przy twojej pracy. Style diagnostic.css przedstawione przez Erica znajdziesz w przykładach na jego stronie internetowej.

Całość sztuczki polega na odpowiednim przygotowaniu tła dla oczekiwanego efektu. Element zawierający formatowany tekst pozycjonujemy relacyjnie, a wewnątrz niego umieszczamy dodatkowy znacznik span. Wszystko po to, aby dodatkowy element pozycjonowany absolutnie przechowywał tło.

Download · Live Demo

Połączenie tych dwóch technik umożliwia uzyskanie nałożenia tła na tekście i połączenie go z kolorem bazowym tła. Uzyskanie wspomnianego efektu wymaga dodatkowych elementów w strukturze dokumentu. Jest to konieczne, ponieważ tekst zawsze wyświetlany na tle danego elementu.

Innym sposobem osiągnięcia przezroczystego tekstu w kolorze tła jest ustawienie odpowiednich właściwości dla elementu: background: url(kuba.jpg); i color: transparent;. Niestety samo to nie wystarczy, ponieważ zmiana sposobu generowania tekstu i tła wymaga jeszcze ustawienia jednej właściwości. A dokładnie reguły background-clip: text; ze specyfikacji CSS3.

Kiedy programista tworzy konfigurację, a w przyszłości analizuje i zmienia ją osoba nietechniczna, najpewniej doprowadzi to do kłopotów. Dlaczego wprowadzanie zmian w plikach konfiguracyjnych jest trudne i mało zrozumiałe dla prostych ludzi? Pewnie dlatego, że same pliki są skomplikowane składniowo.

Najmniej użyteczna forma zapisu konfiguracji to pliki języka, w którym programujesz. Świetnie jeśli używasz PHP albo Pythona, ale handlowiec czy marketingowiec, któremu za rok zlecą zmianę na stronie nie zrozumie zapisów technicznych.

Używanie plików XML jest bardzo ciekawym doświadczeniem, bo przecież każdy rozumie filozofię znaczników otwierających i zamykających, atrybutów i wartości, nie wspominając o prologach i komentarzach. Niestety języki znaczników mają jedną wielką wadę! Ogromny narzut wielkości w stosunku do przesyłanych danych, poza tym, że mała literówka spowoduje błąd parsowania pliku.

Kiedy twoja konfiguracja będzie rozbudowana. Tablice, liczby i słowniki zagnieżdżone wielokrotnie potrzebujesz łatwego i czytelnego zapisu takich danych. Nie znałem języka, który oferowałby użytkownikowi tak wiele, za tak niewiele, dopóki nie poznałem YAML.

YAML jest uniwersalnym językiem przeznaczonym do zapisu danych w strukturalny sposób. Brzmi to skomplikowanie, w rzeczywistości składnia tego języka jest bajecznie prosta. Sposób edycji wymaga od autora zachowania kilku reguł, a daje praktycznie nieograniczone możliwości.

Poszczególne struktury danych pliku oddzielone są znakami nowej linii, a ich wzajemna hierarchia wynika z znaków wcięcia. Dzięki temu możliwy jest zapis list, słowników, a także skalarów. Możliwe są również wskaźniki pomiędzy istniejącymi danymi, co ogranicza nadmiarowość. Niestety używanie znaku tabulatora do tworzenia wcięć jest niezgodne ze specyfikacją języka.

Mimo tego, YAML jest zwięzły i czytelny dla człowieka. W swojej prostocie jest całkowicie przenośny pomiędzy językami programowania i reprezentuje wbudowane struktury danych. Dodatkowo YAML jest rozszerzalny i łatwy w edycji przez narzędzia, przetwarzające tekst. Moim skromnym zdaniem te cechy są ogromnymi atutami języka.

ColorHexa prezentuje szczegółowe informacje na temat szukanego koloru. Prezentuje kolory pośrednie pomiędzy dwoma podanymi kolorami, aż w końcu przedstawia zestawy kolorów dopasowanego do bazy według założonych kryteriów. Wszystko to skromnej, lekko eleganckiej formie.

Niestety dla mnie osobiście mało ważne są wartości składowych koloru zapisane w kilkunastu postaciach. Jako twórca arkuszy stylów kaskadowych korzystam jedynie z zapisu heksadecymalnego, a pewnie każdy ma swoje uzasadnienie do określonego zapisu koloru. Moim naturalnym krokiem naprzód będzie używanie notacji RGBA W przyszłości. Wiem, jak poszczególne składowe wpływają na ostateczny kolor, ale nadal najbardziej interesujący aspekt tego typu narzędzi to algorytm działania, który poznam i praktycznie wykorzystam.

Sztuka tworzenia wydajnych i czytelnych arkuszy stylów to kwestia doświadczenia, ale i odpowiedniego podejścia. Według filozofii zorientowanej obiektowo reguły przygotowywane są pod kątem ponownego wykorzystania. Z tego względu nie powinny być ograniczane poprzez selektory kontekstu czy potomka. Jednak czy grupowanie wspólnych właściwości w klasach jest czymś nadzwyczajnym? Przecież to jedna z podstawowych zasad obowiązujących w CSS.

Wprowadzenie

Louis twierdzi, że separowanie wspólnych reguł, takich jak kolory, marginesy, czcionki i wiele innych daje zysk w sytuacji, gdy powtarzają się one w kontekście innych elementów na stronie. Zgadzam się, z tym stwierdzeniem choć określanie atrybutu class wielu elementom bywa zbyteczne. Teraz pojawia się kwestia wydajności i przejrzystości. Czy lepszy jest krótszy kod CSS (jeśli to w ogóle możliwe) czy jednak przejrzysta struktura dokumentu? Oba warianty mają swoje zalety i osobiście obstawałem przy drugim wyborze.

Niestety przy komercyjnych projektach struktura dokumentu i arkusze stylów rozrastają się równie szybko. Istotne jest rozsądne wyważenie podziału między obiema warstwami. Podejście zorientowane obiektowo przynosi korzyści przy naprawdę złożonych projektach. Nicole Sullivan jako pierwsza, która zaproponowała taki sposób tworzenia arkuszy stylów.

Globalne spojrzenie

Idąc dalej, tym tropem, uświadamiamy sobie jak wysokie wymagania wiążą się z pisaniem wydajnych stylów kaskadowych przez projektantów i koderów. Kod CSS jest zbyt wrażliwy na zmiany osób trzecich, szczególnie mało doświadczonych. Każda osoba wplata w pisane arkusze swoje wieloletnie nawyki, utarte schematy i osobisty tok rozumowania. Wówczas nasze rozbudowane style są praktycznie nieprzydatne dla innych osób.

Twórcy siatek CSS zrozumieli to wiele lat temu i stworzyli uniwersalne style dla układów wielokolumnowych. Ten kierunek jest zdecydowanie dobry, a zapoczątkował go 960 Grid System. Czy przeniesienie podobnego rozumowania na grunt pozostałych właściwości elementów stron internetowych jest możliwe?

Dobre praktyki

1. Stwórz reguły, które wykorzystasz ponownie wykorzystasz.
2. Niech twoje style będą semantyczne i jednolite.
3. Niech moduły będą przezroczyste od wewnątrz.
4. Bądź elastyczny.
5. Pokochaj siatki.
6. Ograniczaj selektory.
7. Podziel strukturę i wygląd.
8. Podziel kontenery i treść.
9. Niech elementy struktury korzystają z przygotowanych klas.
10. Używaj resetowania i czcionek ze stylów YUI.

Powyższe punkty zawarte w prezentacji Nicole są jasne, a przynajmniej w większości są jasne. Zdecydowanie zgadzam się z niektórymi, z paroma mniej, a kilku nie rozumiem. Podział reguł CSS na uniwersalne moduły skutkuje budowaniem wspólnego wyglądu elementów z mniejszych składników. Dzięki temu kolejne podstrony, właściwie nie potrzebują dodatkowych właściwości. Wspólny wygląd dla nagłówków, list i innych semantycznych elementów powinien być jednolity w obrębie całej strony, a zatem niech zostanie zdefiniowany w jednym miejscu. Rozdzielenie struktury i wyglądu stylów.

Podczas tworzenia stylów kaskadowych, częściej kieruje się rozsądkiem, niż emocjami. Z tego powodu nigdy nie używałem siatek. Mimo tego sformułowanie “Siatki określają szerokość, a zawartość wysokość elementów” jest prawdziwe. Rzeczywiście reguły typu .example {...} są bardziej użyteczne niż div.example {...}. Ale dlaczego wskazane jest korzystanie z gotowych stylów YUI? Czyżby były aż tak genialne?

Możliwe pułapki

1. Style zależne od lokalizacji.
2. Unikaj przypisywania klas do konkretnych elementów.
3. Zapomnij o identyfikatorach dla stylów wewnątrz treści.
4. Unikaj cieni i zaokrąglonych rogów dla nieregularnych teł
5. Nie buduj map z wszystkimi obrazami.
6. Unikaj wyrównania w pionie.
7. Tekst jako tekst, a nie obraz.
8. Nadmiarowość.
9. Unikaj przedwczesnej optymalizacji.

Jeśli określone style są mocno zbliżone do siebie w obrębie danej strony to są niepraktyczne również w całym arkuszu stylów. Zdecyduj się na jednej wariant i stosuj go konsekwentnie. Niech jednolite reguły określają wygląd tych samych elementów. Nadpisywanie kolejnych właściwości w zależności o przodka elementu lub innych kryteriów jest kosztowne. Wówczas elementy zachowują się przypadkowo. Połączenie identycznych wspólnych reguł w różnych wariantach pozwala na szerokie zastosowanie.

Podsumowanie

Część z wymienionych punktów pokrywa się lub wzajemnie wyklucza w porównaniu z listą dobrych praktyk. Tak czy inaczej, wszystkie zalecenia traktujmy jako sugestie podczas procesu projektowania i tworzenia stylów kaskadowych. Całościowy zarys koncepcji jest nieco ogólny, a stosowanie poszczególnych wytycznych mocno uzależnione od samodyscypliny kodera.

Wszyscy wiemy, że CSS ma pewne braki, a internet rozwija się niezmiernie szybko. Jednak pisanie wydajnych arkuszy nie stanie się łatwiejsze wraz ze wsparciem CSS3 przez przeglądarki. Doświadczenie i sprawdzone schematy wciąż są ważne, co nie zwalnia nas z poszukiwania lepszych i optymalnych rozwiązań.

Strategia to czynnościowy wzorzec projektowy, który hermetyzuje algorytmy z danej rodziny w postaci klas. Jeśli taka definicja brzmi skomplikowanie to diagram UML wyjaśnie wszelkie wątpliwości.

Często okazuje się, że dziedziczenie jest niewystarczającym sposobem tworzenia oprogramowania. Wtedy z pomocy przychodzi inne techniki projektowania aplikacji.

Strategia definiuje wspólny interfejs dla każdego obsługiwanego algorytmu. Wymusza to na nas stworzenie implementacji obsługiwanych funckji w klasach dostarczających konkretne algorytmy. Klasa, która korzysta z tych algorytmów, ustawia referencję do aktualnie używanej strategii poprzez motodę ustawStrategie(). Jeśli klient zmienia algorytm danej strategii, wiąże się to z ustwieniem nowej strategii dla klienta. Analogicznie tworzenie następnych algorytmów nie wymaga ingerencji w klasy klienta, ani interfejsu, a jedynie stworznia nowej strategii implementującej znany interfejs.

Wzorzec strategii opiera swoje działanie na kompozycji i delegacji, a nie dziedziczeniu. Dzięki temu unikamy mało elastycznych instrukcji warunkowych w klasie klienta, który wybiera dany algorytm. Poszczególne strategie mogą być zmieniane w trakcie działania programu, co daje korzyści w postaci różnego zużycia zasobów lub złożoności obliczeniowej. Takie rozwiązanie ma też swoje wady w postaci narzutu komunikacji między klientem i strategią, a także większą liczę utworzonych obiektów. Jednak moim zdaniem to mały koszt w stosunku do przytoczonych zalet.

Przykładowe wykorzytanie tego wzorca w PHP opiszę szerzej w artykule dotyczącym wsparcia generowania tabel XHTML.

Istnieje w sieci mnóstwo serwisów typu Question & Answer, z czego pierwszym był prawdopodobnie Answers Yahoo. Jednak to zupełnie inna bajka, bardziej ogólna i skierowana do masowego odbiorcy. Kiedy szukam informacji na temat konkretnej biblioteki, danej funkcji czy składni określonego języka używam wyszukiwarki, a wśród pierwszych kilku wyników wyszukiwania, prawie zawsze pojawia się adres do odpowiedzi na Stackoverflow.

Znalazłem tam mnóstwo odpowiedzi na różne pytania, a mimo to sam nie zadałem ani jednego. Możliwość szukania nie wymaga rejestracji i logowania od użytkowników. System weryfikacji i oceniania odpowiedzi, promuje najlepsze wpisy, aby pytający uzykał najlepszą odpowiedź. Dodatkowo system tagów wspomaga kategoryzowanie tematów, aby wszystkim było łatwiej.

Niestety, szukanie polskich źródeł, dokumencji i dokładnych opisów, dotyczących programowania jest utrudnione, gdyż takie materiały mają zawsze charakter lokalny. Dlatego, jeśli szukam informacji w sieci, to praktycznie tylko po angielsku. Dzięki temu mam większe szanse, że znajdę to czego szukam. Jeśli jednak, szukasz czegoś na temat programowania w języku polskim to, prawdopodobnie pomocne okażą się devpytania. Udany odpowiednik opisywanego pierwowzoru, który ciągle się rozwija i zdobywa nowych zwolenników.

Na początku roku moja domowa biblioteka wzbogaciła się o kilka książek, które z pewnością zrecenzuję. W najbliższym czasie dowiecie się dlatego warto kupić Smashing Book #2, bo zdecydowanie warto. Ostanio czytam wiele na temat wzorców projektowych i kwestii projektowania aplikacji. Będzie do dobry czas do dyskusji na temat dziedziczania i architektury systemów klasy enterprise.

Git oraz GitHub, tak mi się spodobaby, że zamięszcze tam kolejne pomysły i narzędzia, nad którymi pracowałem lub pracuję. W końcu pojawi się kilka wpisów na temat programowania, zarówno Python czy Django, ale także Xhtml i CSS. Tak czy inaczej sporo wyzwań i planów. Byle do przodu.

Zobaczymy za rok, co poniższej listy zostanie zrealizowane. Oto moje postanowiena na trwający już 2012 rok.

TOP 10

1. Python, nauka i rozwój
2. SPINNING STAR 2
3. Moja własna książka o XHTML i CSS3
4. Więcej deski niż rok wcześniej
5. Co najmniej 1 wpis tygodniowo na blogu
6. Chorwacja w wakacje
7. Nowe portfolio
8. Więcej czasu dla bliskich i znajomych
9. Przybranie 5 kilogramów
10. Kredyt hipoteczny

Plany bardzo ambitne i jak najbardziej realne. Wykonanie przynajmniej pięciu z mojej listy, oznacza dobry rok, ośmiu – bardzo dobry, a wszystkie – REWELACYJNY!