Theora et Vorbis bientôt dans Firefox !

[bobo]

Ton code loupe parce que tu annonce un image/png et tu donne un gif.

Tout à fait, c'est pour illustrer le fait qu'on est obligé de donner une information 2 fois (3 en réalité avec la config du serveur pour qu'il délivre le bon content-type pour ton fichier) avec le risque d'avoir des incohérences qui feront que l'image ne s'affichera pas.

[calimo]

Par contre, les footer et autres header sont assez stupides.

Non, au contraire.
C'est très utile.

[bobo]

Inconvénients de <img> :
Je ne peux pas imbriquer plusieurs images l'une dans l'autre pour fournir du contenu alternatif (en fait, je ne peux même pas utiliser un contenu alternatif "riche")

C'est un avantage d'object sur le papier, c'est indéniable.
1er problème pratique, certains navigateurs ne gèrent pas correctement l'imbrication, ce qui limite son utilisation.
2e problème pratique, je ne pense pas que beaucoup de concepteurs de pages envisagent sérieusement de fournir les images sous plusieurs formats via ce moyen. Le concepteur va choisir un seul format qui passe sur le plus grand nombre possible de configurations, et c'est tout. De toute façon, même sans object tu peux déjà fournir le format d'image adapté via la négociation de contenu.

Je ne peux utiliser que des formats que les navigateurs supportent nativement. Sachant que tous les navigateurs ne gèrent pas les mêmes formats, ou même que certains formats sont subitement abandonnés, ça invalide ton avantage.

C'est pour ça que la balise <object> reste utile pour traiter les cas exotiques. On ne parle pas de la supprimer.

Avantage de <img> pour le navigateur :
C'est une image, j'ai des options pour afficher ou non les images, je peux mettre en route des optimisations pour l'affichage des images (parce que bon, y'en a souvent des images quand même).

Euh, bin pareil quand c'est utilisé avec la balise object... Quand le navigateur est reglé pour ne pas afficher les images, ça ne veut pas dire "ignorer les balises img", mais bien "ignorer les images", qu'elles soient introduites avec la balise img, object, en CSS...

