Bonjour,

Quand on soumet son code à un validateur pour la première fois, une longue liste d'erreurs peut être décourageante :nono:

Pour vous aider à éviter cela, j'ai publié une liste d'erreurs fréquentes et faciles à éviter.

Cette liste n'est pas exhaustive, hélas, n'hésitez pas à en signaler d'autres.

Pour faire une présentation sympa, j'utilisais le code #149; pour faire un bullet
N'étant pas au standard du W3C, je l'ai remplacé par •
Mais lorsque je regarde ma page avec le viewver lynx, je vois en clair • dans la page.
Qu'est ce que je peux utiliser de mieux ?

Si l'utilisation d'un validateur est utile, il est indispensable d'utiliser une documentation VALIDE. Or j'ai fais tout mon site avec une doc fausse, tout du moins sur le plan 'validator'. Je me retrouve avec tout un tas de fautes..

Voilà, A+, AnonymuS.

Dans ton article, tu dis :


J'ai déjà lu ca quelque part, et ca m'avait paru tellement ... pas possible, que je n'y avais pas prété plus attention. J'aimerais en avoir le coeur net :
<a href="foo.php?id=1&id=2">foo</a>
Ca, c'est pas valable ????
Et tant qu'on y est : mettre des apostrophes ' ' ' ' ' ' à la place des guillements " " " " , dans le <a href, c'est valable, ou pas ?

Merci, A+, Anonymus.

Anonymus,

Regarde ce post d'Ernestine: http://www.webmaster-hub.com/index.php?sho...findpost&p=1583

C'était très exactement le même cas de figure.

Je sais qu'Invision travaille à la validation XHTML de son forum, et que ces &amp; dans les différents liens sont dans le champ de tir

Dan

Effectivement, il y a un an encore, il n'existait pratiquement pas de sites valables en français. Aujourd'hui encore, plusieurs d'entre eux considérés comme référence, ne se sont pas encore mis à jour et continuent donc de recommander... des erreurs :down:

Quand j'ai débuté, en réponse à mes questions un peu naïves, on me proposait le site du W3C. Même si je parvenais à la page recherchée, je n'y comprenais rien... mon dictionnaire ne m'était pas très utile pour le vocabulaire trop spécialisé

Dans mes articles, je fais référence aux traductions (fidèles) du W3C. L'URL vers la version originale en anglais s'y trouve toujours.
Je prépare une petite liste d'autres sites indispensables à connaître

Il manque une erreur à la liste

Elle est assez fréquente, surtout si l'on utilise des langages qui génerent une page html, c'est le fait qu'il faut utiliser des ID uniques, en somme pas deux ID identiques dans une page.
C'est un oublit fréquent dans les faq

Sinon, je pense ne rien avoir à redire si ce n'est que c'est du bon boulot

Bonjour Xethorn,

Je parle de l'identificateur ID dans les articles consacrés aux feuilles de style, mais je pense que tu fais allusion à son utilisation dans les scripts (tel que JavaScript) ?

Il est vrai que je ne maîtrise pas du tout ce langage, et l'utilise très rarement.
Ce type d'erreur est-il signalé par le validateur HTML ?

La mise en forme doit être séparée du contenu... Est ce que width et height peuvent quand même rester dans la balise ?? ou faut il creer une classe pour chaque image
<img src="image.gif" width="460" height="108" alt="description">

Anonymous >


Non ce n'est pas valide ni l'un ni l'autre.
Il faut bien remplacer les "&" par des "&amp;"
Il faut utiliser des " au lieu des ' pour les valeurs des attributs

ams51 >


Effectivement il faut créer des classes pour les "types" d'images que tu utilise souvent (comme des boutons par exemple ou des screenshots)
Pour les autres images, ne mettre ni width, ni height, ni classe : Elle seront affichée à leur taille normale une fois chargée, pas la peine de fixer une taille prise par l'image.

Bonjour,

Les dimensions d'une image sont un cas un peu à part.

Si elles ne sont pas renseignées dans le code, le navigateur affichera d'abord le texte puis le déplacera en fonction des images à y insérer => un effet pas très heureux et assez inconfortable pour le visiteur, un temps plus long avant que le contenu puisse être réellement consulté.

