fonctionnement de l'attribut alt avec Firefox

[PsyDk]

C'est un bug, et c'est corrigé dans Gecko 1.8 ! ^^

Tu as le n° du bug ?

Non, j'ai cherché comme j'ai pu avant de poster, mais je n'ai rien trouvé. Mais en testant une nightly de la suite, ça fonctionnait impec.

C'est quand tu as deux « img » qui ont la même valeur de « src », le 2e « alt » ne s'affiche pas.

[Invité]

C'est quand tu as deux « img » qui ont la même valeur de « src », le 2e « alt » ne s'affiche pas.

Pas que le 2ème, tous les suivants
Mais bon le principal c'est que ça sera corrigé pour Firefox 1.1

[calimo]

As-tu un document officiel qui confirme ce que tu dis ou c'est juste une constatation du comportement de différents navigateurs (j'avoue avoir testé avec firefox, opera ainsi que le machin nommé amaya, ça ne passe dans aucun des trois) ?

Tout ce que j'ai c'est ça : http://www.la-grange.net/w3c/html4.01/i ... r-entities
Rien qui ne l'interdit donc, mais rien ne l'autorise non plus...
En revanche en XML (donc en XHTML) c'est clairement défini : http://www.w3.org/TR/REC-xml/#sec-entity-decl

C'est pour ça que je pense que ce n'est pas possible en HTML (à part peut-être en reprenant la dtd du W3C et en la modifiant)

C'est quand tu as deux « img » qui ont la même valeur de « src », le 2e « alt » ne s'affiche pas.

Ça doit être ça, j'arrivais exactement à la même conclusion

Mais bon le principal c'est que ça sera corrigé pour Firefox 1.1

Et je pense que tu n'en aura pas besoin avant ?

[Bobe]

J'ai trouvé ça:
http://www.freebsd.org/doc/fr_FR.ISO885 ... /x748.html

Donc à priori, ce serait plutôt une insuffisance des navigateurs actuels dans leur gestion du sgml (dont HTML est une application).

Je cherche d'autres documents.

[calimo]

Cependant dans la déclaration SGML de HTML 4.01 il y a

Code : Tout sélectionner

                  NAMECASE GENERAL YES
                           ENTITY  NO

Pour savoir ce que ça signifie il faudrait voir dans la doc SGML... mais quelque chose me dit que ce n'est pas étranger à l'impossibilité des entités

[Bobe]

Non, cela concerne la politique à suivre concernant la casse des caractères.

Voir là (pas d'ancre, faire une recherche dans le document sur le mot "NAMECASE"):
http://xml.coverpages.org/wlw14.html

edit:

Ah, je crois que j'ai décroché la timballe là
Une analyse de la déclaration SGML de HTML 4.0:
http://www.webreference.com/dlab/books/html/3-4.html

Tout le document est interessant d'ailleurs:
http://www.webreference.com/dlab/books/html/3-0.html

Il y a une partie (voir sommaire) qui parle des entités. Je suis en train de la lire.

[calimo]

Bon, ben alors je te laisse ouvrir un bug sur bugzilla dans ce cas
(comme ça au moins on aura ouvert un bug dans ce sujet )

[Ptit Lutin]

Hello

Bon c'est décidé, je vais travailler en HTML 4.01 Strict !
(...et là vous me dites: "c'est pas toi qui disait :")

Parce que faire du HTML alors que le XHTML existe, c'est un peu dommage je trouve.

Oui oui j'ai dit ça mais changé d'avis !... et il y a des raisons à ce changement. Pour l'expliquer je vais reprendre le fil de ce sujet:

1. Pour un problème avec l'attribut alt, je crée ce sujet et poste mon code XHTML 1.1 défini avec un type mime text/html (comme indiqué dans le tutoriel du site du zéro)

2. calimo me suggère (à raison) de modifier ce type en application/xhtml+xml pour être valide XHTML 1.1

3. Je m'exécute promptement et, là encore fort justement, calimo me rétorque:

Ce qui compte c'est l'entête HTTP. C'est là qu'il faut mettre application/xhtml+xml. Si tu es directement depuis ton système de fichier, alors c'est l'extension qui compte, tu dois la mettre sur .xhtml

4. puis à ma question de novice:

Si je veux écrire une page en xhtml fonctionnant à la fois sous Firefox et IE comment je fais ?

me répond:

IE ne supporte pas le XHTML. Au mieux il traite le XHTML que tu lui as envoyé en text/html comme du html malformé, exactement comme Firefox, les navigateurs sont suffisemment tolérant pour que ça passe mais ça devrait pas.

5. Là je fais la moue ( ) puis me dis que j'aurai au moins appris quelquechose aujoud'hui :
pour du XHTML, le type mime est application/xhtml+xml
pour du HTML, le type mime est text/html

6. Je décide alors de prendre un cas concret et me penche sur ce que j'ai immédiatement sous la main (à savoir le code source du forum Geckozone) et là stupeur

Code : Tout sélectionner

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
...
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />

et calimo qui me confirme:

Si, c'est absolument valide XHTML.

Du XHTML avec un type mime text/html ! ... et valide en plus !
Interloqué je me dis: Hééé Lutin soit tu es dans les choux, soit il y a XHTML et XHTML !

7. Et il y a bien XHTML et XHTML (comme indiqué dans le document XHTML Media Types du W3C) ou plus précisément XHTML 1.0 et XHTML 1.1. Le premier tolère le type text/html (pour la compatibilité HTML) tandis que le second n'accepte que application/xhtml+xml.
Première réaction: Mais du XHTML que l'on définit en text/html c'est plus du XHTML c'est du HTML !
Deuxième réaction: C'est absurde d'écrire du XHTML en sachant pertinemment qu'il sera traité en HTML ! (avec les soucis d'interprétation que ça implique)

