Archive pour le mot-clef ‘standards’

Utiliser la police de son choix sur son site internet

ArobaseL’intégration de polices de caractères sur un site web a longtemps été un casse tête pour les intégrateurs. On avait diverses solutions à portée de main : du flash, du javascript et quelques bidouilles assez incompatibles entres-elles pour lier directement une police dans le CSS.

Techniquement, si le W3C recommande depuis longtemps l’utilisation de Font-Face, celle-ci n’a pas toujours été implémentée comme il le faut dans les navigateurs. Aujourd’hui, l’horizon s’éclaircit progressivement même s’il faut encore fourber avec plusieurs formats pour arriver à un résultat efficace sur l’ensemble de la gamme des navigateurs. Dans l’ensemble on y arrive assez bien. Démonstration.

Tu l’a acheté ? Chuuuut ! Faut pas le dire sur internet…

Ah ! Un détail avant de vous lancer dans le code : une police de caractère est une oeuvre assimilable à un logiciel sur le plan juridique. Donc on touche au copyright (normal), aux droits d’auteur (un peu) et aux droits de diffusion (surtout). Si vous avez acheté une police, relisez bien les conditions d’utilisation, il est fort à craindre que vous n’ayez pas le droit de la proposer en téléchargement sur votre site web. Logique à priori, vous n’allez pas donner un truc qui se vend…

Sauf que… Les règles de Gutenberg ont un peu de mal avec le monde moderne. Si vous utilisez votre police sur votre site, il faudra bien que la machine de l’internaute la télécharge pour l’afficher. Même si l’utilisateur ne pourra pas (à priori, j’vous connais) s’en resservir dans un autre logiciel, vous placez cette police en téléchargement. C’est un fait. C’est stupide, mais c’est comme ça, sed lex.

L’idéal reste (once more) les polices gratuites ou sous Creative Commons. Perso, j’ai pris l’habitude de me fournir chez Google ou sur DaFont. Quitte à faire un petit don à l’auteur au passage (bah, au prix des polices payantes, ça reste tout bénef’ et vous assurez la pérennité du truc…).

Fourrer tout ça, proprement, dans son CSS…

Aller, une police libre dans une main, un ordi dans l’autre, comme l’ensemble des navigateurs ne comprennent pas tous la même chose, il faudra prendre soin de satisfaire chacun avec son ou ses formats de police préférés :

  • de l’Embedded OpenType (eot) pour Internet Explorer 4+
  • du Web Open Font Format (woff) pour Firefox 3.6+, Internet Explorer 9+ et Chrome 6+
  • et du Scalable Vector Graphics (svg) pour Chrome 3+, Opéra 9+
  • du TrueType (ttf) supporté par Firefox 3.5+, Opéra 10+, Safari 3.1+, Chrome 4+

Attention, l’ordre d’appel des différents formats dans le CSS compte et évitera à un navigateur qui comprend à la fois le SVG et le WOFF de charger le SVG à la place du WOFF. Au passage, ça vous évitera aussi quelques bugs sur certains navigateurs qui se mélangent un peu les pinceaux quand l’ordre ne leur convient pas (tatillons ?).

Pour convertir votre police dans les différents formats nécessaires à la pleine satisfaction les différents navigateurs Font Squirrel sera votre sauveur. Attention, ce dernier vous renverra à la loi si vous lui proposez une police handicapée d’un vilain copyright (et toc !).

Assez bavardé, voici le code magique à placer en tête de votre CSS.

@font-face {
    font-family: 'maPolice';
    src: url('fonts/maPolice.eot?')format('eot'),
         url('fonts/maPolice.woff')format('woff'),
         url('fonts/maPolice.svg#IdMaPolice')format('svg'),
         url('fonts/maPolice.ttf')format('truetype');
}

