LaurentDenis

Tout ceci est également très bien expliqué dans les spécifications : http://www.la-grange.net/w3c/html4.01/appe...es.html#h-B.2.2 Très franchement, la démarche consistant à "apprendre" en codant un peu au hasard et en cherchant à partir des messages d'erreurs des validateurs me semble douteuse. Aucun des deux validateurs n'a été conçu comme un "précepteur" d'apprentissage. C'est une erreur de l'utiliser de cette manière, ou d'encourager à le faire. Pourquoi ne pas commencer, avant de soumettre un code au validateur ou à la sagacité des autres auteurs, par vérifier que sa syntaxe est conforme aux règles les plus apparentes et aux exemples donnés par la spécification ? Certes, ici, le fait de vouloir aborder immédiatement XHTML sans avoir les bases du HTML4.01 rend la consultation des spécifications plus difficiles, puisque deux spécifications doivent être consultées (C'est d'ailleurs pourquoi je ne crois pas qu'il faille recommander XHTML aussi vite qu'on le fait en général.) Mais tout de même, par exemple : - j'ai un formulaire à écrire; - je vais dans l'index des éléments de la spécification HTML4.01 pour trouver le lien vers le chapitre formulaire; - je lis rapidement l'introduction et je trouve un modèle prêt à l'emploi: En utilisant cet exemple, j'ai une structure valide et en outre accessible :j'apprends au passage à utiliser <label> et je prends de bonnes habitudes. Evidemment, en voulant faire tout de suite du XHTML, j'ai encore à modifier sa syntaxe...

Il me semble que c'est une option qui peut être modifiée dans Dreamweaver. Sinon, passe par n'importe quel éditeur texte (le bloc note de Windows par exemple).

Si ma mémoire est bonne, à cause des problèmes de supports partiels et variés selon les navigateurs et les lecteurs d'écran anciens, il est prudent de répéter l'information dans les attributs alt et title. Quelqu'un peut confirmer ?

Javascript ne convient pas. Tu peux le faire en php... Mais si tu peux utiliser php, tu peux du coup remplacer ta combinaison d'imagemap et d'iframe par des pages sans cadres et des includes php pour ton menu...

Formellement, oui Reste à tester ce qui ne peut être repéré par la machine et que seul l'utilisateur peut expérimenter... Cela dit, une erreur qui a curieusement échappé aux validiteurs : les boutons de soumission des formulaire n'ont plus de libellé sans CSS, autrement dit dans un navigateur texte, un lecteur d'écran, etc: <input class="envoyer_bleu" name="submit" type="submit" value=" " /> <input class="rechercher" type="submit" name="submit" value="" /> avec input.envoyer_bleu{ background-image: url(../image/envoyer.gif); } input.rechercher{ background-image: url(../image/rechercher.gif); } Et un lien dont l'intitulé est dénué de sens hors contexte : <a href="http://www.fnac.com/Shelf/article.asp?...">Cliquez</a>

Une petite imprécision dans http://www.crajkaro.com/iddotclear.php Pour le titre de post : tous les titres ont la même classe "post-title", mais l'id change à chaque billet : id="p1", id="p2", etc... Donc, en CSS, ne pas utiliser ces id

Bah... Ne fais pas attention à mes petites crises de défenseur des DTD ignorées Sinon, je suis complètement rouillé, ou bien une simple : <frame src="centre.html" name="centre" marginwidth="100" /> ...suffit effectivement à centrer un cadre dans des marges de largeur fixe ?

