LaurentDenis

Bon, je vais essayer quelque-chose qui va peut-être te sembler déroutant, mais où on peut t'aider à arriver à un bon résultat et surtout à comprendre le couple mystérieux HTML/CSS: - oublie temporairement http://www.zengrafom.org/site/fonds2.html qui est juste l'apparence que tu souhaites donner à ta page (on y reviendra après). Il n'y a pour l'instant aucun contenu, juste de la déco, à part cette répartition en 3 zones qui suggère un contenu en trois parties (Je suppose, deux menus et un texte ?) - fais une page sans aucune présentation, couleur, images, positions... qui contienne toutes les informations réelles que tu veux mettre dans ta page. Quelque-chose d'affreux (temporairement), mais avec ton texte réel, tes liens... Si tu veux, fait un fichier texte, peu importe : ce qui compte à ce stade, c'est ce que tu as à dire, pas comment le dire. A partir de cette page (on l'appelera ton "contenu"), on procèdera par étapes rapides : 1. on lui donnera une bonne structure (pas de div superflues qui t'embêtes à juste titre), lisible par tous les navigateurs, plus facilement exploitable pour la présentation ; 2. on refera une feuille de style à partir d'une structure saine, en reprenant l'idée de ton projet graphique http://www.zengrafom.org/site/fonds2.html Pour l'instant, tu procèdes en faisant la démarche inverse : présentation d'abord, structure et contenu ensuite. Or bien utiliser CSS, c'est le voir comme l'étape finale de la création d'une page, après le contenu et sa structure. Voici un excellent résumé de la "bonne" démarche, librement traduit de la source anglaise : http://www.mezzoblue.com/archives/2004/04/30/a_roadmap_to/ Veux-tu jouer le jeu ? Il en vaut la chandelle

A priori, un width: 75%; appliqué à la div contenant le tableau devrait faire l'affaire. En tout cas, le résultat est bon dans le test que je viens de faire. En revanche, Gribouille26 : que diable veux-tu faire avec un position:absolute sur le tableau ?

Théoriquement, les éléments de formulaires devraient être stylables à volonté en CSS. En pratique, l'implémentation est très limitée, particulièrement dans Internet Explorer. Il manque une bonne ressource en français sur le sujet, tiens

Pour les taille de caractères, c'est OK. Quatre petites choses encore. un petit problème d'indentation des listes du menu, facile à régler - IE, Opera... appliquent par défaut une marge gauche aux éléments <ul>. Ta CSS l'annule comme il faut avec margin-left: 0em; - Mais les navigateurs basés sur Gecko (Mozilla, FireFox...) n'utilisent pas une marge, mais un padding gauche de 40px par défaut pour les <ul>. Pour éviter que ton menu ne soit décalé vers la droite dans ces navigateurs, il faut ajouter à ta CSS un padding-left: 0; pour les <ul>. Alléger la feuille de style Tu n'utilises qu'une seule police de caractère pour toute la page (sanserif). Il te suffit de la déclarer une seule fois pour body, et la règle s'appliquera par héritage à tous les éléments du body (sauf les <code>, <samp> et autres <var> que tu ne risque guère d'utiliser, je suppose). De même, tu peux simplifier pour les couleurs des liens en déclarant pour a la couleur choisie. Elle s'appliquera par héritage aux a:hover, a:visited.... accessibilité Pour améliorer la page, tu peux envisager une mesure d'accessibilité très simple : dans un lecteur d'écran par exemple, avant d'accéder au contenu principal de la page, il faut écouter tout le menu de navigation. C'est très pénible et on voudrait pouvoir écouter tout de suite le contenu. Tu peux facilement y remédier en modifiant ta <div id="header"> pour y ajouter un petit lien vers le contenu : <div id="header"> <a class="textheader" href="#contenu">contenu</a> | <a class="textheader" href="http://s.billard.free.fr/">Home</a> </div> Par la suite, si tu installes un moteur de recherche du site ou un plan de site, les liens vers les deux pages correspondantes seront également très appréciés dans ce menu d'accessibilité. Voir différents exemples de ces menus : - sur le weblog de Denis http://www.cybercodeur.net/ - sur le mien http://www.blog-and-blues.com/ - sur le site OpenWeb http://openweb.eu.org/ liens Et enfin un détail : les liens de ton contenu principal sont clairement soulignés, mais cette info n'est pas renforcée par un changement d'apparence au survol de la souris ou lorsqu'ils sont sélectionnés au clavier (:hover). Pour une meilleure ergonomie et une meilleure accessibilité, il vaut mieux ajouter un doigt de :hover. Par exemple, une mise en gras, ou passer d'un soulignement pointillé à un soulignement continu, ou à la rigueur un changement de couleur (moins satisfaisant pour l'accessibilité)... C'est en tout cas un premier essai de CSS très réussi

