LaurentDenis

Lorsque je clique sur un lien vers une page d'accueil de site, je m'attends à être bien accueilli, c'est à dire à trouver la porte ouverte, et à pouvoir entrer immédiatement dans le site. Quand je trouve la porte fermée, avec un bouton du genre "cliquez ici pour entrer dans mon site"... comme je suis un peu paresseux, je renonce et je m'en vais Ta "page d'accueil" en l'état ne sert à rien qu'à faire perdre son temps au visiteur. Fais plutôt entrer directement sur http://users.skynet.be/bk371725/home.htm

J'étais un peu pressé hier soir, et je n'avais pas vu qu'il te le fallait en majuscule, et que tu le voulais dans l'attribut alt... Donc, en fait, en bref : - tu ne peux pas l'avoir dans l'attribut alt à cause d'IE - l'encodage numérique valide est &#338; et non &#140 qu'il ne faut surtout pas utiliser. - la police de caractère n'y est pour rien - c'est la faute à Windows Essayons de débrousailler un peu tout ça : Tu travailles sous Windows, n'est-ce pas ? De nombreux outils d'éditions (HTML et autres) sous Windows n'encodent pas tous les caractères de manière standard (en ISO-8859-1 par exemple) : ils encodent selon le charset propre à Windows, qui est Windows-1252. Dans ce charset Windows, une série de caractères ne sont pas encodés de manière valide, c'est à dire conforme au standard ISO-10646 sur lequel repose le HTML. Il s'agit des caractères codés (par Windows) de &#129 à &#159 qui ne doivent donc jamais être utilisés en HTML. Le Œ et le œ en font partie. Attention: "encoder" ne veut pas dire forcément "mettre le code numérique" (&#338;), mais tout simplement mettre le caractère, que ce soit sous forme littérale ou numérique, dans un éditeur sous Windows. Encodés incorrectement, ces caractères ne donneront le résultat attendu que dans un navigateur (ou une autre application) qui utilise le charset Windows-1252. Ce qui complique les choses et qui fait qu'on ne voit pas toujours le problème, c'est : - qu'IE, et d'autres navigateurs, interprètent en fait souvent les pages en Windows-1252, sans le dire, même si l'encodage ISO-8859-1 a été spécifié à l'aide d'une méta. C'est pourquoi ton caractère était partiellement restitué dans ton navigateur et dans ta base de donnée... - que beaucoup de tableaux d'équivalence donnant les encodages numériques des caractères indiquent cette plage de codes incorrects au lieu des bos codes. D'autre part, l'encodage de ces caractères en entités caractères (&oelig; et &OElig;) est valide... mais ne sera pas reconnu dans tous les cas par tous les navigateurs Le bon encodage de ces caractères, valide en HTML, est indiqué dans ce tableau de référence : - & #8230; pour le point de suspension, et non & #133; - & #338; pour le Œ et non & #140; - & #339; pour le œ et non & #156; - & #8212; pour le tiret cadratin —, et non & #151; - etc. En les utilisant, ton Œ passera partout dans tous les navigateurs... Et pour les moteurs de recherche aussi (l'encodage numérique est en fait le moyen le plus direct de faire référence au caractère recherché dans le Character Set ISO-10646 qui est la référénce utilisée par les moteurs de recherche). ...sauf dans l'attribut alt avec Internet Explorer ...qui a un bug là-dessus Moralité : un Œuf <img src="..." alt="un oeuf">

Hum... Pour aller au plus simple, encode ton caractère en entité numérique : &#339; [edit] Sgrnwf de %$! de ... qui interprète les entités[/edit] Attention, si tu travaille sous Windows, c'est l'un des caractères que celui-ci encode incorrectement en Windows-1252, même si ta page est théoriquement en ISO-8859-1 (voir http://www.openweb.eu.org/articles/caracteres_illegaux/ et http://www.openweb.eu.org/articles/jeux_caracteres/ )

