Comme vous avez pu le remarquer, le redesign de dascritch.net n'a pas consisté qu'en un bête changement de couleurs ou d'éléments de navigations. Aujourd'hui : l'aménagement d'espace.
Historiquement, les pages web sont écrites dans un langage de balise, appelé HTML. Celui-ci dérive du SGML, qui est en fait un système de PréAO comme Microsoft Word, TeX et le DVI. De cet héritage, et avec l'arrivée des CSS, la plupart des webdesigners ont inconsciemment retenu que la largeur de votre texte est considérée comme contrainte, mais que votre page s'allonge indéfiniment verticalement.
C'était sans compter sur l'arrivée des écrans larges dans la bureautique. Les ratios 16/9, 16/10 et autres “écrans cinémas” se sont popularisés par la lecture des DVD (ou des DivX, hein... soyons pas aveugles), et surtout l'impossibilité d'utiliser autrement Excel[1] sur des tableaux très larges.
Rien n'est plus agaçant que de lire des sites prévus pour des largeurs VGAesques[2] à l'heure des écrans de 1300 pixels de large, en format cinémascope... La moitié de votre écran est occupé par du VIDE. Car on est arrivé à un paradoxe : la plupart des sites web sont beaucoup plus long que large, alors que le rapport s'inverse pour les écrans.
Voici donc ce que donne un design élastique (contraint horizontalement, ce que j'appelle “corset”), celui de mon ancien site. Notez le magnifique espace vide des deux côtés.
C'est ce qui a en partie motivé mon redesign de site : j'ai décidé d'abandonner l'aspect “corset” du design élastique. Que diable ! Laissons le lecteur choisir la largeur qu'il veut ! Vive le design liquide !
Voici ce que donnait en design liquide la maquette de mon nouveau site (le texte est issu du même billet) :
Rapidement, je fut confronté à un problème inhérent au design liquide : selon l'étirement de la fenêtre du navigateur, les lignes de texte risquent d'atteindre des longueurs rendant leur lisibilité digne d'un marathon oculaire. Heureusement, en tant que lecteur très fervent des sites des développeurs des navigateurs, j'avais déjà apprécié les tests de mise en colonne.
Dans les discussions en cours autour de la norme CSS 3 a été proposé le concept de la mise en colonne. Une idée que je trouve largement plus intéressante et utile que le multi-background ou l'ombrage de texte, car celle-ci s'attaque directement à la lisibilité et à la mise-en-page, au lieu de se concentrer sur un aspect du décor. Sans toucher au HTML, le navigateur décide tout seul quand les colonnes doivent apparaître et où les césures doivent être faites. Il s'agit encore d'un brouillon de norme, mais les développeurs en pointe l'ont déjà intégré dans leurs navigateurs.
Qu'elles sont pratiques ces colonnes ! Même primitives dans leur implémentation (nous n'avons pas encore le choix entre le style Dorique, Ionique ou Corinthienne), elles évitent de rendre la lecture essoufflante pour les muscles longitudinaux des globes oculaires, harassés par une suite de courses de fond 1500 pixels-haies, au point que le regard se perd dans des colonnes de une à deux lignes...
J'avais le choix entre un nombre fixe de colonnes, ou un nombre variable. J'ai opté pour cette dernière possibilité, avec une largeur minimale, arbitrairement 540 pixels. Pourquoi 540px ? Tout simplement parce que c'était le gabarit largeur de mes articles dans mon précédent design, et la plus grande largeur des images incluses dans le texte de mes billets (je ne compte pas les images lightboxées).
Étant donné que j'ai fixé la largeur de ma sidebar à 220 pixels, la largeur minimale de mon site (pour laquelle il se comporte à nouveau comme design élastique) est de 760 pixels[3]. Et la largeur minimale du viewport où apparaissent les colonnes, de 220 (sidebar)+540×2(colonnes)+10=1310 pixels.
Mais à quoi correspondent ces 10 pixels ? À l'espace inter-colonnes (en anglais : gap), actuellement vide, voire occupée par un trait vertical (en anglais : ruler) dans les navigateurs supportant cette fonction. Car il faut bien évidemment penser à séparer suffisamment les colonnes pour éviter que le texte ne se mélange. Or, et on sent que l'on est encore dans un brouillon de norme, tout le monde n'est pas encore exactement d'accord sur les comportement des règles entre colonnes.
Si elles sont fichtrement bien pratique, ces colonnes ne sont pas encore la panacée. Parmi les inconvénients, je note :
- L'impossibilité de faire couvrir plusieurs colonnes par un élément flottant ;
- L'impossibilité de limiter la taille verticale au viewport. Le lecteur doit remonter en haut de page après avoir atteint le bas de colonne ;
- L'impossibilité d'aligner un texte verticalement par CSS. Le seul moyen existant actuellement est de recourir aux tableaux, urk...
- Et les liquides étant incompressibles, le volume de texte reste constant, une très grande largeur réduit la longueur occupée, ce qui peut créer un vide en bas d'écran.
En attendant que ces propriétés soient enfin fixées, les navigateurs les ayant implémentées (Firefox version 1.5+ et Safari 3+) n'utilisent pas la syntaxe préconisée, mais préfixées par leur balisage “expérimental”[5] . Donc toute propriété column
doit être répétée deux fois : par -moz-column
et -webkit-column
. Et comme personne ne semble avoir implémenté le page-break
, seule méthode CSS pour indiquer qu'un élément ne supporte pas d'être étalé entre plusieurs pages/colonnes, on a droit à quelques erreurs, surtout visibles dans les listes de billets.
Va falloir que je fasse du lobbying auprès de Daniel Glazman à ce sujet, puisqu'il fait partie du comité d'étude...
En résumé, oui, les colonnes ça fait très prétentieux comme façade de votre site pavillonnaire, mais comme ça rend jaloux le voisin, moi je m'en prive pas.
Ces captures d'écrans n'auraient été possibles sans l'assistance technique de Vric et son fantastique écran 1600×1200. Ne reproduisez pas ces cascades chez vous si vous n'avez pas un écran 25”...
Pour les webmestres qui ne jurent que par les maîtres : un article d'A List Apart, qui étonnement site exactement les mêmes références.
Notes de bas de page :
NB 1 : Ouvrez votre tableur payant favori, faites de très larges colonnes, puis faites glisser l'ascenseur de défilement horizontal... À noter que le tableur d'OpenOffice dans sa version 2.0 a lui aussi adopté l'impossibilité de ne voir qu'une portion de colonne à gauche, rendant la navigation dans un grand tableur très pénible si votre écran fait une taille “raisonnable” pour des travaux de secrétariat.
NB 2 : La norme d'affichage VGA a été créée en 1987. La Haute Résolution professionnelle de l'époque y autorisait un affichage de 640 pixels de large (comme le CGA, l'Atari ST et l'Amiga) pour 480 de haut, offrant enfin au PC des pixels carrés. Certains sites limitent encore leur largeur pour être intégralement affiché dans ces 640px. La plupart sont passés aux 800px voire au 1024, courant le risque d'avoir une barre de défilement horizontale sur des écrans de 800 pixels de large. Soit tout de même 1% des web-surfeurs, frange nettement plus significative que ceux qui vont sur les sites WAP si coûteux à développer.
NB 3 : Soit la largeur d'un écran 800 par 600 pixels. Actuellement la plus petite taille significative dans mes stats de visite, mais surtout la résolution de mon écran de secours quand mon PC est squatté !
NB 4 : Cliquer sur un des articles de l'International Herald Tribune, puis dans la boite de présentation, cliquer sur mode «3-Column Format».
NB 5 : Notez que ces andouilles de Microsoft oublient de mettre un “-
” en préfixe de leur balises CSS “expérimentalement” propriétaires, commençant illico par “mso-
”. De toutes façons, on s'en fout, ils ont le CSS2 à apprendre avant de passer aux colonnes du CSS3.. Encore du Microsoft-bashing, c'est le troisième dans ce billet... J'avoue que c'est pas très sain, mais depuis six mois, j'en bave tellement avec Internet Explorer que je n'ai pas trop envie d'être tendre.
IE7 ne connaît pas les colonnes. IE8 ne sera probablement pas CSS 3-aware ; et étant donné le taux moyen de mise-à-jour des navigateurs Microsoft par leurs utilisateurs (comparé aux Maqueux et aux Firefoxistes), on aura très longtemps des MSIE aveugles aux colonnes.
5 réactions
1 De Nono - 09/08/2007, 01:00
Effectivement, le mode trois colonnes de l'IHT est vraiment agréable (mais je "justifierai" le texte, quitte à le passer sur deux colonnes seulement, goût perso). Par contre, si on veut utiliser des images plus larges qu'une colonne... problème.
A mort le design fluide! (comme sur mon blog, par exemple, hum hum...)
2 De Da Scritch - 11/08/2007, 10:15
À propos du problème des très grandes résolutions, je vous conseile la lecture de cet article : http://www.codinghorror.com/blog/ar... “The Large Display Paradox”
Morceaux choisis :
« because [small monitors] are small, they nudge users into a simpler, windowless method of working »
[...]
« You don't often want to maximise a folder or document window on a screen this big; either you'll end up with a lot of white space and important program buttons separated by a vast expanse of nothing, or you'll get lines of text 300 or more characters long, which are difficult to read. »
J'adore l'idée du grid-move : déplacer la fenêtre avec le bouton du milieu la contraindrait en zones pré-définies. Me manque encore un 25” pour en vérifier la praticité...
3 De da scritch net works - 11/12/2008, 16:55
Microsoft Internet Explorer ou l'inflation dans la
Je ne sais pas comment ils font. Malgré tous leurs efforts pour rendre leur navigateur acceptable, ils arrivent à faire en sorte de devoir reprendre tous les anciens sites pour qu'ils fonctionnent comme avant....
4 De da scritch net works - 19/03/2009, 08:56
Quand les lunettes Javascript peuvent être génantes pour
Je me retrouve bloqué dans la recherche d'une dégradation élégante inversée pour implémenter l'attribut , et il ne me reste qu'une solution, la plus extrême : faire appel à mes lecteurs. Du joyeux bordel...
5 De da scritch net works - 21/03/2010, 23:41
Propriétés en tests et préfixes de vendeurs
De leur histoire, leurs usages, leurs inconvénients et de ma petite contribution à solutionner le problème....