Mariusz Tarnaski "MariuszT"

Temat narzędzi wspomagających budowanie stron www po stronie klienta gościł już na moim blogu. Chociażby w październiku pisałem o Bootstrap od Twittera. Do tej pory nie znałem jednak HTML5 Boilerplate.

Jak zaczynacie budować nową stronę? Ja mam przygotowany gotowy wzór. Plik z podstawowym szkieletem strony, wpisanymi meta tagami, które uznaję za potrzebne oraz niewielką strukturę katalogów i kilka plików np. do resetu styli CSS czy do obsługi przezroczystych PNG (kiedyś, teraz już nie ). Pewnie każdy z Was ma coś podobnego. Jeżeli nie gotową paczkę to chociaż swój ulubiony model, który kopiujecie z jednego projektu do drugiego.

To jest oczywiście sensowny sposób, po co za każdym razem robić coś od nowa, powtarzać tą samą pracę. Można jednak pójść o krok dalej i zamiast korzystać z własnego rozwiązania, użyć np. HTML5 Boilerplate, który został opracowany i przetestowany przez wiele tęgich głów i na pewno spisze się lepiej niż samodzielnie przygotowany wzór dokumentu.

Najważniejsze cechy HTML5 Boilerplate:

• HTML5 to przyszłość
• Ale nie zapominamy nawet o takich starociach jak IE6
• Kod dostosowany do urządzeń mobilnych
• Użyto normalize.css zamiast resetu stylów
• Użyto respond.js dla CSS3 Media Queries
• Rekomenduje i współpracuje z Google Chrome Frame dla starszych wersji IE
• Użyto modernizr do detekcji możliwości przegladarki
• Wsparcie cachowania CSS i JS
• Poprawia bezpieczeństwo PHP np. wyłącza register_globals lub usuwa nagłówek HTTP-X-Powered-By informujący o wersji PHP
• Udostępniono ustawienia dla serwerów Apache, ngnix itp. dodające obsługę popularnych typów MIME, włączających kompresję gzip itd.
• i wiele, wiele więcej

To naprawdę tylko drobna lista wszystkich właściwości. W HTML5 Boilerplate jest mnóstwo drobnych udogodnień o których sami na pewno nie pamiętalibyśmy. Koniecznie przeczytaj dokumentację, przejrzyj pliki. Znajdziesz tam również wiele linków do materiałów dodatkowych takich jak integracje biblioteki z CakePHP, Zend Framework, WordPress czy Django. Fani WordPressa znajdą dodatkowo listę gotowych skórek opartych o HTML5 Boilerplate.

Do tego wszystkiego mamy prosty skrypt do zbudowania własnej biblioteki tylko z tymi elementami, które potrzebujemy i w takiej postaci jaka nam odpowiada. A jeżeli to nie wystarcza to skorzystaj z Initializr gdzie masz szereg dodatkowych opcji.

HTML5 Boilerplate robi ogromne wrażenie. Włożono w niego mnóstwo pracy, ilość wiedzy jaka była do tego potrzebna jest imponująca. Samemu nie jesteśmy w stanie zrobić tego lepiej. Żałuję, że nie wiedziałem o HTML5 Boilerplate wcześniej, użyłbym go do ostatniego projektu, przetestował w praktyce. Ale mój następny projekt będzie już korzystał z możliwości tej biblioteki.

Pisałem już o stylach resetujących domyślny CSS przeglądarki. I to nie raz. Czy to jednak jedyny sposób aby wszystkie przeglądarki wyświetlały Twoją stronę jednakowo?

Całkowity reset styli CSS do standardowych wartości jest często krytykowany za niewłaściwe podejście. Zdaniem niektórych, lepiej byłoby zmieniać tylko to co powinno być zmienione. Stworzyć reguły naprawiające tylko te ustawienia i tylko w tych przeglądarkach gdzie faktycznie jest coś nie tak. Ta idea przyświeca twórcom normalize.css.

Takie podejście jest trudniejsze do zrealizowania ale zdaniem niektórych, wydajniejsze i bardziej poprawne.

Podstawowe zalety normalizacji:

• Współpraca z przeglądarkami na urządzeniach mobilnych
• Reguły dostosowane do HTML5
• Mniej styli, mniejsza objętość
• Podczas debugowania nie mamy takiego bałaganu (kto pracował z Firebugiem i zwykłym resetem ten wie o czym mowa)
• Brak idiotycznych reguł opisujących, że koło jest naprawdę okrągłe
• Można się czegoś nauczyć, wiele pomocnych komentarzy przy stylach