8. Sonné par ces révélations ( ) je me mets en quête d'avis sur le net et trouve ces articles assez intéressants:
XHTML ? non, HTML
XHTML 1.1, beaucoup de bruit pour rien
Laissez tomber le XHTML ?
Standards, être plus royaliste que le roi ?

9. Pour résumer on a (avis personnel ):
XHTML 1.1 : Le plus cohérent, puisque le XHTML est bien défini comme tel (application/xhtml+xml), mais malheureusement pas reconnu par IE (dans le cadre d'une diffusion à grand échelle c'est problèmatique)
XHTML 1.0 : Le plus insensé. Du HTML qui se prend pour du XHTML et inversement (limite schizophrène). Difficile de m'y résoudre

10. Bref, plutôt que de faire du faux XHTML, autant faire du vrai HTML !

Voilà donc ma petite histoire (un peu longue je l'avoue). Toute réaction est bienvenue . Pour ma part, je sais maintenant où je vais et pourquoi j'y vais donc tout va bien

[Bobe]

Ah, ça y est. Après la vague pro-XHTML (avec les aberrations du genre XHTML 1.1 envoyé en text/html notamment), voilà la vague rétro.
Allez, c'est décidé, demain, je refais mon site en HTML 3.2 (Cougar de son petit nom).

[calimo]

XHTML 1.0 : Le plus insensé. Du HTML qui se prend pour du XHTML et inversement (limite schizophrène). Difficile de m'y résoudre

Ah non ! Tu peux très bien envoyer du XHTML 1.0 en application/xhtml+xml, c'est d'ailleurs même ce qui est recommandé en fait.
C'est juste que si tu suis suis les règles de compatibilité, alors tu peux l'envoyer en text/html.

10. Bref, plutôt que de faire du faux XHTML, autant faire du vrai HTML !

Ouiiiiiiiiiiiiiiiiiiiiiiii !!!

Ah, ça y est. Après la vague pro-XHTML (avec les aberrations du genre XHTML 1.1 envoyé en text/html notamment), voilà la vague rétro.
Allez, c'est décidé, demain, je refais mon site en HTML 3.2 (Cougar de son petit nom).

Et pourquoi pas ? C'est un standard après tout...
Parce que HTML 3.2 ne contient rien pour le CSS, c'est vrai ! Mais pour le HTML 4.01, rien ne s'y oppose amha...

[Bobe]

Et pourquoi pas ? C'est un standard après tout...

Pourquoi pas HTML premier du nom tant qu'on y est ?

Les standards sont amenés à évoluer, à être remplacés par d'autres (standards ou version du même standard) plus évolués.
L'intérêt d'un standard, c'est aussi et surtout que même 20 ans après, on peut accéder aux données puisqu'on a accés au standard utilisé pour formater ces données. Cela ne veut pas dire que le standard en question peut (rien ne l'empèche cependant, sauf les implémentations existantes à ce moment là) être utilisé même 20 ans après son avènement (dans le domaine informatique du moins).

HTML 4.01, rien ne s'y oppose amha...

Oui.
En fait, mon message était mi énervé/mi humoristique.

Si on a vraiment pas besoin des avantages que procure le XHTML, autant rester en HTML 4.01. Je trouve juste ça dommage au niveau suivi des technologies récentes et relativement bien supportée.

Pour des pages statiques, et à moins d'accepter de réaliser deux versions pour chacune d'elle, une en HTML et une en XHTML, et de bien régler son serveur pour faire la négociation de contenu, cela ne vaut pas le coup pour l'instant, mieux vaut rester en HTML 4.01 (Ceci dit, il existe un module apache, mod_xhtml_neg, spécifiquement écrit pour permettre la sélection d'un des deux type de média pour une même ressource).

Maintenant pour des pages dites "dynamiques" servies par exemple à l'aide de PHP, ça devient beaucoup plus simple. Une dizaine de lignes de code (qu'on peut trouver très facilement sur Internet) suffit pour servir son XHTML 1.0 avec le type de média application/xhtml+xml ou text/html.

