LaurentDenis

Le nouveau parseur du validateur CSS n'arrive pas à sortir le numéro de ligne de certaines erreurs... Ici, l'erreur est à la ligne 60 où se trouve un } orphelin. A ce sujet, je me permets un conseil : indente tes feuilles de styles. Je reprends les lignes où se situe l'erreur : select, option, input, textarea, checkbox, .Cache { color:#000000; background-color:#EFF6FF; border:1px solid black; font-family:serif; font-weight:bold; } option, input, textarea, checkbox, .Cache { padding:3px; } } est beaucoup moins lisible que: select, option, input, textarea, checkbox, .Cache { color:#000000; background-color:#EFF6FF; border:1px solid black; font-family:serif; font-weight:bold; } option, input, textarea, checkbox, .Cache { padding:3px; } } La double }} saute plus facilement aux yeux avec un code indenté, non ? [edit] Un petit "truc" avec le validateur CSS : en cas d'erreur difficile à interpréter, faire simplement un copié collé du code CSS renvoyé par le validateur et le tester sur sa page : - les petites erreurs comme celle-ci sont ainsi éliminées; - au passage, on récupère un code indenté - il suffit de comparer la différence de rendu avec la CSS originale pour repérer où se situent la plupart des autres erreurs.

Tu n'as apparemment pas d'erreurs de niveau A : celles-ci seraient signalées juste après le titre "Priority 1 User Checks". Tous les points de contrôle qui sont cités dans cet extrait sont des avertissements : "vous devez déterminer manuellement s'ils s'appliquent [à votre page] et, si c'est le cas, si votre page répond aux exigences." : Avertissement quasi systématique de Bobby sur toutes les pages. Simple rappel. Là encore, cet avertissement est toujours déclenché par la présence d'une feuille de style. La page est tout à fait lisible sans CSS. Mais pas tout à fait consultable dans de bonnes condition, puisqu'elle commence par une très longue liste de lien avant d'en arriver au contenu principal. Il faudrait un lien d'accès direct à ce contenu en début de page. Ou plus logiquement, inverser la structure (et revoir la CSS, du coup). Bobby ne peut pas vérifier cela, c'est pourquoi il t'invite à le faire toi-même. Avertissement déclenché ici par tes règles de couleur CSS sur les liens et les titres. Bobby a vu des h2 en vert, à toi de vérifier s'il y a un autre élément spécifique de présentation qui les distingue (c'est le cas AMHA avec le gras, l'indentation et les bordures de contenu). Pour les liens, le soulignement et le changement de pointeur au survol les indiquent clairement... si on met la souris dessus. Ce n'est pas évident pour le lien [suite] dans le contenu, qui n'attire pas assez l'oeil (je reviendrais sur ce lien qui pose un autre problème plus grave). En vision monochrome (ou sur un écran noir et blanc), tes liens de contenu ne seront pas facielement repérés) Ton image de titre est correctement rendue par le contenu de son attribut alt, tout va bien. Mais Bobby étant incapable de "lire l'image" et d'en peser le sens, il s'en remet à toi pour faire cette vérification... Ce qui suit dans le rapport Bobby sont deux autres rappels systématiques sans rapport avec des éléments précis de ta page. Par exemple, Bobby te rappelle de signaler les changements de langue parce qu'il ne sait pas déterminer lui-même si le contenu est rédigé dans une seule langue ou dans plusieurs. Conclusion pour ta page ? - avec sa structure HTML actuelle, il faut un lien d'accès direct au contenu pour sauter le menu de navigation. - tes liens ne sont pas assez nettement différenciés du contenu. Je reviens sur ton lien [suite] : Bobby étant en carafe au moment où j'écris, je ne peux pas voir le rapport complet sur ta page. Mais dans les erreurs de priorité AAA, il doit te signaler que tu utilises le même intitulé de lien pour des cibles différentes. Imagine que je n'ai "sous les yeux" que les liens contenus dans ta page (différents aides à la navigation le font). J'aurais pour ton contenu quelque-chose comme : Comment savoir où me mènent ces liens ? De quoi il s'agit ? Ils n'ont plus aucun sens hors de leur contexte. Si j'active le remplacement des intitulés de liens par le texte de leur attribut title, j'aurais alors: C'est déjà un peu plus explicite. Mais guère. Si je m'en tiens à l'url des liens, autre possibilité sans doute beaucoup plus rarement exploitée: Bof, pas plus explicite que les title. Que faire ? - Ne jamais utiliser de liens [suite], [lire cet article] ou autres [cliquer ici] - Pour cette page, reprendre simplement le titre de chaque news dans l'intitulé du lien, sous la forme: <a href="http://www.autre-voyage.org/velo-nouvelles.htm" tabindex="100" title="Dernières nouvelles : Petite vadrouille en Roumanie"> [Lire "Petite vadrouille en Roumanie"] </a> Ou placer le lien dans le titre de la nouvelle... ce qui n'est pas forcément très clair pour tout le monde. Le lien doit alors être visuellement très répérable, avec ou sans couleur... En fait de priorité AAA (niveau 3 de la WAI), cette question des intitulés de lien me semble devenir très sensible avec les nouvelles versions des aides d'accessibilité. Ouf ! j'ai fait un peu long, mais j'espère t'avoir aidé à décrypter ce bon vieux Bobby, plein de bonne volonté mais souvent un peu elliptique