Sami musimy zdecydować co nam lepiej odpowiada. Z pewnością normalizacja jest teraz bardziej trendy od resetu

Certyfikaty to dobra rzecz, potwierdzają Twoją wiedzę. Jestem skłonny zaryzykować twierdzenie, że dla każdego normalnego pracodawcy jeden konkretny certyfikat może być więcej wart niż studia, nawet w oczekiwanym kierunku.

Problemem natomiast jest wybranie, który certyfikat chcemy zdobyć. Strona w3schools.com osiągnęła mistrzostwo w pozycjonowaniu przez co pojawia się na czołowych pozycjach W Google dla wielu zapytań o HTML, CSS a nawet PHP i MySQL. Nazwa nie pozostawia złudzeń, że to wszystko musi mieć coś wspólnego z konsorcjum W3C.

W3Schools oferuje na swojej stronie możliwość zdania płatnych, certyfikowanych egzaminów. Jest w czym wybierać. Na tą chwilę (grudzień 2011) mamy testy z HTML, CSS, JavaScript, jQuery, XML, ASP i PHP. Każdy za 95 dolarów (kiedyś było taniej ).

Na pierwszy rzut oka, wygląda atrakcyjnie. Wczytajmy się jednak w szczegóły.

• Po pierwsze, egzamin zdajemy online. Każdy rozgarnięty w tej chwili sobie myśli „Ej! To co z wiarygodnością?”. Wiarygodność ma zapewnić ktoś od Ciebie Ktoś kto w teorii ma nad Tobą stać i patrzeć czy rozwiązujesz test samodzielnie a potem podpisać się pod certyfikatem. Od Ciebie zależy czy to będzie Twój kumpel z podwórka czy np. Twój szef ze znanej i szanowanej firmy IT. Oczywiście Twój Anioł Stróż mógłby Ci wystawić zwykłą rekomendację i miałaby taką samą moc no ale wtedy W3Schools by nie zarobiło
• Test to 70 pytań wielokrotnego wyboru lub pytań TAK/NIE, limit czasu to 70 minut. Ja mam alergię na takie testy ale zdaję sobie sprawę, że to najprostsza i najszybsza forma egzaminu i może być nawet skuteczna o ile pytania są sensowne. W tym przypadku jednak nie są. Pytania są banalne. Tzn. nie wiem jakie są bo oczywiście nie przystąpiłem do żadnego testu ale są testy przykładowe i ich poziom woła o pomstę do nieba.
• Jeżeli nie zdasz (minimum 75% poprawnych odpowiedzi) lub chciałbyś poprawić swój wynik to masz jeszcze jedną próbę. Jak rozumiem, w cenie.
• W3Schools nie ma żadnego związku z konsorcjum W3C. Żadnego!

To wszystko powoduje, że nikt o zdrowych zmysłach nie weźmie pod uwagę tych certyfikatów. Więcej! Może uznać Cię za cwaniaka, który przyszedł go oszukać lub głupka, który dał się na tą farsę nabrać.

Do w3schools.com jest wiele więcej zarzutów. Społeczność webmasterska wyłapała wiele nieścisłości i błędów we wskazówkach tam umieszczonych. W swej złości stworzyli stronę w3fools.com gdzie bezwzględnie wytykają wszystkie grzechy autorów kursów.

Przy okazji, jakie certyfikaty warto zrobić?

Ja znam jeden dobry, certyfikat od Zend. W świecie PHP (w tej chwili certyfikat jest z PHP w wersji 5.3) nie ma cenniejszego certyfikatu. Osoby mocno związane z Zend Framework mogą też pomyśleć o certyfikacie z tego frameworka. Być może inne firmy egzaminują również z innych frameworków, CMS’ów itd.

Na pewno warto zastanowić się nad certyfikatami z bezpieczeństwa lub z baz danych. Szczegółów jednak nie podam bo ich nie znam Szukajcie przede wszystkim takich egzaminów, które mają błogosławieństwo od firm autorów oprogramowania.

