Pas mal de boulot pour faire évoluer Flip-Zone (#SPIP, #HTML5, #responsive…) :
►http://www.flip-zone.com
Le premier but est de faire une page d’accueil avec un immense image, façon « plein écran » (particulièrement spectaculaire sur une grande tablette…) :
Il y a plusieurs aspects techniques intéressants, ici.
(1) D’abord ce n’est pas réellement plein écran, comme j’ai pu le faire sur certains sites : c’est simplement qu’il y a deux proportions d’images. Une version horizontale si l’écran est horizontal, et une version verticale si l’écran est vertical.
Quand j’essaie de réellement « remplir » l’écran lui-même, il y a plusieurs problèmes :
A. Ça me fait des maquettes aux proportions aberrantes, avec ces gens sur PC aux écrans très horizontaux, la barre de menu au dessus, et des saloperies qui font qu’au final, on doit calculer une maquette en 1365x300 pixels…
B. Techniquement, l’image qui s’affiche là-dedans à des dimensions inconnues, et donc je ne peux pas choisir l’image par feuille de style, mais en attendant que Javascript démarre après le rendu du DOM. Donc pas de <picture>, ce qui est très problématique désormais.
Du coup, cette version propose différentes tailles d’images, de résolutions (écran Retina), et de proportions (horizontal, vertical) en fonction sur support, et dont les dimensions sont directement connues avant même l’affichage de la page ; donc accessibles en CSS et media queries, donc nativement avec la balise <picture>. La grande image de Une est donc directement gérée par une seule balise dans un gros <picture>. C’est donc fait avec mon #plugin Image responsive :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
La grosse particularité de cette page, c’est d’avoir un effet de profondeur, avec le mannequin qui se « détache » du fond, avec en dessous le logo Flip-Zone qui apparaît. Certes j’ai bien un PNG dans l’espace privé avec le mannequin détouré, mais ce n’est surtout pas ce que j’affiche sur le site public (avec des images de cette taille, un tel PNG ferait un fichier monstrueux). Ce que j’affiche, c’est exactement le JPEG déjà utilisé « en dessous », mais avec un masque de détourage qui est une image en niveaux de gris (calculée rapidement en PHP à partir de la couche alpha du fichier PNG). Et pour réussir à afficher une image JPEG avec un masque de détourage dans le HTML, je fais un petit montage en SVG. (De fait, au lieu d’utiliser un JPEG de fond plus un gros PNG par dessus, j’utilise le JPEG de fond, je réutilise le même fichier JPEG par dessus, en le détourant avec un JPEG en niveaux de gris de taille réduite.)
Ce qui amène à une autre difficulté : il faut que cette <image> dans le SVG soit elle-même responsive (la même que le <picture> de l’image de fond), ce qui n’est pas possible directement (même avec des CSS, je n’ai pas réussi à contrôler l’image qui s’affiche à cet endroit). Solution : je fais le <image> du SVG avec rien.gif et j’y insère en Javascript le résultat de ce qui s’affiche dans le <picture>. De cette façon c’est la <picture> nativement responsive qui gère le choix du bon fichier. J’ai abordé ça ici :
▻http://seenthis.net/messages/479467
Et la méthode pour aller chercher le currentSrc de l’image responsive :
▻http://seenthis.net/messages/470853
Même topo, en fait, pour l’image du masque de détourage en niveau de gris, c’est récupéré d’un <picture> (que je cache). Astuce ici : l’image du masque est deux fois plus petite que l’image affichée, parce que je n’ai pas besoin d’être ultra-précis à cet endroit.
Et la dernière difficulté avec ce SVG, c’est que je ne peux pas changer dynamiquement ses proportions (fixées par la viewBox). Solution pour l’instant : il y a deux SVG dans la page à cet endroit : une avec les proportions horizontales et une avec les proportions verticales, et leur affichage est contrôlé par média queries. En dehors du « texte » des balises du SVG surnuméraire, ça ne pèse pas plus lourd, puisque de toute façon c’est le même contenu (tiré des <picture> ailleurs dans la page) qui y est inséré dynamiquement), la seule différence étant la viewBox « en dur » des deux SVG…
(2) Auparavant l’aspect responsive des menus supérieurs était géré de deux façons :
– sur un écran pas trop étroit (petite tablette), les derniers éléments à droite (ceux qui « dépassent » de l’écran) étaient placés dans un petit menu déroulant ;
– sur tout petit écran, remplacement par un menu hamburger et une navigation « cachée » dans un slider à gauche de l’écran.
C’est désormais remplacé par un menu horizontal qui dépasse (si nécessaire) de l’écran, et qu’on peut scroller automatiquement horizontalement. On verra bien si c’est efficace.
Ah, un gain notable : comme je n’ai plus de gestion d’un menu « hors page » avec décalage complet de la page « vers la gauche », je n’ai plus besoin de placer toute la partie scrollable de la page dans un élément spécifique (en scroll:auto) alors que le body n’était plus scrollable. Mine de rien, ça provoquait parfois des bugs d’affichage lors du scroll (notamment sur pages longues, notamment sur Safari). Là je reviens à un très traditionnel scroll sur le <body> de la page, et je n’ai plus ces bugs bizarres au scroll.
(3) Dans la précédente version de la page d’accueil, le but était d’avoir une page très courte. Mais ça ne semble plus trop la mode (les magazines font des pages d’accueil à scroll quasi-infini), et surtout parce qu’on veut mettre en avant le fait qu’il y a des articles désormais (en anglais essentiellement), le choix est désormais inverse, avec une page très longue.
En revanche, calculs amusants (dans les boucles SPIP) pour alterner les articles (un article de temps en temps) et les collections de photos (parfois plusieurs par jour). Et essayer de conserver une certaine construction logique pour les photos (par Couture/Prêt à porter/Mariage…, et par saisons…).
Pour le poids, une possibilité était de charger la longue page (sous la grande image) en "ajaxload" (on charge la page avec juste le haut, et dans un deuxième temps on lance le chargement du bas de page). En pratique ça donne des résultats très désagréables, notamment quand on fait « back » vers la page d’accueil (on perd le positionnement dans la longue page). De la même façon, mon plugin d’images responsives permet de les gérer en lazy load, mais ça ne me semble plus utile : ça bloque le preloader et ça fait un effet désagréable quand on revient sur la page déjà en cache.
En pratique, j’ai l’impression que les navigateurs récents se débrouillent très bien tous seuls pour gérer les chargements et la mémoire si on utilise directement la balise <picture>.
Faudra voir à l’usage.
(4) La construction de la liste essaie de grouper les collections de photos de manière logique, notamment par saisons (genre : « Printemps-été Automne-hiver 2016-2017 ») :
Cette partie a un peu les mêmes principes que le haut de page : effet de « transparence » sur une partie détourée d’une image, géré via un morceau de SVG qui évite de balancer un PNG ; et slider horizontal automatique pour le responsive.
Ah, je n’ai pas évoqué comment faire des liens qui s’affichent « en dessous », mais tout de même cliquables (et qui apparaissent au survol ou au clic). Et ça se gère directement en CSS sans Javascript. C’est un vieux truc que j’utilise depuis longtemps : il y a en réalité deux fois le même contenu, parfaitement superposés (par exemple l’ensemble des vignettes, ou le menu de navigation supérieur…). Et la version du dessus est masquée, et n’apparaît qu’au survol (ou au clic). L’« astuce » importante est que l’élément est masqué uniquement en avec opacity:0, et devient visible avec opacity:1 ; si on jour avec display, ça ne fonctionne plus correctement en tactile, puisque le premier clic sera intercepté pour faire le changement d’affichage (alors que le changement d’opacité se fait sans désactiver le touch).
(4) Des petits effets de pseudo 3D :
Au survol de certains éléments (les liens vers les vidéos), il y a un effet de surgissement 3D avec une petite animation. Ce qui est marrant, c’est qu’il n’y a rigoureusement aucun Javascript pour gérer ça, c’est purement CSS.
J’aurais pu systématiser ces effets, mais ça oblige tout de même à recourir à mon « truc » de masque de détourage en SVG, un peu lourd, puisqu’il faut tout de même une seconde image (le masque en niveau de gris) pour chaque. Et puis graphiquement ça aurait un peu tourné au cirque, et j’essayais plutôt d’introduire de la variété dans cette longue liste.
(5) Ça devrait fonctionner presque entièrement sans Javascript et directement au chargement de la page en CSS, y compris les diverses petites animations de survol. Avec les progrès des navigateurs, à l’affichage ultra-fluide, les pré-loaders, etc., c’est devenu très important d’avoir la page entièrement construite dès le premier affichage, sans calculs Javascript. L’effet de « fluidité » est vraiment important. (Tu me diras que ça a toujours été important, mais a. on ne pouvait pas toujours faire autrement, b. les progrès de fluidité d’affichage des navigateurs rendent les pages « pas très fluides » vraiment perceptibles).
(6) Un peu partout (notamment en énorme sur le haut de page), j’ai le logo Flip-Zone qui apparaît et qui change de couleur en fonction de l’environnement. Auparavant je faisais autant de fichiers graphiques (PNG) que nécessaire. Maintenant c’est du SVG directement intégré dans le DOM, et colorisé par feuille de style. C’est une astuce que j’utilise de plus en plus fréquemment (ça permet notamment de changer la couleur d’une icone non seulement en fonction du contexte, mais tout bêtement au survol d’un lien hypertexte).
(7) Sinon, ce n’est pas totalement nouveau, mais les pages des « articles longs » sont pas mal (encore une fois, c’est du SPIP), notamment avec ses images installées sur une même ligne, plus large que la colonne de texte, et positionnées de manière responsive :
►http://www.flip-zone.com/Caftan-silhouettes
Celle-ci est plus marrante, parce que l’effet de « lignes » fonctionne avec un mélange d’images et de vidéos, et l’image finale en fond d’écran (tout en bas de page) :
►http://www.flip-zone.com/Nicolas-Jebran-5957
