Mariusz Tarnaski "MariuszT"

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?

Domeny z narodowymi znakami są już dłuższy czas dostępne ale nie przyjęły się za bardzo, przynajmniej nie w Polsce. Nie usprawiedliwia to jednak programistów, którzy o nich zapominają. Może to nam wygenerować poważne problemy.

Kilka dni temu musiałem poprawić pewien mały skrypcik. Administrator może podać adres, który potem jest używany w przekierowaniu PHP. Zwykłe, banalne header():

I nagle zaskoczenie. Ten kod w Firefox i Safari (z Chrome i Operą było wszystko OK, IE nie testowałem) nie działa gdy zmienna $address to adres domeny z polskimi znakami diakrytyzowanymi!

Oczywiście pierwsza (i słuszna) myśl to przekodowanie takiej domeny do pierwotnej postaci. Jak powszechnie wiadomo, za tymi ładnymi narodowymi literkami kryją się okropne, niezrozumiałe krzaczki. Domena gżegżółka.pl tak naprawdę wygląda tak: xn--gegka-2ta76cmoc.pl. Do konwersji służy algorytm o nazwie Punycode.

Jeżeli masz PHP w wersji co najmniej 5.3 to rozwiązanie jest banalne. Masz dostępne dwie funkcje służące do konwersji z UTF8 do ASCII i z ASCII do UTF8.

Poniżej PHP 5.3 musisz posiłkować się zewnętrznymi bibliotekami. Najpopularniejsza z nich ma swoją stronę domową tutaj natomiast tutaj jest źródło do ściągnięcia.

Konwersja z UTF8 do ASCII:

Otrzymamy:
http://www.xn--gegka-2ta76cmoc.pl

Konwersja z ASCII do UTF8:

Otrzymamy:
http://www.gżegżółka.pl

Jeżeli spróbujemy poddać konwersji normalną domenę, nie IDN, to nic się nie stanie więc funkcje/metody są bezpieczne i można ich używać na wszystkich domenach, bez dodatkowego rozróżniania. Pamiętaj tylko aby mieć adres w UTF8.

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

Bloga założyłem z kilku powodów:

• aby mieć coś swojego, bardzo prywatnego, na własnych i tylko własnych zasadach i co nie musi zarabiać na siebie
• aby mieć miejsce gdzie mogę napisać o swoich wszystkich przemyśleniach, pochwalić się czymś, polecić coś, podzielić się czymś z innymi
• aby pomóc innym w problemach przez które sam przebrnąłem

Wszystkie cele zostały osiągnięte Problem sprawia mi jedynie ostatni podpunkt...

Lubię pomagać. Naprawdę. Muszę trzymać się jednak pewnych zasad bo inaczej pomoc odbywałaby się kosztem mojej pracy i moich dochodów z niej. Dlatego przyjąłem, że na sprawy związane bezpośrednio lub nawet pośrednio z wpisami na moim blogu odpowiadam TYLKO na blogu. Dlaczego?

Dlaczego nie przez komunikator? Bo wtedy rozmówcy wydaje się, że od chwili gdy się do mnie odezwał powinienem się skupić tylko i wyłącznie na jego problemie. Zasypie mnie setką pytań, sam nie zastanowi się nawet chwili nad rozwiązaniem bo przecież łatwiej napisać dwa zdania na GG i niech inny się głowi. Takie rozmowy ciągną się w nieskończoność, pytań przybywa i nie można się skupić na niczym innym.

Dlaczego nie przez e-mail? Ta droga komunikacji jest przyjemniejsza bo to ja decyduję kiedy zajmę się daną sprawą. Przy okazji wymaga trochę więcej wysiłku aby napisać sensowny e-mail co daje pewne szanse, że zgłaszający podjął chociaż małe próby samodzielnego rozwiązania problemu. Nadal jednak to nie jest najlepsza forma z prostej przyczyny: często przychodzi mi odpowiadać wielokrotnie na te same pytania.