Zdecydowanie nie warto podpierać się jakimikolwiek kursami i egzaminami z HTML i CSS. Wystarczy zrobić swoje portfolio i niech jego źródło mówi za nas. Miałbym również duże wątpliwości czy warto inwestować w coś co potwierdzi naszą znajomość Flasha i AS3. Natomiast jeżeli ktoś pracuje bardzo dużo z JavaScript to pewnie jakiś certyfikat byłby bardzo mile widziany (ale już nie z jQuery, to za proste!). Tylko czy coś takiego istnieje?

Niektórzy twierdzą, że e-maile w ogóle nie powinny występować w postaci HTML. E-mail to ma być prosta, tekstowa wiadomość, od wszystkiego innego są strony www. Trudno odmówić temu rozumowaniu logiki. Zwłaszcza, gdy dostajemy kolejną reklamę przeładowaną grafiką. Mnie osobiście podobają się jednak ładne, dobrze zorganizowane e-maile, bez bajerów i innych wodotrysków. To cieszy oko i ułatwia korzystanie. Chciałbym budować maile używając HTML’a i CSS’a. Ale…

Najważniejszych przeglądarek internetowych mamy kilka, każda w kilku wersjach. Potrafi to przyprawić o ból głowy. Na szczęście już całkiem nieźle radzą sobie z obsługą standardów. Natomiast klientów pocztowych są dziesiątki a może nawet setki! Po pierwsze, trzeba je podzielić na klienty desktopowe i webowe. Tych pierwszych jest mniej ale i tak wiele. Tych drugich jest zatrzęsienie i nie ma tu żadnych reguł, każdy dostawca poczty często robi wszystko po swojemu.

Efekt jest opłakany. Zbudować dzisiaj atrakcyjny e-mail w HTML/CSS, który byłby prawidłowo wyświetlany we wszystkich popularnych klientach jest co najmniej ogromnym wyzwaniem. Prym wśród najpopularniejszych wiedzie… Gmail! Rozumiem, że to w trosce o swoich użytkowników ale ich klient wycina ze źródła prawie wszystko.

No ale dość tych gorzkich żali Czas na jakieś wskazówki. Oto co należy robić a czego bezwzględnie unikać przy budowaniu kolejnego newslettera:

• Używaj UTF-8.
• Cofnij się o 8 lat w rozwoju i do zbudowania głównej struktury użyj tylko tabelek.
• Cofnij się o 10 lat w rozwoju i nie wstydź się tagów typu <center />.
• Możesz używać styli CSS tylko w postaci inline czyli przypisanych bezpośrednio do tagów w atrybucie style=”". Nic innego nie zadziała.
• Gdzie tylko możesz, używaj starych atrybutów zamiast CSS np. width=”". A najlepiej oba.
• Zapomnij o pozycjonowaniu absolutnym. Najlepiej zapomnij o jakimkolwiek pozycjonowaniu.
• Zapomnij o tłach obrazkowych. Gdziekolwiek i bez względu na użytą metodę. Tekstu nad obrazek po prostu nie wstawisz, koniec kropka. Zostaje Ci tło jako kolor.
• Lepiej zrobić wszystko na konkretne wymiary i podawać je gdzie się da. Procenty lub pomijanie podawania niektórych wymiarów może się skończyć rozjechaniem całego szablonu.
• Marginesy zewnętrzne i wewnętrzne? Niestety, nie możesz.
• Nawet width i height mogą nie zadziałać na innych elementach niż tabelki i ich komórki.
• W sekcję <head /> możesz wpisać tag odpowiedzialny za kodowanie znaków. I to też tylko dla świętego spokoju. Nic więcej nie umieszczaj bo i tak wytną.
• Nie dodawaj niczego bezpośrednio do tagu <body /> bo i tak zostanie to usunięte.
• Jeżeli chcesz dać np. kolor tła dla całej wiadomości to użyj jakiegoś kontenera (np. <div />) i daj mu szerokość 100%. Wysokość zawsze dostosuje się do zawartości, inaczej się nie da.
• Dla swojego dobra powielaj gdzie się da ustawienia dla czcionki itp. bo nigdy nie wiadomo dla którego elementu nasz klient pocztowy postanowi zresetować te wartości do tych domyślnych.
• JavaScript? Najprostsza droga do katalogu „Spam” (I moim zdaniem dobrze, obsługa JS to byłaby już jednak przesada).

To lista najtwardszych zasad, którymi musisz się kierować ale ograniczeń jest oczywiście dużo więcej. Każdy znający HTML/CSS łatwo odpowie sobie, które jeszcze rzeczy nie zadziałają skoro nawet tak podstawowe metody wymienione wyżej sprawiają ogromne problemy.