Ton texte en position absolue restera en effet à cette position dans tous les écrans. Mais pas ton image ou le reste de ta page. Tu risques donc d'avoir des suprises. Si je comprends bien, tu cherches à associer une image et une légende, toutes deux centrées horizontalement ? Dans ce cas, la solution la plus directe est : .img { text-align: center; width: ...; } (width: ... à utiliser et modifier si tu veux que la légende s'affiche dans une largeur donnée, celle de l'image par exemple) et pour une légende en dessous de l'image : <p class="img"> <img src="..." alt="..." width="..." height="..."> <br> Ici le texte de légende de l'image </p> ou pour une légende au-dessus de l'image : <p class="img"> Ici le texte de légende de l'image <br> <img src="..." alt="..." width="..." height="..."> </p>

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.

Au passage, pour ceux qui travaillent beaucoup hors-ligne, les articles OpenWeb sont diffusés en pdf par un bénévole: http://blogs.developpeur.org/orion/archive.../02/13/532.aspx

Pour mémoire, tu connais sûrement le Référentiel accessibilité des services Internet de l’administration française. Il y a quelques points criticables, mais c'est une bonne approche "réaliste" de l'accessibilité, par opposition à l'approche purement théorique des standards. D'autre part, il est l'un des rares à lier/articuler explicitement accessibilité et utilisabilité (ergonomie si vous préférez).

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 :-(

Il y a simplement beaucoup trop de "font-size: 1em" répétés dans la feuille de style. Un seul suffit pour couvrir les paragraphes, les listes... et cela règle ton problème dans IE. D'autre part, inutile de mettre 1.0em : 1em suffit.

Ce que tu décris ressemble plutôt à un plan/carte de site qu'à un menu de navigation ! Donc : - simplifier le menu et s'en tenir aux items principaux, pour éliminer le javascript et les menus déroulants, toujours moins agréables à consulter qu'une page plate quand les items sont trop nombreux; - laisser au plan de site son rôle de liste organisée de toutes les pages disponibles (utiliser une bonne hiérarchie de titres pour faciliter l'accessibilité)

Le rendu graphique est correct, en effet. Mais ta page d'accueil a un gros problème de structure des titres. Je les reproduis ici en utilisant l'indentation pour refléter la structure logique réelle : <h1>Docteur Vincent RENARD</h1> <h2>Le site des Docteurs Renard et Weiler</h2> .... <h3>Bienvenue sur le site du Cabinet Médical Joffre</h3> <h1>Dr Renard Vincent</h1> .... <h3>Choisissez le menu</h3> .... Deux erreurs : - <h1>Dr Renard Vincent</h1> qui devrait être un <h4>Dr Renard Vincent</h4> - <h3>Choisissez le menu</h3> qui devrait être un <h2>Choisissez le menu</h2> Pour le premier, il s'agit d'une sous-section du titre h3 précédent. j'imagine que le choix de h1 est lié à des questions de présentation ou de référencement... qui ne le justifient cependant pas. Pour la présentation, CSS permet d'obtenir le même résultat avec un h4. Et pour le référencement... le gain obtenu est très incertain. Pour le second, la page a deux parties de même niveau : contenu / menus Outre qu'elles aboutissent à une structure illogique, ces erreurs sont gênantes pour l'accessibilité, car la navigation par niveau de titre dans la page devient acrobatique.

