LaurentDenis

J'ai décidémment la tête comme une passoire, aujourd'hui. J'oubliais encore : - une bonne vielle <img src="..." alt="..."> ne pose pas ce type de problème d'accessibilité; - mais tous les titres et liens "texte mis en image" ont un défaut commun : sauf dans Opera, ça ne peut pas être agrandi avec les seules aides à l'accessibilité du navigateur... Et dans Opera ou avec une surcouche de type "loupe", l'agrandissement dégrade parfois suffisamment l'image pour en rendre la lecture difficile...

J'oubliais : Paul Peter Koch propose une solution... en javascript non obstructif qui semble prometteuse : http://www.quirksmode.org/dom/fir.html ... A tester.

Le graphisme est très réussi, en effet. Bravo ! En fait, le texte du menu et celui de #aussi sont à peine discernables sur l'écran de mon portable... Il peut y avoir beaucoup de raisons différentes de désactiver ou de modifier les couleurs : daltonisme, mais aussi vision un peu basse qui fait rechercher des contrastes plus élevés, généralement en clair sur fond sombre... Mais il y a aussi un autre problème, c'est la manière dont les navigateurs s'y prennent. IE a une option Internet Options > Accessibility > Ignore Colors specified on Web Pages ... qui est proprement dévasttatrice puisque qu'elle supprime aussi bien les images d'arrière-plan que les couleurs spécifiques du site. Dans ton cas, le menu est blanc sur fond blanc dans IE avec cette option activée...

Je n'ai plus les détails en tête, mais je me souviens avoir fait cela assez facilement en passant par les "Batch Actions" de HTML-Kit...

"Accueil | Contact | Contribution | Forum" me semblent très explicites, Monique

Une des particularités des utilisateurs d'Opera est, si j'en crois mes sources, leur réactivité à la sortie d'une nouvelle version... Peut-être est-ce dû à un phénomène micro-communautaire, et/ou à la facilité du téléchargement d'une nouvelle version vu son peu de poids ?

Le même message, un peu plus explicite, avec quelques mots en plus, svp ?

Pour ma part, je n'ai pas d'erreur 404, mais de multiples erreurs de javascript liées à la détection de navigateur dont le script est apparemment erroné.

C'est une simple animation Flash... à laquelle il manque un bouton "Pause"

Au passage, une petite astuce pour ceux qui utilisent des bookmarklets dans Opera 7.5x : javascript:if(document.selection) x=document.selection.createRange().text; else x=document.getSelection();void(hubsearch=window.open('http://www.google.com/custom?sa=Rechercher&q='+escape(x)+'&hl=fr&domains=www.webmaster-hub.com&sitesearch=www.webmaster-hub.com','_blank')); Sélectionnez un mot ou une expression dans un document Web et cliquez sur le bookmarklet après l'avoir installé... (Les liens javascript étant bloqués ici, je ne peut pas donner le lien direct à glisser déposer dans votre barre d'outils personnelle. Si vous voulez pouvoir faire un simple glissé-déposé, allez sur Favelets Webmaster-Hub et WordNet [edit]Au fait, ça marche aussi, mais moins bien, dans ce navigateur bizarre... Comment s'appelle-t-il, déjà ? Ah ! Oui : Mozilla, je crois

C'est bien le problème avec les résumés comme celui de l'altruiste : il aurait dû lier explicitement cet attribut "target" avec le document qui le définit... et qui est lui-même un autre projet en cours du W3C. En effet, le "target" présent actuellement dans le Document de travail XHTML20 n'est pas celui du HTML4.01 ! Il fait référence au projet de module XFrames, qui remplacerait à terme HTML4.01 frameset et XHTML1.0 frameset. Xframes permettrait de composer des documents dans un même frameset, mais en corrigeant les défauts du frameset HTML4.01, et en particulier en identifiant exactement chaque "combinaison" possible à l'aide d'une URI d'un type nouveau permettant au navigateur de gérer l'historique de navigation, aux moteurs d'exploiter correctement le framset, etc... Pour info, cet URI serait du type : Voir le WD XFrames Enfin, le Working Draft du module XFrames ne fermant pas la voie à l'utilisation de target pour... ouvrir un lien dans une nouvelle fenêtre, voilà un exemple de retour éventuel à faire à www-html-editor_AT_w3.org (à propos de XFrames, pas de XHTML2.0 qui s'en remet à XFrames là-dessus)

