Archiwum Szsz.pl: września 2009

Google Chrome - Ostre krawędzie

środa, 30 września 2009

Od pewnego czasu testuję Google Chrome na systemie Linux, myślę że najwyższa pora by podzielić się wrażeniami.

Na początek Łoooł… błyskawiczny start… Strony wyświetlane prawie natychmiast… Minimalistyczny wygląd. Trzeba trochę czasu, by ochłonąć i zacząć dostrzegać jakieś wady.

Oczywiście nie jest to mój pierwszy kontakt z tą przeglądarką. Pisałem już wcześniej o Google Chrome ( 1, 2).

Dotychczas jednak ograniczałem się do uruchamiania Chrome pod maszyną wirtualną. To dla tego że miałem pewne problemy z uruchomieniem tej przeglądarki pod Linuksem. Próbowałem nawet własnej kompilacji, po to by przekonać się że moja wersja rozlatuje się tak samo jak oficjalny build.

Dopiero kilka tygodni temu, przypadek naprowadził mnie na właściwy trop. Jeżeli na dzień dobry pojawia się zagadkowy błąd: 

Check failed: read_buffer_->data().

To może on być spowodowany niewłaściwymi uprawnieniami do katalogu /dev/shm. Rozwiązaniem jest poniższy wpis w /etc/fstab 

none             /dev/shm         tmpfs       rw               0   0
i wykonanie polecenia mount /dev/shm.

Porównując z Mozilla Firefox

Porównanie z przeglądarką, której używam na co dzień nasuwa się samo…

Szybkość

(+) Chrome jest wyraźnie szybsze – Muszę to przyznać mimo olbrzymiej sympatii jaką darzę Liska.

(+) Silnik Javascript V8 daje tej przeglądarce miażdżącą przewagę nad konkurencją. Można się o tym przekonać odwiedzając stronę JSNES. U mnie Chrome jest 4~5 razy szybsze niż Firefox.

(+) Animacja i efekty. Gecko ma możliwości animacji w html, jedynie dzięki temu że współczesne komputery są wystarczająco szybkie. W porównaniu z nim, ma się wrażenie że Webkit został zaprojektowany z myślą o efektach specjalnych. Wszystko jest płynne i odbywa się bez żadnych niespodzianek.

(-) Jednak po pewnym czasie natrafiłem na kilka stron gdzie Chrome okazywało się… wolniejsze. Niekiedy niemożliwe było przeczytanie strony w całości. Paradoksalnie Firefox nie miał problemów z tymi stronami. Najczęściej podobne objawy występują przy wyższym obciążeniu procesora spowodowanym np przez Adobe Flash. Jednak, nawet w tym przypadku, przeglądarka radzi sobie całkiem nieźle: przynajmniej inne zakładki nie cierpią w takich okolicznościach.

Istnieją sytuacje gdy separacja zadań pomiędzy poszczególnymi zakładkami jest niewystarczająca. W końcu istnieje jeden proces zajmujący się wyświetlaniem grafiki, z którym wszystkie inne muszą się komunikować. W efekcie niekiedy jest tak samo jak na przeglądarce Firefox, gdy otwiera się kilka stron na raz, trzeba poczekać na inne zakładki by zobaczyć tą jedną która nas interesuje.

Największe zalety

(+) Odrębne procesy dla stron. Chyba to jest największy plus tej przeglądarki. Można łatwo zobaczyć która strona jest źródłem wszelkiego zła. Można zabić pojedynczy proces z poziomu systemu. Wpływ poszczególnych stron na stabilność przeglądarki został zminimalizowany.

(+) Zoom. Nie wiem czemu, ale ludzie z Mozilla Foundation implementując zoom, uparli się by stosować nieistniejące API X-Window (dosłownie!). Efekt jest taki, że Firefox skalując zdjęcie wyświetla brzydkie poszarpane krawędzie, podczas gdy Chrome i wszystkie inne programy nie mają w tym temacie większych problemów.

