Le Carnet de Thierry » safari

Les favicons de l’iPhone : les Apple Touch Icons

Thierry — Wed, 03 Dec 2008 18:01:57 +0000

Les possesseurs d’iPhone ou d’iPod Touch sont des utilisateurs un peu à part. Ils ont leur propre format de favicon. Les favicons « classiques » ne sont pas affichées par Safari Mobile. Mais il est par contre possible de définir une icône à afficher sur l’écran d’accueil (utilisée comme raccourci). Je vous conseille fortement de prendre le temps de créer une icône pour ses utilisateurs. Si aucune icône n’a été définie pour le site web, Safari Mobile réalise une capture d’écran de la partie visible de la page afin de l’utiliser pour icône. En pratique, à moins d’avoir un site comportant des couleurs vives et uniques, à partir de la deuxième icône de ce style, il devient très difficile d’identifier le raccourci.

Comme vous pouvez le voir avec cette capture d’écran de mon iPhone, l’icône générée automatiquement est totalement inutile car il est quasiment impossible d’identifier le site web (pour cette exemple, mon blog) et en plus elle est moche! Par contre, l’icône personnalisée a l’air d’être native à l’iPhone et attire le regard, ce qui est idéal pour les utilisateurs exigeant que sont les consommateurs des produits Apple.

Comment fait on pour personnaliser ces icônes?

Premièrement, ce n’est applicable que sur les iPhones avec au moins la mise à jour 1.1.3 comportant la fonctionnalité Web Clip. Je pense que tous les iPhones sont à jours, mais on ne sait jamais…

Il faut savoir que l’iPhone applique 3 effets avant de rajouter l’icône sur l’écran d’accueil :

des bords arrondis,
une ombre sous l’icône,
un aspect brillant.

Ne donnez donc pas un aspect brillant ou des bords arrondis à votre image. Cela ferait double emploi… L’iPhone attend une image au format PNG de 57 par 57 pixels, dans le cas contraire l’image est redimensionnée à la bonne taille.
Mise à jour du 28 juin 2010 : Avec la sortie de l’iPhone 4, la taille maximale des icônes est passée à 114 par 114 pixels pour tenir compte du nouvel écran.

Le plus simple pour appliquer l’icône sur tout un site web, est de la mettre à la racine avec le nom : apple-touch-icon.png. Depuis la version 2.0 du firmware de l’iPhone, il est possible d’indiquer par le nom du fichier, que l’on ne veut pas des effets visuels supplémentaires. Pour cela le fichier doit s’appeler : apple-touch-icon-precomposed.png.

Mais si on ne veut appliquer l’icône que sur sur une page, ou un ensemble de pages? Dans ce cas-là, il vous faut la définir directement dans le section head de votre document HTML par ce bout de code :

L’effort n’est pas monstrueux et c’est beaucoup plus confortable pour les utilisateurs d’iPhone et d’iPod Touch. Vos internautes pourront alors être fiers d’arborer le raccourci de votre site sur leur écran d’accueil.

Voici 2 articles de l’Apple Developer Connection sur le sujet :

Les tests Acid sont-ils positifs?

Thierry — Tue, 01 Apr 2008 18:55:34 +0000

La semaine dernière, Safari et Opera ont obtenu le score de 100/100 pour le test Acid3. Les deux navigateurs ont annoncés leur réussite à quelques heures d’intervalles, terminus d’une course effrénée pleines de rebondissement. (qui n’aura su passionné que quelques geeks, dont moi…) Il est indéniable que toutes améliorations des navigateurs sur leur support des standards est une bonne chose, mais les tests Acids ont-ils pour autant un effet positif?

Le premier test Acid est apparu en 1998, il s’agit d’un test basé sur la spécification CSS1. Son créateur Todd Fahrner avait pour soucis d’offrir un élément de référence sur le box model pour les développeurs de navigateur. Ce test de qualité a fini par rejoindre en 1999 la suite de test de CSS1.

Il aura fallu attendre 2005 pour voir l’apparition du test Acid2. Cette fois-ci le test développé principalement par Ian Hickson, teste de nombreuses propriétés CSS 2.1, mais aussi le support des PNGs transparents, de l’élément objet ou encore comment le navigateur se comporte face à des erreurs dans la feuille de style. Le test ne se concentre plus sur un domaine précis, mais regroupe différents points mal supportés par les navigateurs présents alors sur le marché et que la communauté aimerait vite voir corrigés. Ce fut indéniablement un bon moyen de motiver certaines équipes de développement, bien que l’on commençait déjà à se séparer de l’esprit de base.

