The @Mapbox sprite on my photo site weights 222 kB:
nicolas-hoizey.photo/ui/thumbn

I would like to serve it with @cloudinary to enhance performance, as this PNG sprite will fast get heavier with new photos.

If you agree, please vote! github.com/mapbox/mapbox-gl-js

nho.link/n/2022/01/07/1/

@nhoizey rien à voir mais j'en profite un peu, j'aimerais bien savoir comment tu as choisi les tailles (360w, 884w, 1407w, 1930w, 2454w, 2977w, 3500w) sur le détail de tes photos (par exemple nicolas-hoizey.photo/galleries ) et aussi à quoi te sert `sizes="(min-width: 60rem) calc(100vw - 2 * 1rem - 9rem - 2vw - 2 * 2.744rem), calc(100vw - 2rem)"` ?

#view-source

@dav sur le choix des dimensions dans `srcset`, j'ai fait des confs pour expliquer qu'on fait ça mal, commencé à développé un outil il y a plus de 3 ans… mais pas encore abouti… 😅

@nhoizey merci pour ta réponse, ça fait quelques jours que je suis dessus et c'est vraiment un sujet complexe 😱

De ce que je comprends, quand tu mets `width="3500" height="2333"` sur le tag `<img>` c'est pour gérer le cas le plus grand alors que le `src` contient une image de 800px ? J'aurais pensé qu'il fallait mettre les dimensions de l'image de fallback dans ce cas là mais peut-être que le navigateur ne s'en sort pas ensuite ? 🤔

@dav du coup, ces déclarations dans le HTML sont complètement équivalentes :

width="3500" height="2300"
width="1750" height="1150"
width="35" height="23"

@nhoizey oh 😮 d'accord je comprends mieux merci beaucoup 🙇

@dav pour compléter, sur mon site photo, c'est vraiment pas classique, j'ai voulu que la photo soit intégralement visible sans scroll au chargement de la page, du coup j'ai des calculs pas simples à comprendre sans explication :

github.com/nhoizey/nicolas-hoi

😅

@nhoizey ah oui 😱

J'aimerais éviter de faire trop de calculs en CSS, notamment car ça vient ensuite impacter ce qu'il y a dans `sizes` (fort couplage…)

Là par exemple j'essaye d'appliquer sylvaindurand.org/masonry-phot _mais_ ça veut dire prendre en compte des `.gallery div:nth-child(8n+1)` pour savoir quelle est la dimension d'affichage réelle, ce qui devient du pur cauchemar 🙃

@dav dans ce masonry, il triche avec un `object-fit: cover;` pour que la largeur affichée soit fluide, alors que l'image réelle reste de même dimension puisque la hauteur est fixe.

J'avoue que je n'aime pas trop cet effet, j'aime que mes photos soient « entières ».

J'attends l'implémentation native de masonry pour peut-être m'y mettre.

En attendant, il est possible d'utiliser l'algo de Flickr : github.com/flickr/justified-la
(je me demande si @edasfr n'avait pas essayé récemment)

@nhoizey @dav j'ai plusieurs billets sur mes essais de composition de pages photos. Je dois en avoir un sur le layout historique de Flickr, oui. Il est assez basique mais fonctionne très bien si on ne cherche pas à mettre des images en portrait et qu'on accepte d'avoir des lignes pas trop hautes.

J'ai fini avec un truc plus complexe (parce que dès que je n'ai pas de deadline je finis toujours avec des trucs méga complexes)

@nhoizey @dav et n.survol.fr/n/encore-des-agenc pour ce que je fais aujourd'hui sur les pages de galeries (que j'ai complexifié un peu depuis)

Sinon pour les pages photos plein écran j'ai des calculs qui ressemblent aux tiens mais je crois que j'ai un résultat moins complexe.

Pour les srcset le hint donné au navigateur est une approximation qui au pire donne une taille par excès. Ça me suffit

Follow

@nhoizey @dav que ce soit pour ce que je fais ou pour Flickr, c'est jouable sans JS. Tu determines une taille arbitraire côté serveur et ensuite tu définis tout en % ensuite dans le code HTML/CSS.

Il y a même moyen de faire 2 layouts (un sur une colonne pour le mobile et un en maçonnerie pour les écrans larges) et basculer entre les deux via media query. Ça fait envoyer pas mal de CSS dans la page mais c'est jouable sans JS