J'avais hésité à citer ChuWiki, en raison de tes doutes sur une éventuelle faille de sécurité. http://www.genezys.net/ Qu'en est-il finalement ?

Bobby n'est pas à conseiller pour débuter, parce que ses rapports ne sont pas d'un maniement toujours facile. Il faut en particulier faire la différence entre les erreurs et les avertissements pour que Bobby soit vraiment intéressant. La suggestion de créer une version alternative... n'est qu'un avertissement, justement : un rappel, disons, de ce principe de base de l'accessibilité. Il ne faut y voir aucun jugement sur la page elle-même, et surtout pas l'équivalent d'une validation "humaine" approfondie. Bobby reste, AMHA, le meilleur des validateurs, aussi décrié qu'il ait pu être depuis un ou deux ans et l'émergence des validateurs plus récents (pourtant, j'apprécie beaucoup Wave). En fait, ceux-ci répondent à un autre besoin : faire simple. La grande qualité de Bobby, justement, c'est qu'il ne ramène pas l'accessibilité même formelle (vue sous l'angle d'une analyse mécanique de la page) à quelque-chose de simple.

Vite fait, mais je tâcherais d'y revenir : Non, car : - la structure linéraire de la page doit refléter sa structure logique (le HTML est linéaire). - un titre ne se "pondère" pas au poids de son importance symbolique. Il est déterminé par sa place dans la structure linéaire de la page. Dans la structure logique de la page, après ton titre h1 de page, tu as, logiquement, au moins un h2 de contenu et un autre h2 de menu. Arg ! Je n'ai pas le temps tout de suite, mais je crois qu'on met le doigt sur quelque-chose d'intéressant, là. [edit] j'y reviens quand même : c'est un peu comme le bon vieux plan de dissert' au bac, cette histoire de titre

Désolé : je ne comprends pas. Peux-tu faire un effort de rédaction ? Un message clair et correctement écrit aura d'autant plus de chance de recevoir des réponses. Comme le disent les règles du forum : Sinon : - Pour le javascript des commentaires, voir Des liens javascript plus accessibles. Tout y est. - Pour les liens adjacents, le rapport de Bobby te donne les numéro de lignes. - pour la langue, en XHTML : <html xmlns="http://www.w3.org/1999/xhtml" lang="fr"> (Utiliser l'attribut xml:lang en XHTML1.1 ou si le XHTML 1.0 est servi en application/xhtml+xml) Doubler d'une méta classique pour être sûr d'être bien compris, par exemple : <meta http-equiv="Content-language" content="fr" /> Plus radical, faire dans l'en-tête HTTP (Content-Language) - le h1 : après l'avoir ajouté, vérifie la hiérarchie des titres : h1>h2>h3>... Les choses du genre h1 suivi d'un h3 ne sont pas conformes (sémantiquement) et ne sont pas navigables (dans Jaws par exemple).