Je prendrais le problème par un autre bout (celui du contenu de la page et non de sa présentation graphique): L'information "Linux" ou "Windows" est-elle essentielle à la compréhension de la page ? Pour cela, doit-elle être lue dès le titre ? Est-elle donnée par ailleurs de manière suffisante (le texte qui suit tes titres...) Si l'info est essentielle, elle ne doit pas être donnée via CSS : elle doit figurer dans le contenu de la page. Alors, tes images <img src... sont une bonne solution, si tu veilles à bien renseigner les deux champs alt="Windows" et alt="Linux" pour que l'info soit disponible dans les medias non graphiques. Si l'info est décorative, elle doit être donnée via CSS. Et le fait que les visiteurs d'IE n'y auront pas droit n'est pas dramatique. Au contraire : dans la mesure où on est dans le "décoratif" et dans l'accessoire, il est logique que les utilisateurs d'un navigateur ne bénéficient que du rendu qui est à la portée de celui-ci. S'ils cherchent une expérience de navigation plus fun, c'est à eux de faire évoluer leur navigateur. Attention : je répète clairement que ceci n'est valable que pour du "décoratif". Il ne faut en aucun cas agir de cette manière avec du contenu utile.

Quelques points de méthode : - Quand il s'agit de faire passer aux standards des pages existantes de ce type, ne pas commettre l'erreur de commencer par un DTD stricte ! Il faut commencer par une DTD "permissive" : HTML4.0 ou 4.O1 transitionnel, voire frameset. Ensuite, faire évoluer la DTD au fil des étapes de correction. - Faire attention en particulier aux DTD qui modifient le mode de rendu CSS (DocType switching). Eviter le mode de rendu strict quand on ne maîtrise pas encore bien CSS. - Ne pas vouloir corriger obligatoirement toutes ses pages, voire les porter au même standard. Travailler plutôt par ordre de priorité : pages-clés du site, pages les plus visitées... Conserver une partie du site en HTML 4.0 frameset ou transitionnel n'est pas un problème. - Ne pas viser obligatoirement le standard le plus exigeant : toutes les spécifications "se valent", d'un certain point de vue. L'important est d'être conforme et d'éliminer le plus possible de soupe.

Quelques remarques rapides, si tu permets : Accessibilité Pourquoi ne pas respecter justement sur cette page l'une des règles les plus importantes en matière d'accessibilité : ne pas utiliser le même intitulé pour des liens différents, et rédiger des intitulés de liens les plus explicites possibles. En effet, une fois extraite de son contexte, dans un mode "affichage des liens de la page" par exemple, ta première série de liens vers les spécifications est... incompréhensible Donc éviter d'intituler un lien "spécifications officielles" ou "traduction" : utiliser plutôt "spécification XHTML1.0 (en anglais)" et "traduction française de la spécification XHTML1.0". Spécifications Pourquoi ne pas commencer par le commencement... et indiquer : - la Spécification HTML 4.01 (en anglais) - la Spécification HTML 4.01 (traduction française partielle) Avant d'aborder XHTML, il est conseillé d'avoir une bonne maîtrise du HTML valide validateurs d'accessibilité Il n'existe aucun validateur "officiel" en matière d'accessibilité. Et il faut rappeler la limite de la validation automatique d'accessibilité : elle ne donne qu'un résultat indicatif, car une part importante de l'accessibilité réelle doit être vérifiée à la main (c'est tout le sens des "labels" comme celui d'AccessiWeb). Sinon : - un excellent validateur aux résultats très lisibles (présentés graphiquement) : Validateur d'accessibilité Wave (en anglais) - un autre validateur, utilisable hors-ligne : Validateur d'accessibilité A-Prompt (en anglais) Voir enfin les possibilités offertes par Opera pour tester différents éléments de base d'accessibilité : Using Opera to Check for Accessibility Enfin, bien qu'elle ne soit plus mise à jour, la FAQ XHTML/CSS (hardware.fr) créée par gm_superstar reste une très bonne liste de liens de base sur le sujet des Standards.

