Conférence : “un site responsive en une heure”

J’ai eu la chance d’être invité à AgoraCMS pour y présenter une conférence que j’ai appelée “Un site Responsive en une heure”.

Le titre de ma présentation était volontairement provocateur et tout le monde a pu le comprendre rapidement puisque la réponse est “on ne peut pas”.

Cela ne m’a pas empêché de jouer à mon jeu préféré : prendre le site web de l’organisateur, AgoraCMS, le rendre responsive, et d’expliquer pas à pas comment j’ai procédé.

Avant la démonstration, j’ai commencé par détailler 4 notions qui me semblent indispensables à maîtriser quand on se lance dans le Responsive Web Design :

  • les tailles des devices
  • les media queries CSS3
  • la propriété box-sizing
  • la gestion des débordements

Au final, je fus un peu pris de court (je pensais avoir 1h et non 50min), et je constate que je parle toujours aussi rapidement quand j’ai plein de choses à dire !

Les slides de conférence sont disponibles sur Slideshare.


Les mobiles nous mentent ! (version 2013)

Cet article est une version remaniée et mise à jour d’un billet éponyme publié il y a quelques mois.

image

On sait depuis un bon bout de temps à présent que les écrans de nos smartphones et tablettes sont des mythomanes et nous font croire tout un tas de fourberies à leur propos.

On a commencé par mettre un moment à comprendre qu’un écran mobile ne disposait non pas d’un seul type de largeur (et de hauteur), mais de trois :

  • largeur “constructeur”
  • largeur “device-width” (ou screen.width en JS)
  • largeur de fenêtre (viewport)

Mais les contrevérités ne s’arrêtent pas là, loin de là.

Voici donc la liste officielle des mensonges véhiculés par les constructeurs mobiles et qui embrouillent les esprits des développeurs web aujourd’hui encore.

Toutes les affirmations suivantes sont FAUSSES, au moins en partie :

  1. On détecte un iPhone 4 (ou 5)  en testant si sa largeur en portrait correspond bien à 640 pixels.
  2. On détecte un iPad 3 (ou plus) en testant si sa largeur en portrait correspond bien à 1536 pixels.
  3. La largeur de fenêtre (viewport) sur mobile est de 980px.
  4. La valeur de device-width correspond à la taille d’écran d’un mobile.
  5. La valeur de device-width est fixée une fois pour toute pour chaque périphérique.
  6. La valeur de device-width change selon l’orientation du mobile.
  7. Il faut utiliser une meta viewport de valeur “width=device-width”.
  8. Il faut utiliser une meta viewport.
  9. Un iPhone 4 (ou 5) est doté d’un écran “HD”.
  10. On gère les écrans HD en produisant des images de taille doublée.

Important : je suis actuellement en train de préparer une conférence sur ce sujet, c’est pour cela que les affirmations sont volontairement dénuées d’explications. Je divulguerai les explications dans quelques temps, promis…

Quelques ressources très intéressantes pour étayer le sujet, à lire très consciencieusement :


En 2013, y a t-il encore un problème de pixels ?

Voilà ressorti le plus vieux troll du monde des intégrateurs : celui du méchant pixel qui n’est pas accessible.

Je propose de réouvrir ce joli débat dans le contexte actuel de 2013, alors que l’on voit enfin disparaître certains navigateurs dinosaures.

Je vais tâcher d’avancer de manière logique et pragmatique dans ce billet, à vous de me dire si je me trompe dans ma logique…

L’espace de commentaires est libre, mais essayons de raisonner en adultes responsables, évitons les taches de sang !

Le problème des pixels :

  • IE6 ne dispose que d’un zoom texte
  • IE7, IE8, IE9 et IE10 disposent d’un zoom texte et d’un zoom global de page (par défaut)
  • En zoom texte, IE6 et IE7 (et IE8 ?)  figent les polices en pixels : les contenus ne peuvent pas s’agrandir, ce qui est bien entendu gênant en situation de handicap
  • Tous les autres navigateurs permettent d’agrandir les polices en pixel depuis longtemps

Hypothèses :

  • En 2013, on peut supposer que IE6 est devenu suffisamment négligeable pour ne plus être pris en compte (IE7 aussi ?)
  • On ne peut pas connaître le nombre de personnes utilisant IE7 ou IE8 et qui ont fait le choix d’opter pour le zoom texte (car c’est un choix, ce n’est pas le réglage par défaut)
  • On ne peut pas connaître le nombre de personnes handicapées utilisant IE7 ou IE8, même si on peut présumer que les chiffres sont proches de la moyenne générale.
    EDIT : une enquête de WebAIM donne des chiffres intéressants sur ce sujet.

REM : c’est l’avenir ou déjà le présent ?

  • L’unité em est une unité fluide, ce qui résout par principe tous les problèmes de polices figées en pixel
  • Une taille de police en em a pour référent la taille de police de l’élément parent, la cascade impose donc des calculs (par exemple, un label de 1.5em au sein d’un paragraphe de 2em aura en fait un coefficient multiplicateur de x3)
  • L’unité rem est - comme em - une unité fluide. Mais son référent n’est pas le parent de l’élément mais l’élément racine HTML (donc si HTML a une taille de 10px, tous les éléments de la page faisant 1.5rem auront 15px quel que soit leur position dans le DOM)
  • rem est une unité CSS3 en Candidate Recommandation supportée par l’ensemble des navigateurs, à partir de IE9, et à l’exception d’Opera Mini : http://caniuse.com/#feat=rem

Le code ci-dessous permet aux paragraphes de disposer d’une taille fluide équivalente à 14 pixels, facile à calculer, tout en proposant une alternative en “vrais” pixels pour les navigateurs plus anciens :

html {
	font-size: 62.5%; /* equiv 10px */
}
p {
	font-size: 14px;
	font-size: 1.4rem; /* equiv 14px mais fluide */
}

Toute la question est : qui sera encore pénalisé aujourd’hui par cette méthode ?

EDIT : quelques discussions sur le sujet :