Je ne sais plus lequel m'avait semblé meilleur que les autres, mais si j'ai bien pêché dans mes signets, ce doit être l'un de ceux-ci : http://www.online-translator.com/text.asp?lang=en http://www.worldlingo.com/fr/products_serv...ranslation.html http://babelfish.altavista.com/ http://www.freetranslation.com/web.htm (Attention : c'est du brut, et il doit aussi y en avoir un ou deux particulièrement mauvais )

Oups ! Je t'ai donné les indications pour la version 1.2 beta (pense à changer de version quand tu changera d'hébergement). Je n'ai pas la 1.0rc3 sous la main ce matin, mais si je me souviens bien, tout est dans template.php pour la répétition des prénoms. Je te dirai ça rapidement. Pour le mail chez Online, je vois dans les rapports de bug : Le numéro de ligne n'est sans doute pas le bon pour la 1.0rc3, mais tu devrais pouvoir trouver.

validité des frames Les frames (cadres) sont tout à fait valides au regard du W3C... dans le cadre de la spécification HTML 4.01 frameset. Faire des cadres valides et respecteux des règles d'accessibilité serait déjà un premier pas pour découvrir le codage standard. Voir : http://www.la-grange.net/w3c/html4.01/present/frames.html frames et <div> Les <div> n'ont aucun rapport avec les frames et ne remplissent pas du tout le même rôle : c'est un simple élément de regroupement dans le code HTML, qui permet de faire un "bloc" contenant des éléments textes, formulaires ou autres. Il sert essentiellement à consolider la structure de la page et à en faciliter la présentation en CSS. frames et include Les include CGI, PHP, ASP... répondent en partie à ton besoin dans la mesure où ils permettent d'insérer dans la page, côté serveur, des blocs de code contenu dans des fichiers uniques pour l'ensemble du site, et donc plus faciles à gérer (à la manière des frames). <div>, include et cache Ni les <div> ni les include ne sont conservés en cache par le navigateur séparément du reste du code de la page.

Comme tu le vois, c'est aussi une habitude pour beaucoup d'entre-nous, sans méchanceté ni prétention cependant. Denis ayant pris les devants et traité des problèmes de validité HTML, je me permettrais pour ma part de te recommander de te préoccuper d'accessibilité et d'étudier par exemple le Rapport Bobby sur ta page d'accueil. En autres choses : - Faire un usage plus modéré d'un javascript mieux codé (ton système de commentaires ne fonctionne, au mieux, que pour une partie de tes visiteurs, par exemple) - utiliser l'élément label pour étiquetter les champs de formulaires - séparer les liens adjacents par un caractère au moins - préciser dans l'en-tête que ta page est en français - utiliser des titres correctement hiérachisés pour permettre la navigation dans tes pages par ce biais - donner aux liens un intitulé explicite : une vingtaine de liens successifs qui apparaissent dans un lecteur d'écran sous la forme "lire cette news"... c'est inutilisable. Et côté CSS: - revoir le dimensionnement trop rigide qui force un scroll horizontal sur de nombreux affichages, - corriger le "vertical-align: text-middle;" invalide et inopérant. Si cet accueil te semble un peu sévère, je dirais que nous sommes rigoureux, mais que ne mordons pas... et que nous remettons nos propres compétences en cause chaque jour N'hésites pas à demander des précisions sur les problèmes soulevés ci-dessus : nous sommes là pour ça.

J'y reviens pour lever un doute, au cas où : l'attribut longdesc ne contient pas un texte lui-même de description d'une image, mais un lien vers une autre page contenant la description en question.

Réponse toute théorique, car je n'ai jamais mis en pratique avec un document tableur openoffice. Celui-ci, sauf erreur de ma part, est un document xml valide. Il peut facilement être transformé à l'aide d'une feuille XSLT en document (X)HTML doté de ses feuilles de style d'écran et d'impression. Rest à écrire le script (ou à en trouver un quelque-part dans les ressources OpenOffice).

