Meilleure façon d'entrer les dimensions d'une image .svg

Bonjour,

Cette discussion fait suite à ce sujet.

Maintenant que grâce à l'attribut viewBox je connais les dimensions de mon image .svg.

Pour la redimensionner par la feuille de type, quelle est la meilleure façon ?

width : 150px
height : 50.2156482px

ou

width : 150px
height : auto

Je sais que les deux marchent mais y a-t-il une différence en terme de performances ?

Et cela sert-il de doubler la déclaration dans le CSS par des attributs dans le code html ?

<img src="image.svg" width="150" height="51" alt="" />

À ce propos, je ne sais pas si la déclaration par le code html demande un redimensionnement de l'image ou la réservation d'un espace dans lequel l'image est contrainte.
Dans le deuxième cas on peut penser que cela est complémentaire du code .CSS et aide le navigateur à aller vite sans se fatiguer, ce qui est le but recherché.

Merci d'avance.

Bonjour Raphaël,

Merci de ton suivi.

Raphael a écrit :
La meilleure pratique demeure toujours d'indiquer les dimensions des assets dès le HTML afin que le navigateur réserve la place, connaisse le ratio d'affichage de l'image avant même d'avoir téléchargé la ressource.

D'accord mais le cas d'une image .svg (vectorielle) n'est-il pas particulier ?

Mon inquiétude concerne les décimales.

Admettons que la taille réelle de l'image soit :

width : 150px
height : 50.2156482px

L'attribut html n'accepte ni les décimales, ni la valeur auto (sauf erreur).
Je suis donc obligé d'arrondir :
height = "50"
Accessoirement faut-il arrondir plutôt à l'entier supérieur : 51 ?

Et le navigateur va devoir dimensionner une image vectorielle avec des valeurs légèrement fausses, ce qui me semble problématique.

Par la feuille de style ru peux au moins indiquer des valeurs exactes.

Par ailleurs est-il possible de ménager la chèvre et le choux ?

boteha_2 a écrit :
Je ne sais pas si la déclaration par le code html demande un redimensionnement de l'image ou la réservation d'un espace dans lequel l'image est contrainte.
Dans le deuxième cas on peut penser que cela est complémentaire du code .CSS et aide le navigateur à aller vite sans se fatiguer, ce qui est le but recherché.

Salut,

Raphael a écrit :
Hello,

La meilleure pratique demeure toujours d'indiquer les dimensions des assets dès le HTML afin que le navigateur réserve la place, connaisse le ratio d'affichage de l'image avant même d'avoir téléchargé la ressource.

+1

@boteha_2: Je t'invite à lire cet article : qu’est-ce que le Cumulative Layout Shift (CLS) (pratique de la famille de la web perfs )

De mémoire, une dimension décimale en pixel sera arrondie au chiffre supérieur.

edit:
Si tu t'intéresses à la web perf, la plupart du temps, il faudra que tu utilises les outils de développement qui sont dans le navigateur (ces outils ne sont que des indicateurs et peuvent être trompés et te tromper) :
- lighthouse (équivalent à page speed)
- réseaux (nombre de requêtes ainsi que le détail.)
- performance

En avant pour les acronymes de la web perfs... :

