Snippet: kiedy mobilne Safari tworzy automatycznie linki z numerów telefonu
To całkiem przyjemna funkcja, ale czasem safari się myli i tworzy link tam, gdzie nie powinno (nam dziś stworzyło link z numeru KRS i NIP).
To całkiem przyjemna funkcja, ale czasem safari się myli i tworzy link tam, gdzie nie powinno (nam dziś stworzyło link z numeru KRS i NIP).
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ń.
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 :)
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.