Il y a 10 jours, je partageais avec vous la première partie de cet article consacré à l'intégration web tout en em.
Ce précédent billet a pas mal circulé, notamment parce qu'il a été cité pendant Paris Web lors de l'excellente conférence de Nicolas Hoizey, que je remercie encore. :oops:
Je suis ravie de publier la seconde partie aujourd'hui, dans laquelle je vous dévoile les outils et les méthodes qui m'ont aidée à intégrer mon site en valeurs relatives, mais aussi le cheminement intellectuel que cela a nécessité.
NB : ce billet est très long, alors attrapez une tasse de café ou de thé si vous le pouvez, et prévoyez une vingtaine de minutes devant vous. *_*
Maniaques de la grille
Avant de rejoindre Clever Age, en 2011, j'intégrais tout en pixels.
Les préprocesseurs CSS émergaient à peine, et comme il est impossible de calculer, à la main, une conversion entre pixels et em, travailler en em était un réflexe que je n'avais pas encore acquis.
Quand je suis arrivée chez Clever, Vincent m'a expliqué le concept de rythme vertical, et m'a fait découvrir LESS. Cela a bouleversé ma pratique de l'inté.
Au bout de plusieurs semaines douloureuses enrichissantes, pendant lesquelles j'apprenais à manier Outline1, j'étais officiellement devenue (presque) aussi maniaque que lui en matière de grille macrotypographique.
Vincent et moi avons même poussé le vice jusqu'à prêcher les bienfaits des grilles à Paris Web, en 2012. (D'ailleurs, n'hésitez pas à jeter un coup d'œil aux slides, sans oublier de jouer avec les touches G + H, puis avec F et J sur la page de démo !).
Petit mémo langagier
Cela étant dit, même après avoir beaucoup travaillé sur le sujet, j'ai parfois des doutes sur la façon de nommer les choses. Alors voici un petit mémo :
- Le rythme vertical est défini par la grille horizontale, c'est à dire par les lignes ;
- Le rythme horizontal quant à lui est défini par la grille verticale, c'est à dire par les colonnes.
Mélanger les valeurs fixes et les valeurs relatives : une fausse bonne idée ?
Ainsi, nous avions l'habitude, chez Clever Garden2, de définir systématiquement les tailles de typo (font-size
), les interlignages (line-height
), les hauteurs et hauteurs minimales (height
et min-height
), ainsi que les écarts et les positionnements verticaux (margin-top
, margin-bottom
, padding-top
, padding-bottom
, top
et bottom
) en em.
Le rythme vertical est ainsi relatif à la taille de police définie par l'utilisateur des pages web que nous intégrons.
Parallèlement à ça, nous avions l'habitude d'utiliser les pixels pour toutes les autres valeurs, c'est à dire pour les valeurs de la grille horizontale : largeurs (width
, min-width
), marges horizontales (margin-left
, margin-right
, padding-left
, padding-right
) et positionnement horizontal (left
, right
).
Concrètement, cela veut dire que si on fait uniquement un zoom texte de la page intégrée, toutes les tailles de texte, tous les interlignages, toutes les hauteurs et tous les espacements verticaux s'agrandissent en fonction du niveau de zoom, alors que toutes les valeurs horizontales restent fixes.
Mélanger ainsi valeurs fixes et valeurs relatives peut avoir des effets de bord tarabiscotés, qui ne se produisent évidemment pas quand on utilise un zoom page, puisqu'alors tous les éléments de l'interface changent de taille, comme je l'expliquais dans la première partie de ce billet.
Mais l'essentiel, pour nous, c'était que les contenus textuels soient toujours lisibles et accessibles quel que soit le niveau de zoom. Ce qui était le cas avec cette méthode d'intégration qui mixe em et pixels.
Le confort de lecture se dégradait malgré tout au fur et à mesure que l'on zoomait le texte ; sans être illisible, ce n'était pas non plus d'une ergonomie folle.
Entre temps, on avait abandonné LESS au profit de Sass et de Compass.
Chasse à l'em
Tout allait pour le mieux dans le meilleur des mondes lorsque, au printemps 2013, j'ai eu pour mission d'intégrer un gros site institutionnel avec une exigence forte en matière d'accessibilité web3.
Ce site comportait beaucoup de templates différents, pas mal de JavaScript et, comme toujours, une attention toute particulière avait été apportée à la grille pendant la phase de création graphique.
Avant même que je ne commence à intégrer ce nouveau site, Stéphane et Nicolas (encore lui !) avaient travaillé de concert pour écrire un carrousel en JavaScript défini entièrement en em et fonctionnant parfaitement au clavier, ceci afin de respecter les critères d'accessibilité précis qui nous étaient demandés.
Une fois ce travail effectué, Nico a insisté pour que toute mon intégration soit réalisée également en em, afin de continuer sur la même lancée. L'objectif était intégrer un site responsive dont les contenus seraient réellement accessibles, en respectant au maximum les choix faits par l'utilisateur.
Pour me convaincre, Nico m'a fait lire cet excellentissime article, et, j'avoue, j'ai eu comme un déclic. Il a achevé de me convaincre qu'il fallait intégrer tout le site en em, media queries comprises.
Ainsi, j'allais devoir intégrer en em comme d'habitude la grille horizontale, mais également la grille verticale ! :idea:
Ce fut une grande première pour moi qui, je peux l'avouer aujourd'hui, m'a filé quelques sueurs froides. En effet, j'ai mis du temps à trouver les bons mixins Compass et j'ai également dû procéder à une mise à jour de mon mode de pensée, jusqu'alors configuré en pixels.
Mes mixins magiques
Je suis très mauvaise en maths, et je n'ai pas de calculette greffée dans la tête ; qu'à cela ne tienne, grâce aux préprocesseurs CSS – en particulier à Sass –, tout est calculé automatiquement via les mixins adéquats.
Ce qui m'a rapidement bloquée, c'était le calcul du background-position
des sprites générées par Compass : les valeurs étaient calculées en pixels, et non en em.
Par exemple, sur ma navigation principale, j'utilise un magic sprite4 :
Problème : si je zoomais ma page intégrée en em, mais que mes background-position
étaient spécifiés en pixels, l'image d'arrière-plan n'était pas correctement positionnée au fur et à mesure que l'élément grossissait.
J'ai corrigé ce problème en spécifiant le background-position
également en em :
Mais pour ça, il fallait écrire un mixin, car ce mixin n'existait pas :-)
(NB : les captures d'écran ci-dessus ont été faites pendant le développement de mon site ; depuis, j'ai remplacé le PNG par du SVG, ce qui permet aux icônes d'être toujours parfaitement nettes, même avec un fort niveau de zoom.)
Je ne suis pas développeuse, donc si vous voyez des choses à améliorer dans les mixins suivants, surtout ne vous privez pas : GitHub est fait pour ça !
Transformer des pixels en em
Ce mixin n'est pas de moi. Il fonctionne super bien, et je l'utilise tout le temps ! Il prend comme paramètre $target
la taille en pixels que vous voulez obtenir, et en paramètre $context
le contexte dans lequel le calcul doit s'effectuer. Ce dernier paramètre est facultatif.
Spécifier un background-size en em
Voici un petit mixin que j'ai écrit, qui va vous permettre de spécifier un background-size
en em, y compris sur un élément dont l'image d'arrière-plan appartient à un magic sprite créé par Compass.
NB : Au début du gist, j'ai remis la fonction em()
pour rappel.
Spécifier un background entier en em
Allons plus loin avec ce mixin : celui-ci permet de spécifier, en une fois, background-color
, background-image
, background-repeat
, background-size
et surtout background-position
– ces deux dernières valeurs étant calculées en em bien sûr. Ce mixin fonctionne également pour les magic sprites de Compass ! \m/^.^
NB : Au début du gist, j'ai remis la fonction em()
pour rappel.
Je trouve ce mixin utile car il permet de simplifier l'écriture.
Au lieu d'écrire :
.crosses { background: image-url('bg/crosses.png') no-repeat 50% 0; @include em-background-size('bg/crosses.png'); }
J'écris :
.crosses { @include em-background('bg/crosses.png', $position: 50% 0); }
Ok, on n'économise qu'une ligne de code, mais à l'échelle d'un gros projet, c'était pratique d'avoir une version raccourcie qui calcule tout en une ligne !
Voilà, rien de sorcier a posteriori, mais sur le moment, ça n'a pas été de la tarte de trouver comment calculer les background-position
des sprites générés par Compass et de les convertir en em.
Ce mixin m'a servi tout le temps, car j'utilise beaucoup les magic sprites.
Calculer le background-position d'une image sprite en em
Ajout du 29 octobre 2013 : J'ai complètement oublié de partager ce quatrième mixin, qui sert à récupérer le background-position
, en em, d'une image appartenant à un sprite magique créé avec Compass.
Admettons que je crée un sprite magic Compass depuis le dossier machin
. Je vais disposer de la variable $machin-sprites
qui me permet de cibler ce sprite précis dans mes mixins.
J'invoque donc mon mixin comme ceci :
.icon-truc { @include em-sprite-position($machin-sprites, 'truc'); }
Le mixin peut aussi prendre comme argument un font-size
, ce qui calculera les em en fonction de ce contexte.
J'espère que ces mixins vous aideront aussi !
Breakpoints et media queries
Niveau media queries, j'ai opté pour quatre breakpoints (« seuils de basculement ») génériques : 1024, 768, 550 et 320 pixels, auxquels s'ajoutent quelques media queries ponctuelles qui me permettent de cibler par exemple les écrans entre 768 et 1024 pixels, ou ceux qui font moins de 400 pixels.
Ces media queries complémentaires me permettent de fluidifier au maximum l'affichage de certains blocs dans certaines résolutions très précises.
Bien sûr, j'ai spécifié mes media queries en em, et pas en pixels, afin de mettre à profit le travail déjà effectué sur les valeurs relatives de mon site.
NB : une media query se définit toujours par rapport à la taille de l'élément html
, et pas par rapport au font-size du body. Aussi, même si votre body est à 14px, c'est bien par rapport à du 16px que seront calculées vos conversions de pixels en em dans vos media queries.
C'est pour cette raison qu'en plus d'une variable $base-font-size, paramétrée sur 14px, j'ai également créé la variable $browser-size, paramétrée sur 16px : c'est $browser-size que j'utilise quand je calcule une media query.
Exemple :
$tiny: 320px !default; @mixin respond-to($media) { if $media == tiny { @media only screen and (max-width: em($tiny,$browser-size)) { @content; } } … }
Pour éviter d'écrire à la main 50 fois la même media query, j'ai utilisé le mixin proposé par The Sass Way, respond-to()
.
Il m'a bien servi, mais il est possible de le raccourcir encore, par exemple en utilisant le mixin mq()
utilisé par Vincent dans son framework.
Attention cependant : le mixin mq()
gère le fallback pour Internet Explorer proposé par Jake Archibald, qui est embarqué dans Outline. Il ne vous suffira donc pas simplement de copier/coller le mixin mq()
dans votre projet, il faudra aussi prévoir toute la mécanique qui va derrière (deux CSS, appelée dans des commentaires conditionnels, notamment).
Comment inclure tout ça dans WordPress ?
Il y a peu, je vous racontais la refonte de mon #PortfolioOfDoom dans WordPress.
Travailler avec Sass pour créer mon propre thème WordPress fut un jeu d'enfant grâce aux instructions de Mehdi.
Par contre, je n'ai pas mis en place de compilateur Sass sur mon serveur en production, car je préfère faire mes modifications de CSS à tête reposée, chez moi, en local. Ça m'évite de faire une boulette en prod !
Ainsi, quand je veux améliorer un aspect technique de mon site, je développe et je teste en local, puis je déploie la modification en prod directement compilée en CSS.
Cela dit, il existe plusieurs plugins qui permettent de compiler des fichiers Sass directement depuis le tableau de bord de WordPress, mais je n'en cite aucun, ne les ayant pas testés.
L'épineuse question des images proportionnelles
Abordons maintenant un point un peu épineux : les images proportionnelles. C'est bien gentil d'intégrer un site tout en em, mais comment gérer les images proportionnellement une fois que le site a été zoomé ?
Les images elles aussi bénéficient du zoom de votre navigateur. Qu'il s'agisse d'images de contenu ou bien d'images CSS utilisées en arrière-plan, il faut gérer là aussi le zoom.
Les images CSS auront systématiquement besoin d'un background-size
spécifié en % ou en em (voir le support navigateur), et d'un background-position
lui aussi spécifié en % ou en em.
C'est la principale « difficulté » des images CSS dans une intégration tout en em.
Pour les images de contenu, on va utiliser la même méthode CSS que celle qu'on utilise quand on intègre un site responsive : width: 100%
(+ height: auto
pour que l'image conserve ses proportions + max-width: 100%
pour que l'image ne dépasse jamais de son conteneur) afin que l'image s'adapte à son conteneur, dont la largeur sera spécifiée en em.
Ainsi, si votre conteneur n'a pas de largeur définie, l'image prendra toute la largeur, mais s'il en a une, l'image s'adaptera là aussi à la place qui lui est réservée.
Sur mon blog, c'est le cas des images qui flottent à gauche ou à droite de mon contenu, lorsque j'appelle leur format « medium ».
Images vectorielles vs. images matricielles
Le problème que vous allez rencontrer, c'est le zoom des images matricielles (« bitmap ») :
On peut redimensionner une image vectorielle sans perte de qualité, ce qui n'est pas le cas d'une image matricielle.
Dans une intégration en em, on va donc veiller à utiliser SVG dès que nécessaire (avec fallback PNG pour les navigateurs qui ne supportent pas SVG).
Mais ça sera surtout le cas en CSS, car on contribue rarement des images SVG dans le contenu même d'un article. (Moi, je n'illustre mes articles qu'avec des photos, par exemple.)
Dans ce cas, comment gérer le zoom des images matricielles en limitant la perte de qualité ? Sans le savoir, nous avons là une problématique proche de celle des images dites hidpi (ou encore « retina » ou « Super AMOLED Full HD »). Dès qu'on zoome, on modifie la densité de pixels des images5.
Doubler les dimensions des images matricielles ?
Une solution dans l'air du temps consiste à doubler les dimensions d'une image matricielle, puis à l'enregistrer pour le web en qualité très basse. C'est Compressive images du Filament Group (vue aussi chez Daan Jobsis – attention, lien extrêmement lent à charger).
Vous faites ainsi d'une pierre deux coups : non seulement vos images matricielles tiendront la route jusqu'à un niveau de zoom x2 avant de commencer à perdre en qualité, mais vous gérez ainsi aussi l'affichage de votre site sur un écran à haute densité de pixels.
Toute solution comportant des inconvénients, voici ceux que j'ai listés pour cette méthode :
- Sur un blog, on ne dispose pas toujours de toutes les photos en taille double. Cela demande plus de recherches iconographiques, et de faire attention aux formats des images prises par son appareil photo ;
- Safari sur iOS a une limite quant aux dimensions des images affichées6. Si votre image dépasse ces spécifications, elle peut ne pas s'afficher dans cette configuration ;
- Enregistrer une image au double de sa taille en qualité médiocre ne conviendra pas à tous vos clients, en particulier les clients luxe, pour qui l'image a un rôle fondamental. Lorsqu'on utilise l'outil « Enregistrer pour le web » de Photoshop, une qualité 20 va créer des artefacts visuels qui, même s'ils seront atténués voire invisibles lorsque l'image sera affichée sans zoom, risqueront de déplaire aux yeux plus affûtés de certains directeurs artistiques. N'hésitez pas à faire un POC (prototype) avec de vraies images contribuées pour montrer à votre client ce que ça donne avant d'implémenter cette méthode.
Images zoomées : un faux problème
Si vous intégrez un site tout en em et que vous n'utilisez ni SVG ni images deux fois plus grandes (et deux fois moins lourdes) dans vos contenus, vos images vont tout de suite commencer à être pixellisées voire à devenir floues au fur et à mesure que vous allez zoomer.
Je considère que c'est une problématique à la marge : à mes yeux, ce qui compte quand on zoome un site, ce sont les contenus textuels. Ce sont eux qui sont réellement utiles.
Les images, même si elles sont un peu pixellisées, ne sont jamais que de la décoration, dans la majorité des cas7. On peut donc se permettre d'en réduire un peu la qualité, ce n'est pas pour ça que ces images ou votre site deviendront incompréhensibles.
En outre, dans le cas où le site a été automatiquement zoomé à cause d'une taille de police plus grande dans un navigateur précis – par exemple, sur un téléviseur configuré en 24px –, on peut supposer que l'utilisateur sera installé à une distance raisonnable de son périphérique, ce qui limitera là aussi l'impact d'images de légèrement moins bonne qualité qu'à un niveau de zoom 0 dans un navigateur réglé sur 16px, voire sur un périphérique mobile que l'on tient dans la main, et qui se trouve donc à une distance moindre de notre regard qu'une télé.
Lâcher prise (on y revient toujours…)
Il est tentant de se faire plus royaliste que le roi et, une fois qu'on a fourni l'effort d'intégrer un site tout en em, de vouloir que les images elles aussi zooment parfaitement, comme le reste du site, tout en conservant leur qualité initiale. Mais il faut aussi apprendre à lâcher prise.8
Le zoom est un outil que vous développez consciencieusement pour les utilisateurs de votre site : en optant pour un tel niveau de qualité, vous leur apportez spontanément un confort d'utilisation par beaucoup supérieur à celui des sites qui sont intégrés en valeurs fixes, comme le pixel.
En ayant intégré votre site tout en em, vous avez déjà fait énormément de bien au web.
Le zoom est un outil utilisé en connaissance de cause par les utilisateurs : ceux qui modifient la taille par défaut de leur navigateur, voire la taille de police minimale, ont l'habitude que la plupart des sites web s'affichent mal dans ces conditions. (Je vous renvoie aux slides de Nico, en particulier à l'exemple de Cdiscount, slides 5 et 6.)
Ils ne vous lanceront donc pas la première pierre lorsqu'ils constateront – s'ils le constatent ! – que vos images sont légèrement moins précises que dans une configuration qu'ils n'ont de toute façon pas.
Et, je vais vous faire une petite confidence : sur mon site, je n'ai pas mis en place la méthode de Daan Jobsis. :smile: Je pourrais – et je le ferai peut-être lorsque j'aurai résolu tous les autres points que je souhaite améliorer par ailleurs –, mais, pour les raisons évoquées ci-dessus, ce n'est pas une priorité (même si mon site est un portfolio qui mériterait que la qualité d'image soit tout le temps parfaite).
Mon expérience d'intégratrice web m'a appris que la notion de perfection sur le web est une notion ô combien illusoire !9
Ma gestion des images « retina »
En matière de web design responsive, l'outil Adaptive Images est populaire car il permet, pour une image donnée, de la redimensionner pile aux dimensions dont un périphérique a besoin.
Par exemple, si sur un smartphone une image s'affiche en 400x400, et que cette image est appelée sur votre version desktop en 800x800, Adaptive Images la retaille automatiquement en 400x400 sur mobile et en 800x800 sur desktop.
Cela permet de soigner les performances sur mobile, notamment, et de ne pas charger plus d'octets que ce dont on a besoin.
Chez moi, c'est parfois l'inverse qui se produit : certaines de mes images s'affichent en plus grand sur mobile que sur desktop. C'est le cas notamment des miniatures sur ma page d'accueil, dans mon portfolio et dans mon blog.
J'ai donc dû opter pour une autre technique qu'Adaptive Images, sachant, qu'en plus, je voulais assurer un affichage optimal de mon site sur les écrans à haute densité de pixels.
Ainsi, à certains endroits, j'appelle effectivement une image deux fois plus grande que sa taille sur desktop, parce que j'ai besoin qu'elle soit deux fois plus grande sur mobile. Ceci dit, j'ai limité cette technique à des miniatures, pour ne pas forcer le client à charger trop d'images inutilement grandes sur desktop.
Sur mobile, en zoom 0, c'est plus difficile d'accepter que des images soient pixellisées : un utilisateur de mobile consulte le web en tenant son téléphone plus proche de son visage qu'un utilisateur qui le consulte sur son ordinateur ou sur sa télévision.
Il est donc important que les images, sur mobile, soient particulièrement nettes.
Uploader ses images en très grand
La règle d'or, non seulement pour le « retina » mais aussi pour l'évolution de votre site dans le futur, est de toujours uploader vos images de contenu dans la plus grande taille possible, si vous le pouvez.
C'est une règle importante à respecter pour l'avenir : vous ne savez pas quelle tête aura votre site dans cinq ans, vous y afficherez peut-être des images beaucoup plus grandes qu'aujourd'hui. Aussi, pour ne pas avoir à réuploader toutes vos images dans cinq ans, je vous conseille de prendre les devants dès à présent.
Lorsque vous uploadez une image de 2000 pixels de large dans WordPress, cette image va être automatiquement retaillée par WordPress aux dimensions que vous avez spécifiées dans les réglages de votre site et de votre thème. On n'affichage jamais une image à sa taille réelle dans WordPress, justement parce qu'on ne sait pas d'avance quelles vont être ses dimensions.
Dans le cas d'une image affichée en Lightbox, par exemple, je vous recommande d'afficher l'image en taille « large », et pas en « fullsize » pour cette raison.
Il existe plusieurs façons de gérer les images « retina » sur un site WordPress. Moi, je voulais une solution simple, qui fonctionne clés en main et qui ne me demande aucun travail : j'ai opté pour WP Retina 2x, et j'en suis très contente. Ce plugin fait le boulot lors de l'upload de chaque image, et on n'a ensuite plus à s'en soucier.
Autres points que j'ai vérifiés
J'ai passé plus de six mois à intégrer, à désintégrer, à réintégrer mon site. J'ai refait trois fois l'intégration, pas seulement par maniaquerie, mais surtout pour atteindre un haut niveau de qualité.
Outre l'intégration de mon site tout en em, j'ai notamment veillé aux points suivants :
- Vérifier l'affichage de mon site lorsque :
- JavaScript est désactivé ;
- Les images sont désactivées ;
- Les couleurs sont désactivées ;
- Le zoom est agrandi / réduit ;
- Le site est affiché en noir et blanc ;
- Le site est chargé via une connexion bas débit sur mobile.
- Utiliser le moins de JavaScript possible : d'ailleurs, je n'ai finalement pas utilisé de script type « masonry » sur mon portfolio, et ce alors que la maquette graphique s'y prêtait, car tous les calculs de ces scripts sont effectués en em. J'ai opté pour du HTML/CSS aux petits ognions, et, même si l'écriture du template WordPress m'a filé une bonne migraine, je suis bien contente ;
- Vérifier sans cesse les performances, et supprimer tout téléchargement de ressources inutiles ;
- Ne pas utiliser @font-face sur mobile par égard aux faibles bandes passantes et permettre un rendu plus rapide des pages10 ;
- Gérer l'affichage de mon site sous Internet Explorer 7 et moins grâce à cette CSS universelle : proposer une expérience simplifiée, sans design, plutôt qu'un site cassé ou illisible. Comme je le disais, ce qui compte sur un site c'est l'accès universel aux contenus.
Voilà. Je crois que j'ai à peu près fait le tour de tout ce que je voulais vous dire sur la refonte de mon site côté technique. 8-0
Pour rappel, voici tous les articles que j'ai écrits au sujet de la refonte de mon #PortfolioOfDoom, si vous voulez continuer votre lecture :
- Refonte de mon portfolio : positionnement et identité
- Refonte de mon portfolio : créa et design
- Refonte de mon portfolio : WordPress
- Refonte de mon portfolio : du responsive tout en em (première partie)
Merci de m'avoir lue, n'hésitez pas à poser vos questions à la suite des commentaires ! :grin:
- Outline est un framework CSS/PHP maison que Vincent a mis au point comme starter kit pour les intégrations réalisées chez Clever Age, néanmoins le projet est disponible sur Github aussi quiconque peut l'utiliser et y contribuer librement. ↩
- Clever Garden désigne l'équipe UX, web design et intégration web de Clever Age ↩
- Comprendre : une contrainte encore plus forte que d'habitude, vu que nous respectons spontanément la plupart des critères de niveau bronze du label Accessiweb dans nos intégrations. ↩
- Si vous ne connaissez pas encore les magic sprites de Compass, cette documentation est faite pour vous ! ↩
- Si vous ne comprenez pas bien ce qu'est « le retina », lisez cet excellent article sur le sujet (en français) ou regardez cette vidéo (en anglais). ↩
- Voir les spécifications d'Apple à ce sujet, paragraphe « Know iOS Resource Limits ». ↩
- Sauf si le matériau premier du site est l'image – ce qui est le cas d'un portfolio, par exemple. ↩
- Oui, c'est la fille qui a mis deux ans à refaire son portfolio qui vous parle. J'ai fini par apprendre la leçon ! ↩
- À ce sujet, j'avais écrit un article sur Les Intégristes : L'intégration web, cette leçon d'humilité. ↩
- D'ailleurs,
@font-face
est rarement bien utilisé sur mobile : les polices très fines sur du corps de texte, ce n'est jamais une bonne idée sur de petits écrans car c'est très difficile à lire, même quand on a de bons yeux. ↩
21 octobre 2013
Excellent ! Comme je le disais dans mon compte-rendu de la conférence de Nicolas, j'ai rudement envie de tester ça.
Comble du bonheur, tu donnes de grosses clés pour faciliter le travail (notamment les mixins Sass). Merci pour le partage ! :-D
21 octobre 2013
Cool, merci pour ton retour Luc ! :)
21 octobre 2013
Hello,
Encore un super article, merci Marie.
Note : tu ne réserves pas la hauteur pour tes images, donc quand elle se lazy-load, elles décalent le contenu vers le bas...
21 octobre 2013
Oui, en effet… Je n'ai pas encore trouvé de solution pour pallier ça. Comme les images ont un
height: auto
, ce n'est pas évident à gérer.Quelqu'un, quelque part, a sans doute une idée pour corriger ce souci…
21 octobre 2013
Idée pour les hauteurs : parser côté serveur les tailles d'images, mettre un width et un height en dur dans le HTML ? (spip fait comme ça, par exemple…)
21 octobre 2013
WordPress le fait aussi par défaut, mais j'avais supprimé les
width
et lesheight
, pensant que ça aiderait les images à s'adapter quel que soit leur conteneur. Ça ne change rien en fait, donc j'ai rétabli les attributswidth
etheight
.Cela étant dit, comme j'ai besoin que mes images s'adaptent toujours en largeur à leur conteneur (
width: 100%
), je suis obligée de rétablir, en CSS, unheight: auto
, sinon le ratio n'est plus bon.Et c'est là où je coince…
21 octobre 2013
(Ah bin je suis content, grâce à tes articles pendant deux secondes j'ai l'impression d'être un génie.) ;)
21 octobre 2013
Ah ! C'est le double effet Kiss Cool ! ^.^
21 octobre 2013
Bonjour Marie, je pense que ton article est complet quant aux bugs qu'on peut rencontrer sur un design "élastique" (terme utilisé par Vincent). De ton point de vue, penses-tu que ça vaille le coup d'aller jusqu'à ce niveau d'intégration des em?
21 octobre 2013
Bonsoir Gianni,
Définitivement. Cela apporte du confort à tous les utilisateurs de ton site, cela prend soin de son accessibilité, et surtout, c'est une sécurité pour le futur : on ne sait pas quelles seront les nouvelles résolutions et caractéristiques techniques des périphériques de demain.
Tout peut changer : c'est du web ! Je pense donc que miser sur un site « élastique » (moi j'ai l'habitude de dire « proportionnel ») est une assurance pour le court et le moyen terme, non seulement pour nos sites personnels (parce que nous sommes des geeks et que nous ne lésinons pas sur la qualité web), mais aussi pour les sites de nos clients, qu'ils ne refont pas tous les quatre matins, et qui restent souvent plusieurs années en ligne avec la même CSS.
Il est donc important de leur fournir une qualité irréprochable, dans la mesure du possible – et, l'intégration en em, c'est carrément possible : je te parle d'expérience, ça demande une petite adaptation au départ (d'outils, de raisonnement), mais on s'y fait très vite, et quand on repasse ensuite sur de vieilles intégrations en pixels, on prend toute la mesure des bienfaits des valeurs relatives :-)
Donc oui, construire un site sur une base saine et solide avec les em est un très bon investissement, et je te le recommande vivement.
21 octobre 2013
Génial !!
Les articles ont beau être longs, ça reste un vrai régal de lire ce partage d'expérience :D
Et j'ai encore appris quelques détails, notamment pour les background : je vais de ce pas tester certains points. J'ai une question par contre, sur l'utilisation de @font-face par les mobiles : le test est fait uniquement via les media-queries, pour charger ou non les typos ?
21 octobre 2013
Bonsoir Gaël,
Merci, ça me fait plaisir ! Je travaille toujours beaucoup sur mes billets pour que longs ≠ ennuyeux !
Non. J'utilise Web Font Loader pour charger les fichiers typo de façon asynchrone, puis via une media query utilisée via Modernizr, je lance Web Font Loader ou non en fonction du seuil.
Ensuite, j'affecte la bonne
font-family
aux classes CSS générées par Web Font Loader et appliquées sur le DOM :.wf-strangelove-n4-active
et.wf-sueellen-n4-active wf-active
(ce qui correspond aux deux polices que j'utilise avec@font-face
: Sue Elle Francisco et Strangelove).Sur mobile, je réinitialise ces classes-là avec la police par défaut (Courier).
Il y a sans doute une solution plus optimale de faire, ça je ne dis pas. Mais l'essentiel, pour l'instant, c'est que les fichiers typos ne soient pas chargés sur mobile – même si le format WOFF est très léger, ça reste 50 ko d'économisés.
J'espère que ça répond à ta question ! :)
22 octobre 2013
Oui en effet, ça répond bien à ma question :D
C'est un point que je cherche à résoudre depuis un moment et de bêtes media-queries me semblaient tout sauf idéales !
Je vais donc étudier ce mécanisme, merci beaucoup pour cette réponse enrichissante :)
21 octobre 2013
Très bon article dans la lignée des précédents. Ça donne envie de s'y mettre tout de suite !
J'ai une petite interrogation par rapport aux images contribuables (dans le cadre d'une refonte). Cela oblige à réuploader toutes les images aux dimensions les plus grandes afin de pouvoir, ensuite, utiliser les techniques que tu cites ? Si les images sont en 800x600 on doit repasser par un upload non ?
En tout cas c'est du bel ouvrage ton site et j'adore sa vitesse de chargement sur mobile !
Ps: là tout de suite je ne vois pas de solution mais c'est parfois pas simple de cliquer sur les ancres de retour. Exemple sur la note 5, avec mon doigt boudiné je dois bien viser pour pas cliquer sur le lien vidéo qui est juste haut dessus du retour de note (iPhone 3gs)
21 octobre 2013
Salut Olivier !
Merci beaucoup pour ton commentaire, c'est sympa ! :-)
Savoir que mon site se charge à la vitesse de la lumière sur mobile est très satisfaisant, car j'ai beaucoup bossé sur ce point.
Dans l'absolu, non. Cela serait le cas si le commanditaire du site voulait absolument que toutes ses images contribuées soient toutes en parfaite qualité, quelle que soit la densité de pixels de l'écran, ou quels que soient le niveau de zoom et/ou la taille de police par défaut choisis par l'utilisateur.
J'ai du mal à concevoir une telle exigence de la part de nos clients, là où la plupart des intégrateurs eux-mêmes pensent et codent en valeurs fixes…
Toutefois, le « retina » a un peu changé la donne, tout simplement parce que les périphériques à haute densité de pixels commencent à se démocratiser.
Cela étant dit, si le commanditaire du site est réceptif à ce petit défi technique, et qu'il a le temps et les ressources nécessaires pour réuploader toutes ses images, oui, dans l'idéal ça serait mieux…
…Mais c'est largement utopique. À ma petite échelle, je suis loin d'avoir réuploadé toutes les images contenues dans mes billets, ça faisait un boulot trop énorme :-(
Donc je doute qu'à une plus grande échelle, sur un site contenant mille fois plus de photos que le mien (je pense à un catalogue produit), cela soit possible.
Toutefois, parfois les PIM sont remis à jour, notamment lorsque les photos des produits changent de charte. Dans ce cas-là, il devrait pouvoir être possible de conseiller des dimensions d'images x2, a minima.
Faute de quoi, pour une image en 800x600 (pour reprendre ton exemple), si elle doit être affichée en 1600x1200 à cause du zoom ou de la densité de pixels de l'écran, elle sera pixellisée.
Même une solution comme Adaptive Images nécessite que, quelque part sur le serveur, existe une version très grande de chaque image…
OK, je vais essayer d'agrandir la zone focusable :D De même, ça m'encourage à agrandir la taille de typo et l'interlignage par défaut de ma CSS. Merci pour ce retour !
22 octobre 2013
J'aurai deux questions car je m'interroge sur l'utilité et la faisabilité de ces méthodes :
1. Quelle est la part d'utilisateurs sous IE < 9 sur ce site (c'est à dire les navigateurs ne supportant pas l'unité
rem
)2. As-tu tenté de faire un site tout en
em
qui était une application web sur laquelle il y a des itérations fréquentes (un produit vivant, non "livrable") et des intervenants pas forcément spécialistes en intégration ?Merci Marie !
22 octobre 2013
Salut Kaelig !
Je ne peux parler que de mon site, car je n'ai pas accès aux statistiques du site institutionnel que j'ai intégré en em.
Sur mon site, les visites sous IE représentent environ 10% des visites totales, IE8 2,5% et IE7 0,35% (note qu'une seule personne a utilisé IE6, lol).
Donc IE < 9, c'est négligeable, c'est vrai !
Mais, va savoir pourquoi, j'ai encore un petit bloquage psychologique d'abandonner le support de IE8. Ou alors, il faudrait utiliser du rem + du pixels (d'abord définir en pixels, puis en rem ?) – mais dans ce cas, on perdrait la capacité de zoom sous IE8… Je trouve ça un peu dommage.
À l'échelle de mon site, ça ne serait sans doute pas très grave, mais sur un site à forte audience, proposant des fonctionnalités essentielles (je pense aux sites web de nos banques, souvent mal faits d'ailleurs), je me demande quel serait l'impact en terme de confort d'utilisation.
Je pense que plus un site brasse de monde, plus il a besoin d'être accessible.
Non. Par « intervenants pas forcément spécialistes en intégration », tu parles de développeurs ?
Si oui, ils se mettent de plus en plus à Sass et à Compass, sans parler du fait qu'ils sont coutumiers de la ligne de commande. Donc, je pense qu'il est possible de les sensibiliser à l'utilisation de mixins particuliers si d'aventure ils sont amenés à faire des modifs sur le front.
Ça serait bien d'avoir l'avis de Nico Hoizey sur le sujet ! ^.^
22 octobre 2013
Merci !
Pour des petits sites je pense que c'est tout à fait envisageable de tout faire en
em
ou même en pourcentages (GMail le fait, mais leurs choix de design sont drastiques).Pour un gros site avec des modules développés par des intervenants externes qui ne savent pas dans quel contexte sera inséré leur code, alors il est plus sage de se tourner vers les
rem
(avec une dégradation en px). Cela peut aussi compliquer les itérations car le code diffère de l'apparence attendue : un code imprévisible est un code que les devs rechignent à toucher.Le temps passé à rendre le site un poil plus accessible à une minorité d'utilisateurs sur une technologie mourante est d'autant plus de temps qui aurait pu être investi dans la mise en pratique de techniques améliorant l'accessibilité pour le plus grand nombre (je pense à ARIA, à l'accessibilité des formulaires…). C'est pour cela que je suis dubitatif quant à l'utilisation des
em
.22 octobre 2013
Oui, en effet ! Et déjà, en leur demandant de coder en rem, je trouve que tu es bien optimiste… :-)
Là je t'avoue que je ne comprends pas ce que tu veux dire. En quoi le code diffère-t-il de l'apparence attendue ? Je pige pas.
Pas trop convaincue, car parallèlement à l'inté en em, on a passé du temps à mettre en œuvre ARIA, à rendre nos JS encore plus accessibles que d'habitude, etc. Donc on n'a pas « gâché » de temps en faveur des em.
Même si j'ai mis un peu plus de temps à démarrer que sur un projet px/em, cela m'a permis de faire des recherches, de creuser les mixins Compass, d'améliorer mes connaissances en intégration – tout ça ça rejaillira sur mes futures intégrations, quelle que soit l'unité… Donc, définitivement, non, ce n'est pas du temps perdu.
Tu parles de « technologie mourante »… Tu y vas un peu fort ! :-p Le support des em est meilleur que celui de rem, et, en plus, on n'a pas besoin d'alourdir la CSS en doublant toutes les déclarations en rem par la déclaration en pixels équivalente quand on doit encore supporter IE8 et inférieurs, ce qui est le cas apparemment avec les rem.
Car, oui, la compatibilité IE est toujours importante pour la majorité de nos clients.
Tu me diras, rien n'empêche, sans doute, avec Sass, de créer une CSS spéciale IE8 et inférieurs tout en pixels, et une CSS pour les navigateurs modernes tout en rem… Mais, avec les em, pas besoin de se préoccuper de ça ! :-P
Enfin, le calcul de l'héritage ne demande pas de temps particulier avec les mixins, c'est facile et rapide.
Cela dit, j'ai hâte d'utiliser les rem, sans doute sur mon prochain projet perso ! :) Ça me permettra de comparer les deux méthodes.
Tu sais, c'est le même argument qu'on entend depuis des années dès qu'on parle d'accessibilité !… Et pourtant, ça ne nous empêche pas de persévérer et de pousser plus loin la qualité ! Na ! ;-)
22 octobre 2013
Quand je citais les "technologie mourante", je parlais de navigateurs ne supportant pas les
rem
. Désolé, je n'ai pas précisé !Ensuite par rapport à l'imprévisibilité du code par rapport à l'apparence, le souci est que de déplacer un module dans un contexte différent peut lui donner une toute autre apparence. Des ajustements d'espacement (soucis d'arrondis, d'alignement d'icônes…) sont nécessaires à chaque fois. On peut se retrouver très vite avec une codebase impossible à maintenir, et que les développeurs non-experts redoutent de toucher.
J'espère que c'est plus clair.
23 octobre 2013
Merci pour tes précisions, je comprends mieux et je suis d'accord avec toi.
22 octobre 2013
Juste énorme, un concentré de retours d'expérience très pointus.
Ça fait des années que je ne codais plus et ça m'a permis de me conforter dans des points de vue et d'en apprendre pleins d'autres.
Forcément me vient à l'esprit la question du coût. Est-ce que tu saurais en édite de donner une fourchette de temps passer en plus pour produire un site RWD en EM vs un site Rwd en taille fixe ?
Merci et un énorme bravo pour cette série d'articles !
Adrien
22 octobre 2013
Salut Adrien !
Merci beaucoup pour ton commentaire, je suis ravie de t'accueillir par ici !
Nivau CSS :
Niveau JS :
Pour un dév JS, là c'est difficile à estimer, car ça dépend beaucoup des fonctionnalités contenues par le site. Je crois, de tête, que le carousel tout en em développé par Stéphane a dû lui prendre 2-3 jours (tests intensifs au clavier compris).
Il va de soi que toutes les fonctionnalités JS qui manipulent les positions et les dimensions doivent générer des valeur en em… Et inutile de dire que l'écrasante majorité des plugins JS tout prêts génèrent des pixels. Donc prévoir du temps là aussi en fonction des besoins JS, et surtout prévoir un peu de rab pour tester tout ça et être sûr que tout fonctionne bien comme prévu, même si on change la taille de typo, la taille de typo minimale, si on zoome ou on dézoome comme un grand malade… :-)
24 octobre 2013
Adrien : Je rejoins l'avis de Marie : coder en em, c'est une petite gymnastique au début (et encore, on en fait tout un monde, mais c'est franchement pas la mer à boire non plus !), mais une fois l'habitude prise, ça ne change strictement rien.
Je me surprends même parfois à ne plus raisonner qu'en em, genre : tiens il faudrait ajouter un padding à ce box, hop, 1em (ou via les classes .p1 .m1 de RÖCSSTI, pour ne pas le nommer). Du coup, tous les espacements et consorts restent proportionnels selon la typo, agréable pour le responsive et le zoom. Mêmes mes graphistes disent des fois « finalement c'est plus simple et plus logique ».
D'ailleurs, tu vois assez aisément la cohérence de certaines maquettes en fonctionnant ainsi : la meilleure que j'ai eue sur mes derniers projets fonctionnait juste parfaitement en valeurs rondes en em (les margin et padding marchaient pile-poil). Souvent j'intègre très rapidement en em et j'affine avec les valeurs en équivalent-pixel (en em aussi) après, et là j'ai constaté que les valeurs d'em entières étaient déjà parfaites.
La seule différence, c'est si le graphiste veut équilibrer le texte en drapeau, du coup, les padding gauches sont différents des droits, mais c'est pas un problème :)
La seule grosse limite est bien expliquée par Kaelig : si tu as des bouts de code qui viennent de l'extérieur, le côté « dépendant du contexte » des em peut causer quelques soucis. Rien d'insurmontable, mais effectivement, sur des projets complexes, ça peut être gênant.
Ceci dit, sur des projets moins compliqués (avec moins d'intervenants et d'imprévisibilité), cet effet de bord s'encadre très bien. Et avec les pré-processeurs, c'est franchement facile. On en fait toute une mer à boire, c'est jamais qu'un produit en croix quand même !!!
22 octobre 2013
Ha yes ! Merci Marie !!
J'avais trop la flemme de chercher des articles sur le net traitant le sujet alors ton article tombe pile poil !
Tu m'éclaires sur de nombreux points, super !
Demain je teste ;)
Miaourci ♥
22 octobre 2013
Coucou Delphinette !
Tu m'en vois ravie, j'espère que tu me feras part de tes retours, difficultés, questions… N'hésite pas !
Dis donc, je vois sur ton blog que tu fais parfois des vidéos en direct ? C'est quoi c't'histoire ? lol
15 novembre 2013
Hello Marie !
Je suis arrivé sur ton blog suite à la lecture du slideshare.
Ces articles sont vraiment intéressants à lire, même s'ils sont trèèèèèèèèès long, ça se lit trèèèèèèèès bien sans que ce soit lourd, c'est très bien expliqué.
J'aime le fait de comprendre les techniques employées, même lorsque j'emploi un framework. J'ai bien testé foundation qui m'a bien plu, et je testerai outline qui a l'air aussi pas mal.
Salutations ensoleillées de la Martinique !
Mike
16 novembre 2013
Salut Mike !
Ok, super, je suis contente que ces billets t'aient été utiles !
N'hésite pas si tu as des questions. À bientôt !
17 décembre 2013
Salut Marie et merci beaucoup² pour ce retour. Ce billet est l'un des plus utiles que j'ai pu lire cette année.
Est-ce que ce serait une erreur de partir d'une simple variable qui a pour valeur "0.0625em" et de la multiplier par ma valeur en px ?
J'avoue que j'ai un peu de mal à suivre les mixins (je suis pas vraiment aidé, mon cerveau gauche est une gros feignéant).
17 décembre 2013
Salut David !
Merci pour ton commentaire, je suis contente si mon billet t'a été utile !
Cette méthode ne tiendrait pas compte du contexte, qui est pourtant la principale caractéristique d'une intégration en
em
.C'est pour cela que je te recommande d'utiliser le mixin
em()
que j'ai partagé, il est vraiment tout petit et très simple à utiliser ! ;-)Tu y saisis comme premier argument la taille en pixels à atteindre, et en second argument, facultatif, le contexte en pixels dans lequel doit s'effectuer le calcul.
Par exemple :
S'il n'y a pas de contexte particulier, tu peux écrire simplement :
Facile, non ? :)
18 décembre 2013
Salut Marie,
Effectivement, j'ai oublié de penser à l'héritage. :/
Ma variable ne fonctionne que si je suis en rem ou que je ne touche pas au font-size.
Pour ce mixin, il est encore relativement simple à comprendre (C'est l'initialisation qui me posait problème mais c'est rentré dans l'ordre.). C'est avec les backgrounds que ça se complique.
http://giphy.com/gifs/zjQrmdlR9ZCM
Je n'ai pas vraiment poussé mon apprentissage de SASS donc c'est un peu normal en même temps. ^^
Merci pour ta réponse. Y'a plus qu'à mettre ça en pratique.
Passe de bonnes fêtes de fin d'année. :)
9 mai 2014
Salut Marie,
Merci pour ce billet détaillé, j'ai appris pas mal de choses :)
Il me reste une interrogation concernant l'appel des sprites retina dans ton mixin. Comment les gères-tu ?
Dans mes intés, j'utilise le mixin retina-sprite visible sur sur Github. Le bémol de ce mixin est qu'on ne peut pas utiliser d'em.
10 mai 2014
Bonjour à toi, ami de l'accessibilité !
Pour le retina, j'utilise le mixin
hidpi
de Bourbon, couplé aux mixins de Compass pour les sprites magiques.Ce qui donne ça :
C'est très verbeux, sans doute pas optimal, mais après avoir testé des caisses de méthodes retina, c'est la seule que j'aie trouvée qui convenait à mes contraintes, notamment à celle des
em
.Il est sûrement possible de synthétiser tout ça en un énième mixin – mais je n'y suis pas arrivée.
Si tu connais une autre méthode, inutile de dire que cela m'intéresse beaucoup ! :)
11 mai 2014
…Mais aujourd'hui je préfère utiliser des sprites SVG générées avec Grunt (car Compass ne les gère pas).
28 octobre 2014
J'ai trouvé un mixin plus simple et qui à l'avantage de permettre d'utiliser différents dossiers de sprites si on ne veut pas avoir un gros sprite "normal" et un gros sprite retina. Il se trouve ici
En revanche pour faire la conversion en em, c'est un peu plus compliqué ! Je vais tenter de me pencher dessus.
As-tu trouvé un moyen plus light de ton côté ?
7 juillet 2014
Bonjour Marie,
Un article dans lequel je commence à y voir plus clair du pourquoi utiliser les em en dehors des font-size :). Cela dit j'ai une question: les % font également partis des unités relatives, l'utilise tu encore? Et si oui pour quel type d'éléments autres que les images ? Car je suis resté sur le livre de Ethan Marcotte qui recommandait cette unité pour les marges, media queries,... donc je suis un peu perdu. Merci
7 juillet 2014
Bonjour Jojo,
Alors je n'ai plus en tête le bouquin de Marcotte, mais je serais étonnée qu'il conseille d'utiliser l'unité pourcentage dans les media queries. En effet, un écran fait toujours 100% de lui-même… Il peut difficilement en être autrement ;-)
Donc au niveau des unités relatives dans les media queries, tu peux utiliser
em
ourem
: tout dépend du support navigateurs de ton projet car l'unitérem
n'est pas supportée partout.Vu qu'une media query se réfère toujours au
font-size
de l'élément HTML, il n'y a donc pas de contexte particulier à passer, et l'utilisation deem
ou derem
dans ce sens me semble équivalent, hormis cette histoire de support navigateurs.Par ailleurs, oui cela m'arrive toujours d'utiliser des pourcentages, par exemple quand j'ai besoin de créer des layouts fluides (par exemple, un système de 3 colonnes qui font chacune 33.3%, ou de deux colonnes de 50%, ce genre de choses) : je m'en sers beaucoup sur les sites responsive, de fait. Avec du
box-sizing: border-box
, cela fait des miracles.Mais sinon, j'utilise beaucoup
em
. Je me mets àrem
depuis quelques mois, avec un fallback en pixels pour IE8 et moins si nécessaire.Enfin, il faut toujours prendre de la distance avec ce qu'on lit. Ethan Marcotte est bien sûr une référence, mais même s'il recommande d'utiliser telle ou telle chose, cela ne veut pas dire que les autres choses ne doivent plus être utilisées.
Chaque projet a un contexte et des contraintes précis : ce sont donc eux qui doivent te faire faire des choix, et pas ce qu'a dit ou écrit untel ou unetelle :) L'intégration web est une leçon d'humilité permanente, nul n'a la science infuse.
En cas de doute, je penche toujours pour la solution qui rendra le plus service à l'utilisateur.
8 juillet 2014
Déja merci pour ta réponse.
Oups autant pour moi pour les média queries de Ethan Marcotte. Je me suis mal exprimé, je voulais parler des règles css exprimées en % à l'intérieur des règles media queries et pas sur celles-ci mêmes :).
Comme j'ai regardé la conférence sur les em (vraiment top) de Nicolas Hoizey que tu connais bien ;), qui n'avait pas parler des %, cela me posait question et affichait clairement une différence avec ce que j'avais appris jusque là (en l'occurrence le livre de Ethan M. et d'autre ref.) C'est en partie pour cela que j'ai atterri sur ton article et voulait savoir si et comment tu mixais ces deux unités relatives.
Effectivement le fallback avec le rem, est ce que j'utilisais pour la propriété font-size mais maintenant que j'ai compris pourquoi c'était bien d'utiliser cette unité autre que pour la typo. il me reste plus qu'à l'appliquer. La difficulté reste de cerner les contraintes car comme tu le dis on a tendance à suivre des références mais il ne faut pas oublier que notre métier est en constante évolution et remet chaque jour en cause ce que l'on appris hier.
Du coup tu fixes cette font-size 62,5% (par facilité de calcul) ou 100% ?
9 juillet 2014
Salut !
Ni l'un ni l'autre : ça dépend du projet !
Je travaille au moins en 16px sur les nouveaux projets que je designe et que j'intègre, mais il m'arrive aussi d'utiliser du 18px (
font-size:112.5%
).Je définis toujours la
font-size
du body en pourcentage. Ensuite je travaille enem
(et éventuellement enrem
).En tout cas, c'est une mauvaise pratique de réduire la
font-size
par défaut (d'ailleurs, c'est le cas sur mon site, et je me fouette chaque jour à l'ortie fraîche pour faire pénitence).12 juillet 2014
OK merci Marie pour ces nouvelles infos, et l'histoire d'être bien lourd :) j'ai encore 2 questions:
1- Si on travaille sur du 16px pourquoi le préciser dans les balises body (et html),que ce soit n'importe quelle unité: %, em, rem, px... étant donné que c'est la taille par défaut ?
2- Si on le précise, pourquoi mettre des % sur la balise body et pas utiliser le em ou rem+fallback (comme dans mon exemple ci-dessous) ?
http://codepen.io/StudioAnanze/pen/haoKi
13 juillet 2014
Salut Jordane,
C'est la même réponse pour les deux questions : pour obtenir un résultat homogène sur l'ensemble des navigateurs.
Le pourcentage sur la
body
corrige au passage un bug sous IE6 et IE7, notamment pour ce qui concerne le zoom texte. Je te renvoie à l'article How to Size Text in CSS sur A List Apart, qui date de 2007, et qui explique bien tout ça. :)Aujourd'hui, il y a de moins en moins de projets qui doivent supporter IE6 et IE7 (bien que cela existe encore). Il va forcément venir un jour où ces techniques éprouvées évolueront, car on n'aura plus à ce préoccuper de ces dinosaures.
Toutefois, méfiance : la valeur
rem
n'est pas supportée partout.L'intégration est une discipline délicate, aussi je suis d'avis de continuer à utiliser les bonnes vieilles recettes qui fonctionnent partout, en attendant qu'une nouvelle qui aura été abondamment testée partout se révèle plus efficace. If it works, don't fix it!
15 juillet 2014
Une fois de plus Marie merci pour tes réponses :)! Oups tu as découvert mon identité^^, tu devrais peut être faire détective privé à tes heures perdues ;).
15 juillet 2014
Non, j'ai juste vu ton prénom dans ton adresse email (que je vois étant admin) ;)
13 juillet 2016
Salut Marie,
Merci pour ton excellent article très instructif.
J'aimerai me mettre plus sérieusement aux unités relatives, mais je me demandais quelle unité tu recommandes aujourd'hui, em, rem, les deux ?
Sachant que le support d'IE8 se fait de plus en plus rare, et dans mon cas je n'ai pas besoin de supporter ce navigateur.
PS : oui je sais mon message a 2 ans de retard, mais mieux vaut tard que jamais ! :D
13 juillet 2016
Salut Raphaël !
Tout comme toi, cela fait belle lurette que je ne me préoccupe plus d'IE8 (ce qui ne m'empêche pas de pester contre IE9 désormais… et même contre IE10… voire IE11 certains jours… voire même contre Chrome, qui a bien des égard est une sorte de nouvel IE… ^^ #troll).
J'utilise désormais autant du
rem
que duem
dans mes projets. J'essaie autant que possible de privilégier leem
pour les propriétésfont-size
,line-height
,margin
etpadding
, car c'est quand même super pratique pour diminuer ou augmenter d'un coup tout un bloc si besoin.Par exemple, sur mes projets, je change souvent le
font-size
global : s'il est à 20px sur les écrans que j'estime suffisamment grands, je le repasse à 16px sur écran plus petit. Si j'ai bien tout intégré enem
, tout le site se « réduit » automatiquement dès qu'on affiche le site sur un écran plus petit, pas besoin de redéfinir tous lesfont-size
de tous les blocs (chose impossible si on n'utilisait que durem
).Exactement ! \m/ Je suis contente de voir que ce vieux billet peut encore être digne d'intérêt :)
20 juillet 2016
Merci pour ces précisions, c'est parfait !
En réalité, j'ai lu ton article il y a 2 ans, mais n'ayant pas trouvé le courage ou le temps (excuse au choix :D) de m'y mettre, j'avais gardé l'info dans un coin de la tête. ;)
Sur ce, bonne continuation et merci encore pour les conseils !