** TTFB : time to first byte (c'est le temps de retour de la requête et que le premier octets soit chargé ). Tu peux le vérifier dans l'onglet réseau au niveau du document. Il est à noter que le TTFB est principalement à optimiser côté serveur (gzip, cdn, protocole http, etc.).
** FCP : first contentful paint (c'est le temps du premier élément qui s'affiche à l'écran (text/image/video/etc.). Ce qui veut dire : attention au poids du html et des ressources bloquantes (les fonts par exemple, images, video, css, js). Il y a quelques bonnes techniques pour optimiser le FCP (exemple : le critical css). Tu peux le vérifier dans l'onglet perfomance
** LCP:largest contentful paint (ça va mesurer l'élément le plus large de la page). Le but derrière cette mesure est que l'utlisateur ait l'élément de l'information qu'il recherche le plus rapidement possible. Prenons le cas où tu as un header et un footer qui prennent la largeur de la page, mais que le contenu même s'affiche plus tard.... Tu peux le vérifier dans l'onglet performance. Aussi, cette métrique n'esrt pas aussi fiable et peu importante (sauf cas extrême bien sûr)
** TTI : time to interactive (c'est le moment où l'utilisateur peut agir avec la page : cliquer, scroller, saisir un form, etc.). Quand tu utlises des technos serveur comme Python, Java, PHP, Ruby, etc. Il est très rare d'avoir des soucis puisque ces technos donnent le rendu de la page dans son intégralité. Par contre, quand tu utilises des technos JS comme Angular, React, Svelte, Vues, Next, Nuxt, SvelteKit, etc. c'est bien quelque chose à prendre en compte surtout si tu affiches en stream le contenu (Youtube est un bel exemple). Tu peux le vérifier dans l'onglet performance.
** CLS : Cumulative Layout Shift (le lien de l'article partagé plus haut). Tu peux le vérifier dans l'onglet performance.
** PWA : progressive web app. Je te renvoie sur l'intro que wikipedia fait sur le sujet. Ce sujet est assez long et intéressant (cache, optimisation, etc.).
Modifié par niuxe (14 Aug 2023 - 23:21)

Bonjour niuxe,

Merci pour toutes ces infos et liens très utiles.

Une expérience perso sur une image .svg assez complexe semble monter que dans le code html il faut arrondir à l'entier supérieur (fonction ceil en PHP) et non à l'entier le plus proche (fonction round en PHP). 50,002 devient 51, pas 50.
L'image s'affiche plus vite.

Par contre vous ne répondez pas à ma question théorique.

En priorité, on indique les dimensions dans le code html en arrondissant à l'entier supérieur, d'accord.
Cela étant fait, indiquer les dimensions exactes AVEC décimales dans le code CSS est-il ?
a) Utile.
b) Inutile mais pas nuisible
c) Nuisible

J'ai cherché un peu sans trouver de réponse, ni même la question ainsi posée.
Modifié par boteha_2 (15 Aug 2023 - 12:14)

boteha_2 a écrit :
Cela étant fait, indiquer les dimensions exactes AVEC décimales dans le code CSS est-il ?
a) Utile.
b) Inutile mais pas nuisible
c) Nuisible

b => Totalement inutile. Je n'irais pas jusqu'à dire que c'est nuisible, on alourdira juste la page avec un peu de code CSS qui ne sert à rien, c'est tout.

Olivier C a écrit :
b => Totalement inutile. Je n'irais pas jusqu'à dire que c'est nuisible, on alourdira juste la page avec un peu de code CSS qui ne sert à rien, c'est tout.

Bon d'accord, je le note.

Je n'aurais pas posé la question pour une image .jpg ou autre non-vectorielle.

Pour une image vectorielle, je ne sais pas comment procède le navigateur pour le redimensionnement.
Mais s'il recalcule les vecteurs, je me demandais s'il ne valait pas mieux lui donner les dimensions exactes avec toutes les décimales afin de l'aider dans l'exactitude du calcul.

C'est quand même intéressant de savoir comment procède le navigateur (ce que j'ignore).
Modifié par boteha_2 (15 Aug 2023 - 14:20)

Même les images vectorielles ont une taille de base de référence, taille que les navigateurs utilisent par défaut. C'est pour cela que les polices d'icônes, par exemple, limitent la tailles par défaut de leur glyphes afin de ne pas rendre une page HTML totalement explosée en cas de défaut de chargement des styles.

L'intérêt du SVG, c'est qu'il est scalable à l'infini sans perte de qualité. Pour le reste, il se comportera comme n'importe quel élément HTML.

Merci de tes précisions.

Je suppose que le navigateur va chercher dans l'attribut viewbox de l'image .svg les dimensions natives.

Par exemple viewBox="0 0 308.57 291.07"

Le code html demande width="121" height="115"

L'image redimensionnée devrait faire exactement : 121 x 114,1376997

Le navigateur utilise les valeurs de viewBox pour calculer une image de cette taille, dans un espace de 121 x 115.

D'où l'inutilité d'introduire les décimales dans le code CSS, car le navigateur dispose des données nécessaires dans viewbox.
Enfin c'est moi qui suppose que cela se passe ainsi.
Modifié par boteha_2 (15 Aug 2023 - 16:06)

