D'autant qu'il sont effectivement des propriétés de l'image et non des directives de présentation. C'est une information supplémentaire sur l'objet image, comme le src.

C'est vrai qu'il est de plus en plus fréquent de supprimer ces propriétés.
La raison me parait simple : la taille et la hauteur sont des attributs de mise en forme (on les supprime bien sur les tableaux par exemple) donc, instinctivement, on a tendance à ne pas les laisser dans le code HTML.
Je comprends les deux façon de voir les choses : les avantages que tu décrits et le respect de "l'éthique CSS" qui est de séparer le fond de la forme.

Sauf que la largeur et la hauteur d'une image sont autre chose que celles d'un calque par exemple.
Dans le premier cas, c'est une information sur l'image (en général utilisée par le navigateur lui même comme l'indique Laurent), dans le second cas, c'est effectivement uniquement pour la présentation.

Raphaël : il n'y pas "d'éthique CSS", sauf celle que chacun peut s'inventer s'il estime cela nécessaire et justifié Mais les normes ne portent pas là-dessus et ne peuvent servir à en justifier.

Les normes ne définissent que " la structure légale, les éléments, et les attributs qu sont disponibles pour un document se conformant à la DTD." (www.w3.org/TR/xhtml1/#gen...

Il y a décidément un petit côté "nouvelle religion" dans le mouvement en faveur des standards :D

On ne souligne pas assez ce qui est illustré sur le site htmldog.com suite à un article sur ALA (traduit sur Pompage récemment), à savoir que les width et height que l'on donne ici ne sont pas nécessairement la taille de l'image d'origine exprimée en pixels. Il est possible, entre autre, de donner des tailles en cadratins (em) et alors la taille de l'image va varier en fonction du réglage de la police par défaut (voir la première image ici: "Elastic Design Demonstration")
www.htmldog.com/articles/...
Essayer sous IE par exemple (si si vous ne me croyez pas mais ça marche sous Affichage modifiez la taille du texte, la taille de la première image varie.
@mitiés
Philippe

Bobe> Absolument pas. Les dimensions réelles de l'image peuvent être toutes autres. Il s'agit bien là des dimensions auquelles sera affichée l'image et donc de présentation.

@phdm : la technique des tailles d'images en em spécifiée en CSS n'empêche pas, contrairement à l'exemple de htmldog.com, de spécifier height et width en pixels dans le code HTML.

@JMF : imagine que tu veuilles extraire d'un site d'art les informations relatives aux images affichées, afin d'en dresser un catalogue. Celui-ci est supposé indiquer les dimensions des images. Tes pages étant en XHTML, tu procèdes à l'aide d'une simple transformation XSLT.

Si les dimensions ne sont pas indiquées dans le document... te voilà contraint de procéder à un traitement plus lourd pour retrouver l'information. Passe encore.

Si ce sont d'autres dimensions proportionnelles qui sont spécifiées... Comment fais-tu la différence entre les images réellement dimensionnées et les images re-dimensionnées ?

Modifier la taille affichée d'une image relève effectivement de la présentation : mais on gagne à indiquer les "vraies" dimensions en HTML, et à forcer le redimensionnement en utilisant les propriétés CSS

Ma foi, je spécifie rarement les attributs width et height lorsque je mets des images... Mais c'est plus par flemme que par réelle conviction, car sinon ma pensée converge vers celle de Laurent : dans ce cas précis width et height sont des propriétés de l'image et non des directives de présentation.

Ma foi, je spécifie rarement les attributs width et height lorsque je mets des images... Mais c'est plus par flemme que par réelle conviction, car sinon ma pensée converge vers celle de Laurent : dans ce cas précis width et height sont des propriétés de l'image et non des directives de présentation.

@Denis: en même temps sur la plupart des sites, quand l'auteur du site mais une image, elle est dans une taille bien définie à l'avance. Cette taille dépend généralement du role et de l'emplacement de l'image. Bref, il s'agit de choses qu'on met plus facilement dans la CSS (pour que ce soit valable dans toutes les pages avec le même modèle) que dans le HTML (reprécisé dans chaque page alors qu'elles ont toutes le même modèle).

Je crois que le bon point est celui soulevé par Dam et bobe :

Soit on parle des attributs propres à l'image et alors AMHA ça n'a absolument rien à faire dans la CSS (qui s'occupe de la présentation). Mais en même temps dans ce cas pourquoi déclarer la taille alors qu'elle est déjà contenue dans l'image ? pour éviter de casser le design ? mais alors on parle de présentation, pas de contenu, on parle de la taille d'affichage et pas de la taille intrinsèque de l'image, bref : on tourne en rond.
Il reste le problème de la modification du design au fur et à mesure de l'arrivée des images. Maintenant ce n'est un problème que sur relativement peu de design (le reste du temps le design est tout à fait correct même sans l'image) et de moins en moins présent avec les débits et puissances actuels (je n'aurai pas dit ça il y a 5 ans avec les modems 28.8k). Et généralement quand ça pose problème c'est avec les images de présentation, pas les images de contenu (donc qui ne devraient de toute façon pas être dans le HTML)
AMHA si on parle de la taille de l'image et pas de la taille d'affichage, on fait mieux de ne pas la préciser.

Soit on parle de la taille d'affichage et alors il s'agit bien de présentation non ? la CSS est alors logiquement plus adaptée que le HTML. Quant au problème de réaffichage il ne se pose plus dès qu'on a spécifié la taille (qu'elle soit en CSS ou en HTML importe peu). Si toutes les images ne sont pas différentes la CSS sera même plus pratique.

Par "éthique CSS", je parlais simplement de la règle qui veut séparer le fond de la forme.
Parfois, comme tu le dis, les frontières sont floues et les directives ne sont pas claires (on l'a vu récemment avec :hover).
Doit-on observer "strictement" cette règle (ne pas faire avec :hover ce qu'on peut faire en DOM par exemple) ? Je ne connais pas la réponse, je n'ai que mon opinion

Pour ce qui est du height/width, je suis de l'avis du "tout ou rien" : s'il s'agit de propriétés pour l'image et non des directives de présentation, alors je pars du principe qu'il en est de même pour les autres éléments non images (blocs, tableaux, etc.)... dans ce cas, ces propriétés devraient être TOUTES présentes dans le HTML.

Ce n'est pas de la religion ou du dogmatisme, c'est simplement que je n'aime pas les règles floues dont je préfère (essayer) de les respecter au pied de la lettre

PS : il fallait lire "donc" et non pas "dont" en fin de commentaire

Je suis d'accord avec Éric, en quoi le fait de casser le design au chargement est-il choquant ?

Tous les éléments sont pareils, et le fait que les images soit chargées en parallèles est une contrainte des navigateurs graphiques qui ne devraient concerner que leurs développeurs... Mes tableaux (ou mes divs), se chargent très bien malgré le fait que je ne spécifie pas le nombre de cellules (ou de mots) qu'ils contiennent.

Si on examine bien la DTD:
height %Length; #IMPLIED -- override height --
width %Length; #IMPLIED -- override width --

Il s'agit bien d'option de présentation. "override height" - « surcharge de la hauteur » : il ne s'agit en aucun cas de donner une information supplémentaire sur l'image, mais bien de spécifier la taille à laquelle elle devra s'afficher. Et Google ne doit pas en tenir compte puisqu'il est clairement défini dans la DTD que ce sont des valeurs de surcharge, et pas la taille réelle de l'image.

Eric je concidere que heigth et width sont des meta informations sur l'image et que non, elle ne sont pas inutiles , je pense que ce sont les seules info qu'un serveur n'est pas susceptible d'envoyer (à part le contenu) dans un HEAD (HTTP) sur le fichier image lui meme (il envoie la taille en octets et le mime-type) donc pour pouvoir rassembler les informations relative à l'image sans télécharger cette image.

Je pense que width et height sont utiles comme attribut de la balise (en temps que valeurs réelles), d'autant que si on précise une valeur différente dans le CSS, c'est cette dernière qui prend le pas pour l'affichage de l'image.

Mouais, la question est finalement plus complexe qu'il n'y parait.

Jusque là, je pensais que les attributs width et height sur la balise <img> avaient seulement un but informatif, pour permettre par exemple à l'agent utilisateur de restituer l'image plus rapidement (je suppose que c'est le cas de toute façon?), mais ce fragment de DTD me fait furieusement douter.

Ces attributs sont également très utiles pour que, en cas d'absence de l'image (mais ce serait valable pour tout objet inséré avec <object>) sur le serveur, le bloc prenne tout de même l'espace qu'il est sensé prendre si l'image était affichée. Mais là encore, on est dans le domaine de la présentation...

@Anubis : "Les commentaires du DTD sont uniquement informatifs." ( www.w3.org/TR/1999/REC-ht... )

"override heigh" n'a pas valeur normative

@Eric : Je suis tout à fait d'accord avec le fait que la taille **d'affichage** de l'image a bien sa place dans la CSS (C'était le sens de mon commentaire sur les images redimensionnées).

Pour la taille **en propre** de l'image, "pourquoi déclarer la taille alors qu'elle est déjà contenue dans l'image ?" : simplement pour que cette information soit immédiatement disponible dans le document, sans avoir à aller la chercher dans l'image, comme l'exprime clairement Dam dans son dernier commentaire. Il n'y a là rien d'obligatoire. C'est une commodité dont on peut avoir besoin

Essayons d'être pragmatiques ...


Il me semble qu'un des intérêts des CSS, c'est aussi de ne déclarer qu'une fois des choses qui sont utilisées sur plusieurs pages.

Dans le cas de logos différents mais toujours de même taille, j'aurais ainsi plutôt tendance à mettre la taille (et même le logo lui-même d'ailleurs) dans la CSS. Ca tombe bien, je dirais que ces logos sont plutôt liés à la présentation.


Si je fais des pages de galeries d'images de tailles variables, je ne vais par contre pas m'amuser à déclarer dans ma CSS autant de classes ou d'id que d'images, surtout si je dois avoir tout dans une seule CSS pour des images présentées en plusieurs pages. Je mettrais donc là les tailles dans le <img />. Ca tombe après tout plutôt bien, ces images sont des contenus. Leur taille (en tout cas si elle correspond à la taille réelle) est une information, pas un élément de présentation.

@Laurent
Je vois. Mais je pointais cette remarque tout simplement parce que des attributs width et height pour une image sont des attributs ambigus (taille de l'image, taille rendu ?) et je pense que ces commentaires sont là pour lever cette ambiguité.

Il est vrai que ce sujet est plus difficile qu'il n'y parait, on peut par exemple se demander pourquoi un navigateur affiche automatiquement une image à sa taille orginale si celle-ci n'est pas spécifiée, alors qu'il ne fait pas de même avec les objects, qui porte pourtant eux aussi une information de taille dans le fichier.

C'est je pense la raison d'être de ces attributs, les navigateurs font peut-être l'erreur d'afficher les images à leur taille d'origine alors qu'il devrait toujours utiliser les attributs with et height. Mais je m'avance un peu et je ferais mieux de regarder dans la spec...

Ahah ! Finalement une réponse dans la spec ! Je regarde la balise IMG dans HTML 4.01, je suis lien sur Visual presentation of images, objects, and applets
(www.w3.org/TR/html401/str...
et je trouve :

«
All IMG and OBJECT attributes that concern visual alignment and presentation have been deprecated in favor of style sheets.
»

Il me semble donc bien comprendre que le W3C ne recommande pas l'usage des attributs width et height, au même titre qu'ils ne recommandent pas l'usage des attributs border ou align.

@Anubis > pas si sûr : "alignment and presentation" n'est pas obligatoirement la hauteur et la largeur, mais bel et bien l'alignement (float, vertical-align)et la présentation (euh)

Je n'ai pensé à ça que par le fait que ce chapitre décrit les attributs width, height, hspace, vspace, border et align.

J'ezn profite pour remettre le lien cassé par DotClear:

www.w3.org/TR/html401/str...

Ça dit que les attributs de présentation sont dépréciés, width et height ne sont pas marqués [deprecated]. Donc je concluerais plutôt que le w3c indique par là que width et height ne sont pas des attributs de présentation.

Bref, de toute évidence, la recommandation comporte des incohérences et/ou n'est pas assez claire sur certains points.

@Anubis : "les navigateurs font peut-être l'erreur d'afficher les images à leur taille d'origine alors qu'il devrait toujours utiliser les attributs with et height." ... Les navigateurs affichent les images sans se référer à leur taille d'origine lorsque height et width sont spécifiés.

Pour "All IMG and OBJECT attributes that concern visual alignment and presentation have been deprecated in favor of style sheets.", tu fais une erreur de lecture de la spécification :
- "visual alignement and presentation" renvoit aux attributs déconseillés énumérés dans cette partie de la spécification : hspace, vspace, border et align, pour lesquels il est effectivement précisé à chaque fois qu'ils sont "deprecated", c'est à dire admis en transitional mais abandonnés en strict.

- en revanche, toujours dans la même partie, il n'y a, et pour cause, aucune mention "deprecated" pour height et width...

Que la spécification HTML4.01 comporte nombre d'ambiguïtés, voire d'erreurs littérales n'est pas nouveau ni surprenant (aucun erreta depuis 2001).

Cela dit, il me semble plus prudent de se référer à la DTD proprement dite (le billet ci-dessus) qu'à la spécification plus susceptible d'induire en erreur, AMHA.

En effet, j'avais complètement raté cette mention « Deprecated » sous chaque attribut, merci de l'avoir signalé.

@ Nicolas Hoizey> "Dans le cas de logos différents mais toujours de même taille, j'aurais ainsi plutôt tendance à mettre la taille (et même le logo lui-même d'ailleurs) dans la CSS. Ca tombe bien, je dirais que ces logos sont plutôt liés à la présentation."

Mettre son logo en CSS ? Oui. Dans certains cas, pas dans d'autres. Peut-être pas sur une page d'accueil où le logo marque l'identité d'une entreprise, par exemple...

Ce qui est intéressant, ici, pour une fois, c'est la cohérence apparente de la spécification : une image en CSS (propriétés background ou content) n'a ni width ni height spécifiable.

Comme si les dimensions d'une image présentative (CSS) perdaient tout à coup toute importance, alors que les dimensions d'une image "de contenu" (HTML) avaient une valeur plus grande... Ceci tendrait-il à montrer a contrario que les dimensions réelle d'une image ont bien un poids sémantique ? je ne sais pas, mais c'est amusant

Je crois qu'il s'agit avant tout d'une question de sémantique.
Soit l'image est un élément de présentation et on la met dans le CSS (en puce ou en fond) ; soit on considère qu'elle fait sens et on la met dans le HTML.

Dans ce cas, il faut considérer qu'un élément image est fondamentalement différent d'un élément texte. Un texte peut être affiché (medium graphique), mais ce n'est pas sa seule présentation possible : il peut aussi être lu (medium audio). Une image en revanche ne peut exister que dans un medium graphique. Elle s'inscrit nécessairement en hauteur et en largeur. Ces deux dimensions n'ont rien de présentatif, ce sont les conditions pour que l'image puisse exister. Donc elles sont nécessaires dans le HTML et je pense que les omettre est une erreur (je me fais combien d'ennemis là ? ).

Est-ce donc une question d'inimitiés ? Pourquoi serait-ce toujours polémique ?

Cela dit, autant je partage la distinction image décorative CSS/image de contenu (X)HTML, autant je suis surpris par le terme "sémantique"... Une décoration est tout à fait sémantique !

La sémantique est AMHA indépendante du médium, justement. Et une image peut être "lue", tout comme un texte : très primitivement grâce à alt et longdesc, mieux grâce aux éléments RDF qu'elle serait susceptible d'inclure.

Une image ainsi "lue" ne **dépend** en rien de sa largeur ni de sa hauteur, même si ces informations peuvent être représentées alors.

En d'autres termes, une image peut être lue, mais encore faut-il qu'elle ait un texte alt (requis par (X)HTML). A la lecture, ses dimensions peuvent avoir un intérêt pour l'auditeur. C'est pourquoi width et height sont optionnels (en (X)HTML).

@LaurentDenis/15h21:
Ton raisonnement est faussé. Si tu utilises cet attribut pour essayer de connaitre la taille en pixel de l'image, tu vas te planter pour toutes les pages qui spécifient via HTML une taille d'affichage différente de la taille intrinsèque de l'image (et ils en ont le droit). Quand elle est présente, cette information ne peut être prise que pour une dimension d'affichage et nullement pour une métadonnée de l'image.
Le fait que souvent on souhaite afficher "à taille réelle" n'est n'est qu'une coincidence si on peut dire. On ne peut *pas* se baser dessus pour catégoriser l'image pointée.

@Nicolas:
Pour les images en vrac à taille variable je suis d'accord pour dire que les CSS ne sont pas adaptées. Maintenant, est-ce que dans ce cas ne rien préciser du tout est *vraiment* dommageable ?
Et le problème de ta dernière parenthèse c'est que justement la taille spécifiée ne correspond pas forcément à la taille réelle. Aucun client HTML ne devrait donc considérer que c'est le cas ou l'utiliser en tant que taille intrinsèque de l'image (si tant est que ce soit utile de la connaitre à l'avance). cf ma réponse à Laurent juste au dessus.
Maintenant, il faudrait arrêter de culpabiliser tout le monde avec la présentation. Un doc avec de la présentation dans le HTML n'est pas le mal incarné et si il fallait mettre de la présentation dans certains cas (vrac d'images de tailles différentes) pour éviter que ça fasse des horreurs, je n'y verrai pas une horreur.

@Laurent/17h27:
La priorité entre les attributs HTML et règles CSS est identique sur tous les éléments HTML. Tu ne peux donc en tirer aucune conclusion sur le poid ou l'utilité de la taille des images.
Il s'agit juste d'une convention globale. Elle n'est d'ailleurs pas dénuée de sens je pense. Le design est généralement fait pour être réutilisé sur plusieurs pages et/ou élément. La valeur en HTML est plus spécifique à un objet que la valeur CSS, elle est donc prioritaire.

@Anne:
La taille de l'image est nécessaire, la question est de savoir où aller prendre cette info (dans le HTML, dans le CSS ou dans l'image elle-même). Le fait que la taille soit utile ou nécessaire n'apporte aucune réponse.
Je dirai même que tout élément affiché a besoin d'une taille, pourtant presque tous savent avoir des tailles calculées au dernier moment, voire dynamique. Le fait que la taille soit nécessaire à la présentation de l'image n'implique en rien qu'il soit utile de la préciser explicitement.

Que conclure de tout ceci ?

Le billet rappelait simplement que ces deux attributs (X)HTML sont valides dans toutes les DTD, qu'ils sont optionnels, et que rien dans les spécifications n'invite à passer par un coûteux détour CSS pour éviter à tout prix de les employer.

Mais à quoi doivent correspondre leurs valeurs ? Dimensions réelles ? Dimensions d'affichage ? Les spécifications sont muettes sur l'utilisation de ces attributs pour redimensionner une image, c'est à dire obtenir un taille affichée différente de la taille réelle.

Ce redimensionnement est cependant possible via CSS (l'exemple de htmldog.com étant un cas extrême), ce qui permet de spécifier la taille réelle de l'image en HTML si on le souhaite afin que cette information soit disponible sans avoir à les lire dans l'image elle-même.

Enfin, remarquons que la question disparaîtrait purement et simplement dans le futur et éventue XHTML2.0 : tout élément y a la possibilité d'être remplacé par une image, dont seule la source est spécifiée via un attribut src générique; toute mention de hauteur et de largeur ayant alors disparu.

Là, j'apprécie bcp de lire pour une fois quelqu'un qui ne dit pas "ça c'est mal" ou "ça c'est bien" mais qui dit simplement ce qui est valide ou pas, et ce qu'on peut choisir ou pas !
(c'est rare avec les blogueurs sur les Standards)