Xhtml et validité de certains attributs

[xpatval]

Bonjour/'près-midi,

Pourriez-vous me dire si les attributs (je les appelle comme cela) "onfocus", "onmouseover", etc. sont permis en XHTML strict ?

Et s'ils le sont, comment doit-on les coder ?

Question posée car lignes non-validées par le validator, sur des éléments <a href> avec "onMouseOut" qui semble poser problème

Merci,

xpatval

Modifié 22 Janvier 2005 par xpatval

[Country]

Ils sont permis mais il faut les écrire en minuscule (comme tous les attributs en XHTML) , donc en écrivant "onmouseout" tu ne devrai plus avoir de problèmes de validation

[xpatval]

Y'a vraiment des fois, où, j'te jure, des fois, non mais sans blague !

Merci, that was the solution.

xpatval

[Denis]

Utiliser ces attributs en strict ne pose aucun problème, tant et aussi longtemps que la grammaire est respectée, c'est vrai. Par contre (et c'est peut-être la raison pour laquelle tu poses la question au départ), leur utilisation peut entrainer des problèmes d'accessiiblité s'ils servent à introduire des fonctions javascript qui elles, seraient essentielles à l'utilisation du site sans que ce dernier n'offre de méthode de contournement via un noscript ou du code HTML approprié...

[Ganf]

Ces attributs sont valides, les autres l'ont dit. Maintenant je ne comprend souvent pas pourquoi ils sont utilisés dans les pages avec un modèle strict.

Quel est le but mené quand tu as choisi le modèle strict ?

Si c'est séparer la description du contenu de sa présentation (pour ne pas mettre des <font> à chaque fois par exemple), pourquoi alors gardes tu ces attributs de comportement au milieu de ta description de contenu ? sauf des cas exceptionnel ça ne me semble pas logique.

Si tu veux une idée de ce que j'entend par là je te propose de lire la seconde moitié de l'article http://cybercodeur.net/weblog/articles/art_20041030.php sur Cybercodeur.net

J'y parle de l'utilisation de onclick pour ouvrir des nouvelles fenêtres mais ça peut s'appliquer à tous les on* de manière générique.

[xpatval]

...seraient essentielles à l'utilisation du site sans que ce dernier n'offre de méthode de contournement via un noscript ou du code HTML approprié...

Ces attributs, dans le cadre de ma question, définissent les états successifs de boutons, générés par fireworks ou photoshp.

Bien entendu, comme tu le dis, si le bouton n'est qu'une chaîne de caractères, sans graphisme particulier, la simple définition des différents états, par HTML ou CSS suffit.

Dans le cas de graphisme particulier, et voulant être conservé par le client, j'ai conservé les attributs onmouseout, onmouseover, appelant du javascript, d'où mon post d'origine.

Maintenant, s'il existe une autre méthode, je suis preneur...

xpatval

[LaurentDenis]

Ils sont permis mais il faut les écrire en minuscule (comme tous les attributs en XHTML) , donc en écrivant "onmouseout" tu ne devrai plus avoir de problèmes de validation

<{POST_SNAPBACK}>

Une remarque : les spécifications, les "standards" si vous préférez, n'ont pas vraiment pour rôle premier de vous renseigner sur ce genre de choses. Ils ont plutôt pour but de permette l'élaboration et donc l'utilisation d'outils gérant cela à votre place.

Ce qui est amusant, là, c'est que très peu de gens, avant de poser ce type de questions, passent simplement leur code à travers un outil comme "Tidy", dont le rôle est justement de gérer cela, en passant automatiquement les noms d'attributs et d'éléments en minuscules

AMHA, avant de se poser une question sur la non-validation d'une page Web, on devrait d'abord voir ce que donne la même page après passage dans un outil tel Tidy. Par exépience, le gain de temps est considérable.

[Ganf]

Dans le cas de graphisme particulier, et voulant être conservé par le client, j'ai conservé les attributs onmouseout, onmouseover, appelant du javascript, d'où mon post d'origine.

cf l'article que j'ai cité, il est possible dans une majorité de cas de faire un marquage fonctionnel avec des classes ou ce genre de chose, de définir des comportements dans un fichier javascript externe et de relier les deux avec des gestions d'évenements DOM.

Au niveau technique ça marche exactement pareil que les on* dans le code HTML mais sur le principe c'est AMHA beaucoup plus dans la philosophie de conception de stricte séparation. C'est un peu plus complexe à coder au départ, par contre ça amène probablement plus de confort et de simplicité sur le long terme. A toi de voir si ça correspond à ce que tu cherches.

passent simplement leur code à travers un outil comme "Tidy", dont le rôle est justement de gérer cela

Pour moi c'est un peu comme si tu conseillais aux gens de ne pas se préoccuper de l'orthographe et de la grammaire parce qu'il y a un correcteur dans le traitement de texte.

Ces outils sont intéressants, ils sont certainement sous utilisés, mais ils ne sont que des roues de secours ou des "dernière étape".

Ce d'autant plus qu'ils souffrent du même problème que les navigateurs et les correcteurs de traitement de texte : l'ambiguité et la connaissance restreinte.

Comment tidy va bien pouvoir corriger "<b> hello <p> World " ? comment peut il savoir si ce que cherche à faire l'utilisateur c'est réellement le théorique <p><b> hello </b></p><p> world </p> ou si c'est <p><b> hello </b></p><p><b> world </b></p> ? difficile voire impossible de savoir. Voilà pour le problème d'ambiguité.

Pour les attributs il peut éventuellement repérer qu'il y a des majuscules en trop parce qu'il a été programmé pour vérifier ce point de détail particulier. Mais que fera t'il quand il tombera sur une erreur non prévue ? genre oublier le "v" de onmouseover ?

Les outils comme tidy c'est très bien pour essayer de voir ce que corrige le logiciel, mais ça ne remplace pas la connaissance pour le rédacteur de ce qui est "juste" ou "faux". Ca n'empeche pas le rédacteur de devoir essayer de taper juste dès le départ. D'autant que comme tous les correcteurs automatiques, des fois il se plante sur ce que voulait réellement faire le rédacteur et corrige d'une mauvaise manière.

[Dash]

Les outils comme tidy c'est très bien pour essayer de voir ce que corrige le logiciel, mais ça ne remplace pas la connaissance pour le rédacteur de ce qui est "juste" ou "faux". Ca n'empeche pas le rédacteur de devoir essayer de taper juste dès le départ. D'autant que comme tous les correcteurs automatiques, des fois il se plante sur ce que voulait réellement faire le rédacteur et corrige d'une mauvaise manière.

<{POST_SNAPBACK}>

Un exemple flagrant : je me suis apercu qu'avec PHP4, meme avec un doctype 'XHTML 1.0 Strict' Tidy rajoute systematiquement un attribut "name" au formulaire. De temps en temps, Tidy ne nettoit rien, au contraire il lui arrive de degrader la qualite d'un code HTML initialement correct... On aurait mieux fait de s'en passer.