C'est surtout que le CSS n'est pas fait pour ça. Il n'a pas pour but de répéter le HTML, il a pour but de le modifier.

Olivier C a écrit :
C'est surtout que le CSS n'est pas fait pour ça. Il n'a pas pour but de répéter le HTML, il a pour but de le modifier.

Oui, bien sûr mais encore une fois mon inquiétude concernait les décimales impossibles à entrer dans le code html et la nature vectorielle de l'image.

Je dois mettre en ligne un gros paquets de petits dessins en .svg, je préfère être sûr de ce qu'il faut faire.
Pour l'instant en test c'est fait par le CSS uniquement (avec les décimales) mais je vais le faire par le html uniquement (avec arrondi à l'entier supérieur) et ne manquerai de vous informer du résultat.

Je vais essayer de reprendre les choses sous un autre angle : définir une image (salable ou non) avec des unités absolues (px, rem, em, ...) est TOUJOURS une erreur. La seule propriété qui devrait posséder ce genre d'unité pour cet élément est max-width (ou max-height).

En effet, on veut des sites responsives, donc adaptables à n'importe quelle résolution d'écran, de l'écran 32 pouces à la montre connectée (bon, là, peut-être pas, mais on voit l'idée). Ce n'est donc JAMAIS l'image qui doit imposer son gabarit, mais les éléments conteneurs. L'image doit s'inclure à 100% dans son élément conteneur, ou au pire doit être une fraction de ce pourcentage, mais jamais plus.

Du coup j'en reviens à ma première intervention sur le topic précédent :

.miniature {
  width: 100%;
  max-width: 100px;
  height: auto;
}

Et il n'y a pas d'arguments de "performance" qui tienne, le CSS est fait pour ça. Si l'on veut tester ces fameuses performances, l'outil Lightouse dans l'inspecteur Chrome est tout indiqué. Ce sera bien mieux de tester son code avec ce genre d'outil plutôt que d'écouter les avis (plus ou moins éclairés) des uns et des autres sur les forums.
Modifié par Olivier C (15 Aug 2023 - 21:50)

Hello Olivier C,

Je souscrit à tes propos.

Néanmoins, dans mon cas, ce sont des petites images sont la plus large ne doit pas dépasser 200px, donc elles passent partout sauf peut-être dans une montre connectée.
Même si ce n'est pas optimal je ne vois pas d'inconvénient à dimensionner les images par le html, dans mon cas précis je précise.
Modifié par boteha_2 (15 Aug 2023 - 22:11)

Dans ce cas-là il faudrait plutôt mettre un :

max-width: 200px

Et cela couvrira tous les cas de figure, notamment ceux auxquels on ne pense pas (Comment ça ? L'utilisateur peut utiliser un zoom dans ses préférences de navigateur et ça explose la mise en page de mon site ! ).

Bonjour Olivier C,

Tu as raison, c'est noté.
Merci de ton suivi.

Bonsoir,

Un truc que personne n'a dit jusqu'à maintenant, ou en tout cas pas explicitement, est que, sauf grosse erreur de ma part, ce qui est indiqué dans le code HTML a toujours la priorité sur ce qui est écrit en CSS.
Donc si tu spécifies une taille en HTML et en CSS, c'est le HTML qui prime, et ce que tu as écrit en CSS ne sert à rien.

En d'autres termes, pour:

<img width="100" style="width: 80px;"/>
img { width: 60px; }

100px prend le pas sur 80px, qui lui-même prend le pas sur 60px, donc résultat, 100px.
Ne rien spécifier équivaut à auto.


Maintenant j'ai une question: la définition du pixel, c'est, en gros, la plus petite unité indivisible affichable sur un écran quel qu'il soit (que ce soit sur un écran UUUHD 32K qui fait 10m de long ou une montre avec un écran qui fait 10cm, c'est pareil, l'écran ne peut pas afficher quelque chose de plus petit qu'un pixel)
Du coup à quoi ça sert de spécifier des tailles en pixels non entières ? Sachant qu'elles seront nécessairement arrondies, par définition.