Le XHTML est du HTML, mais reformulé selon la syntaxe XML, très proche de celle du SGML (dont est issu HTML de même que XML). À partir de là, je ne vois strictement rien qui s'oppose à ce que le XHTML 1.0 puisse être envoyé avec le type text/html à défaut de l'être avec le type application/xhtml+xml, d'autant que c'est ce qu'autorise le W3C.

Tout cela reste bien sùr dans l'optique où on ne profite pas pleinement des possibilités offertes par le XHTML (Mixage avec du SVG, du MathML ou n'importe quel autre format XML), lesquelles sont de toute façon bridées par ces saloperies de DTD (Calimo en sait quelque chose ).

Malgré tout, je continue de servir mes pages en XHTML 1.0 en négociant sur l'en-tête accept envoyé par le client par:

- plaisir d'utiliser une techno récente (bah oui, et puis si personne les utilise, quelle évolution peuvent-elles espérer ?)
- Pas envie de brider les navigateurs récents à cause de quelques antiquités car:
- parser du XML est beaucoup plus simple que de parser du HTML qui, par définition, peut être du HTML valide aussi bien qu'une soupe de balise.

[bon, j'ai plus d'idée sur la fin. Rédiger un texte en discutant au téléphone, c'est pas simple , donc je complèterai si besoin]

[calimo]

Pourquoi pas HTML premier du nom tant qu'on y est ?

Les standards sont amenés à évoluer, à être remplacés par d'autres (standards ou version du même standard) plus évolués.

C'est exact. Cependant, pour le XHTML, c'est peut-être trop tôt (disons plutôt qu'il y a un outil qui empêche d'avancer).

Oui.
En fait, mon message était mi énervé/mi humoristique.

Ça j'avais bien compris

Si on a vraiment pas besoin des avantages que procure le XHTML, autant rester en HTML 4.01. Je trouve juste ça dommage au niveau suivi des technologies récentes et relativement bien supportée.

Maintenant pour des pages dites "dynamiques" servies par exemple à l'aide de PHP, ça devient beaucoup plus simple. Une dizaine de lignes de code (qu'on peut trouver très facilement sur Internet) suffit pour servir son XHTML 1.0 avec le type de média application/xhtml+xml ou text/html.

Et ce pour autant qu'on n'utilise pas de technos un peu poussées (MathML, Svg...)

Le XHTML est du HTML, mais reformulé selon la syntaxe XML, très proche de celle du SGML (dont est issu HTML de même que XML). À partir de là, je ne vois strictement rien qui s'oppose à ce que le XHTML 1.0 puisse être envoyé avec le type text/html à défaut de l'être avec le type application/xhtml+xml, d'autant que c'est ce qu'autorise le W3C.

Il y a quand-même ce document cité plus haut : http://hixie.ch/advocacy/xhtml

<br /> devrait être interprété <br>/> par un parseur sgml-compliant (et il y en a). Moi c'est le genre de trucs qui me gêne un peu, m'appuyer sur un bug des navigateurs (même encouragé par le w3c...)