Nie oszlifowane krawędzie

Oczywiście nie wszystko jest idealne. Używając tej przeglądarki dłużej, można trafić na wiele drobnych niedogodności typowych dla tak młodego programu.

(-) Dla mnie największą przypadłością jest to że Chrome ignoruje informację o DPI monitora. W efekcie, mając dużą rozdzielczość na małym ekranie, typowym dla laptopa, muszę patrzeć na koszmarnie małe literki. Możliwość powiększania strony działa nawet lepiej niż na Firefox, ale cóż z tego? Przeglądarka w żaden sposób nie zapamiętuje stopnia powiększenia… co skutkuje koniecznością ustawicznego naciskania ctrl – +.

Udało mi się nieco złagodzić ten problem, pisząc małe rozszerzenie korzystające z API Greasemonkey. Powiększa ono automatycznie strony o 120%. Moje rozwiązanie nie jest niestety doskonałe, ponieważ skrypt uruchamia się dopiero po załadowaniu strony, co jest bardzo dokuczliwe przy stronach, które nie potrafią się w całości załadować – zadziwiająco częste zjawisko w czasach gdy każda strona musi być pełna reklam i różnych udziwnień.

(-) Pasek przewijania, nie jest prawdziwym paskiem przewijania. Pod Linuksem nawet nie wygląda jak systemowy pasek. Przyzwyczaiłem się do tego że powinien mieć wysoki kontrast – dzięki czemu wyraźnie widzę w którym miejscu dokumentu się znajduję.

Niekiedy zdarza się że klikając myszką na ów pasek, dokument przeskakuje nie o jedną stronę, ale o dwie i więcej.

Jest jeszcze jedna wada: W przypadku prawdziwego paska przewijania, można zdecydować po której stronie ma być wyświetlany, jest to bardzo pomocne dla leworękich użytkowników tabletów.

(-) Chrome obsługuje Skrypty Greasemonkey, ale brakuje wsparcia ze strony interfejsu użytkownika, nawet instalacja skryptów wymaga ręcznego przeniesienia ich do odpowiedniego katalogu. Trochę szkoda, bo właśnie te skrypty niejednokrotnie ratują tą przeglądarkę i pozwalają załatać najbardziej dokuczliwe niedogodności.

(-) Krening i ligatury. Kolejny problem udało mi się zidentyfikować dopiero kilka dni temu. Otóż, zauważyłem że niektóre strony niewygodnie mi się czyta na Chrome. Gdy porównałem ich wygląd na Chrome i Firefox, zauważyłem że ta druga przeglądarka znacznie lepiej radzi sobie z pismem szeryfowym.

Przyglądając się dokładniej, można zauważyć że pismo jest nieproporcjonalne, przeglądarka nie używa kerningu. Brakuje też ligatur, które potrafią istotnie poprawić czytelność tekstu. Efektem jest zaburzenie rytmu w piśmie i komfort porównywalny z jazdą autem po wybojach.

Wydaje się że to drobiazg, ale… Znana gazeta Times rozpoczęła od zaprojektowania własnego kroju pisma (o tej samej nazwie), a system Windows, część swojego sukcesu zawdzięcza czytelności fontu Arial. Często właśnie takie szczegóły, na które normalnie nie zwraca się uwagi, potrafią zaważyć o sukcesie lub porażce.

(-) Nie obsługuje dynamicznie ładowanych fontów. Wielka szkoda, bo zdążyłem polubić tą funkcję. Mam jednak nadzieję że wkrótce się to zmieni, bo Safari nie ma z tym większych problemów.

(-) Awaryjność. Nie ma co ukrywać, Firefox jest dużo stabilniejszy. Przy dłuższym używaniu Chrome można spotkać się zarówno z awariami poszczególnych zakładek jak i całej aplikacji. Oczywiście konsekwencje są znacznie mniej katastrofalne – zazwyczaj wystarczy przeładować stronę / przeglądarkę, ale mimo wszystko… Każda taka usterka to potencjalny punkt zaczepienia dla ewentualnych exploitów.