Si elles sont renseignées, le navigateur affichera d'abord le texte mais en réservant l'espace utile aux images => l'internaute peut commencer sa lecture avant l'affichage complet de la page.

Merci,
Mon problème est là, sur certains site j'ai plusieurs images, lorsque je teste avec un modem RTC l'affichage de la page est parfois lent (>10 secondes) et l'écran n'arrete pas de bouger, donc pour commencer à consulter la page il faut attendre le chargement complet.
Le hic, chaque image a ses propres dimensions et je ne vais pas creer une classe pour chacune d'elles....

Je crois que pour ce cas particulier je ferai une entorse aux normes Dans mes créations futures j'harmoniserai la taille des images dans la mesure du possible.

Tu peux être rassuré et tu dois continuer à renseigner la taille de tes images dans le code (et non via CSS) : ce n'est pas une entorse aux normes, width et height font partie des attributs de l'élément img

merci

J'avoue avoir du mal avec les définitions des normes... beaucoup trop de doc à lire

salut

pour mettre mon grain de sel, si tes images ont toutes une dimension différente, il est mieux d'utiliser <img style="width:...px;height:...px" pour chacune

c'est tout à fait valide, et justifié, et cela te permet d'éviter les sauts de texte comme expliqué plus haut

sinon tu peux choisir de faire toutes les images à la même dimension, ou n'avoir que 2 dimensions, par exemple pour les images en portrait et en paysage, et dans ce cas là effectivement définir des classes est le plus simple

essaie aussi au maximum de mettre en css les images qui se retrouvent sur plusieurs pages et qui ne sont là que pour décorer, tu éviteras ce problème et tu n'auras pas besoin de alt

Totalement inutile. Comme le rappelait Monique, width et height sont des attributs (X)HTML valides pour l'élément img

<img src="..." width="..." height="..." alt="..." />

Passer les déclarations de dimensions d'images en CSS n'apporte aucun gain de validité ni de sémantique. En revanche, cela alourdit inutilement le code avec des styles internes et complique la tâche.

Quant à placer en css les images purement décoratives.... Oui, tout à fait.

D'ailleurs width et height sont toujours valides même en xhtml, cf W3C :
http://www.w3.org/TR/xhtml-modularization/...l#s_imagemodule

J'apporte mon support à Monique, Laurent et les autres à propos des dimensions des images. Mis à part que ces attributs demeurent tout à fait valides en (x)html, certains pourraient avancer que les dimensions des images sont de l'ordre de la présentation, donc qu'ils devraient faire parti de la CSS. Je ne suis pas sûrs qu'ils aient totalement tort, mais cela va tellement à contre-sens de la logique que je me refuse à m'y plier, ne serait-ce que pour ne pas me ramasser avec un fichier CSS et HTML combiné de 325k pour couvrir toutes les images avec les classes y étant rattachées.

Si toutes mes images étaient de la même dimension, je le ferai probablement, simplement pour alléger au maximum mon code, mais comme c'est rarement le cas...

Pourrait-on plus avancer que les attributs height et width sont principalement de l'ordre de la structure du document et donc qu'ils devraient absolument demeurer dans le fichier HTML ? J'aimerais bien trouver une vraie référence là-dessus, c'est une question que je me pose souvent. Selon la simple logique, ils penchent plus du côté de la valeur structurelle que présentationelle.

Il semble y avoir une démarcation entre ces deux attributs et l'attribut border qui lui, est définitivement considéré comme de l'ordre de la présentation. En même temps, il est facile de le régler par un simple img {border: 0;} dans la feuile de style, peu importe le nombre d'image affectées. Mais quelle est l'argument irréfutable et documenté qui différencie border de width et height ? Je le cherche encore...

Denis, je te propose quelques éléments :

D'abord, voici le discours plutôt contourné de la spécification HTML4.01:
http://www.la-grange.net/w3c/html4.01/stru...cts.html#visual



Donc height et width ne devraient être utilisés que quand on demande au media de ne pas respecter les dimensions natives de l'image ?

Mais non, car ce n'est pas fini :



Autrement-dit, height et width peuvent être utilisés dans tous les cas pour faciliter le travail du navigateur... Ou alors, on ne les utilise pas... mais rien n'invite à les remplacer par des règles CSS.