He he... Je l'aurais parié : - attention au respect des espaces : media="screen" title="deco" /> plutôt que media="screen"title="deco"/> - attention au rôle de l'attribut title dans les link de CSS Voir le détail dans http://devedge.netscape.com/viewsource/200...s/index_fr.html

Je compatis, Denis : j'aurais adoré, pour ma part, avoir ma petite esperluette dans mon nom de domaine

Non : <li> est le seul élément qui peut être placé dans <ul> Donc plutôt : <div class="blocsmenu"> <h2>Titre de menu 1</h2> <ul> <li>texte 1</li> <li>texte 2</li> <li>texte 3</li> </ul> <h2>Titre de menu 2</h2> <ul> <li>texte 1</li> <li>texte 2</li> <li>texte 3</li> </ul> </div> Et si jamais tu rencontres des problèmes avec le décalage vers la droite de tes items de menus selon les navigateurs, voir : http://devedge.netscape.com/viewsource/2002/list-indent/ pour comprendre le jeu du padding-left et du margin-left entre Mozilla et IE (en anglais, mais bref et simple)

Peux-tu reproduire ici le code exact de tes link ? ce sera plus facile de t'aider ;-)

Une chose m'échappe : si tu utilise DotClear, tu peux utiliser les include php pour les parties de tes pages qui sont constantes (menus...) Donc, pourquoi ce frame qui semble te compliquer la vie ?

Attention à ne pas confondre : - le caractère & #39; qui est l'apostrophe que tu as entrée (résultat : ') - le guillemet anglais simple ouvrant ou fermant, codes & #8216; et & #8217; (résultats : ‘ et ’) Sur les caractères qui provoquent fréquemment des erreurs, voir ce tableau des encodages valide/invalide : http://openweb.eu.org/articles/caracteres_illegaux/ (utiliser de préférences les entités numériques valides plutôt que les entités caractères valides) [edit] : zut ! je renonce à me battre avec ce fichu bidule pour obtenir un affichage correcte des codes d'entités. J'ai donc ajouté un espace entre chaque & et #

Hélas : http://www.freedomscientific.com/fs_suppor...View.cfm?QC=565 (Bulletin d'information de freedomscientific, qui produit Jaws - 10/13/2003 - JAWS for Windows Version: 5.0 plus) visibility:hidden revient donc au même que display:none pour Jaws : le caption en question ne sera pas restitué :-(

Je vois la différence de la manière suivante : - <l> serait défectueux car le saut de ligne n'est pas le comportement par défaut attendu des navigateurs, et que cela doit être précisé via CSS. Exactement comme un <span> associé à une astuce CSS. - A la différence de <br /> qui oblige le navigateur à adopter comme comportement par défaut un saut de ligne, sans intervention nécessaire d'une règle CSS. Donc <br /> a bien une "valeur ajoutée"... D'autre part, si la sémantique recherchée est bien celle du saut visuel de ligne, alors un élément unique du type <br /> placé à l'endroit du saut me semble plus logique qu'un élément englobant comme <l>...</l> Il y a dans tout cela une idée d'économie du code qui me semble de plus en importante : le code (valide) le plus direct est presque toujours le meilleur. Exactement comme : <ul class="menu"> ... est préférable à : <div class="menu"> <ul> ... Je ne sais pas si c'est très clair

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]

Hum... Daniel Glazman avait quelque réserves intéressantes sur l'élément l et la suppression éventuelle de br dans le futur html2. En particulier : Voir http://daniel.glazman.free.fr/weblog/archi...c.html#87473606