(-) Nie znalazłem sposobu na selektywne wyłączenie pluginów.

Reklamy

Reklamy, reklamy, reklamy… To straszne. Po latach, mam okazję zobaczyć jak wygląda Sieć w oczach przeciętnego użytkownika – już po kilku dniach byłem znużony ich natręctwem.

Niestety. Niezależnie od używanej przeglądarki, zawsze mamy do czynienia z tym samym Flash Playerem, głównym spowalniaczem systemu.

Tak więc najlżejsza przeglądarka to ta, która sprawnie odrzuca śmieci.

Na koniec

Pisząc ten tekst, starałem się skoncentrować nie tylko na zaletach, ale także na wadach nowej przeglądarki. Wiekszość z nich to choroby wieku młodzieńczego i spodziewam się że wkrótce będą tylko wspomnieniem.

Google Chrome już teraz ma bardzo duży wpływ na rynek przeglądarek, wystarczy zobaczyć planowane zmiany wyglądu przeglądarki Firefox

Mimo to jest trochę wcześnie by wyrokować i jednoznacznie wskazywać na konkretnego zwycięzcę. Przykład z kerningiem pokazuje że inne przeglądarki mają wiele zalet, będących efektem wieloletnich udoskonaleń, których nie sposób tak zwyczajnie zignorować.

ps
By upewnić się, że moje wrażenia, nie są złudzeniem, zainstalowałem także kila innych rozwojowych przeglądarek. Po pierwszym uruchomieniu Seamonkey 2.0, też odniosłem wrażenie większej szybkości (niż Chrome). Efekt był spowodowany tym, że zazwyczaj porównuje się nowo uruchomioną przeglądarkę (z jedną tylko zakładką) z czymś czego używamy na co dzień – niech to będzie przestrogą przed pochopnym wyciąganiem wniosków.

Etykiety: , ,

Komentarze (0)

Red 11:25

Dynamiczny CSS

wtorek, 8 września 2009

Ten tekst został zainspirowany postem na blogu nme.pl.
Zaprezentowane rozwiązanie zainteresowało mnie, ze względu na pewne analogie do moich eksperymentów z gradientami

Wprowadzenie

Na początek muszę napisać że nie jestem zwolennikiem opisywanych technik.

Powinno być tak, że

Tyle teorii, w praktyce i tak wszystko wychodzi zupełnie inaczej.
JavaScript często wspomaga warstwę prezentacyjną, omijając liczne ograniczenia przeglądarek.

Do rzeczy. Istnieje kilka sposobów na modyfikację stylów.

Inline CSS

Najprostszy, polega na modyfikacji właściwości style danego elementu. Jest to łatwy w użyciu i mało elegancki sposób. Jako jedyny działa identycznie na każdej przeglądarce.

W3C DOM CSS Level 2

Oficjalnie istnieje API pozwalające modyfikować style, zdefiniowane za pomocą elementów link i style.

Style opisuje właściwość document.styleSheets

… i na tym koniec, bo obiekt, który otrzymamy nie doczekał się spójnej implementacji. Różnice pomiędzy przeglądarkami zabijają. API wygląda jak jakiś ponury żart. Dokumentacja jest żałosna. Nic dziwnego że rozwiązanie nie zdobyło popularności.

Modyfikacja elementu Style

Jest jeszcze jedna metoda. Użyłem jej przy okazji moich zabaw z gradientami. Wystarczy stworzyć własny element style i wypełnić go treścią. Ma to niezaprzeczalny urok — jest bajecznie proste. Wady? W IE próba modyfikacji elementów style kończy się błędem Unknown error.

Jak nie kijem, to pałką

