LaurentDenis

Hum... Pourquoi compliquer inutilement les choses et vouloir "forcer" un comportement chez l'utilisateur ? Il a le choix, avec les seuls fonctions de son navigateur, entre : - cliquer le lien avec ouverture éventuelle dans son navigateur - choisir dans son menu contextuel "enregistrer la cible sous..." (ou autre équivalent). Bref, ce type de fonctionnalité devrait être laissé côté client, avec de simples liens directs du type : <a href="blabla.pdf" title="pdf">bla bla</a>

Il y a beaucoup à faire pour améliorer l'accessibilité, car avec un lecteur d'écran, je ne dépasse pas la page d'accueil qui est très difficilement consultable... Le mieux est de tester la page avec Wave : http://www.wave.webaim.org/index.jsp Il t'indiquera les différents points à corriger. Pour le plus urgent : - les images uniquement décoratives doivent être dotées d'un alt="" - La mise en page se "linéarise" très mal dans les medias où les tableaux utilisés pour la présentation ne sont pas restitués (consulte l'aperçu dans un navigateur texte) Il faut au minimum fournir au début de la page un mini-menu d'accessibilité contenant des liens "aller au contenu", "aller à la navigation", "aller à la recherche". Mieux, refaire la mise en page sans tableau, ou à défaut, avec un tableau unique de ce type : <table> <tr> <td id="vide"> </td> <td rowspan="2" id="contenu"> ici le contenu </td> </tr> <tr> <td id="menu"> ici une colonne de navigation qui sera placée à droite </td> </tr> </table> Le première cellule (vide) et le rowspan="2" permettent au tableau de se linéariser correctement dans un navigateur texte, une plage braille, un lecteur d'écran, etc : le contenu de la page apparaîtra en premier, le menu en dernier.

Balisage des éléments de formulaire : les listes de définitions (voir article récent traduit par pompage.net) offrent une solution élégante sur le modèle : <dl> <dt><label for="...">...</label></dt> <dd><input id=..." name="... ></dd> </dl> (Non, ce n'est pas un détournement de balise : revoir la spécification HTML4.01 qui invite explicitement à étendre l'usage de ces listes au-delà des définitions proprement dites) Accesskeys : inutile d'encombrer tes formulaires avec des accesskeys systématiques. Le sujet sera bientôt traité sur OpenWeb. Disons simplement que ce mécanisme d'accessibilité nécessiterait une sérieuse remise en question. Mieux vaux soigner l'ordre de tabulation (tabindex) et les labels, plus pertinents. Enfin, l'attribut title ne doit être utilisé que - s'il apporte une information pertinente en complément de l'intitulé du lien, - s'il est bref (il sera éventuellement lu par jaws, IBM HPR...) - et s'il contribue à identifier la cible du lien. Autrement dit, si l'intitulé des liens donne clairement le titre de l'article. le title peut être exploité pour donner la date de parution, l'auteur, le site-cible... Mais en aucun cas "Lire cet article" qui serait identique pour tous les liens (inutile des points de vue sémantique et ergonomique et gênant du point de vue accessibilité). Ni "Lire cet article : titre de l'article" puisque l'info est déjà dans le contenu du lien. Au passage, ne pas oublier hreflang pour les liens.

Merci Monique

Mort au champ d'honneur... De profundis. Minute de silence...

Pas le temps d'en faire bcp ce matin, mais la page-test est inconsultable dans Opera (7.50 preview 3), qui ne donne aucun scroll et n'affiche pas le texte de contenu. Un peu brutalement dit, je n'ose pas penser à ce que ça donne dans un navigateur texte, un lecteur d'écran, un robot de moteur de recherche... En fait, ce serait bien de partir, déjà, d'un code HTML plus "propre" et plus proche de la validité. Es-tu intéressé ? Et puis, décider en connaissance de cause pour les bidules qui bougent : c'est totalement inaccessible pour x% des utilisateurs, et les mesures d'accessibilité sont plutôt lourdes à mettre en oeuvre pour ça. Franchement, la page serait plus attractive sans le flash (c'était bien du flash, il me semble ?)...