Dlaczego komentarze? Bo z jednej strony skorzystanie z nich jest tak proste i szybkie jak z komunikatora a z drugiej wymusza zadanie sensownego pytania (a więc zastanowienie się nad problemem). Ja mogę na to pytanie odpowiedzieć w wolnym czasie. A co najważniejsze, odpowiedź widzą inni! I o to się tak naprawdę rozchodzi. Następny pytający być może przejrzy komentarze i tam znajdzie odpowiedź na trapiący go problem lub w ostateczności zada pytanie a ja go odeślę do gotowej odpowiedzi.

Na stronie Kontakt umieściłem wyraźny komunikat:

Masz pytanie związane z jakimś tematem, który poruszyłem na blogu? Pisz TYLKO w komentarzach. Jeżeli zignorujesz moją prośbę to bądź pewien, że ja zignoruję Ciebie.

I co? I... Musiałbym brzydko odpowiedzieć Oczywiście całe tabuny ludzi jakimś magicznym sposobem zupełnie nie dostrzegają tych dwóch zdań. Pewnie nawet jakbym sprawił aby ten napis migał to znalazłby się taki co akurat mrugał jak napis się pojawiał i dlatego go nie zobaczył...

Wylewam tu swoje żale bo po raz kolejny poświęciłem komuś czas, mimo, że zignorował moje prośby, nie uszanował mojej woli i nie zadał sobie trudu aby samemu poszukać rozwiązania. A na koniec nie usłyszałem nawet głupiego "dziękuję". Nic, ani słowa. Tak jakby pomaganie było moim obowiązkiem.

W związku z tym, ogłaszam oficjalnie, że od teraz wprowadzam w życie zasadę z powyższego komunikatu. Do tej pory byłem wyrozumiały ale tym wpisem usprawiedliwiam się i oczyszczam swoje sumienie Chociaż wiem, że Ci na których narzekam i tak nie przeczytają tych słów

Ale żeby nie było tak nudnie i marudnie to napiszcie w komentarzach jak to jest z Wami? Często ludzie oczekują od Was pomocy gdy dowiadują się, że jesteście jakoś związani z IT? Jak sobie z tym radzicie?

Obsługa standardów w przeglądarkach nadal nie jest na takim poziomie jakiego byśmy oczekiwali. Przezornie nie wykorzystujemy wielu możliwości CSS3 bo "znowu rozwali się w IE i będę miał przez to tylko problemy". Jest jednak grupa efektów, które działają we wszystkich (lub prawie wszystkich) przeglądarkach i jedyny problem z ich zastosowaniem jest taki, że w różnych programach interpretowane są różne reguły.

Pomocną dłoń wyciąga do nas autor css3please.com. Na tej stronie znajdziemy kilka interesujących efektów CSS3 w wersjach na różne przeglądarki. Wszystko jest ładnie opisane, ciągle aktualizowane a obsługę ułatwiają nam skrypty JS. Warto przejrzeć reguły umieszczone na stronie, zapamiętać i wracać regularnie. Polecam!

Skuszony wieloma rekomendacjami i niskimi cenami, postanowiłem skorzystać z oferty hostingowej linuxpl.com. Podstawowym plusem jest także możliwość zmiany wersji PHP na 5.3. Ta wersja pojawiła się dwa i pół roku temu a do tej pory nie jest dostępna na większości hostingów :/

Na linuxpl.com dostajemy również dostęp do SSH, co bywa dla mnie czasami zbawienne. W ustawieniach zmieniłem wersję PHP na 5.3 i z poziomu SSH chciałbym uruchamiać skrypty także pod tą wersją. Niestety, bez względu na ustawienia w panelu, komenda "php skrypt.php" pod SSH zawsze chce korzystać z PHP w wersji domyślnej dla linuxpl.com czyli PHP 5.2. Dokonałem tego odkrycia podczas gorączkowych przygotowań do uruchomienia lastdeal.pl więc postanowiłem nie czekać na support i rozwikłać zagadkę sam.