Pour ma part, je prendrais le problème sous un autre angle, celui des objets :

- Une image est essentiellement un objet non HTML inclus dans le contenu. On peut l'assimiler à l'élément object, même s'il n'est pas utilisé, voir http://www.la-grange.net/w3c/html4.01/stru...ml#edef-OBJECT. Cet objet étant par nature visuel, il semble logique de le définir, outre la source, par ses paramètres visuels de base, c'est à dire ses dimensions. Il en est de même pour une animation Flash, du java ou surtout pour du SVG.

- En revanche, la présence ou l'absence d'une bordure ne définit en rien l'image ou l'objet inclus dans le contenu. Juste sa présentation...

- Enfin et surtout, d'un point de vue pratique et pédagogique, width et height sont des mécanismes valides, simples, relativement connus, dont bénéficie l'utilisateur puisque l'affichage de la page est amélioré pendant le chargement des images...

[edit]Voir une argumentation mieux documentée Taille des images et séparation excessive du contenu et de la présentation en cas de doute sur la validité de width et height [/edit]

Après réflexion je pense un peu comme vous... Il y a 2 cas :
- soit on fixe les dimensions pour que la présentation de l'image colle bien à notre design dans ce cas c'est le contenant donc ça va dans le CSS (image de déco ou diaporama par exemple)
- soit les dimensions sont utilisées pour fixer les dimensions de l'image pour aider le navigateur... Et là on est dans le contenu donc dans l'html.

Passez un bon 1er Mai et un bon week end

Merci Laurent pour l'éclaircissement... ce sont de très bonnes indications qui font beaucoup de sens. :up:

salut





merci laurent, alors ça veut dire que je n'ai plus besoin de m'embêter à changer ça quand j'insère une image avec dreamweaver ? cool

mon truc a-t-il un autre inconvénient, à part l'inutilité, et devrais-je revenir à <img src="..." width="..." height="..." alt="..." /> ?