Le test Acid3 est encore tout chaud. Il est sortie du four le 3 mars 2008. Encore plus ambitieux que son prédécesseur, le test Acid3 effectue 100 tests sur la page. Il se concentre principalement sur le DOM, mais comportent aussi des tests sur les sélecteurs de CSS3, sur SVG ou encore SMIL. Le soucis principal de ce nouveau test est de motiver les navigateurs à repousser leur limite. Ian Hickson aura mis près d’un an pour développer ce test Acid et il aura du faire appel à la communauté pour concevoir les derniers tests (afin d’avoir un beau score final de 100).

Malheureusement les derniers tests Acid, bien que formidable de part leur élaboration (je suis admiratif des connaissances que certaines personnes ont accumulé pour les concevoir), sont surtout un moyen de faire de la pub. Soyez le ou les premiers à passer un test Acid et le nom de votre navigateur se retrouvera sur tous les digg-like et tous les blogs et les sites ayant un lien avec le développement web. C’est ce qui a sûrement du pousser Opera a faire son annonce sans pour autant avoir une version de test de leur navigateur à offrir en téléchargement, ou pour Webkit, d’activer des aspects non finalisés de leur moteur de rendu pour valider certains tests. Il est amusant de remarquer que chez Firefox, on prend le contre-pied en précisant que non, Firefox 3 ne passera pas le test Acid3, car il y a des choses plus importantes à faire.

On en vient au final à se questionner sur les réels bénéfices apportés par le dernier test Acid. Il force les développeurs de navigateurs à implémenter des morceaux de spécification pour passer le test. Même si ces propriétés nouvellement supportées pourront se révéler utile dans de futures développement. On est bien loin de la réalité du développement web. Ne vaudrait t’il pas mieux se concentrer sur certains spécifications, voir certains aspects d’une spécification, qui répondraient à des besoins spécifiques mis à mal actuellement? Au lieu de faire un test qui s’occupe un peu de tout…

Débloquer le menu Debug sous Safari

Thierry — Sun, 10 Feb 2008 11:21:14 +0000

Note : Avec la sortie de Safari 3.1, les explications données dans ce billet ne sont plus à jour. Depuis la version 3.1, ce menu se nomme maintenant Développement et s’active depuis la section Avancées des préférences de Safari. Les explications dans le billet pour activer le menu Debug concernent donc les versions précédentes.

Pas toujours connu des développeurs web sous Mac, il existe un menu caché par défaut sous Safari permettant de combler plusieurs de leurs besoins. Il ne rend pas Safari aussi puissant qu’une installation de Firefox pleine à craquer d’extensions pour le développement web, mais Safari n’a pas pour autant à rougir de la comparaison.

Ce menu vous permet entre autres :

de modifier le User-Agent de Safari (ce qui peut se révéler pratique même en dehors des périodes de développement) ;
d’ouvrir la console JavaScript ;
de modifier différents paramètres liés à la gestion de l’affichage de la page ;
ou encore d’ouvrir son fameux Web Inspector (captures ci-dessous).

Ce Web Inspector fera très plaisir aux utilisateurs réguliers de Firebug car ils y retrouveront des fonctionnalités de cette extension indispensable de Firefox.

C’est bien gentil cette présentation. Mais maintenant que je vous ai alléché. Vous faîtes comment pour accéder à ce menu? L’explication que je fournis n’est valable que sous Mac. Si vous savez comment débloquer ce menu pour la version Windows, merci de laisser un commentaire. (ptrubert nous a offert la solution dans les commentaires)

Commencez par ouvrir votre Terminal (Faîtes une recherche Spotlight ou lancez le depuis /Applications/Utilitaires/, raccourci SHIFT+COMMAND+U dans Finder). Une fois que le Terminal est ouvert, copiez-collez cette ligne :

defaults write com.apple.Safari IncludeDebugMenu 1

Vous n’avez plus qu’à appuyer sur Entrée. Si le Terminal ne vous affiche rien de particulier sauf une nouvelle invitation à taper une commande, c’est que cela a marché. Le jour où vous voudrez enlever le menu Debug de Safari, il vous suffira de recopier la même commande, sauf que cette fois-ci vous mettrez un 0 à la place du 1. Pour admirer le nouveau menu, il vous faut relancer Safari.

Il ne reste plus qu’à vous amuser avec ces nouvelles fonctions. Cependant garder bien au chaud votre installation de Firefox. Ces fonctions de Safari sont sympa, mais restent encore assez limité.