Ah... Les em sont souvent déroutants, parce qu'une faible différence de valeur peut se traduire par une grosse différence de rendu. D'autre part, il faut te dire que le rendu dépend étroitement de ta configuration d'affichage (résolution, taille par défaut dans le navigateur). Même si c'est un peu grand chez toi... ce sera différent chez un autre Cela dit, tu peux essayer : body { font-weight : normal; font-size : 80%; font-family : Verdana, Arial, Helvetica, sans-serif; background-color : #ff9900; } h1 { font-weight : bold; font-size : 1.2em; color : #333333; font-family : Verdana, Arial, Helvetica, sans-serif; text-decoration : none; } h2 { font : normal 1.1empt Verdana, Arial, Helvetica, sans-serif; } h3 { font-weight : bold; font-size : 1em; font-family : Verdana, Arial, Helvetica, sans-serif; } table { font-weight : normal; font-size : 1em; font-family : Verdana, Arial, Helvetica, sans-serif; border: none; } a { color : #000000; text-decoration : none; font-weight : normal; } a:hover { color : #0955a2; text-decoration : underline; font-style : normal; font-weight : normal; font-variant : normal; } .special { background : #ffffcc; } .petit { font-size : 0.8em; font-family : Verdana, Arial, Helvetica, sans-serif; } .titrebleu { font-weight : bold; font-size : 1.1em; color: #0000FF; font-family: Verdana, Arial, Helvetica, sans-serif; } Qui devrait être correct. La valeur en % pour la taille de caractère du body... est une astuce, critiquable comme toutes les astuces. A ce sujet, voir les commentaires de http://blog-and-blues.org/weblog/2004/05/24/214-font-size-em

Article intéressant, mais... je vais jouer les casse-pieds Contrairement à un discours de plus en plus fréquent dans la promotion des Standards Web, je ne crois pas qu'il faille transformer l'accessibilité en "fourre-tout" en la confondant en particulier avec : - l'utilisabilité / ergonomie dont le but est de faciliter l'accès au contenu, - l'interopérabilité dont le but est de permettre l'exploitation du contenu quelque-soit le media (par exemple, le robot du moteur de recherche). - la sématique (qui concerne également les moteurs de recherche... en théorie) Donc l'accessibilité n'a pas pour "cible" (même accessoire) les moteurs de recherche. Il est vrai, cependant, que certaines contraintes d'accessibilité coïncident avec des pratiques généralement considérées comme utiles au référencement : l'emploi correct de l'attribut alt des images, de l'élément h1, etc. Mais beaucoup de mesures d'accessibilité spécifiques n'ont sans doute guère d'effet sur les moteurs de recherche (l'attribut longdesc serait-il exploité, par exemple ?) D'autres part, deux petits détails : Quel est le rapport entre meta et accessibilité ? <embed> est une balise invalide. L'élément valide est <object>, dont le contenu sert d'alternative si l'objet ne peut pas être restitué.

Arf ! IE n'y est pour rien, le pôvre Il refuse d'afficher le code source... tout simplement parce qu'il n'y en a pas C'est une image qui est envoyée en text/html, au lieu de image/jpeg, ou image/png, etc...

S'il s'agit du script générant ce bloc... il faut s'adresser au webmestre du site, S'il s'agit du design du bloc... il faut s'adresser au webmestre du site, Lequel mérite qu'on respecte ses droits et qu'on ait la politesse de lui demander son accord avant de reprendre une partie de son travail Cela dit, au passage, le site en question m'a l'air d'utiliser un de ces %%W?x§ ! de scripts de détection de navigateurs... qui n'aime pas mon firewall et qui m'a obligé à passer par le cache de google pour afficher sa page d'accueil

Ce n'est pas le pixel qui est redimensionné ! (Quoique pour cela, il suffise de changer de résolution d'écran) C'est la taille par défaut des caractères dans le navigateur, exprimée en pixels, qui est modifiée lorsqu'on redimensionne. Cette taille par défaut est celle que l'utilisateur a définie dans les préférences de son navigateur et qui sert de base à l'affichage en em, puisque 1em = la taille par défaut dans ce navigateur. En fait, redimensionner une page en em et une page en px, c'est la même chose...

Comme dit plus haut: Ce sujet est fermé.

Source : Supprimer du contenu de l'index Google

Denis a tout à fait raison sur le plan pratique Mais en fait, c'est dû à un bug d'IE qui ne redimensionne pas les pixels... qui sont en fait une unité relative au même titre que les em, et devraient donc être redimensionnables dans tous les navigateurs. les unités absolues (pt, cm, etc...) sont essentiellement celles du media "print" (impression papier).