Na szczęście są strony, które kontrolują sytuację i sprawdzają za nas co wolno a czego trzeba się wystrzegać.
Pierwsza z polecanych przeze mnie witryn to www.campaignmonitor.com/css/. W ładny i przystępny sposób prezentuje ograniczenia klientów pocztowych. Na górze, w prawej ramce, mamy linki do obszerniejszego raportu, obejmującego 24 klienty (stan na grudzień 2011).
Druga strona to www.email-standards.org. Prezentuje dokładne recenzje wielu popularnych klientów. Niestety nie w tak przystępnej formie jak powyższa strona ale też przydatne.

Radzę wziąć sobie te zasady do serca i pilnować grafika jeżeli takowego masz w zespole bo i bez jego finezyjnych wygibasów w Photoshopie, możesz spędzić kilka godzin nad przygotowaniem jego wizji w formie wiadomości e-mail. Znam z doświadczenia

W Internecie cały czas trwa dyskusja czy strony www muszą wyglądać identycznie we wszystkich przeglądarkach czy może nie powinniśmy skupiać się na robieniu kopii co do każdego piksela i pozwolić na lekkie różnice.

O problemie pisałem już w tekście "Reset styli CSS" gdzie opowiedziałem się za standaryzacją domyślnych ustawień przeglądarek. Czasami po prostu strona musi wyglądać identycznie aby wszystkie efekty, animacje etc. działały jak należy. Dla mnie ta cała dyskusja jest niezrozumiała.

Piszę to wszystko bo ostatnio napotkałem na dziwny problem z przeglądarką Firefox. Tak, o dziwo nie tylko IE w dzisiejszych czasach potrafi coś spartolić Otóż FF dodaje do przycisków formularzy (buttom, submit itp.) wewnętrzny margines. Zresztą sami zobaczcie:

Ustawianie własnego padding nic nie pomaga o ile nie użyjemy tego pięknego "::-moz-focus-inner". I skąd webmasterzy mają o tym wiedzieć? :/

W porównaniu do lat gdy zaczynałem zabawę z HTML (chyba rok 1999) mamy teraz piękne czasy. Mimo to nadal nie jest idealnie i mam duże wątpliwości czy kiedyś będzie.

Listę domyślnych styli CSS w Firefox znajdziemy wpisując w okno przeglądarki taki adres: resource://gre-resources/forms.css

Pod tym adresem znajduje się oficjalny arkusz CSS dla elementów języka HTML 4. Natomiast tutaj jest nieoficjalny (oficjalnego nie mogłem znaleźć) kod CSS dla HTML 5.

"Tnąc" grafikę do HTML/CSS często też zwracamy uwagę na rozmiary zapisanych plików. I tak na przykład w formacie JPG sprawa jest jasna. Jest to format z kompresją stratną i sami ustalamy gdzie leży granica między rozmiarem a jakością. Pliki GIF używają kompresji bezstratnej (algorytm LZW i jego pamiętne patenty...) ale format ten obsługuje jedynie 256 kolorów więc następuje kwantyzacja kolorów i rozmiary tych plików są niewielkie (co było istotne w latach 80. i 90.). A co z PNG?

PNG powstał jako odpowiedź na GIF i problemy pantentowe. Jest to format kompresji bezstratnej i teoretycznie powinniśmy się spodziewać, że eksport do PNG da zawsze takie same lub przynajmniej bardzo podobne rozmiary plików. W praktyce, podczas zapisywania pliku, następują pewne przekształcenia. Można je wykonać mniej lub bardziej dokładnie co ma wpływ na dwa czynniki: czas generowania się pliku wynikowego i jego rozmiar.

Niestety wiele programów graficznych nie traktuje problemu zbyt poważnie i lecą po linii najmniejszego oporu. Efektem są pliki o zbyt dużych rozmiarach.

Od kilku lat stosuję z powodzeniem program OptiPNG. Dzisiaj ze zdumieniem odkryłem, że jego początki sięgają grudnia 2001.

Program daje pozorny wybór stopnia kompresji. Nie działa to oczywiście tak jak w JPG. Jest to po prostu kompromis jaki sami ustalimy między dokładnością a czasem. Im dokładniej tym dłużej ale tym także mniejszy rozmiar pliku.

