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.Yoko a écrit :Ton code loupe parce que tu annonce un image/png et tu donne un gif.
Theora et Vorbis bientôt dans Firefox !
C'est un avantage d'object sur le papier, c'est indéniable.Xanthor a écrit :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")
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.
C'est pour ça que la balise <object> reste utile pour traiter les cas exotiques. On ne parle pas de la supprimer.Xanthor a écrit :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.
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.Xanthor a écrit :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...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).
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.Xanthor a écrit :Ça, c'est stupide : actuellement, il existe des balises sémantiques qui globalement sont nécessaires et suffisantes pour un document HTML.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)
Supprimer les balises sémantiques actuelles, comme en rajouter un grand nombre est aussi idiot.
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).
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...calimo a écrit :Non, au contraire.Xanthor a écrit :Par contre, les footer et autres header sont assez stupides.
C'est très utile.
J'ai pas déjà expliqué plus haut que c'est exactement comme avec la balise img ?bobo a écrit :Tout à fait, c'est pour illustrer le fait qu'on est obligé de donner une information 2 fois
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 normesC'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.
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.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.
De plus, je rappelle qu'on n'est pas obligé de fournir nécessairement une image en fallback.
Non.De toute façon, même sans object tu peux déjà fournir le format d'image adapté via la négociation de contenu.
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...
Et si j'ai un titre exotique, je vais utiliser une autre balise ? C'est cette redondance qui est absurde...C'est pour ça que la balise <object> reste utile pour traiter les cas exotiques. On ne parle pas de la supprimer.
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.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.
Cette sémantique supplémentaire est intégralement contenue dans l'attribut type. Vous ne perdrez aucune info à utiliser la balise officielle...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.
Un div (sans role) n'est pas une balise sémantique. Un object en est une.Je trouve personnellement tout aussi idiot d'utiliser un div pour faire un titre que d'utiliser un object pour afficher une image.
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é.Xanthor a écrit :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...
Par ailleurs, ce sont surtout des balises destinées aux applications Web qui sont introduites, très peu concernent la structure du document.
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.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
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.
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.Cette sémantique supplémentaire est intégralement contenue dans l'attribut type. Vous ne perdrez aucune info à utiliser la balise officielle...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.
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.
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.Un div (sans role) n'est pas une balise sémantique. Un object en est une.
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éBenoit a écrit :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é.
Complètement faux. C'est partir des besoins.Le processus de normalisation c'est pourtant exactement ça : partir des usages et des supports actuels pour établir de nouvelles normes.
Mais en quoi remplacer <object type="audio/*" /> par <audio /> rajoute quoique ce soit ?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.
Je ne sais pas comment le dire plus clairement : c'est mathématiquement équivalent.
Très bien.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.
Mais où est le problème ?
Non.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.
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...
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à etXanthor a écrit :[le processus de normalisation] C'est partir des besoins.
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.
La possibilité d'y associer une interface DOM spécifique.Mais en quoi remplacer <object type="audio/*" /> par <audio /> rajoute quoique ce soit ?
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 ?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)
Comment pourrait-on avoir plus d'infos (ou moins) si c'est "mathématiquement" équivalent ?Si on rajoute ses attributs, on a même plus d'infos que les balises inutilement inventées par le WHATWG...
J'ai écrit partir, pas se limiter. Il y a une nuance.Benoit a écrit :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
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...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.
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...La possibilité d'y associer une interface DOM spécifique.
Si tu ne définis pas à quoi sert le groupement, comment tu veux lui donner du sens ?C'est un rappel de quel axiome ? En quoi "grouper des éléments" n'est pas de la sémantique.
The PRE element tells visual user agents that the enclosed text is "preformatted"Ou inversement, quelle est la sémantique de pre ?
Car l'élément object a d'autres attributsComment pourrait-on avoir plus d'infos (ou moins) si c'est "mathématiquement" équivalent ?
-
- Tyrannosaurus Rex
- Messages : 2359
- Inscription : 26 juin 2004, 19:44
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
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
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).
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).
♫ Li tens s'en veit, je n'ai riens fais ;
Li tens revient, je ne fais riens. ♪
Li tens revient, je ne fais riens. ♪
Qui est en ligne ?
Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 18 invités