La tête dans le Flux !

Unicode c’est fantastique !

La ruée vers le Web mobile apporte de nouveaux questionnements et de nouvelles techniques de conception web. Notamment de performances web et d’adaptation des images aux écrans haute-définition.

Le sujet des pictogrammes, icônes et autres petites images décoratives est à la mode et un bon nombre de techniques existent pour cumuler le maximum d’avantages à la fois :

• le moins de requêtes serveur possible, voire aucune
• format le plus léger possible
• pas de dégradations visuelles lors de l’agrandissement
• pas de dégradations visuelles sur écrans “rétina”

Le format Unicode, via l’encodage Utf-8 permet d’afficher un nombre (presque) incalculable de caractères dont la plupart sont totalement inconnus.

Et pourtant, beaucoup de ces caractères sont parfaitement capables de remplir un rôle parfait de pictogramme… sans avoir à charger de fichier puisqu’il existe déjà dans les polices de caractères classiques.

Tous les avantages sont réunis… à condition que tous les navigateurs les interprètent correctement, ce qui n’est pas toujours le cas (à vous de vérifier au cas par cas). Ce serait trop simple sinon.

A des fins personnelles, je me suis construit une petite base de pictogrammes qui me semblent intéressants pour illustrer des sites web.

Vous la trouverez à l’adresse http://goetter.fr/unicode/

Et pour rappel, j’avais déjà fait quelques tests sur le sujet, visibles ici : http://www.ie7nomore.com/css2only/characters/

EDIT : puisque j’ai de nombreux retours et commentaires (justifiés) concernant l’accessibilité de ces pictogrammes, je vous renvoie vers un article récent : “Icônes @font-face et accessibilité”. J’y décris différentes méthodes pour résoudre les gênes pour lecteurs d’écrans.

Le saviez-vous ? display est inutile sur un élément flottant

J’ai envie aujourd’hui de revenir sur une idée reçue de longue date : le mélange du positionnement flottant (float) et de la propriété display.

Associer float et display: block (ou inline)

C’est parfaitement inutile.

Tout simplement parce que les deux schémas de positionnement ne peuvent pas cohabiter : un seul sera interprété, le flottant.

Pourtant, bon nombre de feuilles de styles cumulent les deux propriétés sur le même élément, sous prétexte de pouvoir lui attribuer une largeur width ou une hauteur height.

Eh ben non, c’est inutile.

La seule exception acceptable est celle d’employer display: inline pour corriger un bug identifié sur IE6 sous le nom de double-float margin bug.

Ah mais oui puisqu’un flottant devient un élément de rendu block !

Non.

Float n’a aucune influence sur la valeur de display d’un élément. Pour preuve, un élément qui sort du flux de quelque manière que ce soit (float, position: absolute ou fixed) occupe par défaut la largeur de son contenu et non la largeur de son parent. Donc pas du tout le comportement d’un bloc.

Par contre, un élément qui sort du flux bénéficie d’un avantage commun aux display block : celui de pouvoir supporter les propriétés de dimensionnement (largeur, hauteur).

Cumul des mandats ?

Les spécifications W3C admettent l’éventualité de cumuler différents schémas de positionnement.
Voici exactement comment cela se passe pour éviter les règles contradictoires :

1. Si display: none est appliqué, alors l’élément ne crée pas de boîte et les propriétés position et float ne sont pas employables.
2. Sinon, si une propriété position est appliquée et a pour valeur absolute ou fixed, ce schéma devient prioritaire, la valeur de la propriété float est forcée à none (elle devient inutile) et l’élément est placé selon les éventuelles valeurs de top, right, bottom et left.
3. Sinon, si une propriété float est appliquée avec la valeur left ou right, l’élément devient flottant et display devient inutile
4. Sinon, l’élément est disposé selon son mode de rendu par défaut inhérent à la propriété display (inline, block, list-item, etc.).

En résumé : si les propriétés float et display apparaissent au sein du même bloc de déclarations, alors display (à l’exception de display none) doit être purement et simplement ignorée par les navigateurs. Elle devient inutile.

De même, si position absolute, float et display cohabitent, ces deux dernières doivent être ignorées par les navigateurs.

Pour élargir le débat, je vous invite à consulter cet article dédié au positionnement flottant : http://www.alsacreations.com/article/lire/972-float-le-grand-bluff.html

Préfixes CSS : le pavé dans la mare

L’ogre WebKit

WebKit est un moteur de rendu libre et ouvert initialement lancé par Apple en 2003 et composé actuellement de nombreux développeurs de Google. Adobe participe aussi activement à Webkit car c’est le moteur de rendu utilisé dans toute leur suite.