Dla programu istnieją różne dodatki/nakładki. Testowałem OptiPNG-UI. Program nie jest najładniejszy ale nie trzeba wszystkiego robić z linii poleceń co jest zbawienne przy większej ilości plików. Domyślnie wszystko jest po włosku. Aby to zmienić należy kliknąć na niebieską strzałkę w prawym górnym rogu i w nowo otwartym oknie wybrać jakąś flagę (dostępne języki: włoski, angielski, hiszpański, francuski).

Optymalizujcie swoje grafiki, stosujcie też technikę CSS Sprites (którą w pewnym stopniu opisałem tutaj). To wszystko daje wymierne efekty.

Twitter wypuścił jakiś czas temu w świat całkiem ciekawy twór, który zwie się Bootstrap. Można go chyba zaliczyć do frameworków CSS chociaż korzysta też z możliwości JavaScript.

Nie zdołałem się jeszcze przekonać do takich produktów jak Blueprint (3 i pół roku temu zamieściłem nawet krótki wpis informacyjny o tym frameworku, tutaj link) czy 960 Grid System. Niby znam ich zalety ale jakoś brakuje czasu i energii żeby wreszcie któryś poznać. Chyba nie leży mi przede wszystkim idea budowania CSS na bazie siatki. Może kiedyś będzie okazja się przemóc i spróbować któregoś rozwiązania.

Bootstrap wpadł mi jednak w oko. Może dlatego, że jego dokumentacja (tak, to ten sam link co wcześniej ) jest tak banalna, przejrzysta i przyjazna, że każdy złapie w lot jak go używać.

Bootstrap to zbiór bibliotek CSS wzbogacony o LESS (napiszę o tym więcej, obiecuję!) i pluginy JavaScript. Razem prezentuje się to naprawdę atrakcyjnie i prosto. Wystarczy spojrzeć na przykłady z dokumentacji. Typografia, przyciski, formularze, okienka. Wszystko to i wiele więcej, gotowe do użycia, często bez naszej ingerencji, czasami wymaga tylko dodania odpowiedniej klasy do elementu.

Raczej to nie jest jeszcze ten moment gdy zbuduję pierwszą stronę w całości opartą o framework CSS jednak Bootstrap idealnie pasuje mi do tworzenia różnego rodzaju paneli administracyjnych. Z wyglądem takich paneli zawsze jest problem a tutaj mamy wszystko gotowe.

Polecam Bootstrap, warto też bliżej przyjrzeć się dostępnym pluginom JavaScript (oparte o mój ulubiony famework JS czyli jQuery) i podejrzeć trzy przykładowe strony (pierwsza, druga, trzecia).

Źródła dostępne są do ściągnięcia na GitHub pod adresem https://github.com/twitter/bootstrap.

Zdarza się czasami, że musimy wykonać jakąś bardzo specyficzną pracę programistyczną. Mi to się niestety zdarza aż za często Tak było i tym razem. Musiałem zamienić pobrany kod CSS na coś bardziej strawnego, najlepiej na tablicę PHP. Przy tego typu zadaniach dobrze jest zacząć od Google, znaleźć rozwiązanie, użyć i zapomnieć. Niestety z tym znajdowaniem nie zawsze jest tak różowo...

Przeszukałem dość dokładnie Internet pod kątem parsowania kodu CSS w PHP. Znalazłem kilka, może kilkanaście rozwiązań ale z większością z nich były jakieś problemy. Skoro już przez to przeszedłem to chyba dobrze byłoby napisać o tym kilka słów i zaoszczędzić innym nieszczęśliwcom trochę pracy.

Zacznę od prostego, anonimowego kawałka kodu, który znalazłem gdzieś w sieci. Po lekkich poprawkach prezentuje się w taki sposób:

Kod jest naprawdę prosty a efektem jego działania jest ładna tablica wielowymiarowa PHP z kluczami głównymi jako selektory CSS do których są przypisane pary właściwość <-> wartość.

Na tym właściwie mógłbym zakończyć tego newsa ale zdaję sobie sprawę, że niektórzy mogą mieć inne/większe potrzeby dlatego teraz krótki przegląd rozwiązań:

• CSSTidy - Rozbudowane narzędzie, dostępne w dwóch postaciach: plik wykonywalny EXE oraz aplikacja PHP. Głównym zadaniem CSSTidy jest tak przerobić dany kod CSS aby zmniejszyć jego objętość wywalając niepotrzebne fragmenty i poprawiając niektóre definicje. Dostępna jest również kompresja kodu. Oczywiście aby wykonywać takie czynności, potrzebny jest rozbudowany parser CSS Osobiście go nie testowałem dlatego chętnie przeczytam każdą opinię. PS: Autorzy na stronie chwalą się, że nie użyli żadnych wyrażeń regularnych.
• PHP CSS Parser - Nie testowałem ale wygląda na całkiem rozbudowany parser CSS, w wygodnej, obiektowej formie. Przyda się szczególnie tym, którzy nie tylko chcą coś z kodu CSS odczytać ale również go zmodyfikować.
• PEAR HTML_CSS - Z PEAR praktycznie nigdy nie korzystałem, jakoś nie było potrzeby, nie mogłem się do tego przekonać... Z opisu wygląda zachęcająco. Nic więcej o tym nie mogę napisać ale mimo to umieszczam na liście bo część z Was na pewno ma duże zaufanie do PEAR.
• CSS parser - Prosta i przyjemna w użyciu klasa za pomocą której łatwo wyciągniemy informacje jaka wartość została przypisana do właściwości dla danego selektora. Martwi mnie jedynie wiek tego kodu (rok "produkcji": 2003) i lista tagów HTML w źródle, która jest niepełna i na nasz grzbiet spadnie obowiązek jej uzupełnienia i aktualizowania w przyszłości.
• CssMin - Oprogramowanie nastawione przede wszystkim na "kompresję" styli CSS ale z krótkiej analizy kodu wnioskuję, że używa bardzo ładnego i rozbudowanego parsera CSS. Chętnie przeczytam opinię jak to działa jeżeli ktoś pokusi się o testy/użycie

Oprócz tej krótkiej listy istnieją oczywiście inne rozwiązania. Szczególnie sporo jest malutkich parserów zrzucających CSS do tablicy PHP ale kod przedstawiony przeze mnie powyżej sprawdza się wyśmienicie dlatego chyba można sobie darować inne klony.

Na koniec dodam, że warto przed obróbką parserem usunąć z kodu CSS wszelkie komentarze. Pewnie te bardziej zaawansowane parsery same się tym martwią ale te mniej rozbudowane już niekoniecznie. Oto kod:

Przez ostatni rok wiele się mówiło o HTML5 w kontekście tagów audio i video, nowych tagów takich jak header, article, footer itp. oraz walki z Flashem. Tymczasem niezauważona przemknęła informacja, że atrybut target="_blank" wraca do łask!

Konsorcjum W3C dawno temu postanowiło, że atrybut umożliwiający otwieranie linków w nowym oknie ma być zdeprecjonowany (deprecated) co przeważnie oznacza jego całkowite usunięcie w przyszłych wersjach języka. Główny argument był taki, że to użytkownik ma mieć możliwość decydowania w jaki sposób będzie otwierał linki. Jeżeli zechce otworzyć link w nowym oknie to naciśnie środkowy przycisk myszki lub skorzysta z menu kontekstowego.

Założenia szlachetne ale niestety teoria nie wytrzymała zderzenia z praktyką. Przede wszystkim, większość użytkowników sieci nie jest świadoma konsekwencji jakie niesie za sobą otwieranie linków w tym samym lub w nowym oknie. Większość klika lewym przyciskiem myszy a potem "spaceruje" po stronach korzystając z przycisków poprzednia/następna, skutecznie się gubiąc po chwili. Po drugie, ciężko jest właścicielom stron przełknąć gorzki fakt, że niestosowanie target="_blank" powoduje ucieczkę użytkowników z ich stron. W ekstremalnym scenariuszu mogłoby to spowodować ograniczenie linkowania w sieci a przecież linki to podstawa Internetu! Po trzecie wreszcie, nietrudno podać przykłady gdzie otwieranie nowego okna jest mocno zalecane np. gdy ktoś wypełnia długi formularz i na końcu ma link do regulaminu, który należy zaakceptować. Nieuważny użytkownik kliknie go lewym przyciskiem myszy i straci wszystko co wpisał w formularzu.

