Przez chwilę myślałem, że się nie da. Jednak wystarczy ustawić odpowiedni background image na inline’owym elemencie. Albo border, jeśli nie potrzebujemy obrazka.

Rzecz super prosta, ale zaczynając przygodę z responsive można o tym zapomnieć. Media queries w CSS to rzecz jasna i o nich się pamięta. Na desktopowej przeglądarce skalujemy przeglądarkę i wszystko działa. Gorzej jest, kiedy zaczniemy testować stronę na urządzeniu – okazuje się, że telefon czy tablet skalują stronę.

Mobilne Safari robi nam psikusy. Kilka dni temu pisałem o dziwnym skalowaniu tekstu, dziś sposób na poprawne ostylowanie pól tekstowych i buttonów. Safari niestety domyślnie w nosie ma nasz CSS i do inputów dodaje na siłę border-radius i wewnętrzny cień.

Piękny to parametr, który ułatwia życie. Dzięki niemu, wartość w szerokość elementu w CSS nie jest wliczany padding i border, co ratuje tyłek przy tworzeniu skalowalnych layoutów na gridzie. Zurb Foundation ma to w standardzie, dziwię się że Twitter Bootstrap jeszcze nie.

Szerzej na ten temat rozpisał się Paul Irish: http://paulirish.com/2012/box-sizing-border-box-ftw/

Kilkukrotnie zdarzało mi się trafić na sytuację, kiedy przy budowie responsywnej strony zupełnie bez większego uzasadnienia część tekstu na stronie wyświetlanej na Safari pod iOS zmieniało swój rozmiar, pomimo zdefiniowanych reguł w ramach media queries. Oczywiście taki problem nie był widoczny na przeskalowanej przeglądarce desktopowej, więc zupełnie nie wiedziałem jak się zabrać do zdebugowania tego problemu. Na szczęście, poszukując desperacko rozwiązania trafiłem na taki parametr w CSS:

Warto zwrócić uwagę na zastosowane tutaj 100%. Problem rozwiązać może też ustawienie wartości „none”, przy czym to zablokuje skalowanie rozmiaru tekstu na przeglądarkach dektopowych poprzez „ctrl+/ctrl-” (lub „cmd+/cmd-” na OS X).

Więcej na ten temat na http://blog.55minutes.com/2012/04/iphone-text-resizing/

Czasami zdarza mi się, że na Chrome pod OS X czcionki wyglądają na zbyt grube. Graficy od razu zaczynają płakać a akanci popadają w depresję, tłumacząc klientowi dlaczego strona nie wygląda w przeglądarce identycznie jak w Photoshopie. Prosta rada: zmienić wartość parametru font-smoothing w CSS.

Uwaga: działa to tylko na Maku. Pod Windows nie ma absolutnie żadnej różnicy. No i warto stosować z rozwagą. Zwykle, bardzo poprawia to wyrazistość przy dużych nagłówkach, natomiast zastosowanie tego parametru do tekstu głównego o rozmiarze 12-14 punktów może sprawić, że tekst zacznie wyglądać jak na IE6 pod Windows 98 :)

Często zdarza mi się taka sytuacja, że potrzebuję wykorzystać jakiś specyficzny kawałek kodu, właściwość czy super-trik. Poświęcam czas na jego znalezienie, stosuję w projekcie i… zapominam. O tym, w którym to było projekcie również. Kiedy za 2 miesiące problem powraca, poszukiwania rozpoczynają się od początku. Aby temu zaradzić, do tej pory zapisywałem sobie takie triki w Evernote. Ale, skoro mam bloga – to czemu nie robić tego tutaj? Może komuś poza mną się to przyda!

Pierwszy w cyklu temat, to odpowiedniki liczbowe dla grubości czcionek w CSS.

Właściwie każdy projekt, który wychodzi spod moich palców, gdzieś zaszytą ma jakąś animację z wykorzystaniem CSS3 transitions lub opartą na jQuery – proste przejście od opacity: 0 do opacity: 1, czy też animacje fadeIn/fadeOut to praktycznie standard. Rzadkością są też projekty, gdzie nie embedowałbym przynajmniej jednego kroju czcionki jako webfont. W jednym z realizowanych projektów zauważyłem, że te dwie przydatne praktyki nie lubią się na wzajem – a raczej, nie lubi ich Google Chrome. Czcionka zachowuje się po prostu… dziwnie.