J’utilise de plus en plus Google Chrome pour tester mes pages web. J’ai trouvé dernièrement une petite astuce qui m’évite d’ouvrir Photoshop pour connaitre la correspondance des couleurs hexadécimales dans les formats RGB ou HSL. Dans une optique de dégradation gracieuse, je prends l’habitude de préciser une couleur au format «hexa» suivie de la même couleur au format RGBa pour profiter des effets de transparence. →
WordPress de A à Z — C comme CSS & Composé HTML5
«For Those About To Rock…» Dans B comme Basics, j’ai abordé la mise en place d’un Blank Theme pour démarrer différents projets de site web. Je pensais réserver la lettre «C» pour les commentaires(1), mais après le marquage HTML5, il m’a semblé important d’aborder au plus vite la partie CSS. Une des difficultés à surmonter lorsqu’on crée un thème de base, c’est d’éviter 1) d’avoir trop d’éléments à ajouter et 2) d’en avoir trop à supprimer. L’équilibre est délicat. D’autant plus que les intitulés des éléments doivent être le plus générique possible pour s’adapter à toutes les situations et permettre de se repérer facilement. «Fire !» Voici le sommaire complet des 26 articles de WordPress de A à Z. →
Créer des « Call to Action » ou des « boutons CSS » dans l’éditeur WYSIWYG TinyMCE
Cette petite astuce toute simple permettra à vos clients(1) de styler certains liens différemment des autres (Call to action, bouton, etc.) depuis TinyMCE, l’éditeur WYSIWYG de WordPress. Il suffit de créer un lien et de le mettre en «gras» avec l’icône B. Cette combinaison toute simple vous donnera le composé HTML suivant : →
hgroup disparait du brouillon HTML5, une chance pour logo et motto ?
Suite à la demande de Lars Gunther, la balise `hgroup` ne fait plus partie du brouillon HTML5 des spécifications du W3C. Les raisons de cet abandon semblent assez subjectives. Il semblerait que Lars Gunther n’aimait pas vraiment cet élément et que Ian ‘Hixie’ Hickson non plus. Il n’en fallait pas plus pour que cette balise disparaisse purement et simplement du brouillon HTML5. →
L’intégration HTML & CSS «Pixel Perfect» est une prestation en voie de [développement] [disparition] ?
Les claviers ont crépité la semaine dernière autour du rendu des maquettes Photoshop au pixel près. En relisant les billets et les commentaires, j’ai finis par me demander de quoi on parlait exactement. Lorsque l’intégrateur web reçoit un PSD (qui a déjà été validé, donc) à découper, il se se pose généralement pas la question : il prend une longue inspiration, se remémore quelques épisodes de Dexter et commence à découper sa maquette bien proprement. →
Intégration HTML & CSS des maquettes Photoshop au pixel près
Je reviens rapidement sur la question du rendu identique des maquettes quelque soit le navigateur. Je pense que tout le monde est d’accord pour reconnaitre que les standards ont encore une marge de progression et que les spécifications CSS3 et HTML5 prendront du temps avant d’être validées et implémentées correctement dans au moins deux navigateurs. En attendant, il faut bien faire avec l’existant. Est-ce à dire qu’il faut faire son deuil du rendu unique dans tous les navigateurs ? →
Standards du Web vs. Standards du Print
Julien Dubedout @mariejulien vient d’écrire un article très intéressant sur le rendu au pixel près des maquettes dans les différents navigateurs. Il explique son point de vue sur certaines différences de rendu de certaines propriétés qui ne sont pas { acceptables | logiques | normales } ; elles proviennent d’un standard qui — par définition — devrait garantir un affichage identique d’une même propriété sous tous les navigateurs. L’argumentation est rigoureuse et l’analyse est fine ; je partage une grande partie des points abordés par Julien que je résume rapidement ainsi : →
Et si Photoshop permettait de tester des maquettes fluides ?
Si c’était possible techniquement, est-ce qu’on s’amuserait à faire des rendus différents pour le plaisir ? Réponse : NON.
Cette interrogation de @mariejulien suite à la publication de l’article Les sites web doivent-ils s’afficher exactement de la même manière dans chaque navigateur ? et cette réponse lapidaire se poursuivent par la réflexion suivante : la norme est donc bien d’avoir un contenu identique, et le reste n’est qu’argument fallacieux à une impossibilité technique.
Question à laquelle j’ai répondu en bottant un peu en touche en disant que le monde de l’imprimé et du web ne répondaient pas aux même lois de la physique. →
Les sites web doivent-ils s’afficher exactement de la même manière dans chaque navigateur?
Cette question récurrente est un peu le serpent de mer du webdesign et de l’intégration web. Elle provient à l’origine d’une application sans discernement du flux de production PAO à des projets web qui n’ont pas les mêmes problématiques à résoudre. En PAO, il est impossible de dire au client que sa brochure imprimée aura un nombre de colonnes différent selon les lecteurs ou que la belle typo qu’il a déjà sur sa carte de visite ne passera pas à l’impression. C’est ainsi qu’est né le mythe du rendu des maquettes Photoshop au pixel près. Et pour cause : une fois que l’on a fait signer le BAT au client, on a les mains liées. Difficile de lui expliquer ensuite pourquoi son site ne ressemble à rien sur le PC de sa secrétaire qui utilise IE6. Et c’est normal du point de vue du client qui a bien raison de se moquer des problèmes existentiels des ouvriers qui travaillent à fond de cale 🙂 →
Maqetta — Editeur HTML5 / Javascript en ligne ou à emporter
Maqetta est un éditeur HTML5 open source lancé par IBM sous l’égide de la fondation Dojo. Cet éditeur existe en deux parfums : une version en ligne en mode Saas et un logiciel de 42,7 Mo à télécharger sur son poste de travail. La version en ligne est déjà très intéressante : l’ajout des contrôles jQuery UI s’effectue par glissé-déposé et l’interface est suffisamment WYSIWYG pour voir les Menus à onglets (Tabs) ou les Menus en accordéons (Accordions) fonctionner pour de vrai. On peut passer à volonté du mode «Design» au code «Source» ou avoir les deux à l’écran, horizontalement ou verticalement. →