Non. Dans le cas du menu d' http://www.alsacreations.com/ , le menu est parfaitement exploitable sans le javascript : celui-ci ne conditionne pas le fonctionnement des liens. Il ne fait qu'afficher une information supplémentaire qui n'est franchement pas indispensable (elle ne se justifierait même pas dans es attributs title des liens, vu que les intitulés de liens sont très explicites). Si le script en question avait été obstructif, Denis serait bien évidemment monté sur ses grands chevaux !

La question importante, AMHA, est : Est-ce que la vision de cette image apporte une information nécessaire à la pleine compréhension du contenu de la page ? Dans le cas de http://devepl.stephane-huc.net/cfppa/enseignement/adresses/ J'aurais personnellement des doutes sur l'utilité de décrire ces portaits. Donc je mettrait simplement un alt="" sur chacun, et pas de longdesc. (Il ne faut pas oublier qu'un longdesc, c'est un lien de plus, et qu'un trop grand nombre de liens dans une page pose également des problèmes d'accessibilité) Sinon, l'attribut longdesc est à présent plutôt bien supporté par les aides spécialisées : - Jaws 4.51, IBM Home Page Reader et pwWebSpeak vont signaler le lien contenu dans longdesc - Windows Eyes l'ignore. En revanche, aucun navigateur graphique à l'exception d'iCab ne gère longdesc. Quoi que j'ai un doute à propos de je ne sais plus quelle version de Mozilla... Pfff... fatigué, moi On peut utiliser à la place un "lien D" comme substitut : lien apparent dans le contexte d el'image, renvoyant à la même url que l'attribut longdesc Mais c'est un mécanisme empirique, parfois mal connu des utilisateurs et peu intuitif (au minimum, remplacer l'intitulé "D" par un texte plus clair). En fait, je me demande si la meilleur description longue d'une image, et surtout la plus justifiée, n'est pas celle qui se place tout naturellement dans le texte même de la page...

Au passage, pour éviter la répétition des prénoms dans les pages de billet: Edite le fichier /dotclear/themes/default/post.php et modifie les lignes <p class="post-info">Par <?php dcPostAuthor(); ?>, <?php dcPostDate(); ?> à <?php dcPostTime(); ?> <span>::</span> <a href="<?php dcPostCatURL(); ?>"><?php dcPostCatTitle(); ?></a> en <p class="post-info">Par <a href="<?php dcPostCatURL(); ?>"><?php dcPostCatTitle(); ?></a>, <?php dcPostDate(); ?> à <?php dcPostTime(); ?> Si nécessaire, même genre de manipulation dans /dotclear/themes/default/list.php pour les pages de listes de billets

Edite le fichier : /dotclear/themes/default/template.php Et modifie la ligne <h2>Cat&eacute;gories</h2> Au fait, chez free, le mail fonctionne pour l'avertissement des commentaires.

"Responsable", non ! Il n'y a qu'un seul maître à bord de DotClear : Olivier Meunier Moi, je donne un coup de main, c'est tout. Cela dit, l'info sur les sessions est effectivement présente dans la FAQ DotClear, mais tu as raison, il faudra le rajouter dans la page "Installation". Merci [edit]C'est ajouté dans la documentation[/edit]

Pour le RSS, je te renvoie à : - http://www.pointblog.com/abc/000244.htm pour une intro générale et le suivi de l'actualité sur cette technologie - http://upian.net/znarf/carnet/2003/11/CoursRSS pour un survol technique Pour les trackback, en très gros : - tu veux signaler à un site que tu parles de lui dans une de tes pages, en lui transmettant ton url, ton titre et un extrait de ton texte qu'il pourra automatiquement insérer dans son propre contenu. - Le site en question te fournit une url-cible qui va recevoir ce signal (le "ping"). - Ton serveur envoie donc une requête à cette url avec tes infos en query string, du genre : http://url_cible_du_ping?url=mon_url&title=mon_titre &execrpt=extrait_de_mon_texte&blog_name=mon_site - Si tout va bien, le serveur visé répond qu'il a bien reçu en renvoyant un simple fichier XML avec le code d'erreur 0. <?xml version="1.0" encoding="iso-8859-1"?> <response> <error>0</error> </response> - Ton "commentaire" s'ajoute à la page concernée du site visé. Une erreur souvent faite quand on "pingue" un weblog : il ne faut pas utiliser le lien permanent du billet comme url de ping. Celle-ci est une url spécifique. [edit] J'oubliais à propos des trackback, voir http://climbtothestars.org/archive/2004/03...estce_que_cest/