Il est le cœur de très nombreux navigateurs de bureau (Chrome, Safari, Konqueror) mais aussi sur mobile (Safari mobile, Android, etc.).

En quelques années, il s’est imposé comme un acteur majeur du Web.

Plus important encore : Webkit va plus vite, plus haut et plus fort que les autres. Et ça excite les webdesigners.

Les préfixes vendeurs CSS

Les composants de CSS3 étant pour la plupart en cours d’élaboration à des stades divers, le souci de l’implémentation dans les navigateurs web devient problématique. En effet, si chaque module est susceptible d’évoluer, voire de changer, dans les mois ou années à venir, il est totalement contre-productif pour un navigateur de tenter d’adapter au jour le jour son traitement de toutes les propriétés fluctuantes.

Que faire alors ? Patienter jusqu’à l’aboutissement de chacun des modules ou modifier ses algorithmes à chaque modification des spécifications d’une propriété ?

Le Consortium W3C propose depuis CSS 2.1 une alternative qui a le mérite de ne pas bloquer l’évolution des agents utilisateurs : à partir des informations dispensées dans les spécifications, chaque navigateur a carte blanche pour construire ses propriétés personnelles dérivées en les faisant précéder d’un préfixe vendeur propriétaire. Lorsque la spécification atteint le stade de Recommandation Candidate (CR), le préfixe doit être supprimé.

Ainsi, Mozilla Firefox a pu développer sa propre variante -moz-border-radius pour permettre d’utiliser la célèbre propriété border-radius (définissant l’arrondi des coins d’un bloc), très récemment finalisée dans la norme CSS 3. L’avantage est que l’un et l’autre isotope de la propriété ont leur propre vie et peuvent être développés indépendamment, voire se distinguer… jusqu’au jour de la reconnaissance officielle de border-radius par le W3C, auquel cas sa copie propriétaire n’a plus de raison d’exister.

Les spécifications recensent une douzaine de préfixes propriétaires (appelés aussi préfixes vendeurs) dont les plus fréquemment rencontrés sont attribués aux navigateurs web principaux, à savoir :

• -moz- pour le moteur de rendu Gecko de Mozilla Firefox ou Thunderbird ;
• -ms- pour Microsoft Internet Explorer
• -o- pour Opera ;
• -webkit- pour les moteurs WebKit de Safari et Chrome par exemple ;
• -khtml- pour les moteurs KHTML (par exemple Linux KDE).

Cette convention évite les collisions de noms entre les fonctions standards et propriétaires, sans entraver les progrès des constructeurs de navigateurs. Toutefois, dans la pratique, cela contraint les auteurs à multiplier les écritures de déclarations de propriétés pour parvenir à un accord sur tous les navigateurs.

Opera annonce qu’il va supporter le préfixe -webkit-

Nous parvenons enfin au cœur du feuilleton : Opera a annoncé aujourd’hui qu’il allait implémenter très prochainement le préfixe -webkit- initialement “réservé” au moteur de rendu du même nom (sur son navigateur Opera Mobile dans un premier temps, puis sur l’ensemble de ses services).

L’explication est simple : WebKit est devenu l’unique référence pour de nombreux concepteurs web, qui ne prennent plus la peine d’ajouter les préfixes des autres navigateurs.

Pire, ils se contentent parfois de cette seule syntaxe, en occultant la syntaxe officielle finalisée sans préfixe.

L’expérience utilisateur s’en voit bien entendu dégradée sur un grand nombre de navigateurs, qui pourtant sont capables de reconnaître ces fonctionnalités CSS3.

Même dans le marché grandissant du Web mobile, où Opera est très représenté en terme d’usage,… tout le monde développe spécifiquement pour Android ou iOS, et le préfixe -webkit- est roi incontesté.

Opera a donc opté pour une solution radicale : supporter les propriétés préfixées par -webkit-. Cette décision a bien entendu levé un vent de panique dans notre microcosme.

Dans la pratique, Opera ne va pas implémenter les propriétés en triple exemplaire (-webkit-, -o- et sans préfixes) : seules certaines propriétés préfixées seront reconnues, et considérées exactement comme s’il s’agissaient de propriétés préfixées par -o- (un peu comme un alias).

En outre, cela ne concernera évidemment que les fonctionnalités déjà supportées par Opera.

Concrètement ?

En fait le principe est assez simple, le voici illustré par un exemple fictif :

• Chrome et Opera supportent tous les deux la propriété transition (CSS3 actuellement en working draft)
• Chrome (sous Webkit) la supporte avec le préfixe -webkit-transition
• Opera (sous Presto) la supporte aussi, mais avec le préfixe -o-transition

