Forums d'assistance et de discussion sur les logiciels produits par Mozilla ou créés à partir des technologies Mozilla. Ce site ne dépend pas de la fondation Mozilla et est maintenu par un collectif de bénévoles.
https://forums.mozfr.org/
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.
Non, au contraire.Xanthor a écrit :Par contre, les footer et autres header sont assez stupides.
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")
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.
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.
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.
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...
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
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.
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.
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.
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.
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.
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 ?