Pour ma part, mes pages statiques sont (presque) toutes en HTML 4.01 ou en vrai xhtml (application/xhtml+xml). Je ne maintiens plus de page dynamique depuis que smilissimo a fermé, et malheureusement le moteur des extensions.geckozone (wikini pour ne pas le citer) n'est pas assez strict pour faire du vrai xhtml...

Toujours est-il que je serai le premier à applaudir des 2 mains quand on pourra enfin vraiment utilise le xhtml et toutes ses potentialités

[Thomas]

Toujours est-il que je serai le premier à applaudir des 2 mains quand on pourra enfin vraiment utilise le xhtml et toutes ses potentialités

On peut déjà. Tant pis pour Tu-sais-qui ^^

[Bobe]

Il y a quand-même ce document cité plus haut : http://hixie.ch/advocacy/xhtml

Oui, je connais.

"SPECIFIC PROBLEMS"

* <script> and <style> elements in XHTML sent as text/html have to be
escaped using ridiculously complicated strings.

ok, je suis d'accord, c'est pas très simple à gérer.

* A CSS stylesheet written for an HTML4 document is interpreted
slightly differently in an XHTML context

Non, ça c'est un problème de passage du HTML au XHTML (d'où éventuelle adaptation des feuilles de style liées). Écriture des noms de balise en minuscule dans le document et dans les sélecteurs CSS == pas de problème.
C'est un inconvénient ponctuel (adaptation).

* A DOM-based script written for an HTML4 document has subtly
different semantics in an XHTML context (e.g. element names are
case insensitive and returned in uppercase in HTML4, case sensitive
and always lowercase in XHTML;

Un peu plus génant en effet, mais un toLowerCase() sur les attributs nodeName qu'on manipule et c'est réglé.

you have to use the namespace-aware
methods in XHTML, but not in HTML4

Bah... De toute façon, puisqu'on envoit le doc en text/html, pas question d'y insérer des balises d'autres namespaces donc méthodes DOM *NS inutiles.

* Scripts that use document.write() will not work in XHTML contexts.
(You have to use DOM Core methods.)

Tant mieux

* Current UAs are, for text/html content, HTML4 user agents (at best)
and certainly not XHTML user agents. Therefore if you send them
XHTML you are sending them content in a language which is not
native to them, and instead relying on their error handling. Since
this is not defined in any specification, it may vary from one user
agent to the other.

Pas de réponse, je ne suis pas sùr de comprendre. Un agent utilisateur pourrait ne pas considérer le document comme du HTML (par exemple au vu du doctype) et le rejeter ?
Ça va quand même à l'encontre de la politique de tolérance de tous les navigateurs que je connais mais bon...

* XHTML documents that use the "/>" notation, as in "<link />" have
very different semantics when parsed as HTML4. So if there was to
be a fully compliant HTML4 UA, it would be quite correct to show
">"

ok, bien que je n'ai toujours pas rencontré de tels agents utilisateurs.

"COPY AND PASTE"

* Documents sent as text/html are handled as tag soup [1] by most UAs.

Pas de désavantage par rapport au HTML donc.

Les items suivants concernent des documents non-valides donc je passe.

* The "/>" empty tag syntax actually has totally different meaning in
HTML4. (It's the SHORTTAG minimisation feature known as NET, if I
recall the name correctly.)

Les navigateurs courants ont un comportement incorrect vis à vis de cette syntaxe mais ça ne la rend pas invalide pour autant donc c'est compatible HTML (ok, je pinaille). Ou alors j'ai mal compris et " />" est invalide en SGML.

* Script and style elements cannot have their contents hidden from
legacy UAs. The following XHTML:

Non recevable. Les vieux navigateurs ne gèrent pas même le XML donc à quel UA vondrait-on cacher le contenu d'un bloc <style> ou <script> ?
Voir aussi réponse plus haut.

* The "xmlns" attribute is invalid HTML4.

Les navigateurs n'utilisent pas de parseurs validant. Pour un parseur validant, je ne suis pas sùr qu'il s'interesse au type de média fourni par un quelconque moyen et récupèrera simplement la DTD (XHTML 1.0) liées au document (dans laquelle est bien déclaré l'attribut xmlns en question).

Why UAs can't handle XHTML sent as text/html as XML