Nie da się na linuxpl.com sprawić aby zwykłe "php skrypt.php" działało w wersji innej niż PHP 5.2. Można jednak podać ścieżkę do innej wersji PHP. Jest to kłopotliwe bo trzeba wpisać za każdym razem długie ścieżki ale przynajmniej w ogóle się da. Swoją drogą niektóre (większość?) skrypty mają "na sztywno" wpisane samo "php coś tam" i trzeba będzie niestety je zedytować przed uruchomieniem.

Nie przedłużając, oto gotowa recepta.

Po zalogowaniu na SSH musisz zejść "niżej" w strukturze katalogów, wyjść ze swojego konta. Najlepiej "cd /". Binarka PHP w wersji 5.3 znajduje się tutaj: "./usr/local/php5.3/bin/php". Zamiast wpisywać "php skrypt.php" musisz wpisywać "./usr/local/php5.3/bin/php ./home/twoje_konto/domains/twoja_domena/public_html/skrypt.php".

Próbowałem zrobić symboliczny link aby chociaż trochę skrócić ścieżki ale niestety, nie powiodło się. Tam gdzie mam uprawnienia do tworzenia linków, tam nie zadziała ta binarka PHP. Trzeba zejść niżej, wyjść z własnego konta. A tam znowu nie mam już uprawnień...

Gdy była chwila spokoju, napisałem zapytanie do supportu. Potwierdzili to co sam znalazłem, dodając jedną wskazówkę:

jezeli chce pan uzyc swojego php.ini to komenda

/usr/local/php5.3/bin/php -c /usr/local/directadmin/data/users/lastdeal/php/lastdeal.pl/php.ini skrypt.php

Mam nadzieję, że ten wpis zaoszczędzi komuś trochę czasu i nerwów

Jak już wspominałem w innym artykule (przeczytaj komentarze, warto!), przeglądarki, ze względów bezpieczeństwa, ograniczają nasze możliwości komunikowania się między stronami w różnych domenach. Możemy natomiast dowolnie pracować i komunikować się w obrębie tej samej domeny. Jak rozszerzyć nasze możliwości?

Istnieje pewna metoda i nazywa się window.postMessage. Opracowano po prostu bezpieczną metodę komunikowania się cross-domain.

Sposób ten nie jest obsługiwany przez starsze przeglądarki (np. IE 7) dlatego powstał ciekawy plugin jQuery, który w razie czego, potrafi komunikować się w alternatywny sposób, poprzez document.location.hash. Jest także alternatywa w postaci czystego JS.

PS
Wiem, że to nie jest żadna nowość ale ostatnio mocniej zainteresowałem się tym tematem i pomyślałem, że warto o tym wspomnieć. W naszym języku ciężko natrafić nawet na wzmiankę o takich rzeczach.

Jakiś czas temu (kilka lat temu?) ktoś w komentarzu poprosił mnie o wytłumaczenie jak zniwelować dodatkowe obciążenie jakie generuje użycie przyjaznych adresów URL. Zacząłem o tym pisać a potem, z jakiegoś powodu, przerwałem i do tej pory nie znalazło się trochę czasu aby skończyć... Wiele artykułów mi w ten sposób przepadło. Tym razem dokończę dzieła A raczej napiszę od nowa bo wcześniej niepotrzebnie się rozpisałem...

Główne założenia: musisz napisać wydajną aplikację z przyjaznymi adresami URL w których nie przekazujesz żadnych identyfikatorów.

Przyjazne adresy to dzisiaj już konieczność. Ale wymagania wciąż rosną i teraz adresy muszą być jeszcze bardziej przyjazne niż kiedyś Nie tak dawno każdemu wystarczały adresy w postaci example.com/artykuly/1,jakis-adres/ czyli z przekazanym identyfikatorem zasobu. Te jednak okazały się zbyt brzydkie. Dzisiaj już nie chcemy identyfikatorów, chcemy czystych adresów czyli example.com/artykuly/jakis-adres/.