Z koślawym API modelu DOM CSS, zmierzył się Nme na swoim blogu. W efekcie powstała całkiem elegancka biblioteka.

Oto przykład użycia: 

css.replace('.asd',{'color':'green'});

Metodologia jest wzorowana na jQuery. Nie będę dokładniej opisywał samej biblioteki, wszystko można znaleźć u źródeł.

To o czym chcę podzielić to moje przemyślenia nad dostępnymi możliwościami modyfikowania stylów. Dla tego właśnie zacząłem od małego podsumowania.

Zaskakujące jest słabe wsparcie dla modelu W3C. Dla przykładu Firebug nie pokazuje stylów modyfikowanych w ten sposób. Wygląda na to że Mozilla Fundation utraciła dawny zapał do implementowania standardów, gdy nie mają one wsparcia ze strony swojego głównego konkurenta. Czasy świętych wojen document.getElementById vs document.all minęły już bezpowrotnie.

Dotychczas ignorowałem document.styleSheets, dla tego że nie chciało mi się wnikać w szczegóły poszczególnych implementacji.

Oryginalny interfejs, pomijając liczne wady, ma jednak pewną miłą cechę: Daje dostęp do właściwości style: 

document.styleSheets[0].cssRules[0].style.color = '#00c'

Jedyne czego brakuje, to możliwość łatwego wyszukiwania odpowiedniego opisu z użyciem selektorów CSS, może wystarczyło by zaimplementować tylko ten fragment? 

$.css(".asd").color = "#00c";

Na razie to tylko luźny pomysł…

Linkownia

Etykiety: , , ,

Komentarze (0)

Red 00:42

Duchy Internetu

czwartek, 3 września 2009

Krąży powiedzenie że IE na każdy element w HTML, CSS i DOM posiada jakiś błąd.

Niedawno potrzebowałem elementu noscript, by opisać fragmenty kodu, które inaczej umknęły by niezauważone i natknąłem się na coś dziwnego…

Błąd, który w mojej opinii, jest królem wszystkich błędów, ukoronowaniem wielu lat doskonalenia się w tej jednej dziedzinie. Nie dla tego że jest poważny… ale… Jak u licha można popełnić błąd w czymś tak prostym?

noscript

Element noscript i jego zawartość powinien być widoczny tylko dla tych, którzy wyłączyli obsługę skryptów w przeglądarce.

Nie w IE8, tu wystarczy określić kolor tła, czy też krawędzi i pojawi się na ekranie w jako pusty prostokąt…
Teraz, ta przeglądarka jest już kompletna… w pewnym sensie.

Nie jestem pierwszą osobą, która to odkryła. Błąd jest znany, więc może za kilka lat to naprawią?

Przy okazji znalazłem coś równie… fascynującego…

Króliczek

Wystarczy mieć dwa elementy, np: div i wewnątrz img, przypisać obu właściwość display:none, następnie, pokazać element div, a obrazek sam wyskoczy niczym królik z kapelusza.

Na szczęście ten błąd objawia się tylko w trybie wstecznej zgodności.

IE, albo zdrowie

Zazwyczaj powstrzymuję się od pisania tekstów o negatywnym brzmieniu, ale tym razem zrobię wyjątek.

Opisane tu błędy są ledwie czubkiem góry lodowej. Każda strona w internecie pełna jest kodu powstałego wyłącznie by omijać pułapki tej jednej przeglądarki.

Używanie przeglądarki Internet Explorer jest szkodliwe dla otoczenia. Z powodu jednego programu cierpi cała Sieć.

Etykiety: , , ,

Komentarze (1)

Red 20:28

70 lat temu

wtorek, 1 września 2009

ii wojna światowa

Siedemdziesiąt lat temu miał początek najbardziej ponury okres naszej historii.

Etykiety: , ,

Komentarze (0)

Red 09:32

Archiwum

…

Subskrybuj

RSS / Atom