Wyżej wymienione powody doprowadziły do tego, że webmasterzy albo używali dalej target="_blank" i olewali standardy (a nie ma się co martwić, że przeglądarki kiedykolwiek przestaną obsługiwać ten atrybut z wartością _blank) albo oszukiwali walidatory różnymi rozwiązaniami w JavaScript albo zaciskali zęby i linkowali zgodnie z zaleceniami W3C (ale przeważnie robili to ze łzami w oczach ).

W3C wreszcie dostrzegło, że ich zakaz jest niemile widziany przez dużą część webmasterów. Dalsze upieranie się przy swoim nie miało sensu i zniesiono zapis "deprecated" dla target="_blank". Linki potwierdzające ten fakt:
http://www.w3.org/TR/html5-diff/#changes-2008-01-22
http://www.w3.org/TR/html5/browsers.html#valid-browsing-context-name-or-keyword

I jeden cytat:

"the target attribute for the a and area elements is no longer deprecated, as it is useful in Web applications, e.g. in conjunction with iframe."

Osobiście byłem przeciwnikiem zakazywania target="_blank" czego mogliście doświadczyć na tym blogu Jednocześnie dostrzegam logikę w argumentach przeciwników decydowania za użytkownika. Problem co prawda stracił na ważności od czasu gdy pojawiły się w przeglądarkach karty (wcześniej otwierały się nowe okna co faktycznie było kłopotliwe) ale nadal istnieje. Dlatego proponuję wszystkim webmasterom oznaczanie wszystkich linków z target="_blank" odpowiednim symbolem. Efekt taki można uzyskać w bardzo prosty sposób:

Efekt prezentuje się tak: otworzy się w nowym oknie. Wartości przy padding-right i line-height ustaw według własnego uznania, pamiętając o wymiarach ikonki nowego okna.

No tak... Ledwo się Riddle pojawił a już mi podebrał temat o którym planowałem w najbliższych dniach napisać Ale to bardzo dobrze bo pewnie nie mielibyście takiego pożytku z mojego wpisu jak z jego.

Każda przeglądarka internetowa ma zbiór podstawowych reguł CSS, które ustawiają właściwości tagów HTML. Dzięki temu możemy stworzyć dokument HTML bez żadnych reguł CSS a mimo to będzie odpowiednio wyglądał (tag strong będzie pogrubiał, h1 będzie ustawiał odpowiednio duży nagłówek itd.). To nie jest efekt jakichś magicznych reguł umieszczonych wprost w kodzie źródłowym przeglądarki a właśnie rezultat zastosowania CSS.

Wszystko byłoby pięknie gdyby twórcy przeglądarek umieli się dogadać ale jak wszyscy wiemy nie potrafią nawet stosować się do przyjętych standardów więc jak tu wymagać aby stosowali takie same zasady w mniej formalnych aspektach. Z tego powodu mamy totalny bajzel. Wystarczy spojrzeć na te dwie strony (tu i tu - adresy też znaleziony u Riddle ) aby przekonać się jak duże różnice są między przeglądarkami a nawet ich poszczególnymi wersjami.

Dążąc do perfekcji (aby nasze strony wyglądały identycznie w każdej przeglądarce) webmasterzy postanowili stworzyć zbiór reguł CSS, które zresetują wszystkie zasady CSS ustawione przez przeglądarki. W ten sposób zaczniemy budować każdą stronę z "czystym kontem". Wystarczy jednak wpisać w Google "CSS reset" aby się przekonać, że pomysłów na rozwiązanie problemu jest wiele. Który jest najlepszy?

Rozwiązaniem może być to co wczoraj zaproponował Riddle. Wygląda to naprawdę zgrabnie, jest dokładnie opisane, przygotowuje nas już do pracy z HTML5. Polecam.

Pamiętaj jednak, że nim zaczniesz stosować te reguły to dobrze byłoby je zrozumieć. Znam przykłady gdzie koder zastosował jakieś reguły mimo, że ich nie potrzebował i potem przy każdym wystąpieniu np. odnośnika (tu zwróć uwagę na to co napisał Riddle o text-decoration) je "odkręcał". Z drugiej strony warto rozszerzać te reguły o swoje własne jeżeli upraszczają pracę z Twoim projektem. Nie chodzi przecież o to aby mieć idealne reguły resetujące ustawienia przeglądarek a o to aby posiadać reguły maksymalnie ułatwiające nam budowanie własnej strony.

EDIT 02.02.2011
Eric Meyer opublikował drugą wersję swoich resetujących styli, link tutaj.