Et heureusement! Puisqu'on leur dit que c'est un contenu de type text/html, ils n'ont (ou ne devraient avoir) aucune raison de le traiter comme du XML.

Pour résumer:

- Gestion des blocs de scripts (pour les blocs <style>, c'est pas indispensable) embarqués
- toLowerCase() si on manipule des attributs nodeName dans un script
- Un navigateur qui rejeterait un doc HTML sous prétexte qu'il arbore une DTD XHTML 1.0 ? J'y crois pas trop.
- Un vrai parseur SGML embété par cette même DTD ? Un vrai parseur SGML n'a pas vocation à parser des docs HTML publiés sur Internet vu qu'ils sont pour la plupart non-valides.
- Ce fameux problème de balise vide qui n'en est pas un car tous les navigateurs existants (à ma connaissance) s'en accomodent (c'est pas une raison mais c'est comme ça)

[Ptit Lutin]

7. Et il y a bien XHTML et XHTML (comme indiqué dans le document XHTML Media Types du W3C) ou plus précisément XHTML 1.0 et XHTML 1.1. Le premier tolère le type text/html (pour la compatibilité HTML) tandis que le second n'accepte que application/xhtml+xml.
Première réaction: Mais du XHTML que l'on définit en text/html c'est plus du XHTML c'est du HTML !
Deuxième réaction: C'est absurde d'écrire du XHTML en sachant pertinemment qu'il sera traité en HTML ! (avec les soucis d'interprétation que ça implique)

XHTML 1.0 : Le plus insensé. Du HTML qui se prend pour du XHTML et inversement (limite schizophrène). Difficile de m'y résoudre

Ah non ! Tu peux très bien envoyer du XHTML 1.0 en application/xhtml+xml, c'est d'ailleurs même ce qui est recommandé en fait.
C'est juste que si tu suis suis les règles de compatibilité, alors tu peux l'envoyer en text/html.

Je n'ai pas dit qu'en XHTML 1.0 il fallait utiliser text/html, juste que celui-ci tolérait text/html, donc que l'on pouvait utiliser text/html mais que application/xhtml+xml était conseillé.
Par contre quand j'ai dit que XHTML 1.1 n'acceptait que application/xhtml+xml j'avais tort (mais bon comme le précisait Bobe, XHTML 1.1 avec text/html c'est vraiment n'importe quoi )

Ce qui m'irrite le plus ce sont ces nuances:
- en XHTML 1.0 on peut utiliser text/html mais on devrait utiliser application/xhtml+xml
- en XHTML 1.1 on ne devrait vraiment pas utiliser text/html (mais c'est pas interdit) et on devrait utiliser application/xhtml+xml

On en arrive à une situation confuse où text/html en XHTML est plus ou moins bien toléré (l'appréciation étant laissée au navigateur) et où les utilisateurs se demandent que choisir (tiens ! qui vois-je )

Et on finit par se poser les mauvaises questions. Par exemple, en démarrant ce sujet, n'y connaissant pratiquement rien ni en XHTML ni en HTML mais soucieux du respect des standards, je me disais: ça serait bien d'utiliser XHTML plutôt que HTML... vous m'auriez demandé pourquoi j'aurais sûrement dit: parce que c'est plus récent ! (donc ça doit être mieux)... encore une victime de versionite aigüe
Obnubilé par les standards, j'en avais occulté les questions essentielles:
Quel est mon objectif ? et Quelles sont mes contraintes ?

Ce n'est qu'après avoir répondu à ces questions que je peux me poser cette troisième: Quels sont les standards les mieux adaptés pour atteindre mon objectif tout en tenant compte des contraintes ?

Personnellement, vu que je dois écrire un système d'aide (objectif) lisible sur les navigateurs les plus courants (contrainte), HTML 4.01 Strict suffit et me semble le plus cohérent.

En clair, choisir le standard en fonction des besoins

- T'as vu mon site il est XHTML 1.0 !!!
- c'est le même qu'avant non ?
- ben nan ! maintenant c'est en XHTML 1.0 !
- le type mime c'est application/xhtml+xml ?
- ben nan c'est text/html... mais c'est valide en XHTML 1.0 si si !
- Et c'est mieux qu'en HTML 4.01 ?
- ben ouais c'est en XHTML 1.0 !
- ...
- c'est bien hein !!!