Je t'avoue que je n'ai jamais regardé comment les mails étaient envoyés (la réponse doit être dans le fichier layout/prepend.php) J'allais spontanéement te répondre "est-ce que ce ne serait pas plutôt l'occasion de s'initier au lecteur de fil RSS puisqu'il y a un feed pour les commentaires ?", mais je réalise que ça ferait peut-être beaucoup à la fois pour tes utilisateurs Fais déjà un test sur ton hébergeur. Et en cas de problème, pose directement la question sur le forum DotClear : http://www.dotclear.net/forum/

Dans ce cas, en effet, il n'y a pas copie. Hum... Enfin... pour l'instant. Si la loi sur la brevetabilité logicielle est finalement adoptée... rien n'empêchera de déposer des brevets sur "la technique du menu en float" ou "le zoom d'image en background CSS"

IE est assez limité comme outil de développement, il faut bien le reconnaître. Mozilla et Opera offrent de nombreuses fonctionnalités natives et extensions permettant de lire ce genre de chose sur un site. Certains sont adeptes des extensions Mozillas. Pour ma part, je préfère le mécanisme des CSS utilisateurs exploitées par Opera, question de goût et de couleurs Pour révéler les en-têtes d'une page à l'aide d'une CSS (et donc les urls des feuilles de style, les metas, les links...) voir cet essai rapide (à améliorer): L'envers du décor en CSS

Sur les id du body et les styles utilisateurs, deux posts récents en français : Des sites et des feuilles de styles utilisateurs et aujourd'hui pour Mozilla : Une feuille de styles utilisateur par domaine

J'ai dû mal m'expliquer : la solution ci-dessus n'a rien à voir avec le statut des membres. Ils peuvent (et doivent, dans ton cas, être simples utilisateurs). C'est toi, en tant qu'administrateur, qui définit les catégories, et qui gère leur utilisation un peu particulière dans cette solution. Il faut seulement demander à tes membres ne pas utiliser une autre catégorie de post autre que celle par défaut pour chacun (tu peux configurer cela depuis ton interface admin) en attendant d'avoir écrit le code PHP qui le leur interdira. C'est plus clair ? Sinon, je fais une simulation sur une url de test DotClear et je t'envoie l'accès administrateur par message privé. Tu auras ainsi un exemple concret à reproduire.

Non. Il y a un droit de propriété du créateur de design, au même titre que de l'auteur du contenu. L'id du body est généralement utilisée pour permettre aux visiteurs de gérer finement leurs préférences de présentation sur un site en particulier à l'aide d'une CSS utilisateur appliquée par leur navigateur (ça n'existe pas dans IE). Graâce à cet id propre au site, ils peuvent définir des règles CSS visant uniquement le site en question. Mais pour cela, l'id doit être vraiment unique et spécifique à ce site en particulier. Ici, le "id haut" ne relève manifestement pas de ce mécanisme, et doit plutôt être une erreur (body est l'élément racine unique qui n'a besoin d'aucun id pour renforcer sa spécificité).

Il manque un glossaire simple et pratique des propriétés CSS, tout comme il manque un glossaire "bonnes et mauvaises pratiques" du XHTML. Diverses choses sont en cours pour y remédier. D'ici là, les index des spécifications sont souvent, intuitivement, l'aide la plus rapide : - CSS : http://www.yoyodesign.org/doc/w3c/css2/propidx.html - HTML (éléments) : http://www.la-grange.net/w3c/html4.01/index/elements.html - HTML (attributs) : http://www.la-grange.net/w3c/html4.01/index/attributes.html