Explication de texte

  • La directive font-family permet de nommer la police pour les appels dans le CSS.
  • Dans les sources, on refile l’ensemble des formats aux navigateurs. Le navigateur s’arrêtera à la première qui lui convient.
  • Le point d’interrogation après l’extension eot permet de forcer le téléchargement sur IE afin qu’il n’interprète pas ce qui se trouve après ce caractère (ce qui permet d’ajouter les autres sources).
  • Le format eot s’appelle en fait embedded-opentype, l’utilisation d’eot leurre IE9 qui du coup ne connaît pas ce format et chargera le Web Open Font Format plus léger.
  • Dans le format SVG on notera une chaine louche après l’ancre. Il s’agit de l’identifiant du SVG. Vous le trouverez directement dans les premières lignes du fichier, dans une ligne qui ressemble à ça : <font id="IdMaPolice" horiz-adv-x="786" >.

Une fois la police incluse, elle sera utilisable comme les autres directement dans une directive font-family :

body { font-family: maPolice,sans-serif; } 

Optimiser une police de caractère…

En fonction de vos besoins, il est tout à fait envisageable d’épurer une police pour un usage web. Souvent les polices de caractères contiennent des caractères que l’on n’utilise jamais (symboles, autres langues, etc…) et que l’on peut retirer du package.
Pour ça, il existe deux solutions. Les plus courageux passeront par Font Forge, les plus pressés se concentrerons sur Font Squirrel. Dans le mode « Expert » de ce dernier, on trouve une option « Custom Subsetting » qui vous permettra de sélectionner très finement la gamme de caractères ou uniquement les caractères dont vous aurez besoin. On peut facilement imaginer faire passer le poids d’une police de 150ko à 6ko pour un titre de site par exemple. On est alors très proche du temps de chargement d’une image équivalente, et tellement plus accessible !

L’intégration en mode feignasse by Google

Parallèlement à cette technique qui peut paraître un peu longue à première vue, Google vient de lancer une bibliothèque de polices de caractères librement utilisables. On peut chercher, voir, et surtout, on peut intégrer ça dans son site en une seule ligne de CSS. Google fera le reste (et enverra le bon CSS au bon navigateur).

Google web font previewer

La bibliothèque n’est pas encore très fournie et cette API est encore en version Beta, mais c’est particulièrement prometteur.

Si le sujet vous intéresse, je vous conseille cette lecture ou encore celle-ci, et si vous avez vous aussi des petits conseils sur l’utilisation des polices sur le web, je suis preneur !!


HTML5 : le nouveau souffle des app’s standardisées ?

Avec l’arrivée du HTML5, on sent bien qu’une petite révolution ergonomique se prépare, dans la lignée de celle que fut l’AJAX en son temps. Les premières pages du web commencent à être loin derrière nous maintenant.

Je viens de découvrir Sencha Touch, un kit de développement encore en phase Beta mais qui propose déjà des outils assez bluffants pour créer des site web mobiles avec des interfaces proches de celles que l’on connait aujourd’hui sur les applications smartphones. Pour l’heure, le poids du fichier Javascript laisse à désirer pour un usage mobile (230ko en version compressée), mais c’est parce qu’il prend en charge tous les effets, espérons que ça évolue…

L’avantage de passer par le web pour des applis, c’est de retomber sur ses pattes en utilisant les standards : une seule appli pour couvrir l’ensemble des plate-formes mobiles.

Je vous laisse découvrir, ça fait 20 Mo, et le résultat est visible n’importe quel navigateur, vous m’en direz des nouvelles !


De l’accessibilité des sites web en mobilité

Tel-mobile J’entends souvent dire qu’il faut une version mobile pour un site internet (soyons francs, quand on m’en parle, on appelle ça une version iPhone, ça fait mieux) et je dois dire que je suis assez d’accord. On ne recherche pas la même chose en situation de mobilité que derrière l’écran de son ordinateur confortablement, vautré dans le sofa. Une version bien épurée, pratique et ergonomique permet à l’internaute de gagner du temps et offre une bien meilleure expérience utilisateur. On ne s’adresse pas à l’internaute de la même manière quand il est sur un ordinateur ou sur un téléphone.

Ceci étant, proposer une version optimisée pour les téléphones ne doit pas dispenser de proposer une version générale « compatible » mobile…

Lire le billet »


Développement web durable ?