Bon, sur le fond : Regardez par la fenêtre (la vraie, pas celle sur l'écran). De votre place, vous voyez un horizon donné. Vous savez cependant que le monde extérieur ne se limite pas à cet horizon. Il suffit de vous déplacer même légèrement pour le vérifier : votre fenêtre vous donne un aperçu différent où apparaissent de nouvelles informations. C'est l'image exacte du "viewport", la fenêtre de visualisation du navigateur Web. Le document contient bien plus que ce que ce viewport peut vous en montrer, même si celui-ci est réduit à un seul mot (il suffit de penser aux metadonnées éventuelles, à ce qu'une feuille de style alternative jouant sur la visualisation des attributs html et des meta, link, etc. peut faire). Donc le viewport n'est qu'une "fenêtre", pas au sens que nous lui donnons à propos des ordinateurs, mais au sens d'une fenêtre réelle. Alors, pourquoi vouloir ajouter dans cette fenêtre inévitable un sous-fenêtre (comme dans le cas de ce site), ou vouloir réduire le monde à x * y pixels ? Autant la largeur figée (horizontale) ne pose pas de problème, autant la hauteur figée est, AMHA, étrangère à la notion de navigateur graphique...

Je n'ai pas eu le temps de regarder ton site en détail (surtout côté accessibilité), mais il me semble que : - en l'état, c'est déjà un excellent site au graphisme réussi, et qui m'a semblé tout à fait fonctionnel - ça l'est d'autant plus que tu te dis "autodidacte complet" - c'est une première étape très réussie avant de passer à un design "fluide" qui ne sera pas aussi difficile à aborder que tu sembles le penser, vu ce que tu as déjà fait. Ma remarque dans mon message précédent ne doit surtout pas te décevoir : je croyais avoir affaire à un vieux routier des CSS, à voir ce que tu as fait Sur le fond, maintenant : une quelconque "tyrannie des grands écrans" n'a pas lieu d'être. Utiliser un grand écran avec une haute résolution... suppose qu'on en tire les conséquences... et qu'on fasse appel au besoin à un navigateur capable de "zoomer" n'importe quelle mise en page

Tu trouveras notamment chez Anne van Kesteren et Derek Featherstone (aussi cet article sur la disparition d'accesskey)des réflexions très intéressantes sur des implications bien concrètes des futurs éléments XHTML2.0... Bonne lecture

Je ne rencontre pas de problèmes pour "scroller" à la souris (IE5.0, 5.5, 6.0 - Opera 7.23, 7.5x - Mozilla, Firefox) Pas de problèmes non plus pour consulter et naviguer au clavier En revanche, si le design est très réussi (beau site et beaux chiens ), cette idée d'un "viewport" (zone d'affichage) réduit dans celui du navigateur m'a toujours semblé un peu... suprenante et superflue Pourquoi ne pas exploiter la totalité de la fenêtre d'affichage du navigateur, et ainsi le laisser pleinement gérer le scroll ?

Hum... C'est un peu ancien, et les navigateurs récents ne sont pas pris en compte. CSS panic Guide, Position is Everything et QuirksMode, par exemple, sont plus d'actualité. A compléter...

Peux-tu donner l'url de ton site, svp ?

Le sujet pixel et em, c'est quoi ? Avantages et inconvénients, conversions, etc... avait été discuté ici récemment dans 1 em = combien de px?

