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é.

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)

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.

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)

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.