Oczywiście z punktu widzenia trudności zakodowania takiego rozwiązania, różnica jest niewielka. Jedno małe zapytanie do bazy danych gdzie wyszukamy identyfikator/dane artykułu na podstawie jego adresu. Czas wykonania się kodu też jakoś specjalnie się nie wydłuży. W czasach rozbudowanych frameworków z ich prostymi w użyciu routerami mało kto w ogóle sobie takimi rzeczami zawraca głowę. Być może jednak potrzebujesz ekstremalnej wydajności lub jesteś jej zwykłym fanatykiem (tak jak ja swego czasu ). Jest sposób na zlikwidowanie dodatkowego obciążenia.

Kluczem do sukcesu jest fakt, że przekierowanie w .htaccess, którego używasz (zakładam, że używasz bo inaczej nie uzyskałbyś nawet adresu example.com/artykuly/1,jakis-adres/ a co najwyżej jakieś example.com/artykuly.php/1,jakis-adres/) aby mieć przyjazne URL'e, działa tylko wtedy jeżeli nie istnieje fizycznie na dysku katalog/plik odpowiadający wpisanemu adresowi. Innymi słowy, jeżeli w publicznym katalogu głównym naszej aplikacji istnieje katalog artykuly a w nim katalog jakis-adres to żadne przekierowanie z .htaccess nie zadziała tylko Apache zacznie szukać w tym katalogu jakiegoś pliku index do wyświetlenia/uruchomienia.

Od tej wiedzy do sukcesu już krótki odcinek. Wystarczy podczas tworzenia artykułu (ale nie zapomnij potem o edycji i usuwaniu) tworzyć katalogi, które będą odpowiednikami adresów na stronie. W każdym z takich katalogów wystarczy umieścić plik index.php. Jego zawartość może wyglądać tak:

Oczywiście kod jest zupełnie przykładowy, chodzi o samą logikę. W wygenerowanym pliku mamy informację o identyfikatorze. Dzięki temu nie trzeba robić dodatkowego zapytania do bazy danych. Następnie startujemy naszą aplikację i przekazujemy dalej informację o identyfikatorze.

A więc mamy katalog /artykuly/jakis-adres/ w którym znajduje się plik index.php z powyższą zawartością. Działa. Osobiście przenoszę jeszcze wszystkie wygenerowane katalogi do jakiegoś wspólnego miejsca np. katalogu /cache. To wprowadza mi pewien porządek na dysku serwera, zwłaszcza gdy elementów korzystających z tego mechanizmu jest więcej (miałbym wtedy katalogi artykuly, galeria, imprezy itd. co wprowadza niepotrzebny bałagan). Robię to za pomocą .htaccess. Przykład:

I w ten oto prosty sposób mamy trochę więcej katalogów i plików na dysku ale:
- zyskaliśmy piękne adresy URL
- cały mechanizm nie generuje zbędnego obciążenia
- sposób nie jest zbyt kłopotliwy bo cały cache siedzi sobie w jednym katalogu i nikomu nie przeszkadza
- nasza strona jest o jeden krok bliżej do osiągnięcia sytuacji gdy artykuły są dostępne nawet podczas awarii bazy danych

Podsumowując: gdy ktoś wpisze adres example.com/artykuly/jakis-adres/ to zadziała przekierowanie na katalog /cache/artykuly/jakis-adres/ gdzie wygenerowany plik index.php posiada informację o identyfikatorze tego katalogu, uruchomi naszą aplikację i przekaże jej ID.

Można jeszcze dopisać mechanizm, który zablokuje bezpośredni dostęp do plików cache na serwerze (aby nie działały adresy example.com/cache/artykuly/jakis-adres/). I na tym koniec

PS
Pamiętaj aby pilnować przy adresach bez identyfikatorów aby adresy się nie powtarzały.

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.