LaurentDenis

Tu voulais dire que le "title" n'avait aucune raison d'être pour l'utilisateur voyant les images ?

Si une information est attachée à une image, pourquoi ne pas la mettre simplement et directement dans le texte HTML du document, par exemple en légende de l'image ? Certes, à l'avenir, chaque image pourra sans doute véhiculer ses propres métadonnées (RDF inclus dans l'image) et les navigateurs sauront les restituer. Mais pour aujourd'hui, placer cette information "en dur" dans la page est encore la solution la plus simple et la plus efficace

Mieux vaudrais en effet éliminer cette BOM et les problèmes qu'elle suscite, en utilisant un autre éditeur.

En effet, cette DTD bascule IE6 Win en mode strict Attention : IE6 Win passera en mode Quirks si le document ne commence pas, dès la première ligne, par la DTD. Assure-toi de ne mettre aucun commentaire, aucun caractère... avant la DTD

Quelquie-chose comme cela ? <div id="texte"> <p>Le texte</p> </div> <div id="image"> <p><img src="..." width="..." height="..." alt="..."></p> <h2>Le titre</h2> <p>La légende</p> </div> avec : #texte { float: left; width: 35%; text-align: center; } #image { margin-left: 40%; text-align: center; } Sachant que le titrage après l'image et non avant n'est pas optimal question accessibilité. Mieux vaudrait le mettre avant l'image, ce qui n'empêche pas de le faire apparaître en dessous de celle-ci via CSS avec une position:relative, dès lors que la hauteur de l'image est connue et que le titre est assez bref pour n'occuper qu'une ligne...

Qu'un site comprenne des pages dans des encodages différents n'est pas un problème pour le visiteur. Mais peut-être plus délicat à gérer pour les auteurs

Cela n'a rien d'obligatoire au regard de la validité du document (Voir http://www.w3.org/TR/html401/sgml/dtd.html#head.content )

Ah ! J'espérais bien l'intervention de notre spécialiste maison de l'encodage Ici, il y a une BOM unique pour l'instant, mais Opera, très susceptible sur ce point, ne manque pas de l'afficher. Ce qui expliquerait les problèmes de RaccOOn. Maintenant, que la meta http-equiv correcte en utf-8 est rétablie, il n'y a plus qu'à attendre que Google se mette à jour. En espérant qu'il ne bugue pas sur la BOM

Hum... Faisons simple et accessible, si vous le voulez bien, sans raffinement : - alt obligatoire sur toutes les images, avec alt="" si l'équivalent textuel de l'image n'a pas d'intérêt dans un rendu vocal de la page (exemple-type : une puce ou toute image strictement décorative). - title sur un lien lorsque le texte contenu dans la balise <a... n'est pas compréhensible une fois retiré du contexte. C'est fou le nombre de gens qui naviguent dans une page à partir de la liste des liens extraite de celle-ci... encore faut-il que l'intitulé du lien ait un sens - pas de title sur les images liens qui ont déjà un attribut alt, du type : <h1> <img scr="logo.png" alt="_Titre_de_mon_site_"> </h1> En effet, certains navigateurs/lecteurs gèrent mal la présence simultanée d'un title et d'un alt. Et sur le fond, le alt doit suffire à donner un équivalent textuel hors contexte.

Monique, j'ai été un peu rapide peut-être : ta correction sur la syntaxe de la balise meta était tout à fait exacte. En revanche, l'encodage iso n'était pas le bon. Après quelques vérifications : L'encodage spécifié par le serveur est bel et bien utf-8. Au passage, il est facile à vérifier, par exemple : - directement dans le navigateur (Opera le signale au survol de l'onglet) - ou par l'intermédiaire du validateur HTML du W3C, qui signalait la contradiction entre l'en-tête HTTP (utf-8) et la meta ISO précédente. Il ne signale plus de problème depuis que c'est remis avec une meta utf-8. De fait, la page semble bien être en utf-8 puisqu'elle a même une BOM, c'est à dire une petite signature dans les premiers caractères qui signale l'encodage. Cette signature est ajoutée par l'éditeur HTML. Elle est inutile dans un document Web, et pose souvent des problèmes (voir le lien ci-dessus). Peut-être est-ce ce qui fait tousser Google ?

Aïe aïe aïe ça n'est pas tout à fait ça. Il y a d'abord l'éditeur HTML utilisé par RaccOOn, localement ou en ligne. Cette application "encode" le document dans un charset à déterminer, les plus fréquents étant : - UTF-8 - ISO-8859-1 (ça ne semble pas être ça) - Windows-1252 (apparemment, ce n'est pas non plus le cas) Il y a ensuite le serveur qui héberge le site, et qui envoie au navigateur avec chaque page un en-tête HTTP spécifiant l'encodage de la page. Pour que la page soit correctement interprétée, cette information HTTP doit correspondre à l'encodage "réel" ci-dessus. Dans le cas de RaccOOn, son serveur indique au navigateur que les pages sont en UTF-8... ce qui semble être effectivement le cas. Il y a ensuite la répétition de cette information d'encodage dans le corps du document, sous forme d'un éventuel prologue XML (il n'y en pas ici) et/ou d'une <meta http-equiv="content-type"... Mais en cas de contradiction, c'est l'en-tête HTTP qui l'emporte sur la meta et le prologue... Modifier seulement la meta ne changera donc rien si le serveur n'envoie pas le bon charset. Donc, il faut: - s'assurer du charset réellement utilisé par ton éditeur HTML - modifier en conséquence le charset spécifié par le serveur, ou à l'inverse, utiliser un éditeur qui fasse de l'utf-8 - corriger la meta en conséquence. Voir Spécifier l'encodage des caractères d'un document (X)HTML

A tout prendre, j'aime autant un bon vieil iframe correctement géré (Je sais, je vais peut-être faire hurler ) Une seule exception : les portions de contenu en <pre>, qui ont le chic pour vous poser un problème insoluble avec leur manie de déborder sur la moindre colonne située à droite. Là, le <pre style="overflow:auto"> a du bon, graphiquement parlant. En fait, le plus intéressant ici, AMHA, c'est l'impossibilité de donner le focus via un tabindex sur un élément de ce type (C'est fonctionnel dans IE, mais invalide et ignoré ailleurs à ma connaissance)... La liste d'éléments susceptibles d'avoir un tabindex est exagérément réduite en HTML4.01, il me semble...

Ils peuvent en rêver beaucoup plus concrètement que cela, avec: - l'élément <object> en HTML4.01 et XHTML1.x ... le jour où tous les navigateurs l'implémenteront correctement. - la possibilité de donner à n'importe quel élément XHTML2.0 un substitut graphique, remplacé par le contenu de l'élément en cas de non support (ou, logiquement, d'image non -disponible ou désactivée)...

L'utilisateur peut : - désactiver la feuille de style de l'auteur pour supprimer l'overflow: auto - mieux, ajouter un * {overflow: visible;} dans sa propre feuille de style utilisateur Vous me direz que la plupart des gens ignorent totalement ce qu'est une feuille de style utilisateur, et notamment les handicapés. Le problème est double : - du côté des agents utilisateurs et des outils d'aide... encore trop indifférents aux Standards, et dans lesquels ce type de comportement devrait être aussi facilement gérable que la présentation des liens actuellement, - du côté des utilisateurs eux-mêmes, qu'il s'agit d'avertir et d'aider à découvrir les nouvelles fonctionnalités de leurs outils. Derek Featherstone a écrit un intéressant article sur ce sujet : http://www.wats.ca/articles/educationguidelines/57 Côté contournement, je verrai a priori : - Les styles alternatifs qui permettent une présentation alternative du site spécifiquement conçue pour faciliter la navigation au clavier... - Un tabindex sur les éléments qui le supportent (object, textarea), leur permettant de recevoir le focus au clavier (au moins dans Internet Explorer). En revanche, les solutions javascript seraient un peu perverses. Un problème intéressant, en tout cas : les CSS "libèrent" l'utilisateur des contraintes de présentation voulues par l'auteur. C'est une arme à double tranchant: - un bénéfice d'accessibilité pour l'utilisateur, qui peut corriger localement ce qui lui pose un problème (typiquement, les couleurs, les tailles de caractères...) - mais aussi une difficulté car il ne peut en bénéficier qu'au prix d'un apprentissage supplémentaire, d'autant plus que les navigateurs actuels ont encore des fonctionnalités très limitées pour gérer ses styles utilisateurs. Même Opera, qui est le plus avancé dans ce domaine, ne permet pas par exemple de modifier librement ceux-ci à la volée dans un interface "facile", à moins de passer par un favelet.

Quand CSS et Courriel s'embrassent sous le gui., de Mark Wyner, sur pompage.net

Non Monique, cela n'a rien à voir avec un "standard de fait", et tu ouvres la porte à n'importe-quel abus en disant cela. Le fait qu'un navigateur ne sache pas interpréter une propriété CSS basique ne fait pas de son comportement un "standard de fait" ! Ou alors, acceptons la logique réciproque inséparable de celle-ci, et considérons que: - <marquee> est un standard de fait, - le prologue xml, de facto, doit basculer un navigateur en mode Quirks - application/xhtml+xml n'est pas un type mime valide, et avec lui tout XHTML - les <link rel="... sont tout aussi invalides puisque non supportés par IE, - etc. Il n'y a pas de "standards de fait". Il y a des standards (tout court) déterminés au sein d'un organisme collectif dont Microsoft fait partie (le W3C).

La syntaxe des sélecteurs d'enfants du type html>body n'a rien à voir avec les syntaxes "propriétaires". C'est une syntaxe de sélecteur CSS2... normale, valide, W3cisée, politiquement correcte, propre sur elle, blanche (W...), anglo-saxonne (...AS...) et protestante (...P) Il se trouve que le support partiel de CSS2 dans IE fait qu'il n'implémente pas ce type de sélecteur, et qu'il ignore donc les propriétés qui lui sont associés. C'est donc un moyen tout à fait correct de réserver une propriété telle que position:fixed aux navigateurs qui la supportent, en ayant spécifié auparavant une autre propriété (position:absolute) à IE, le tout avec une syntaxe CSS sans détournements. Pour différencier les types de "hack", voir mon commentaire dans http://www.cybercodeur.net/weblog/commenta...?idmessage=1065

Denis voulait dire simplement que, **dans une url**, le caractère & et son encodage en entité caractère & amp; étaient équivalents aux yeux du navigateur, celui-ci "transcrivant" nécessairement l'entité en caractère avant exploitation de l'url.

Voilà une excellente nouvelle, qui confirme dans l'idée que les divers critiques (légitimes) apportées dans l'immédiat sur votre projet doivent être comptées au rang du "débogage". Comparaison révélatrice : OpQuast s'est prudemment lancé tout d'abord à titre temporaire et confidentiel pendant plusieurs mois pour recueillir la critique des uns et des autres, puis est en train de passer par une autre phase préliminaire plus publique, mais qui vise toujours à recueillir les avis... Vous vous êtes publiés d'un coup comme un projet qu'on pouvait prendre pour achevé, et c'était plutôt courageux Le problème, comme le disait bien Steve Frecinaux dans sa critique (abrupte), c'est que votre site aura, malgré vous, un rôle sans doute non souhaité de donneur de leçons, de décerneur de label et de validateur de qualité... Cela dit, le problème de fond, en ce qui concerne ma critique, est ce discours "naïf" de la page cité dans mon message précédent sur les atouts des Standards, de bonne foi, mais malgré vous nocif par ses effets pervers : un site Standard n'est pas a priori accessible. ne sépare pas a priori contenu et présentation, n'est pas a priori sémantique. XHTML et CSS et leurs principes sont à prendre comme des gardes-fous, non comme des sésames. Bon, comme disait Samuel Latchman, "si vous voulez un patch" sur le discours en question... ou si un coup de main peut être utile, ce sera bien volontier (et je gage que d'autres que moi se mobiliseront bien volontiers si nécessaire). En tous cas, je le répète, kalitee.org ne doit pas être jugé à l'aune de cette période de lancement, mais pour ce qu'il recèle de potentialités à mettre en oeuvre

C'est une excellente initiative, car un tel projet était depuis longtemps attendu, discuté, envisagé ici et là, mais jamais concrétisé. La réactivité des auteurs à la critique (même acerbe ) laisse présager une rapide correction des erreurs de jeunesse du site. A ce propos... le discours sur les standards et l'accessibilité est vraiment abusif Mon seul regret, cependant, c'est ce choix exclusif en faveur d'XHTML, qui : - me semble justifié par l'erreur classique selon laquelle XHTML séparerait contenu et présentation, alors que la séparation est acquise dès HTML4.01 Strict. - écartera d'excellents sites qui ont fait le choix de l'HTML, ou qui ont dû se limiter au HTML faute de maîtriser la totalité de la production de leur code (marqueurs et scripts externes non modifiables à volonté, par exemple). - répand cette autre idée erronée selon laquelle adopter les Standards, c'est obligatoirement adopter XHTML1.0, alors qu'il s'agit plutôt d'encourager le choix raisonné d'une DTD appropriée au projet et aux conditions de production du site... La validité prime sur le prestige du XHTML

J'enfonce le clou après Monique : quelque-soit la police utilisée, répandue ou non, générique ou spécifique, si ton menu dépend d'une largeur de caractères unique... son design échouera chez une partie de tes visiteurs, dont les préférences (users styles), la configuration, le media d'aide (loupe)... casseront ton bel édifice. A titre d'exemple, il suffit d'un simple letter-spacing ou word-spacing dans une feuille de style utilisateur... (J'utilise personnellement un word-spacing de quelques dixièmes d'em pour améliorer la lisibilité des textes que je trouve souvent trop "denses") Pour que ton menu soit fiable, la seule solution est ne pas gérer ses dimensions au pixel, au pourcentage ou à l'em prêt, et d'y introduire un peu de "jeu".

Ce n'est pas un problème d'accessibilité (quoique celle-ci s'en ressente), mais de validité (X)HTML. <noscript> ne sert pas à corriger le code produit par un script, mais à en donner un contenu alternatif en cas de non support du javascript. D'autre part, il est interdit de modifier le script des Google Adsense, ou le code produit par celui-ci. Donc le choix est simple: - ne pas utiliser d'Adsense, - ou ne pas annoncer avoir des pages valides.

Rendre une page accessible, ce n'est pas juste obtenir l'approbation formelle d'un validateur, à moins qu'il ne s'agisse que de "faire genre je suis accessible" pour épater la galerie... D'autre part, empêcher les avertissements de Bobby n'est pas possible, à moins de lui adresser un code différent du code réel, ce qui n'aurait aucun sens. Enfin, les avertissements sont là pour indiquer que le webmestre assume la vérification que Bobby ne peut pas faire... Détail pour détail, et celui est plus important : une page contenant un adsense est de toute façon invalide (bien que cela échappe au validateur du W3C, le code généré par le script de Google est une vraie soupe).

Pour les liens a dans les titres h5, curieusement : h5 a { display: block; width: 100%; } semble finalement passer. Sinon, pour obtenir un comportement de bloc sans passer par display, on peux par exemple utiliser une position absolue ou un float dans le titre doté d'une hauteur... Pour le menu bleu qui disparait, ce sont les deux white-space:nowrap qui provoquent cette disparition dans IE...

Ouf ça, c'est la différence entre contenu structuré et présentation : - du point de vue de la structure (X)HTML, ton bloc positionné en absolu a pour parent la <div> en flux, effectivement. On peut parler en ce sens de "conteneur logique" si cela se réfère à la structure; - mais du point de vue présentation CSS, ce bloc en position absolue n'en a rien à faire de son élément parent pour se placer : ce qu'il cherche, c'est son conteneur (notion qui n'existe pas du point de vue structurel), c'est à dire au choix son élément parent s'il est lui même positionné, et à défaut un élément ascendant positionné ou le conteneur initial. Alors oui, HTML dit une chose du point de vue stucturel, et CSS screen en dit une autre du point de vue présentation visuelle. CSS aural dira encore autre chose Il faut penser, je crois, en termes de "couches" : - la couche structurelle (HTML) - la couche de présentation globale (CSS media All) - la couche de présentation visuelle (CSS media screen, print, etc.) A chaque couche son appréhension spécifique du document, appuyée sur la couche précédente... C'est vrai qu'on ne rappelle jamais assez, pour faire bref, qu'un élément en position absolute/fixed est placé en référence au body sauf un de ses éléments ascendant est lui-même positionné. C'est le vieux coup de la règle position:relative sans top ni left, ni etc... à mettre sur le "conteneur" intuitif souhaité. Si on arrive en retard et qu'on loupe la visite de la ménagerie avant le spectacle... C'est toi qui t'expliqueras avec ma fille, Raphaël ! (et elle a beaucoup plus mauvais caractère que moi) Je file pour de bon, ce coup-ci...