Aïe ! Je savais bien qu'il fallait actualiser quelque-chose dans OpenWeb cet été, mais je n'arrivais plus à mettre le doigt dessus. Merci XHTML en est actuellement à XHTML1.1 pour sa dernière recommandation en date. Pour les curieux, le long processus d'élaboration d'une spécification W3C est détaillé dans le World Wide Web Consortium Process Document. Rapidement : 1- c'est d'abord un simple "technical Report"; 2- puis une série de "Working Draft" successifs, soumis à la critique des différents groupes de travail du W3C, plus généralement des membres du consortium, et à celle du public. A ce stade, le projet ne peut encore être implémenté dans les navigateurs, il est purement théorique et peut être sujet à toutes les modifications au fil des "Working Draft", voire être abandonné. 3- puis est publié un "Last Call Working Draft", considéré comme stable, qui permet de commencer l'implémentation dans les navigateurs à titre de test. A ce stade, le document est toujours ouvert à la critique. 4- puis vient le stade "Candidate Recommendation" 5- puis "Proposed Recommendation." 6- et enfin "Recommendation". XHTML2.0 en est encore au stade 2: c'est un Working Draft, autrement dit un document de travail, suceptible de toutes sortes de modifications, non implémenté dans les navigateurs et encore très loin du statut de recommandation finale. Donc : XHTML2.0 n'est pas un standard Web et ne doit être en aucun cas utilisé ni "documenté" comme l'a fait http://www.laltruiste.com. Le but du jeu est simplement de voir comment vous mettriez en oeuvre les éléments du XHTML2.0 dans des scénarios précis, quels problèmes vous rencontreriez, quel précisions manqueraient dans la spécification, quelles implications nouvelles apparaissent... La version la plus récente du XHTML2.0 Working Draft est la 6e, datant de juillet dernier : - elle est disponible à l'adresse http://www.w3.org/TR/2004/WD-xhtml2-20040722/ - et les commentaires à son sujet peuvent être adressés directement au W3C à l'adresse www-html-editor_AT_w3.org (les archives de cette liste de discussion sont consultable à http://lists.w3.org/Archives/Public/www-html-editor/ ) ou à html2.0_AT_openweb.eu.org qui nous permettra de synthétiser et de traduire si nécessaire vos commentaires afin de les relayer auprès du W3C. L'article d'Openweb mentionné ci-dessus va faire l'objet d'une mise à jour... et vos commentaires sur le futur et éventuel XHTML2.0 sont les bienvenus

Quelques précisions : - Les favicons sont stockés dans le cache du navigateur, et sont soumis aux aléas de celui-ci, sans compter quelques bugs (surtout chez Mozilla et FireFox, voir http://bugzilla.mozilla.org/ ). Parfois, il suffit de vider le cache... Parfois, c'est plus mystérieux - Les favicon ne sont déterminés par aucun standard... Ce sont à l'heure actuelle des technologies uniquement "privées", qu'il s'agisse de l'ico de Microsoft ou du png de Mozilla (même si png est un format non propriétaire, son utilisation pour les favicon n'est pas normalisée pour autant). Il n'y a donc ni "bonne" ni "mauvaise" manière de faire, dès lors que le <link rel...> est correctement renseigné. En fait, la technique de l'ico avec le lien complet est même la plus indiquée, puisque la mieux supportée... - Le code <link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" /> ...est suffisant et marche effectivement dans IE6 pour ce site.

On ne peut pas dire que XUL mobilise les foules pour l'instant Sans doute est-ce encore un peu tôt pour cette technologie "émergeante" (hors du cercle des développeurs Mozilla, s'entend)...

Le sujet avait été discuté ici dans Firefox et favicon.

C'est bon pour opera7.5x Parfaitement

Ne pas hésiter à utiliser <hr> pour séparer les sections principales de la page : la lisibilité dans les navigateurs textes est nettement améliorée avec ce séparateur. En fait, il s'agit plutôt d'éviter d'appliquer des padding et/ou des bordure à un élément, pour que sa taille finale affichée soit identique dans les deux modes de rendu CSS (celui propre à IE et celui de CSS1) : les margin n'entrent pas dans ce calcul de dimension des boîtes. Arf ! Me voilà en bien impressionnante compagnie !

L'élasticité de ta mise en page est une qualité En revanche, tes polices de caractères en 10px pour le body, non redimentionnables dans IE... seront illisibles pour certains visiteurs. Mieux vaudrait passer dans l'unité "em", qu'IE sait agrandire.