@edasfr @nhoizey je n'ai aucun JS sur la page pour le moment, le HTML ressemble à dpaste.org/eCop et pour la CSS de la liste je réutilise sylvaindurand.org/masonry-phot

@dav donc tes images sont parfois croppées quand le viewport diminue ?
@edasfr

@nhoizey oui en partie dans la liste de navigation mais je crois que je peux vivre avec (et j'aime bien l'idée que le rendu puisse être assez différent en fonction des résolutions, il y a un côté lâcher-prise et donc créatif sous certains aspects 😉) @edasfr

@dav @edasfr ce type de présentation horizontale fluide complique la valeur de `sizes` d’ailleurs.

@edasfr mais du coup ta hauteur de ligne diminue en proportion de la diminution du viewport ?
@dav

@nhoizey @dav oui, jusqu'au point de rupture où je décide de basculer sur un autre layout precalculé avec un autre paramètre (aujourd'hui je n'en ai que trois, le standard, la vue mobile sur 1 colonne, et un megasuperextra large, mais si tu pars sur de la maçonnerie tu peux faire autant de variation que tu veux)

@edasfr ok, on est d'accord.

Vivement la maçonnerie native, quand même… 😄

@dav

@nhoizey @dav ou simplement accepter d'utiliser du JS aussi. Ce n'est pas grave le JS tant qu'il y a une version HTML potable par défaut

@nhoizey @dav d'autant que la maçonnerie a aussi ses défauts, si tu as des images en portrait ce n'est pas toujours top

@edasfr oui, les portraits posent problème en maçonnerie horizontale, et les paysages en maçonnerie verticale… 😅

Le dense packing de Grid est pas mal en fait : codepen.io/rachelandrew/pen/Gv

@dav

@edasfr le maçonnerie natif pourrait peut-être permettre un mode en colonne, mais avec les images en paysage qui en prennent 2 :
smashingmagazine.com/native-cs

Mais il me semble que ça laissera nécessairement des trous. 🤔

@dav

@nhoizey @dav tu peux le gérer dans une certaine mesure si tu acceptes de faire varier l'ordre, en plaçant les verticales à l'extérieur. Ça permet d'éviter les trous mais ça ne fonctionne que pour un nombre d'images verticales limitées (même si théoriquement tu peux quand même empiler tant que les plus hautes sont à l'extérieur et les moins hautes à l'intérieur).

L'algo existe, je l'avais dans un coin, mais je ne l'ai vu implémenté nulle part

@edasfr avec ça, tu aurais vraiment aucun trou, du tout ?
@dav

@nhoizey @dav oui, en gros quand tu as une verticale, tu la places sur le bord de la première ligne vide qui arrives et tu places les lignes suivantes sur la portion d'écran qui reste : n.survol.fr/wp-content/uploads

@nhoizey @dav et ensuite tu réutilise l'algo de base pour faire finir tes lignes et ton image verticale à la même hauteur, et tu reprends en pleine largeur après

@nhoizey L'idée de ce genre de mise en page étant d'apporter un aspect bigarré, bariolé, pour flatter l’œil, un algo peut-il alors être moins fortiche mais avoir l'intelligence de combler les trous (ou d'en faire délibérément) en aplat de couleur ?
Parce qu'il n'y a pas nécessité de tout remplir avec des photos finalement. La technique fait un peu oublier l'objectif de ces mises en écran. @edasfr @dav

@emmanuelc tu peux effectivement provoquer toi-même des « vides », mais l’idée des algo « maçonnerie » est pour moi au contraire de remplir le plus possible. C’est moins simple.

@edasfr @dav

@nhoizey @dav honnêtement après beaucoup de jus de cerveau je suis arrivé à "aucun algorithme systématique n'est parfait, même si tu peux parfois compenser les défauts par des mises en avant spécifiques".

Le mien finit par faire des combinaison en comptant l'espace pris par chaque photo et calcule un score à chaque combinaison

@edasfr je préfère ajouter une unique propriété plutôt que du JS, mais oui, ça reste possible.

@dav

Sign in to participate in the conversation
La Quadrature du Net - Mastodon - Media Fédéré

Mamot.fr est une serveur Mastodon francophone, géré par La Quadrature du Net.