(édité, j'avais confondu laurent et denis)

Mais comment diable as-tu pu nous mélanger ? Il aime les chevaux et moi, les sushis...

Cela pourrait être gênant pour l'évolutivité de tes pages, car les styles internes ne seront peut-être pas supportés dans toutes les spécifications futures (Le Working Draft XHTML2.0 hésite à les interdire)

Plus généralement, les styles internes sont à décourager, car ils ramènent les données de présentation dans le HTML. Cela dit, il arrive parfois qu'il soit difficile de s'en passer :-(

Bien que ce soit vrai, je ne crois pas que le commun des mortels ait à se soucier de ce qui prévaudra dans XHTML 2.0 pour l'instant. À la vitesse ou le médium évolue, il faudra bien encore 8 à 10 ans avant que XHTML 2.0 ne devienne massivement utilisé par les développeurs. XHTML 1.0 est LA norme plancher retenue par le W3C depuis le 26 janvier 2000 et encore aujourd'hui, plus de 4 années plus tard, le HTML demeure le langage le plus massivement utilisé par ceux-ci... et généralement très mal en plus.

Bien sûr, parmi nous qui sommes plus au pouls du W3C, cparle t-on peut-être plus de l'ordre de 3 ou 4 ans avant de voir un virage important vers XHTML 2.0 (en autant que les navigateurs suivent), mais même dans ce cas, une telle préoccupation me semblerait excessive pour le moment, ne serait-ce que parce que rien n'est encore figé à ce niveau.

À propos, a t-on des nouvelles de l'évolution de XHTML 2.0 ? L'année dernière, le HTML Working Group sortait un working draft aux trois mois et depuis plusieurs mois, plus rien. Peut-être y a t-il du monde qui s'essoufle au W3C ?

Je suis tout à fait d'accord avec toi sur le fond.

Mais XHTML2 a cependant un intérêt pour tout concepteur, justement dans la mesure où il pose plus de question qu'il n'en résoud: c'est un outil utile pour mettre en évidence les zones douteuses du HTML / XHTML actuel, comme l'usage de <br />, les styles internes, la nécessité d'une bonne utilisation conjuguée du titrage et des <div>... Bref, une invite à bien réfléchir sur ses choix de balisage.

J'ai bien peur que l'évolution a attendre ne dépende trop de l'avenir d'internet explorer...
En situation de monopole ou de quasi-monopole, c'est toujours la même chose...
malheureusement.....

Dino

Non.
On est très loin de pouvoir poser la question en termes d'implémentation dans IE ou dans un autre navigateur.

Un rappel salutaire à lire impérativement quand on s'intéresse à XHTML2 : XHTML 2.0, le vilain petit canard

(Par ailleurs très clair sur le processus d'élaboration d'une recommandation/spécification/norme du W3C, et pour cause, vu l'auteur )

Laurent, tu fais très bien de ramener le billet de Karl. Je me rapelle très bien avoir été du lot à prendre le mors aux dents à cette époque, influencé par tous ces Pilgrim et Zeldman qui voyaient XHTML 2.0 d'un mauvas oeil. Je me rapelle également avoir débattu de la question avec toi, bien avant d'avouir une fonctionnalité de commentaires sur C² (à lire si vous voulez un peu rigoler de mon inconsciente jeunesse) :

http://www.cybercodeur.net/index.php?idmes...=266#archive266

J'ose même pas me relire. Je ne sais donc plus à quel point je disais des bêtises. Heureusement, j'en suis un peu revenu à un moment donné :

http://www.cybercodeur.net/index.php?idmessage=94#archive94



Ce qui est clair, tout ça pour dire que non, je ne crois pas non plus que MS pourra influencer le développement de XHTML 2.0... pas plus qu'ils ont pu influencer XHTML 1.0 ou 1.1

Tout d'abord bravo Monique pour ces articles clairs !

Bon, j'essaie de valider une page en xhtml ( hé oui je me lance !) et je rencontre un pb de validation du code suivant , le terrrrrible validator me renvoyant plusieurs erreur sur cette ligne :



(Pour le border="0" en trop, je viens de voir la solution dans les articles et posts, donc considère qu'il n'y est déjà plus )

A propos, j'avais tenté de mettre rows et cols en feuille de style mais ça marche pas.

Ai-je fait une erreur ou TEXTAERA (en majuscule uniquement pour le besoin du post ! ) n'est pas reconnu ??

A noter que, dans la page, jutilise 3 fois ce genre de ligne, cela a ptet son importance bien que je ne pense pas...

Boonsoir,

eh bien, si je ne me trompe pas, tu fais une mauvaise utilisation de l'élément textarea ... cet élèment fait partie d'un formulaire, et donc n'a pas à être là où tu le places...

Un petit tour sur cette définition te permettra de comprendre en quoi !
Sans oublier qu'il te manque un attribut important dedans... mais là je te laisse chercher un peu

Bonjour Michel,

Pour une réponse plus précise, il serait utile de savoir quelle est la page tu as soumise au validateur.
Quel doctype as-tu utilisé ? Si c'est en strict, le target_blank n'est pas autorisé.

Pour le textarea, je pense que la réponse de ste devrait t'aider à trouver

Quel c.. je suis !!!!! :down:

En effet ! Bon, je pense que je dois pouvoir mettre un formulaire bidon avec uniquement la boîte de texte.

Je vais visiter ton lien pour voir ça.. Merci !

Quant à l'attribut qui manque c'est ptet name mais chuis pas certain.


Monique ce n'est pas du strict, le doctype est :

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">

Mais tant qu'à faire, faisont mieux, alors je vais remplacer _blank par.... heu... _top ?

C'est juste une page test qui n'est pas publiée dans cette version.

Ouf ! page validée xhtml !

Ben chuis content et, c'est une page mineure dans le site ok, mais j'ai quand même mis les boutons W3C héhé ! (mon css est validé depuis quelques jours)

Pour info, ça peut servir à d'autres : un des problèmes majeurs, outre le fait que j'avais oublié que TEXTAREA doit être dans un formulaire [merci ste !], c'était que le texte qui se trouve dans le bloc (destiné uniquement au copié-collé pour le visiteur) contenait des liens href et img.

Dans ce cas, faites gaffe aux caractères tels que < et >!.

C'est très bien expliqué dans l'article de Monique à qui je dois une fleur

Bon, va me falloir bosser pour compléter le formulaire afin que le visiteur reçoive le code chez lui par mail, et ceci dans le respect du code.

Nom d'un cigogneau déplumé, il est tard mais j'vais me payer une bière pour fêter ça !

Bravo, c'est un bon début ! Maintenant le défi, ce serait de voir si tu es capable de passer le tout en XHTML strict... tu y es presque.

En effet ... c'est bien cela ; sois-en sûr !

Allez une autre recommandation utile et importante à retenir :
Créer ton formulaire pour qu'il soit accessible selon la recommandation WAI du W3C :
Une page à lire : Utilisation des formulaires

Bon, je sais, je tatille, je tatille...
Mais, cela te permettra à créer des formulaires qui soient corrects, accessibles.
(intégration des éléments legend, label, select, et autres attibuts id, tabindex, etc...)

Allez, courage

P.S : bien heureux du coup de main

C'est la suite logique des choses et j'y ai pensé.

Puis, bon, il y a les autres pages...

Bonjour tout le monde,

Je ne suis pas sûr d'être à la bonne place pour mon problème de «aller en haut».

Je voudrais pouvoir remonter en haut de page en cliquant sur une image, en bas de page.
Définition de la cible :

Petite image invite à cliquer dessus pour aller vers la "cible":

Excellent en html. Mais, le '#' n'est pas accepté en XHTML. Comment faire ?
Amitiés, pandrekano

???
le "#" est parfaitement accepté en XHTML.

Bonjour Laurent,

J'arrive même plus à retrouver l'erreur que je signalais. Par contre, après des tas de manipulatios, j'ai maintenant d'autres erreurs quand je passe le validateur WC3.

Le problème se trouve à :
En fait à toutes les vignettes de la galerie.

Mais quand on clique sur l'image, la page remonte !!!

Amitiés, pierreandre

Ca parait logique qu'il ne soit pas validé... Ton </head> est loin loin au milieu de ton code...

<edit> ah, tu devais être en train de changer, l'erreur a été enlevée...
Te reste a mettre des guillemets autour de menugauche
</edit>

Merci SARC et Laurent,

Il y avait un paquet d'erreurs... J'ai tellement «taponné!» que je ne sais même pas ce que j'ai fait...

Par contre tout est résolu et fonctionne avec le validateur WC3.

Tu avais parfaitement raison Laurent «#» est OK pour le validateur. Je ne sais pas pourquoi il me l'avais montré... parmi beaucoup d'autres erreurs !

Un petit exemple de mon ignorance et excusez-moi pour le «bruit»!
J'étais (je suis) vraiment perdu !

Amitiés, pandrekano

Bonjour,

J'espère pouvoir passer au Scrict un jour, mais je trouve que la problèmatique n'est pas tellement dans le codage, mais plutôt dans l'adaptation de scripts divers et variés qui rendent quasi-impossible de garder un site valide dans la durée.
Pour en venir au sujet du thread, je suis particulièrement agacé par la syndiquation de contenu car même si la page est valide, il est courant que le simple fait de vouloir afficher un feed XML donne tout un tas d'erreurs sur lesquelles je peux difficilement intervenir.
On se retrouve avec des dizaines d'erreurs sur la même ligne, provenant du parser XML

Bonjour à tous

je me permets de reprendre ce post pour une petite question de conformité XHTML des url avec paramètre.

j'utilise un paramètre tout simple GET pour passer la référence d'une image à afficher dans une galerie :



cette url n'est pas encodée, mais pas de soucis vu que le ? est conforme.

j'utilise dans la page un petit script PHP pour le compteur de visites qui démarre une session à chaque nouvel accès, ce qui signifie qu'un PHPSESSID est passé à chaque rechargement de page, et ce de manière transparente (enfin ça dépend pour qui)



et c'est là que le validateur me laisse en carafe, car le & n'est pas encodé. Je pense que c'est d'ici que vient l'erreur. D'ou ma question : comment encoder ce caractère qui n'apparait nulle part dans mon code ?
J'ai bien pensé à un URLENCODE / DECODE mais ou le faire intervenir ?

merci pour vos conseils !

(à mettre dans un fichier conf si possible).

Plus de détails : http://www.php.net/manual/fr/function.ini-set.php

Problème résolu !!! PHP RULES !!! (j'ai mis les init_set en début de script, c'est pas très propre...)