Dinostrate : Le "zoom intégral d'Opera" est en effet imparable. Mais la question était abordée par Daniel Glazman (http://glazman.org/weblog) à propos des possibilités dans Mozilla... La référence exacte dans son blog doit dater de quelques mois, mais je n'ai plus ça sous la main, désolé. En tout cas, c'est à lire sur le sujet, vu l'auteur

Rockz : lol ! Je retiens l'américain et son caddie de hamburgers. Excellent ! En fait, c'est à peu près l'image que j'ai de DreamWeaver en général, et des bidouillettes à feuilles de style en particulier : CSS est un langage très simple et au vocabulaire très concis et assez intuitif (on est loin d'une horreur type Docbook) qu'on a tout avantages à écrire à la main. Alors n'hésitez pas, si vous voulez vous lancer dans CSS, à revenir au bon vieil éditeur texte. Un bookmarklet avec l'index des propriétés de la spec CSS2 sous la main est sans doute le meilleur outil dans ce cas. (Si un p'tit instit de campagne comme moi a pu le faire quand il n'y avait pas une seule ressource en français sur le sujet, ou presque... des "pro" comme vous devraient y arriver, non ? ) Sinon, désolé si ma réponse était un peu abrupte : c'était tout à fait involontaire, j'étais juste pressé, en fait. Hum... Dans ce cas, un problème de méthode : est-ce que la dégradation "verticale" (ou du moins ce que l'oeil en perçoit) n'est pas affectée aussi par l'extension horizontale due au fameux 100% en largeur ? Je marche sur des oeufs, mais il me semble que le test serait plus probant avec un comportement plus réaliste de l'image. Et même, avec un contenu fictif dans le menu, et un contenu fictif à droite du menu, puisque l'oeil ne se fixera plus de la même manière sur les défauts éventuels de l'arrière-plan quand il aura quelque-chose à lire... Bref, prendre la page globalement, puisque c'est ainsi qu'elle sera d'abord perçue ? ça se passe très en dessous de toute largeur probable d'affichage... là où les moteurs de rendu des navigateurs ne sont plus supposés faire des choses cohérentes... La raison est peut-être à cherche du côté de l'implémentation médiocre de l'overflow dans IE. En tout cas, ce test est intéressant. Continue ! On te suit.

Hum... si tu permets un petit dégrossissage de ta CSS, qui comporte en effet pas mal de choses inutiles : div { background-repeat: no-repeat; background-position: 0% 0%; Où est le contenu du background ? Tout ceci est inopérant sans un background-image: url("...") background-color: #71FA6D; Pourquoi ? L'image remplit toute la div. Sauf cas d'une image PNG et d'un jeu de transparence, la couleur d'arrière-plan ne risque pas d'être visible. position: relative; left: 0%; top: 0%; Pourquoi ce positionnement ? Puisque cette div n'est pas décalée, et qu'elle n'a pas de contenu positionné, ces règles sont inutiles. height: 100%; width: 100%; Donc le contenu de ta div s'étendra à toute la zone d'affichage. C'est le but recherché ? Mais du coup ce qui suit est inopérant : float: left; Ce float n'a pas lieu d'être puisque la div utilise toute la largeur disponible et qu'aucun contenu ne pourra donc lui être adjacent. margin: 0%; padding: 0%; Syntaxe incorrecte. Pour supprimer marges et remplissage, on écrit: margin: 0; padding: 0 (sans unité) border: 0% #71FA6D; syntaxe inopérante. s'il s'agit de spécifier "pas de bordure", c'est border: 0; S'il faut une bordure, c'est par exemple border: 1px solid #71FA6D; } body { background-color: #71FA6D; C'est tout la zone d'affichage qui doit être verte ? margin: 0%; padding: 0%; border: 0% #71FA6D; Voir ci-dessus pour la syntaxe float: left; Le body 'est le conteneur initial, il ne peut pas flotter. C'est inopérant. width: 100%; Pourquoi ? height: 100%; Pourquoi ? Ah ! Peut-être à cause d'IE. qui n'étend pas la div à toute la hauteur d'affichage ? ça échoue cependant dans d'autres navigateurs. left: 0%; top: 0%; position: relative; Le body ne peut pas être positionné. C'est le conteneur initial. (je laisse de côté un éventuel stylage de l'élément html en xhtml strict) } img { background-color: #71FA6D; background-position: left top; background-attachment: scroll; Même remarque que pour le background de ta div : inopérant sans un contenu d'arrière-plan. margin: 0%; padding: 0%; border: 0% #000000; Voir ci-dessus pour la syntaxe float: left; L'image flotte à gauche dans une div dont elle est le seul contenu et dont elle occupe toute la largeur: il n'y a donc rien qui soit supposé venir la flanquer à droite, ou qui puisse le faire. C'est inutile. height: 100%; width: 100%; L'image sera étendue ou réduite de manière à remplir la totalité de la div. OK position: relative; left: 0%; top: 0%; Inutile et inopérant pour les mêmes raisons que ci-dessus. clear: left; L'image ne risque pas d'être adjacente à un contenu flottant et de devoir être repoussée en dessous de lui, vu qu'il n'y en a pas dans la page (son conteneur div ne compte pas ici). Donc inutile. } Là où je ne comprends plus du tout, c'est " dans des proportions raisonnables pour un menu-gauche". Rien n'est à gauche ici, puisque toute la largeur d'affichage est occupée. Où le menu est-il supposé se placer ? A gauche ? Et le contenu de la page doit le flanquer à droite ? Je résume si c'est bien ce que tu cherches (avec un correctif du HTML pour l'accessibilité, et en laissant de côté cette histoire de hauteur trop mal gérée par les navigateurs pour que height soit exploitable au niveau des div conteneurs et du body) : ---HTML <body> <div><img src="images/image_02.jpg" alt=""></div> </body> ---CSS body { background-color: #71FA6D; /* si tout doit avoir un arrière-plan vert */ margin: 0; padding: 0; } div { float: left; width: 25%; /* (par exemple)*/ } img { border: 0; height: 100%; /* l'image s'étend à toute la surface du menu */ width: 100%; } Si ça n'est pas l'effet recherché... Ta page-test sera sans doute plus explicite ?

Auriez-vous quelques exemples de sites utilisant des iframe version timbre-poste, genre franchement trop petits et pas commodes à lire ? Et d'une manière générale, des pages où des champs de formulaire ou autres bitonios sont sous-dimensionnés ou écrits trop petits ? Je cherche à développer quelques bookmarklets pour faire face à ce genre de pb, mais je manque d'exemples pour tester... Merci

Position absolue avec seulement un left, pas de top Le pied de page doit être une div distincte du contenu, en clear:left;

Résultat aussi bien dans Opera que dans FireFox (Win) : le menu apparaît sur la div site, la marge gauche est vide. Il vaut mieux développer ses CSS pour un navigateur ayant un meilleur support CSS2 (indifféremment Opera ou Moz), puis adapter aux lacunes d'IE Win. [edit] Pardon, j'oubliais l'important : souvent, les problèmes de mise en page à base de colonne en float tiennent en fait au box-model Microsoft / standard, autrement dit à des dimensions trop strictement calculées en margeur...

Clear interdisant à l'élément d'être adjacent à tout bloc flottant quel qu'il soit... j'ai bien peur que oui, en effet, il s'appliquera à tous tes blocs float left. Un solution à explorer consiste à introduire un doigt de positionnement absolu dans la combinaison des blocs conteneurs. Le principe est, rapidement : #gauche { float: left; width: 15%; } #droite { position: absolute; left: 20%; width: 100%; } .vignette { float: left; width: ...; height: ...; } hr { clear: left; } Pour : <div id="gauche"> ... </div> <div id="droite"> <div class="vignette">vignette</div> ... <hr /> <p>blabla</p> </div>

Les bugs CSS d'IE5 mac sont répertoriés en particulier ici : http://www.macedition.com/cb/ie5macbugs/#floatclearbug Globalement, IE5Mac supporte à peu près correctement CSS1, mais se met facilement à tousser face à CSS2. Par exemple, voir Crashing bug: vertical-align and background: inherit sur la page ci-dessus.

Source ??? Suis très intéressé, là. La Wcag vieillit mal, et les remises en question ne manquent pas, mais sont très dispersées. Le remplissage exemplaire des zones de formulaires semble en effet apporter peu... Et le label est effectivement plus important... Pour une fois qu'un attribut d'accessibilité est réellement exploité par les Jaws et autres IBM HPR...

Le style switcher fonctionne. Mais comment y accède-t-on, à part depuis le plan du site ? Parmi les problèmes subsistant, quelques urgences : - l'attribut id ne peut pas être répétitif. Un id est unique dans une page (mnémotechnique : id = identité). Dans le menu <p class="enligne">... par exemple, il faut remplacer id par class, et modifier la CSS en conséquence. une class peut être répété autant de fois qu'on veut dans une page. - gérer l'attribut alt des images. Voir http://openweb.eu.org/articles/accessibilite_images/ (désolé de me citer, mais on a écrit l'article pour ça) - encoder l'ampersamp dans les url : ?blabla&bidule s'écrit ?blabla&bidule -revoir la syntaxe de l'élément script

<center> servait (mais ne sert plus) à dire à un navigateur capable de le comprendre (pas tous) : "mets moi ça au milieu de ..." quand c'est dans quelque-chose qui a un milieu, et que c'est visible sur la fenêtre d'un navigateur graphique. ça ne sert pas à diviser une "page" en parties visuelles. Il n'y a pas de balises HTML pour diviser une page en parties visuelles...

Attention : onfocus="this.value=''" peut poser un problème dans certains cas. Par exemple, l'utilisateur a entré son adresse mail et a fait une erreur. Il veut revenir sur le champ pour corriger... tout est effacé. Il vaut mieux prévoir l'effacement seulement si la valeur est du champ est égale au texte par défaut. J'utilise (pour un champ contenant le mot "facultatif" par défaut) : onfocus="if this.value == '(Facultatif)') {this.value=''}" Mais on doit pouvoir faire bcp mieux ?

Pour dessiner des accolades au niveau texte, il y a des caractères standards disponibles dans toutes les polices : [ { } ] Pour des accolades graphiques (accolant plusieurs lignes de texte)... il n'y a guère qu'une image gif ou png. Ou alors, on rentre dans le problème des signes mathématiques, de la norme Math Xml , et là, ça devient un peu futuriste vu le peu de support actuel dans les navigateurs. Et très compliqué. Le reste relève du bricolage franchement hasardeux. D'autre part, les polices symbol... n'existent pas du point de vue css. Je suppose que celles en question ici rentrent dans la série CSS générique "fantasy", dont la caractéristique est d'être totalement imprévisible, vu la variété des formes. Elle n'est pratiquement jamais employée sur le Web. Voir la spec CSS2, assez accessible dans cette partie : http://www.yoyodesign.org/doc/w3c/css2/fon...c-font-families (en français) Sinon, il y a un bon article simple sur le choix des polices et un autre sur la taille des polices ici : http://edu.ca.edu/article67.html http://edu.ca.edu/article70.html

Mozilla non plus n'implémente pas bien la norme Il faut l'aider avec CSS pour qu'il différencie les guillemets...

Une amélioration simple de la page, qui ne coûtera que quelques minutes : mettre un attribut alt="" pour les images spacer.gif ça complètera les titres alt bien renseignés des autres images, et ça rendra la page beaucoup plus sympa pour les utilisateurs non visuels ou texte

IE ne respecte pas le standard HTML pour l'élément q : le texte n'est pas encadré de guillemets... et CSS n'y peut rien, sauf à compromettre le HTML : - en remplaçant q par un autre élément ou en le supprimant, - et en mettant les guillemets directement dans le contenu. Dès lors que le contenu de q est signalé aussi par l'italique via CSS... est-ce si grave ? Le sens (c'est une citation) est bien rendu. C'est ce qui compte. Si c'est quand même si grave... il y a un javascript... tordu. http://www.ookingdom.com/design/phrase (en anglais) J'oubliais, au cas où ce serait utile: obtenir des guillemets français avec les espaces insécables là où il faut : q { quotes: "\00AB\00A0" "\00A0\00BB" "\0022" "\0022"; font-style: italic; } Styler les guillemets selon la langue de la citation : <q lang="en">blablabla</q> q[lang=en] { ... } q[lang=de] { ... } Pour les codes d'entités à utiliser pour obtenir les différents types de guillemets nationaux, voir tout simplement : http://www.w3schools.com/css/pr_gen_quotes.asp (en bas de page, petit tableau bien propre)

Ne me faites pas dire qu'il faut proscrire les pixels ! Les tailles absolues ont leur rôle, mais pas n'importe où. Un design peut être fluide avec un position:fixed ou :absolute, en px, ou avec des width en px, si : - on est en dessous des valeurs critiques qui provoqueront un scroll ou un renvoi de float... - on s'y prend avec soin. Ce n'est pas le plus facile ;-) C'est pourquoi, pour commencer à faire du fluide, il vaut mieux en rester aux em et aux %.

L'association en question a pour but principal de séparer présentation et contenu, pour obtenir un contenu mieux structuré, plus significatif et plus exploitable. Un autre but, moins important, est d'obtenir une présentation qui ne dépende pas de fonctionnalités propriétaires de tel ou tel navigateur, et qui soit donc réussi sur tous les navigateurs eux-mêmes respecteux des standards. Pour les navigateurs sans support CSS, le contenu brut accesible sans fioriture. Quant à vouloir un design parfait dans tous les navigateurs conformes, toutes les configurations d'utilisateurs... Non, pas au sens du même rendu partout : - C'est illusoire, - Ce n'est pas "l'esprit" des CSS : il s'agit plutôt d'avoir la garantie que la présentation se dégradera certes, mais correctement, sans effets gênants pour la lecture et sans que l'équilibre du design ne soit remise en cause (design "fluide") Enfin, pour Macromedia : pour obtenir le design "fluide" ci-dessus, l'erreur à ne pas commettre est d'utiliser des valeurs absolues (px) pour le dimensionnement et le positionnement. Petit extrait de la feuillede style de Macromedia : #fma-home, #homepageStaticFMA { padding: 0px; margin: 0px auto; width: 756px; height: 208px !important; height: 202px; text-align: left; } Petit extrait de la feuille de style d'OpenWeb : #actualite,#articles{ padding:0 2%; width:100%; voice-family:"\"}\""; voice-family:inherit; width:63%; }

Faire à tout prix, non. Faire en fonction de la présentation non plus : -A données tabulaires... balisage tabulaire -A données linéaires... balisage textuel