Malheureusement, très (trop) peu de webdesigners se contraignent à ajouter tous les préfixes et se contentent souvent de -webkit-.

Au final, il n’y aura pas de transitions sur Opera, bien que ce navigateur les supporte très bien.

La solution de repli d’Opera est d’interpréter les préfixes -webkit- et de les appliquer quand-même à condition qu’il reconnaisse la propriété concernée. Du coup, les transitions fonctionneront sur Opera… même en se contentant d’un -webkit-transition.

Hey mais les autres s’y mettent aussi ?!

Pour bien se rendre compte que le phénomène est loin d’être anodin, une réunion de discussion autour de ce thème est prévue prochainement.

Il y sera question de l’adoption du préfixe -webkit- par Mozilla Firefox ainsi que d’Internet Explorer, qui semblent très sérieusement envisager cette éventualité.

Ça va changer quoi concrètement ?

Pas mal de choses.

Pour commencer, c’est un aveu de plusieurs dysfonctionnements (notamment du W3C et de sa lenteur), et aveu de faiblesse devant l’ogre WebKit : soit on s’allie, soit on meurt.

Sinon, plus prosaïquement :

• Les concepteurs web auront encore moins besoin de se soucier des navigateurs tels qu’Opera, Firefox ou Internet Explorer
• La maintenance de sites web en production sera facilitée : inutile de devoir reprendre tous ses sites pour y ajouter des préfixes -o-,-moz- et -ms- dès que les mises à jour des navigateurs reconnaîtront une nouvelle fonctionnalité CSS3

Bref, la nouvelle guerre des navigateurs commence maintenant, attachez vos ceintures !

À propos de rétina et d’images floues

“Rétina”, “retina display” et “retina HD”, sont de bien jolis mots marketing que personne ne saurait définir exactement.

De manière très succincte, parce que je n’ai aucune envie de m’attarder sur ce point, disons tout simplement que “retina” a commencé par désigner la génération iPhone 4 aux résolutions de 960×640px au lieu de 480×320px dans les modèles précédents. Le terme désigne aujourd’hui tout périphérique nomade (tablette ou smartphone) doté d’un écran haute résolution.

Toujours est-il que pour le quotidien d’un développeur web mobile, les différences de rendu selon les résolutions sont loin d’être une partie de plaisir. D’autant plus que les terminaux Apple (iPhone, iPod et iPad) ont la fâcheuse habitude de mentir sur leurs résolutions en mentant sur leur device-width.

Prenons un exemple courant: l’iPhone4 ou 4S. Sa largeur physique est de 640px, mais il déclare un device-width de 320px (en largeur et en hauteur).
En lui appliquant - avec raison - une balise meta viewport de valeur “width=device-width”, il se prend pour un écran de 320px de large… tout en conservant sa précision de 640px.

Les contenus affichés, surtout les images, sont alors interpolées et interprétées comme “doublées”. Un peu comme un large écran de bureau auquel vous imposeriez une résolution de 800x600px : l’interpolation est parfois hasardeuse et manque de précision. Disons-le franchement, c’est parfois un peu flou.

Pour mieux comprendre, voyons le phénomène à travers plusieurs exemples concrets. Des vraies images HTML (img) pour commencer, puis des images d’arrière-plan.

Cas des images HTML

Cas des arrière-plans CSS

Alors, on peut y faire quelque chose ?

Pour contrer ce souci de finesse dans le rendu, les solutions ne sont pas si évidentes car il ne suffit pas de détecter les résolutions HD ou les pixel-ratios.

Voici les hypothèses que j’entrevois :

1. Ne rien faire.
   En toute honnêteté, ce n’est pas une catastrophe d’afficher des images classiques sur un écran haute définition, mais c’est un peu dommage car l’avenir appartient aux mobiles “rétina”.
2. Servir des images “un peu plus grandes” que la largeur finale affichée.
   Par exemple, pour un picto de largeur 32px, afficher une image de 64px. Idem pour les images d’arrière-plan, en pensant à préciser un background-size de 100% auto. C’est une bonne solution intermédiaire à condition de ne pas en abuser car le poids des images aura une incidence non négligeable sur le temps de chargement et d’affichage sur anciennes générations non rétina.
3. Servir des images différentes selon la définition d’écran des mobiles.
   Cela peut se faire du côté client ou serveur et c’est forcément la meilleure solution… et la plus contraignante. Tournez-vous par exemple du côté du script “Retina Images”, de RetinaJS ou celui de adaptive-images.com.

Et vous, vous avez d’autres pistes ? Des solutions ?