Quoi qu'il en soit, mieux vaut effectivement éviter de spécifier des tailles en pixels parce que ça peut représenter des choses très différentes.
Exemple à la con: 50px sur un écran d'ordinateur, c'est déjà une belle icône, mais sur une montre c'est limite compliqué de cliquer dessus...
C'est plus simple et plus robuste de réfléchir en pourcentage ou en fraction de l'espace disponible (p.ex. vw/vh), fixer la taille d'une seule dimension, et laisser le navigateur choisir la taille qui va bien dans l'autre dimension.
Modifié par QuentinC (17 Aug 2023 - 22:33)

Bonjour QuentinC,

Ta synthèse est très intéressante et j'y souscris.

Mais, encore une fois, j'aimerais savoir comment procède un navigateur pour redimensionner une image vectorielle.

Bonjour,

boteha_2 a écrit :
Admettons que la taille réelle de l'image soit : ...

Mise à part la question de la réservation de place soulignée par Raphaël un peu plus haut (qui a du sens si l'image SVG est dans un fichier à part, donc susceptible d'être affiché en léger différé), il n'y a pas vraiment de "taille réelle en pixel" pour les images SVG.

boteha_2 a écrit :
Mais, encore une fois, j'aimerais savoir comment procède un navigateur pour redimensionner une image vectorielle.

Ça dépend des machines, des OS et des navigateurs. Pour s'en convaincre, on peut par exemple essayer d'afficher une image svg représentant une grille composée de fines lignes. Ensuite, on peut s'amuser à la zoomer ou la réduire par divers moyens (via ses dimensions dans le svg, ou dans le html, ou via le navigateur, ou via le css, etc.). Même si on se débrouille pour que ces fines lignes aient à un moment exactement 1px "logique" d'épaisseur, les surprises restent nombreuses (ça fait plusieurs dizaines d'années que je m'esquinte la santé à essayer de dessiner des grilles dans une page web et de ne plus avoir de telles surprises, mais ça rate toujours . Pour ceux qui seraient intéressés par un exemple concret, voir https://jeudego.org/maxiGos/_maxigos/_sample/?lang=fr).

Un point noir n'est pas toujours un pixel noir, loin s'en faut. Et c'est difficile à prédire en toutes circonstances.

QuentinC a écrit :
La définition du pixel, c'est, en gros, la plus petite unité indivisible affichable sur un écran quel qu'il soit ... Du coup à quoi ça sert de spécifier des tailles en pixels non entières ? Sachant qu'elles seront nécessairement arrondies, par définition.

. Ça peut avoir du sens d'avoir des tailles en pixel non entières car il y a pas mal de cas où les navigateurs ou les OS doivent bricoler avec les arrondies. Par exemple :
- certains écrans (comme les écrans retina) peuvent avoir plus de 1 pixel "physique" pour afficher un pixel "logique" (le pixel "logique" étant celui qu'on utilise dans les codes html ou css). Classiquement, un écran retina utilise 4 pixels physiques pour afficher un pixel logique. Certains écrans bricolent en plus avec les couleurs primaires (rouge, vert, bleu) pour améliorer le rendu. Et il y a certainement d'autres combines du même genre. En conséquence, une image composées de fines lignes ayant des coordonnées non entières peuvent quand même apparaitre nettes sur ce type d'écran.
- si on a une image ayant un nombre de pixels impair et qu'on essaie de la centrer dans une fenêtre ayant une dimension en nombre de pixels pair, le résultat est au bon vouloir des codeurs des navigateurs ou des OS (image décalée d'un demi-pixel vers la gauche ou vers la droite ou utilisation de couleurs modifiées via des dégradés ?). Cerise sur le gâteau, si on décale ensuite la fenêtre de seulement 1 pixel logique sur l'écran, bien malin serait celui capable de prédire le résultat. D'une manière générale, rien ne garantit qu'un pixel logique ayant des coordonnées entières sera bien affiché tel quel sur un pixel physique de l'écran.
- contrairement aux images pixelisées (du genre PNG ou autres), un point à l'indice (0,0) d'un SVG est pile poil sur la bordure de l'image SVG (si on suppose que la viewBox du SVG a pour origine le point (0,0) et qu'il n'y a pas de combines altérant ça). Si on dessine une ligne noire de 1 de large (en unités SVG) sur la bordure du SVG et qu'on se débrouille pour que la taille finale en pixel logique de l'image soit identique à la taille de la viewBox du SVG, on ne verra que la moitié de la ligne (s'il s'agit d'une ligne noire, on verra en conséquence la plupart du temps plutôt une ligne gris pale). L'autre moitié de la ligne existe mais est cachée car considérée comme étant en dehors de la viewBox. Alors qu'on verra une ligne noire entière si c'est une image PNG. C'est pourquoi on peut trouver dans un SVG pas mal de coordonnées non entières même si par ailleurs l'auteur souhaitait faire une image "au pixel près", l'idée pour une ligne verticale ou horizontale étant justement de la décaler de 0.5 en unité SVG pour obtenir un meilleur rendu. En supposant que la taille définie par la viewBox du SVG corresponde exactement à la taille de l'image en pixel logique, on augmente alors les chances qu'une ligne apparaisse "nette" à l'écran.
- si l'utilisateur zoome l'image, ce qui n'était qu'une portion de pixel dans le code peut devenir un pixel entier. C'est justement une des forces du SVG que de s'adapter au mieux en cas de zoom, quelque soit les tailles en pixel définies dans la page web pour les afficher à l'écran.
- les mobiles zooment eux-aussi les images. Un pixel "logique" défini dans le code de la page web ne correspondra pas à un pixel physique du mobile.
- les imprimantes ont en général une meilleure définition que les écrans. Un pixel "logique" de l'écran sera affiché par plusieurs "points" sur le papier. En conséquence, l'imprimante sera capable d'afficher parfaitement certaines lignes ayant pourtant moins de 1 pixel logique de large.

