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

(reprise du message précédent)

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.

Bonsoir,

Comme tu l'indique, il s'agit d'images vectorielle, à priori : rien à faire.

Si l'attribut viewbox est disponible, tu as donc un ratio qui sera respecté quelque soit la taille redéfinie par le document l'affichant. En indiquant une largeur ou une hauteur , ce ratio sera respecté.

Une image (balise <img>) est par défaut une boite inline posée sur l'interligne, une reset sur le vertical-align (top ou bottom) permet de faire disparaitre un eventuelle espace indésirable qui correspond au petit espace inférieur de l'interligne prévue pour l'affichage du jambage de certaine lettres (gjqpy...).

Pour finaliser et ajouter au ratio arrondi par le navigateur (ratio défini par défaut ou via: un width ou height (attribut ou style), ou via un width + height (attribut ou style) ou via un aspect-ratio , object-fit:cover peut aider à temporiser les petits écarts.
L'affichage final sera de toute façon en fonction des capacités du media.
Comme toujours, l'affichage d'une page web ne peut pas en plus être faites au pixel prés.
De plus , ce pixel prés n'est souvent perçue que par le designer et intégrateur, le visiteur , quant à lui, n'a pas ou très rarement d'autre référence pour pouvoir faire une comparaison visuelle à l'instant T et en faire une critique.


Si il faut faire le maximum pour que l'affichage soit propre en donnant le maximum d'information visuelle, il faut aussi savoir lâcher prise sur:
* les détails ingérables (la notion de pixel perfect pour un SVG n'existe pas, on est dans du vectoriel!)
* ou imperceptibles pour un visiteur.

Cdt
Modifié par gcyrillus (18 Aug 2023 - 22:31)

Bonjour,

Dans le codepen je présente 5 cas de figure.

Html uniquement avec height trop grand

Html uniquement avec height trop petit

On voit bien que le navigateur réserve un espace, ce qui agit sur la taille du parent, puis redimensionne l'image.
Je trouve intéressant de constater que les proportions de l'image ne sont pas déformées : si height est trop grand le navigateur ignore la valeur et applique auto.
Si height est trop petit le navigateur ignore la valeur width et applique auto à width.

Html uniquement avec height arrondi à l'entier supérieur

Html + CSS avec height auto en css

Html + CSS avec height exact avec décimales en css

Html + CSS avec height calculé par calc en css

À propos des décimales, pour la taille d'une police de caractères, il me semble avoir lu qu'il faut laisser un maximum de décimales sans arrondir.

font-size: 3.333333333333333333em
est mieux que
font-size: 3.33em

J'ai aussi lu que la fonction calc devait être privilégiée, même si cela semble extrême.

font-size : calc(10em / 3)
est mieux que
font-size: 3.333333333333333333em

Je suppose que les décimales sont également utiles pour les images, donc la meilleure solution pour bien aider le navigateur me semble être :

Html + CSS avec height exact avec décimales en css

Étant entendu comme plusieurs font remarquer, dont gcyrillus et parsimonhi, qu'avec une image vectorielle on ne sera pas au pixel exact.

boteha_2 a écrit :
À propos des décimales, pour la taille d'une police de caractères, il me semble avoir lu qu'il faut laisser un maximum de décimales sans arrondir.

font-size: 3.333333333333333333em
est mieux que
font-size: 3.33em

Mieux ? Et pourquoi donc ?

Bonjour Olivier C,

Je l'ai lu dans un bouquin sur le Responsive Design.

L'auteur indique que plus la valeur est précise mieux le navigateur se débrouille.

Je me demande aussi si Raphaël n'aborde pas ce sujet dans un de ses bouquins (sous contrôle).

En tous cas je peux te dire qu'un paquet de décimale ne semble pas déranger les navigateurs.

Quand j'emploie la fonction round () de PHP je limite quand même à 10 décimales au cas ou la division en produirait une quantité énorme.

Je pense que tout cela est très marginal, si tu insistes je peux essayer de retrouver ce bouquin qui date de 10 ans à mon avis.

boteha_2 a écrit :
Je l'ai lu dans un bouquin sur le Responsive Design.

L'important c'est de savoir pourquoi on fait quelque chose. Là, tout de suite, pour grossir la taille d'une police de caractères, je n'y vois aucun intérêt.

Le livre mentionné ne parlait pas forcément du contexte qui nous occupe. Sans compter qu'un bouquin de dev' n'est pas à l'abris de dire des conneries. ***

___
*** Exemple : la bonne époque où tous les dev's parlaient de problème de performance pour le sélecteur CSS universel (*). Croyance relayée sur tous les blogs, jamais vérifiée dans les faits.
Modifié par Olivier C (21 Aug 2023 - 21:30)

Olivier C a écrit :

Le livre mentionné ne parlait pas forcément du contexte qui nous occupe. Sans compter qu'un bouquin de dev n'est pas à l'abri de dire des conneries.

J'ai trouvé la source :

Responsive Web Design
Ethan Marcotte
Eyrolles
2014

En résumant un peu :

Responsive Web Design a écrit :
Font-size de 11 / 24 = 0.458333333333
Vous allez peut être arrondir 0.45833333333333 au nombre raisonnable le plus proche, par exemple 0.46, mais n'en faites rien.
0.45833333333333 est la taille désirée de notre police.
De plus les navigateurs arrondissent les décimales quand ils convertissent les valeurs en pixels. Donnez-leur le plus d'informations possibles pour un meilleur résultat.

Cela dit tu as raison, ce n'est pas parce-que c'est écrit dans un bouquin que c'est vrai.

Mais j'applique cette approche pour tous les types de tailles et je peux dire que si c'est sans avantage c'est aussi sans inconvénient visible.
Modifié par boteha_2 (25 Aug 2023 - 22:13)

Bonjour,

Je vais faire quelques tests avec PageSpeed Insights.

Qui me semble être l'outil de test le plus adéquat.
DareBoost était bien mais cela a été acheté par je ne sais qui et est moins ouvert qu'avant.

Je vous tiens informés.

Bonjour,

Test avec PageSpeed Insights, MOBILE.

Un page avec une vingtaine d'images SVG.

Les dimensions dans le code html :

<img src="im/co/21.svg" width="80" height="42" loading="lazy" />

Les dimensions dans le code CSS selon trois façons.

1)
img[src="im/co/21.svg"] {width: 80px; height: 41.44546258942px}

First Contentful Paint
1,2 s
Largest Contentful Paint
1,2 s
Total Blocking Time
0 ms
Cumulative Layout Shift
0
Speed Index
1,2 s

2)
img[src="im/co/21.svg"] {width: 80px; height: auto}

First Contentful Paint
1,0 s
Largest Contentful Paint
1,1 s
Total Blocking Time
0 ms
Cumulative Layout Shift
0
Speed Index
1,0 s

3)
img[src="im/co/21.svg"] {width: 80px}
img[src="im/co/*.svg"] {height: auto}

First Contentful Paint
1,1 s
Largest Contentful Paint
1,2 s
Total Blocking Time
10 ms
Cumulative Layout Shift
0
Speed Index
1,1 s

En supposant PageSpeed Insights, fiable, ce qui n'a rien d'évident, c'est la propriété height: auto pour CHAQUE image qui donne le meilleur résultat.

Il faudrait évidemment une démarche plus scientifique pour en tirer une conclusion.