En fait, je ne l'ai documenté que pour les citations, mais le principe est exactement le même pour qu'un <abbr> par exemple renvoie sur un glossaire (c'est déjà le cas sur Blog&Blues). La seule différence est que l'url du pseudo-lien n'est pas récupérée dans un attribut de l'élément, mais fixée directement dans la CSS et le fichier XBL...

L'affichage des "title" dans les navigateurs Gecko souffre en effet de rognage du contenu... sans solution. cela dit, dans le cas d'<abbr> et d'<acronym>, ces balises sont destinées à définir des abréviations/acronymes/sigles uniquement. Pour qu'une explication d'un mot apparaisse au survol d'un mot ou d'une expression qui n'est pas un sigle, on peut utiliser au choix: - <em title="..."> ou <strong title="..."> si une emphase est souhaitée sur le terme - <code title="..."> si c'est un terme issu d'un langage informatique - <span title="..."> dans les autres cas. Cela dit, l'explication est réservée aux utilisateurs de navigateurs et autres medias qui gèrent par défaut les titles... Ce qui exclue pas mal de monde Idéalement, faire plutôt : Blabla... <dfn>Mon expression</dfn> (Son explication). Enfin, il y a un petit truc sympa pour Opera et FireFox/Mozilla, pour créer un lien vers un glossaire, généré par le navigateur à partir des seules balises type <abbr>, <code>, <span>, etc... Voir http://blog-and-blues.org/weblog/2004/08/2...ite-pseudo-lien (le même principe, mais appliqué aux citations)

Tout dépend de la manière dont ta feuille de style est liée au document : le visibility:hidden (comme le display: none) sera ignoré avec le reste de la feuille de style dans certains cas (feuille de style importée) mais pas dans d'autres (feuille de style liée). Mais comme Jaws n'est pas le seul lecteur d'écran, et que chaque lecteur a son propre comportement (voir http://css-discuss.incutio.com/?page=ScreenreaderVisibility pour les détails )... mieux vaut s'abstenir d'utiliser visibility:hidden (et display: none) pour masquer du contenu aux navigateurs graphiques si ce contenu doit être restitué dans les médias vocaux. (Accessoirement, ton point-virgule est ignoré à la lecture dans Opera 7.60 vocal, pour la même raison) Au passage, il faut distinguer: - visibility: hidden pour lequel c'est un bug des lecteurs d'écran (visibility ne s'applique pas au media aural pour lequel il est remplacé par la propriété speak) - display: none, pour lequel ils respectent involontairement les spécifications CSS (display s'applique à tous les medias) Une remarque à propos de tes séparateurs ";" : dans la mesure où tes liens sont placés individuellement dans des éléments <li>, le séparateur n'est pas indispensable.

En fait, le caractère est lu, par exemple sous la forme "bar" en anglais, "barre" en français...

http://www.eurodns.com/whois/restriction.php?id=62

Ce que tu cherche n'a aucun rapport avec XML (Voir titre du sujet modifié) Tu cherches un menu déroulant... Tu trouveras les base dans http://www.openweb.eu.org/articles/menu_universel/ Cela dit, la solution la plus efficace et la plus mûre est d'oublier le menu à coulisse, et de faire un simple formulaire...

Je vois mal l'intérêt de cette conversion en HTML. Si le navigateur ne supporte pas application/xhtml+xml, XHTML1.0 peut lui être servi en text/html s'il respecte http://www.w3.org/TR/xhtml1/#guidelines

Heu... Ton image est bel et bien dans le cadre rouge, aussi bien dans Mozilla, FireFox et Opera 7.5x / 7.60 que dans IE6.0...

Je le fais pour des auteurs diffusant gratuitement des applications ou des patchs qui me sont particulièrement utiles.

Pour ceux qui hésitent à utiliser Opera 7.54 (la dernière version finale d'Opera en date) ou à essayer Opera 7.60 Preview 1 (nouvelle version de test) parce qu'ils ne sont disponibles actuellement qu'en anglais, un petit truc : - télécharger la version anglaise, - enregistrer dans le dossier Opera ce patch non officiel pour avoir l'interface en langue française, - Activer le Patch avec le menu Preferences > Langues > Choisir... Au passage, la version de test Opera 7.60 intègre le support de la navigation vocale : vous pouvez commander Opera à la voix, et écouter le contenu des pages Web (en anglais pour l'instant), à la manière d'un navigateur vocal. C'est bluffant !

Bon, quelques précisions : - quelque-soit le détail de la solution retenue, pour certains utilisateurs, une image insérée via CSS sera inaccessible, et aucun équivalent textuel ne sera disponible. C'est le cas si l'utilisateur a coché "Ignorer les couleurs" dans les options d'Accessibilité d'IE, par exemple, ou active la CSS mais pas les images, etc. En fait, ici, CSS est la solution la moins accessible - Séparer le contenu et la préentation ne veut pas dire mettre toutes les images en CSS : une image de logo, un titre ou un lien mis en image... ont tout à fait leur place dans le "contenu", via un <img src="..."> qui sera, lui, beaucoup plus accessible. - il existe d'autres solutions intéressantes que CSS pour gérer des images sans <img src="..."> : javascript et flash en particulier (voir les articles cités plus haut par mee2)

Un navigateur peut, ou ne peut pas traiter du XHTML en tant que XML (application/xhtml+xml). Il n'y a pas de demi-mesure... La négociation du contenu à ce niveau, AMHA, doit rester totalement indifférente au "q-rating".

En fait, ça ira mieux avec http://www.punbb.org/ [edit]Coiffé au poteau par Berberber [/edit] Voir également sur Framasoft, qui en fait l'éloge : http://www.framasoft.net/article2945.html.

Tiens, je viens de remettre la main sur un article de 1997 qui mérite d'être lu par tout ceux qui ne connaissent d'IE que sa version 6.0 en concurrence avec les Gecko et Opera : How I Learned to Stop Worrying and Love Microsoft Vous y découvrirez l'enthousiasme suscité par le support des CSS, l'interopérabilité, etc... grâce à l'arrivée... d'IE4.0