Bref, toute prédiction en la matière est assez compliquée.

Amicalement,
Modifié par parsimonhi (18 Aug 2023 - 03:13)

QuentinC a écrit :
Un truc que personne n'a dit jusqu'à maintenant, ou en tout cas pas explicitement, est que, sauf grosse erreur de ma part, ce qui est indiqué dans le code HTML a toujours la priorité sur ce qui est écrit en CSS. Donc si tu spécifies une taille en HTML et en CSS, c'est le HTML qui prime, et ce que tu as écrit en CSS ne sert à rien.

Ah non, pas du tout. Et heureusement d'ailleurs, sinon à quoi servirait-il de faire du CSS ?
Donc c'est le CSS qui prime. C'est règle est vrai pour les images, elle est vrai pour les éléments de formulaire, elle est vrai pour tous les éléments HTML en fait...

1. Les attributs HTML width et height servent pour la "réservation" de l'image lors du premier calcul de la page par le navigateur, il me semble que Raphaël en parlait plus haut. À ce stade, cela évite un repainting de la page lorsque la ressource est enfin téléchargée.
2. Ensuite c'est le CSS qui prend le dessus. Et là encore il y a une subtilité : le CSS directement défini dans une balise HTML a toujours la priorité sur celui d'une feuille de styles (je pense que c'est avec cette règle qu'il y a eu confusion).

Du coup pour :

<img width="100" style="width: 80px">

// Et dans une feuille de styles :
img { width: 60px; }

C'est 80px qui prendra le pas sur le reste.
S'il n'y avait pas eu de CSS dans tag HTML, ce serait les 60px de la feuille de styles qui seraient prioritaires.
Modifié par Olivier C (18 Aug 2023 - 14:02)

Bonjour,

Tout cela est très intéressant.

Un petit codepen pour voir qui l'emporte entre le CSS et le HTML.

C'est bien le CSS qui l'emporte.

Par ailleurs j'ai bien compris l'avantage de dimensionner les images avec des valeurs relatives, inutile de revenir là-dessus.
Je me permets juste une remarque PRAGMATIQUE qui concerne les petites images, on va dire moins de 200px.
Avec une valeur absolue de 200px je sais que la mise en page tient jusqu'à un écran 400px de large.
Si je mets une valeur relative et que l'écran faut moins de 400px de large ou que le client zoome comme un fou, de toutes façons la mise en page deviendra horrible, sauf à prévoir un media-queries pour adapter la mise en page aux écrans minuscules, en supposant qu'il existe des écrans de moins de 400px.

Donc ma question sur un dimensionnement en px d'une petite image .svg reste légitime.

Je n'ai pas le temps d'aller plus loin ce jour mais je reviens demain.

Encore merci de votre suivi.