Ca fait plusieurs fois ces derniers temps que j’ai l’occasion de me demander « mais pour combien de temps ces gens développent-ils leur site internet ???« . Et chaque fois, l’horizon est de 3 à 5 ans. Le web évolue vite, donc il faut refaire régulièrement. Ils en ont conscience, c’est normal, c’est une dépense lourde, mais Internet est un impératif, ça permet d’avoir une bonne vitrine et de soigner son image, il faut dépenser.

Je ne suis pas totalement contre cette idée. Le web évolue vite. Il faut donc faire évoluer les sites en même temps. Mais en revanche, une grosse refonte de profondeur est-elle vraiment nécessaire si le projet est bien pensé au départ ? A mon gout, le seul risque, c’est le changement radical de technologie (genre ASP => PHP => ROR), pour le reste, des améliorations régulières suffisent amplement.

Sauf quand un site n’est pas prévu pour durer : de très gros développements Flash, absence de séparation entre le fond et la forme, code incompréhensible pondu par une machine sans intelligence, aucune orientation objet dans le développement (ou pensé à peu près comme tel), etc…

Ce qui m’étonne le plus, c’est que l’on soit encore actuellement dans une démarche de vendre ce type de produits. Qu’à-t-on à y gagner ? Refaire le travail tous les 3 ans ? Les changements de chartes graphiques, les évolutions régulières, les nouveaux services, devraient fournir largement autant de travail… et surtout, surtout, permettre d’aboutir à un résultat plus concluant puisque pas repris régulièrement à zéro !

Ah ! Si 2008 pouvait correspondre avec une prise de conscience de l’intérêt d’un développement propre et de celui du respect des standards, ce serait une bonne année
à tous ! (Ben quoi ? Je ne vous l’avais pas encore souhaité !)


Les standards du web : non !

Interdit de W3C
Imaginez : Une belle page, entièrement en strict, avec un minimum de balises et un CSS tout beau tout propre.
Tout passe au vert dans les validateurs du W3C.
J’ai pensé accessibilité tout au long de ma petite création, je sais qu’elle sera lue par Jaws avec une certaine élégance.
Bref, cette page est l’archétype fantasmée du W3C. Je suis fier comme un coq, elle est belle ma page !
Je soumets au Big Boss, qui me dit « Changez 2 mots et on envoi ! ». Chose rare…

Oui, vous avez bien lu : « et on envoi »… et c’est là que tout s’effondre ! C’est là que l’on fait une magnifique plongée 10 ans en arrière… à l’heure où le W3C fêtait ses 2 ans et où tout le monde l’ignorait du haut de son berceau ! Cette page est une newsletter. Une newsletter est lue par des lecteurs de mails. Les lecteurs de mails ne sont pas tous basés sur des moteurs de navigateur, les lecteurs de mails sont de temps en temps des webmails qui font sauter la moitié des balises pour éviter les conflits…
Bref, mon mail passe bien dans Outlook, mais se transforme en horreur dans hotmail, résultats à chier dans gmail, idem dans évolution, j’en passe et des meilleurs…

La solution ? Coder comme un goret ! C’est le seul moyen (ou presque) pour qu’un mail passe bien partout ! Surtout, la règle d’or, si une chose respecte les standards, elle ne passera pas !!! Il faut de la soupe de balises ! Bien grasse ! C’est de saison ! La soupe, c’est bon, mangez en !!

Et bien vous me croirez si vous voulez, mais poser des tableaux partout, des fonts à ne plus savoir qu’en faire, ne pas utiliser le moindre style après des mois et des mois de standards… ça relève d’un exercice assez technique. Surtout, oubliez tout logiciel libre, c’est de la merde, ils ne savent pas faire la soupe ! Heureusement, un vieux Microsoft traînait dans le coin… un coup de FrontPage 2000 et… Houuu ! La jolie page… :-S

Mais bon, ça a marché ! Bien partie, bien arrivée.

Et vous ? Je suis sûr que vous avez trouvé des solutions plus intelligentes pour vos newsletters, parce que là… je ne suis quand même pas très fier…
C’est quoi les solutions ?