Ce fil est tout à fait à sa place, et les frames sont tout à fait légitimes en XHTML et CSS : ce n'est pas pour rien qu'existent les DTD HTML4.01 frameset et XHTML1.0 frameset. En revanche, il est vrai que les frames sont de moins en moins employées (ou devraient l'être sauf pour porter un contenu existant aux normes), en raison: - des problèmes récurrents d'accessibilité et de navigabilité qu'ils posent, - des alternatives offertes par la généralisation du PHP et des include. C'est pourquoi cette question tarde à recevoir une réponse : il y a déjà pas mal de temps que pour ma part je n'ai plus utilisé de frames, et je suis loin d'être le seul dans ce cas ici Cela dit, l'url de la page en question nous faciliterait ce petit travail de mémoire assez intéressant

Si tu n'as pas d'url de test à indiquer, précise ta demande : tu utiles des frames, et que tu voudrais utiliser le title de chaque frame pour faire un menu de navigation dans un des cadres ?

Pour ton "scroll", place ce code dans ta page: <div style="width: 500px; height: 400px; overflow: auto; text-align: center;"> <h3>Titre</h3> <p><a href="..."><img src="..." height="100" width="100" alt="..."></a></p> <p>Le texte</p> <p><a href="..."><img src="..." height="100" width="100" alt="..."></a></p> <p>Le texte</p> <p><a href="..."><img src="..." height="100" width="100" alt="..."></a></p> <p>Le texte</p> <p><a href="..."><img src="..." height="100" width="100" alt="..."></a></p> <p>Le texte</p> </div> En modifiant selon tes besoins: <div style="width: 500px; height: 400px; overflow: auto; text-align: center;"> - width: pour la largeur de ton "scroll" - height: pour sa hauteur - text-align: center, ou left, ou right pour l'alignement du texte et des images <a href="..."><img src="..." height="100" width="100" alt="..."></a> - href pour l'url des pages ou des fichiers sons visées par le lien - src pour l'url des images - height et width pour la taille des images - alt pour le titre de chaque album

Bon, il y a un minimum à savoir pour ne pas rester démuni devant le validateur : Le validateur ne te dit pas que tes variables ne sont pas définies. Ce qu'il te dit, c'est que l'entité &f n'est pas définie. Ce qu'on appelle les entités n'a rien à voir avec ton script ni avec tes variables... cela désigne la représentation codée d'un caractère affichable. Par exemple, le caractère € (euro) peut s'écrire de 3 manières : - directement avec € - encodé en entité caractère &euro; - encodé en entité numérique &#8364; Tous les caractères sont ainsi représentables. Le caractère & (ampersamp, esperluette) s'encode lui-même sous la forme &amp; Une entité commence toujours avec le caractère & et se termine toujours par un point-virgule. Dans une page Web, ce caractère & sert uniquement à introduire une entité caractère ou numérique. Mais il se trouve qu'il est utilisé pour tout autre chose dans les url passant des variables multiples. Il doit alors lui-même être encodé afin de ne pas risquer d'être interprété comme le début d'une entité du type ci-dessus : lorsque le validateur lit &amp;Blabla, il sait que &Blabla n'est pas le code (entité) d'un caractère, et qu'il doit l'ignorer. La présence d'un & non encodé dans une url déclenche donc une double erreur dans le validateur : - entité inconnue : par exemple, &f est un encodage qui n'existe pas (il ne représente aucun caractère) - référence à une entité non terminée, car toutes les entités se terminent par un point virgule, et le validateur n'en trouve pas après le &f Fais un simple copié-collé du code que t'a donné Monique dans la source de ta page, et assure-toi que ton éditeur ne modifie pas les & pour les transcrire en & au cours de tes manipulations.

Tes menus et ton bandeau avec un texte de liens bleu sur fond bleu n'offrent pas un constraste suffisant. pour #gauche ul, #droite ul, le validateur t'indique qu'il manque une famille générique de police : font-family: Verdana, sans-serif;. Recopie simplement à chaque fois la déclaration de police du body (font-family: Verdana, Arial, Helvetica, sans-serif;). Toutes les autres erreurs sont provoquées par les propriétés CSS mozilla -moz-border-radius: 3px; -moz-border-top-colors: #A0BBDD #A0BBDD; -moz-border-right-colors: #EBF2F8 #A0BBDD; -moz-border-bottom-colors: #EBF2F8 #A0BBDD; -moz-border-left-colors: #A0BBDD #A0BBDD; certes très jolies, forcément bien puisque mozilliennes, mais... propriétaires et invalides. Si, ceux du début de page : <a accesskey="p" href="plan_du_site.php" class="header"><span class="gras">Plan du site et raccourci</span></a><br /> <a href="#contenu" class="header"><span class="gras">Aller au contenu</span></a> Tu peux te contenter de rajouter une virgule entre les deux liens (</a>,<br />), ou améliorer en utilisant une liste. En supprimant au passage le span inutile, écris par exemple : <ul class="header"> <li><a accesskey="3" href="plan_du_site.php">Plan du site et raccourci</a></li> <li><a href="#contenu">Aller au contenu</a></li> </ul> Il faut modifier en conséquence ta CSS pour : - supprimer a.header {...} et span.gras{ ...} - ajouter le code suivant : .header a { font-weight: bold; font-size: 0.9em; color: #fff; } .header li { list-style-type: none; } (à compléter pour finir de style les <li>) L'accesskey "p" doit également être modifié, au profit de l'accesskey numérique habituel pour ce lien (voir http://openweb.eu.org/articles/accesskey_e...non_transforme/ ). C'est également le cas des autres accesskey "lettres" que tu utilises.

Ah, je suis allé fouiller dans mes archives du temps où j'utilisais Word : Microsoft diffusait un Office 2000 HTML Filter 2.0, que l'on peut compléter avec un petit coup de Bersoft Word HTML CleanUp 1.0 ou de Textism Word HTML Cleaner, ou encore de Word Cleaner... Pour info, HTML-Kit possède également une fonction "Strip surplus tags in Word 2000 Pages". Enfin, pour OpenOffice, voir dans OpenOffice.org XML File Format Filters and Transformations, ainsi que soffice2html. Ou encore la version OpenOffice.org Developer Build 1.9.m49 supposée gérer l'export en xhtml 1.0 strict valide...

Formellement oui, fieldset est réservé aux formulaires. Mais cette utilisation détournée est indéniablement séduisante Bon, soyons raisonnable : le même effet visuel peut être obtenu avec une div conteneur, un titre, le paragrapahe de contenu et un doigt de position relative sur le titre. Attention cependant à bien régler hauteurs de lignes, tailles de caractères, padding et marges du titre et du paragraphe...

Oups, j'oubliais : le javascript est-il obstructif ? l'accès à la page est-il compromis sans support javascript ? Par ailleurs, il provoque une erreur indéterminée dans ma console Javascript ?

Une première étape : corriger les erreurs CSS, et en particulier la syntaxe des pseudo-sélecteurs : a: link{ color: #6CA1D1; } a: visited{ color: #155894; } a: hover{ color: #91CDFF; } a: active{ color: #DFEEFF; } Les espace sont interdits après les deux-points. Il faut écrire: a:link{ color: #6CA1D1; } a:visited{ color: #155894; } a:hover{ color: #91CDFF; } a:active{ color: #DFEEFF; } Il y a apparemment la même erreur pour un :first-letter et des :hover, ainsi que des erreurs sur un code de couleur, etc. Pour le rapport bobby (page d'accueil uniquement), il n'y a qu'une erreur repérable par le validateur : tu as des liens adjacents dans ta page (ligne 36 de ton code), c'est à dire non séparés par un caractère imprimable et non contenus dans des items de liste. Il t'indique surtout en outre une série de vérifications à faire "à la main", qu'il ne peut faire lui-même : - vérifier le contraste des couleurs - syntaxe des labels de formulaire (éviter la syntaxe implicite qui n'est pas supportée par Jaws) - envisager d'utiliser FIELDSET et LEGEND dans les formulaires - vérfier la pertinence des titles et des intitulés des liens (ils doivent être explicites hors contexte) - il semble que tu aies une image animée : clignote-t-elle ? - faire une carte du site et une page "politique d'accessibilité" si ce n'est pas déjà fait - utiliser les liens relatifs <link rel="start"... pour l'accueil, <link rel="help"... pour la page d'aide à l'accessibilité, <link rel="up"... pour les sommaires de sections éventuels, etc - s'assurer que l'ordre de tabulation est cohérent, ou spécifier un ordre cohérent avec tabindex - prévoir des liens d'évitement de la navigation pour passer les menus - utiliser des accesskeys pour les liens essentiels (accueil, accessibilité, recherche, contact...)

Si c'est ton premier projet de site, peux-être y a-t-il un malentendu sur la notion de "site pro" En effet, l'exemple que tu as choisi n'a rien d'un site "pro": - utilisation exclusive du Flash, donc site visible seulement par une partie de son audience potentielle, sans aucune indication sur le plugin, les liens nécessaire sà son téléchargement, sans contenu alternatif pour les utilisateurs sans support flash, etc - utilisation de frames inutiles codées incorrectement, - page d'accueil "tunnel", composée uniquement d'une intro flash... zippée par 95% des visiteurs. Bref, un site sans contenu interopérable, sans accessibilité, à l'ergonomie très médiocre. Sans exclure l'utilisation de Flash, tu gagnerais à partir sur un projet HTML "classique", dans lequel tu pourras inclure des objets flash sans que l'ensemble du site souffre de ces défauts.

Oups ! Gros oubli dans mon message précédent : Internet Explorer Windows ne supporte le :hover que sur les éléments liens (<a>) Ce qui ne doit absolument pas priver les heureux utilisateurs de navigateurs plus évolués des jolis effets obtenus sur d'autres éléments ...

Pour approfondir l'utilisation du :hover à cet effet (modification d'une image de fond par exemple), tu peux t'inspirer de Bouton CSS qui l'utilise avec d'autres éléments que les cellules td, le principe restant le même.

Tu trouveras ce qu'il te faut dans : - Passer du HTML au XHTML - XHTML en une heure

CMS: Content Management System, ou Système de Gestion de Contenu. Par exemple : SPIP, DotClear...

Ce que tu décris correspond très exactement au système de commentaires d'un Weblog... Pourquoi ne pas chercher dans cette direction et adopter ainsi un CMS cohérent ?

Pourquoi ne pas lire, pour éclaircir les choses, WaSP Asks the W3C : which should we use, HTML or XHTML, and why? ? Réponse du berger à la bergère (autrement dit, du W3C) : Ces bénéfices sont, toujours d'après le W3C: - la facilité de maintenance en raison de la rigueur syntaxique (éléments en minuscule, attributs entre guillemets) qui réduit la marge d'erreur; - XHTML est plus facile à apprendre et à enseigner (pour la même raison); - XHTML1.x évoluera plus facilement que HTML vers XHML2.0; - XHTML est prêt pour XSL; Sur les deux premiers points, XHTML offre, il est vrai, l'avantage de forcer le respect de ces deux règles syntaxiques, et la possibilité de vérifier par la validation. La même rigueur est possible en HTML, mais sans la facilité offerte par le test de validité. Est-ce une raison suffisante pour adopter XHTML sans autre justification ? Peut-être, après tout. Sur le 3e point, la portabilité vers XHTML2.0... J'avoue être très réservé sur la force de l'argument, dans la mesure où l'avenir d'XHTML2.0 est très lointain. Sur le dernier point, pour être bien clair, c'est ma principale raison d'adopter XHTML plutôt que HTML dans mes réalisations personnelles Concernant la séparation du contenu et de la présentation, le même article statue très clairement : C'est bien la seule distinction Strict / Transitional qui compte ici, quelque-soit le choix HTML/XHTML... En conclusion, loin de moi l'idée de décourager l'adoption du XHTML (que je pratique abondamment personnellement), ou de dévaloriser celui-ci. Mais le but essentiel, AMHA, est de favoriser le passage à un Web standardisé, en tirant profit de la palette des standards HTML - XHTML disponibles. A trop vouloir faire passer XHTML pour la seule norme incontournable, ou à lui prêter des mérites qu'il n'a pas, je crains qu'on ne desserve ce but auprès de ceux qui ont à choisir en fonction de conditions de production, d'investissement, etc. qui ne les laissent pas aussi libre que les auteurs de sites personnels.

Non. C'est la séparation du contenu structuré et de la présentation grâce à CSS et aux variantes strictes qui permettent tout ceci, et non le choix HTML/XHTML qui n'y change pas grand-chose... Comme le rappelait Sibelius il y a peu, ne faisons pas d'amalgame entre XHTML et CSS !

Cette version ne fonctionne pas, comme tu as pu le constater, faute de support cohérent de <object> dans les navigateurs. Les seules imagemap actuellement utilisables recourent à <img... <map... et <area...