Certe, mais dans le cas d'<object>, si le type n'est pas connu nativement, tu n'as aucune certitude d'avoir une image ou non, vu qu'il faut passer par le plugin pour l'afficher. (bon, dans le cas d'img si le format n'est pas connu on n'affiche rien dans tous les cas, en effet) Par contre, le gain en optimisation est indéniable.

Pour reprendre l'image des balises génériques, c'est comme si tu n'avais plus que des <div> et des <span> auquels tu donnes un sens avec "class", pour reprendre des choses existantes (certains le font en plus)

Ça, c'est stupide : actuellement, il existe des balises sémantiques qui globalement sont nécessaires et suffisantes pour un document HTML.
Supprimer les balises sémantiques actuelles, comme en rajouter un grand nombre est aussi idiot.

C'est bon de voir que tu arrives à être en partie d'accord avec nous. Le fond du problème, c'est que tu considères que object a suffisament de sémantique en lui même pour gérer tous les cas sans soucis. Alors que pour nous, il y a une valeur sémantique nécessaire à distinguer plus finement les images, les audios et les vidéos.
Je trouve personnellement tout aussi idiot d'utiliser un div pour faire un titre que d'utiliser un object pour afficher une image. Un titre n'est pas un div comme les autres, une image n'est pas un object comme les autres (idem pour audio et video).

[Xanthor]

Par contre, les footer et autres header sont assez stupides.

Non, au contraire.
C'est très utile.

Tu n'as pas compris : ce ne sont pas ces hypothétiques balises qui sont stupides, mais l'idée de leur introduction. Car si on commence comme ça, il n'y a aucune raison valide de s'arrêter là, et de ne pas rajouter toutes celles de docbook... C'est d'ailleurs déjà ce que la communauté XML constatait il y a 2 ans...

Tout à fait, c'est pour illustrer le fait qu'on est obligé de donner une information 2 fois

J'ai pas déjà expliqué plus haut que c'est exactement comme avec la balise img ?

C'est un avantage d'object sur le papier, c'est indéniable.
1er problème pratique, certains navigateurs ne gèrent pas correctement l'imbrication, ce qui limite son utilisation.

Tu sais, les navigateurs ne gèrent pas non plus les balises proprios audio et video, donc on ne va pas commencer à parler des supports actuels, puisque le sujet concerne les nouvelles normes

2e problème pratique, je ne pense pas que beaucoup de concepteurs de pages envisagent sérieusement de fournir les images sous plusieurs formats via ce moyen.

C'est pourtant le cas. Tu n'es peut-être pas concerné, mais tous ceux qui trouvent un intérêt au MNG sont bloqué dans sa diffusion par l'absence de cette fonctionnalité. Et avec l'arrivée du SVG ce sera pareil.
De plus, je rappelle qu'on n'est pas obligé de fournir nécessairement une image en fallback.

De toute façon, même sans object tu peux déjà fournir le format d'image adapté via la négociation de contenu.

Non.
Ex : mon navigateur n'indique explicitement comme format d'image reconnu que le PNG. Alors qu'il supporte aussi le GIF, le JPEG, le SVG...

C'est pour ça que la balise <object> reste utile pour traiter les cas exotiques. On ne parle pas de la supprimer.

Et si j'ai un titre exotique, je vais utiliser une autre balise ? C'est cette redondance qui est absurde...

Certe, mais dans le cas d'<object>, si le type n'est pas connu nativement, tu n'as aucune certitude d'avoir une image ou non, vu qu'il faut passer par le plugin pour l'afficher.

Au navigateur de détecter le media type image/* et d'intervenir avant de passer au plugin, s'il faut empêcher l'affichage des images.

Le fond du problème, c'est que tu considères que object a suffisament de sémantique en lui même pour gérer tous les cas sans soucis. Alors que pour nous, il y a une valeur sémantique nécessaire à distinguer plus finement les images, les audios et les vidéos.

Cette sémantique supplémentaire est intégralement contenue dans l'attribut type. Vous ne perdrez aucune info à utiliser la balise officielle...

Je trouve personnellement tout aussi idiot d'utiliser un div pour faire un titre que d'utiliser un object pour afficher une image.

Un div (sans role) n'est pas une balise sémantique. Un object en est une.

[Benoit]

si on commence comme ça, il n'y a aucune raison valide de s'arrêter là, et de ne pas rajouter toutes celles de docbook... C'est d'ailleurs déjà ce que la communauté XML constatait il y a 2 ans...

Il y a une raison valide qui a du t'échapper, c'est que les quelques balises de structure proposées dans HTML5 (huit en tout, pas "400" comme dans DocBook) sont entre autres basées sur une analyse statistique du contenu réel des pages en ligne. Quelque chose qui n'aurait d'utilité que pour deux ou trois personnes n'aurait tout simplement aucune chance d'être accepté.

Par ailleurs, ce sont surtout des balises destinées aux applications Web qui sont introduites, très peu concernent la structure du document.

Tu sais, les navigateurs ne gèrent pas non plus les balises proprios audio et video, donc on ne va pas commencer à parler des supports actuels, puisque le sujet concerne les nouvelles normes

Le processus de normalisation c'est pourtant exactement ça : partir des usages et des supports actuels pour établir de nouvelles normes. L'adjectif "proprio" est évidemment non avenu quand c'est un standard ouvert, comme tout ce qui est développé dans le cadre du W3C.

En l'occurrence, les navigateurs plus anciens n'auront aucun souci face à une telle balise. Ils ne la connaissent pas ? C'est pas grave, il suffit de l'ignorer et de prendre ce qu'il y a à l'intérieur, comme dans le cas idyllique d'object. Les défauts d'img ne sont pas à craindre ici.

Le fond du problème, c'est que tu considères que object a suffisament de sémantique en lui même pour gérer tous les cas sans soucis. Alors que pour nous, il y a une valeur sémantique nécessaire à distinguer plus finement les images, les audios et les vidéos.

Cette sémantique supplémentaire est intégralement contenue dans l'attribut type. Vous ne perdrez aucune info à utiliser la balise officielle...

Ben si... Avec juste le type de contenu on n'a toujours aucune idée de ce qu'il faut en faire, quelles sont les relations avec les autres éléments de la page.

Dans le cas d'une vidéo, tu peux par exemple vouloir attirer l'attention sur la séquence qui débute à 2:15, ou même faire un arrêt sur image. C'est sûr tu peux mettre un objet et un texte explicatif "jouez la vidéo et appuyez sur pause exactement à 2:15' mais c'est un tout petit peu plus facile si le navigateur peut le faire à ta place.

Un div (sans role) n'est pas une balise sémantique. Un object en est une.

Ce n'est pas la balise de l'objet qui lui donne sa sémantique (peut-être celles qui l'entourent, mais pas object), c'est le contenu de l'objet lui-même.

[Xanthor]

Il y a une raison valide qui a du t'échapper, c'est que les quelques balises de structure proposées dans HTML5 (huit en tout, pas "400" comme dans DocBook) sont entre autres basées sur une analyse statistique du contenu réel des pages en ligne. Quelque chose qui n'aurait d'utilité que pour deux ou trois personnes n'aurait tout simplement aucune chance d'être accepté.

Tu ne peux pas (et personne ne le peut), prévoir les besoins futurs des développeurs. Utiliser la vieille approche un besoin = une balise c'est partir avec un handicap reconnu. Je crois que c'était détaillé de façon plus claire dans le mail que j'ai filé

Le processus de normalisation c'est pourtant exactement ça : partir des usages et des supports actuels pour établir de nouvelles normes.

Complètement faux. C'est partir des besoins.

Ben si... Avec juste le type de contenu on n'a toujours aucune idée de ce qu'il faut en faire, quelles sont les relations avec les autres éléments de la page.

Mais en quoi remplacer <object type="audio/*" /> par <audio /> rajoute quoique ce soit ?
Je ne sais pas comment le dire plus clairement : c'est mathématiquement équivalent.

Dans le cas d'une vidéo, tu peux par exemple vouloir attirer l'attention sur la séquence qui débute à 2:15, ou même faire un arrêt sur image.

Très bien.
Mais où est le problème ?

Ce n'est pas la balise de l'objet qui lui donne sa sémantique (peut-être celles qui l'entourent, mais pas object), c'est le contenu de l'objet lui-même.

Non.
Même un object sans aucune info est déjà sémantique (rappel, il n'y a en HTML que 2 éléments non sémantiques, div et span)
Si on rajoute ses attributs, on a même plus d'infos que les balises inutilement inventées par le WHATWG...

[Benoit]

[le processus de normalisation] C'est partir des besoins.

Tu ne peux pas (et personne ne le peut), prévoir les besoins futurs des développeurs. Oh pardon, je crois que que suis trompé de réplique. J'avais déposé la mienne là et…

Mais bien sûr il ne s'agit pas de moi (je ne définis pas de balises, j'en utilise éventuellement), ni de prévoir. Juste de voir.

Mais en quoi remplacer <object type="audio/*" /> par <audio /> rajoute quoique ce soit ?

La possibilité d'y associer une interface DOM spécifique.

Même un object sans aucune info est déjà sémantique (rappel, il n'y a en HTML que 2 éléments non sémantiques, div et span)

C'est un rappel de quel axiome ? En quoi "grouper des éléments" n'est pas de la sémantique. Ou inversement, quelle est la sémantique de pre ?

Si on rajoute ses attributs, on a même plus d'infos que les balises inutilement inventées par le WHATWG...

Comment pourrait-on avoir plus d'infos (ou moins) si c'est "mathématiquement" équivalent ?

[Xanthor]

Tu ne peux pas (et personne ne le peut), prévoir les besoins futurs des développeurs. Oh pardon, je crois que que suis trompé de réplique. J'avais déposé la mienne là et…

J'ai écrit partir, pas se limiter. Il y a une nuance.

Mais bien sûr il ne s'agit pas de moi (je ne définis pas de balises, j'en utilise éventuellement), ni de prévoir.

Bien sûr qu'il s'agit de prévoir. Si tu n'es pas d'accord avec ça, je comprends mieux pourquoi tu soutiens une spec qui ne voit qu'à cours terme, malgré l'expérience des 20 dernières années...

La possibilité d'y associer une interface DOM spécifique.

Pas besoin d'inventer des nouveaux éléments pour ça : les plugins sont déjà manipulables par javascript. C'est là qu'il faut faire un travail constructif de normalisation...

C'est un rappel de quel axiome ? En quoi "grouper des éléments" n'est pas de la sémantique.

Si tu ne définis pas à quoi sert le groupement, comment tu veux lui donner du sens ?

Ou inversement, quelle est la sémantique de pre ?

The PRE element tells visual user agents that the enclosed text is "preformatted"

Comment pourrait-on avoir plus d'infos (ou moins) si c'est "mathématiquement" équivalent ?

Car l'élément object a d'autres attributs

[Omnisilver]

Pour en revenir au support de la balise <video> qui ne sera pas dans Firefox 3, le travail continue néanmoins : Refactoring of Firefox HTML video element patch.

J'espère qu'on ne devra pas attendre la version 4 pour cette balise, mais qu'on aura une 3.5 avec cette balise, comme Benoit me l'a fait espérer au FOSDEM

[Benoit]

En tout cas pour l'instant le patch est toujours destiné au tronc (Gecko 1.9) et je n'ai pas vu d'intention de le reporter à Mozilla 2.

L'idée de factoriser le code en permettant de changer de backend est certainement positive, c'est aussi comme ça que SVG a pu être intégré progressivement dans Mozilla (pour que finalement tout se focalise sur Cairo).