Xavier

Tu peux cliquer sur la petite flèche pour vérifier. Je t'accorde que ce n'était pas des plus évident

Comme je l'ai dit avec IE 5.5 il y a bien cette barre qui apparaît plus ou moins aléatoirement, mais avec IE 6 (sp2) je ne l'ai jamais vue. Probablement pareil pour le sp1 vu que seuls des bugs de sécurité ont été corrigés, le moteur de rendu lui n'a pas dû bouger d'un iota

Je ne sais pas, mais si c'est le cas tu dois mettre alt="" afin qu'ils ne disent rien en passant sur tes images

Je parlais de IE 6 sp2 En tous cas maintenant c'est parfait dans Mozilla et IE 6

Merci pour vos réponses Entourer les balises abbr ou acronym de span... dans le but de faire "propre" c'est raté J'hésite à m'y mettre, ça ne ferait qu'alourdir les choses. La langue est bien entendu définie pour la page, avec redondance (lang, xml:lang vu que je suis en xhtml et l'entête HTTP content-language) En fait je pourrais reformuler la question, qui était spécifiquement liée aux abréviation, avec en particulier l'exemple de HTML : faut-il imposer la lecture de "HTML" en anglais ("EidjTièMèL" ou quelque chose du genre) afin que le title soit lu correctement ou vaut-il mieux prononcer "HTML" à la française (HachTéèMèL) (ce qui est plus fluide et trancherait moins, rendant du même coup la compréhension plus simple), quitte à risquer une lecture du title plus ou moins hasardeuse ? Et n'existerait-il pas un moyen permettant de définir la langue d'un seul attribut, ce qui serait l'idéal ?

Regarde les infos de la page (dans le menu contextuel). La présence d'un beau doctype fait passer mozilla en mode de respect des standards, c'est à dire un modèle de boîte standard (dans lequel les bords ne sont pas compris dans la largeur de la boîte). En son absence, la page est gérée avec le modèle de Microsoft qui inclut les bordures dans le calcul de la largeur. Regarde donc de ce côté-ci. Remarque : avec IE 6 il y a aussi une différence (mais le décalage se fait dans l'autre sens)

Ça m'a l'air normal sous IE 6. En revanche... si je regarde dans IE 5 le menu est centré. Dans Firefox il est à gauche et dans IE 6 il a tendance à dépasser à la droite sur le contenu... je ne sais pas si ces petites différences sont faites exprès ?

Bonjour, Faut-il indiquer la langue d'une abbréviation ? Par exemple est-il bon de mettre <abbr title="Etended Hypertext Makup Language" lang="en">XHTML</abbr> Est-ce du chipotage inutile ou vraiment utile ? J'ai cherché un peu mais je n'ai rien trouvé à ce sujet (personne ne l'utilise mais je n'ai jamais trouvé une page le déconseillant...) Merci pour vos lumières

Les labels permettent de lier le texte à la zone se saise. Par exemple : <p><label for="nom">Votre nom <i>Your name</i>:<br></label> <INPUT type="text" name="nom" size=30 id="nom"> Avec le for tu fais une relation vers la zone de texte portant le même id (peut-être que ça marche aussi avec name, je sais plus). Petit plus : en cliquant sur "Votre nom", le curseur se positionne automatiquement dans le input correspondant En fait c'est surtout utile quand tu as des tableaux et que les inputs se trouvent loin dans le contenu linérisé. Je trouve quand-même que c'est toujours un petit "plus" Pourquoi les navigateur vocaux ou texte n'auraient-ils pas droit d'avoir un titre digne de ce nom ? À mon avis le mieux c'est de mettre alt="Location ou échange d'appartements, Corse sud [...]". Sinon puisqu'on parle de navigateurs vocaux... comment vont-ils s'y retrouver entre l'anglais et le français ?

Couleurs flash c'est le cas de le dire Pour ma part je n'ai droit qu'à une page orange, mais j'aime bien le orange, c'est toujours plus original que les pages blanches sensiblement plus nombreuses qui parsèment mon chemin Malheureusement pour toi je ne vais pas plus loin sur ce genre de sites et je clique sur le bouton "fermer" qui agrémente chaque onglet de mon navigateur

En tous cas ça donne envie d'aller en vacances Joli, simple, efficace. Une petite remarque, les boutons "old style" du menu supportent mal l'agrandissement dans Mozilla (pas de problème dans IE ou Opera ). En fait seul le texte s'agrandit... Concernant le formulaire de réservation, il n'est pas évident d'accès. En effet il faut passer la souris sur le lien pour le voir un peu bleuir et le pointeur qui change. Il faudrait le mettre plus en évidence (ce n'est pas pour rien que généralement les liens sont bleus soulignés... au moins on les voit tout de suite.) Sinon dans ce même formulaire, tu pourrais utiliser les label c'est très simple et bien pratique (même si dans ton cas c'est évident). Dans le même style il y a un div inutile : <div id="gauche"> <ul class="menugauche"> peut devenir <ul id="gauche" class="menugauche"> Et juste au-dessus tu as deux textes alternatifs pas très adaptés qui feraient mieux de reprendre le texte des images. De même ils pourraient être placés dans un h1 plutôt qu'un div Mais vraiment j'insiste, l'impression générale est très bonne, le look original... j'y vais

Ça viens sans doutes d'une marge (ou d'un padding...) sur #topmenu ul qui n'est pas à 0. En plus tu peux mettre <ul id="topmenu"> plutôt que l'entourer dans une div inutile Ce qui nous donne le code suivant : <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"lang="fr"> <head> <title>Essais de mise en page</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <style type="text/css"> <!-- body,html { margin: 0px; padding: 0px; } #topmenu { background-color: #000000; clear: right; height: 5em; width: 100%; left: 0px; top: 0em; margin: 0px; padding: 0px; } #topmenu ul{ list-style-type: none; } #topmenu li{ float: left; margin-right: 1em; color: #FFFFFF; } #menu { width: 10em; float: left; background-color: #FFFFCC; } #principal { float: left; } --> </style> </head> <body> <ul id="topmenu"> <li><a href="#menu">Menu</a></li> <li><a href="#principal">Contenu principal</a></li> <li><a href="mailto:bidon_AT_bidon.bid">E-mail</a></li> </ul> <div id="menu"> <h2>Menu</h2> <ul> <li><a href="#">menu1</a></li> <li><a href="#">menu2</a></li> <li><a href="#">menu3</a></li> </ul> </div> <div id="principal"> <h1>Positionnement des divs</h1> <p>Héhéhé</p> </div> </body> </html> On dirait que c'est bon

Un problème soulevé par cette (ces en fait, php ou configuration du serveur) techniques est que les navigateurs de type KHTML (Konqueror ou Safari pour ne pas les nommer) n'indiquent pas accepter le type MIME application/xhtml+xml dans leur HTTP_ACCEPT Du coup on leur sert du text/html alors que bien entendu ils supportent très bien le xhtml Ce n'est pas très grave mais ça mérite tout de même d'être mentionné

Lecture très agréable, design simple et efficace, pas de problèmes d'affichage avec Firefox, même avec une résolution de 1280... Par contre les articles de presse ne sont pas stylés car il y a des chemins pointant vers ton disque dur : href="file:///C|/Mes%20documents/Mes%20documents/dossier%20fabienne%20manandise/asbl%20jour%20apres%20jour/JAJ.site/ etc.

Au mieux ton code deviendra moins lisible si un jour tu veux le modifier À toi de voir si ces 36% en valent la chandelle

À mon avis tu devrais commencer par mettre un peu d'ordre dans ton code, de manière à en améliorer la sémantique. Par exemple, en html, un titre (dans le contenu) se met à l'intérieur d'une balise <hx> (h1, h2 etc.), pas dans une soupe de balise comme : </sup></font></font><font face="Verdana" size="2" color="#E74820"><sup> Pour Google ce code ne veut probablement pas dire grand chose, et il lui donnera peu d'importance, en tous cas pas plus qu'un simple paragraphe de texte, car il ne sait pas interpréter les éléments selon leur taille, leur couleur ou leur position. En revanche si tu le mets au milieu d'une balise <h1></h1>, il saura qu'il s'agit du titre de la page. Et lui donnera une importance plus grande. En gros il serait bon d'épurer ton code et de respecter un peu les standards, il me semble. Google donne plus d'importance au contenu en haut du code, hors ici le haut est occupé par le définition de diverses tables imbriquées et leur mise en forme, ton contenu étant relégué plus loin, ce qui ne peut pas être bénéfique. Je ne sais pas quelle influence peut avoir la validation du code, mais il est fort probable que Google s'emmêle les pinceaux s'il y a trop d'erreurs PS : je viens de voir que tu as un <h1>, mais il est carrément au milieu du code, je ne pense pas que ce soit très bon... à confirmer par un expert !

Il me semble que ce genre de balisage n'est reconnu que par Internet Explorer, ce qui veut dire que tous les autres navigateurs seront incapable de jouer ton son, ce qui est bien dommage

Évidemment mon site s'occupe surtout de Firefox Mais seulement pour le contenu qu'il propose. S'il y avait des extensions pour d'autres navigateurs ce serait pareil ! Mais je suis un peu étonné que tu me soupçonne d'avoir optimisé mon code pour Gecko... je ne me suis pas du tout préoccupé de savoir comment il rendait sous IE, j'ai simplement balisé de manière logique. Les spécifications sous la main, ce que je voulais je l'ai mis, tant pis si ça ne passe pas. Pour preuve il doit y avoir quelques display:run-in qui trainent, tant pis pour Gecko s'il ne les supporte pas, il n'y a qu'à utiliser Safari ou Opera. D'ailleurs il me semble d'après ce qu'on m'a dit (à prendre avec des pincettes donc, je n'ai malheureusement pas de Mac pour vérifier) que le site passe très bien dans Safari. Pour les _AT_import à la base je ne savais même pas que IE allait les zapper. Qu'y a-t-il de non-standard à cela ? Au contraire je suis justement en train d'essayer de résoudre ça, et ça c'est plus trop standard Pour moi les standards c'est ne pas s'occuper du navigateur. C'est exactement ce que j'ai fait, me semble-t-il, évidemment la mise en forme saute dans les navigateurs qui ne les respectent pas, on va pas faire un plat de cette évidence. L'important c'est que le site reste lisible, et il me semble que c'est le cas. Quant à la pseudo-détection des navigateurs, elle ne modifie rien. C'est la même page qui est envoyée, à un avertissement près. A ma décharge je dois dire qu'après avoir reçu une grande quantité de mails de gens qui voulaient installer des extensions sur une antiquité (genre Mozilla 0.9) ou dans le mauvais navigateur (si si je ne rigole pas, il y en a qui ont installé des extensions pour Firefox dans la suite Mozilla ou réciproquement... évidemment ça pose des problèmes), eh bien il faut bien faire quelque chose non ? Je t'accorde que ça n'a pas été très efficace, il y en a toujours qui veulent tout faire de travers Je répète, cette détection ne fais absolument rien, s'il n'y a qu'un message d'avertissement qui te pose problème je peux bien l'enlever, mais il me semble que ça ne change pas grand chose au fond, des messages de ce type pouvant très bien apparaitre dans Mozilla aussi. Bref, restons courtois même dans nos coups de gueule et ne nous hâtons pas trop de crier au loup contre une souris, ce sera mieux pour tous

Tu peux mettre des display:block sur tout ce que tu veux, y-compris des tableaux (qui sont par défaut en display:table-[quelquechose] ). Voir la propriété display à ce propos.

La page Browser Statistics de w3schools donne 10%. Il y a les gens comme moi qui n'ont pas envie d'être embêtés (je peux le réactiver en 2 clics), les gens qui ne le peuvent pas pour des raisons physiques, mais il ne faut pas oublier ceux dont l'entreprise a simplement bloqué le javascript (ex : http://www.la-grange.net/accessibilite/day_4.html) qui ne sont pas peu nombreux à ce que je sache, et représentent probablement la majorité des 10%...

Mon site est lisible dans tous les navigateurs, de la dernière version de Firefox à Mosaic 0.1, de Lynx à IE 1-6 ! Tous sont supportés (mais n'est-ce pas plutôt le navigateur qui supporte le site ? Enfin peu importe). C'est ça l'avantage des standards . Que dois-je donc répondre à ta question ? Il est vrai que la mise en forme en CSS est réservée aux navigateurs qui la supportent. Exite Netscape 4.7, IE 6 et autres navigateurs obselètes

La version française a une rubrique "Fichiers en ligne" et une autre "fichiers locaux". Tu peux utiliser la validation locale sur des fichiers en ligne (mais pas l'inverse), dans ce cas tu envoies le code déjà interprété pour Mozilla et fixé, et pas l'adresse. La différence est flagrante et nette, en plus ça joue avec mon explication. Je ne vois pas où tu vois un bug du validateur... si tu lui envoie le code fixé qui a été envoyé à Mozilla, il est déjà interprété et a un doctype 1.1. Si tu lui envoies l'adresse, il y a une "autre" page (c'est logique, c'est même fait pour : "(envoi d'entête différent, publication code différent...)" que tu disais ). Ici le navigateur c'est le robot du W3C, il n'a pas à se soucier de savoir depuis quel navigateur il est lui-même appelé ) Bien, je ne pourrai pas continuer la discussion vu que je pars en vacances (bien vu Monique, j'ai juste eu un petit moment ce soir). Je laisse à d'autres le soin de le faire Bonne vacances à tous ceux qui en ont

C'est logique à mon avis. Si tu fais CTRL+ALT+V (fonctionnalité intéressante que je ne connaissais pas), Opera envoie le code source de la page au validateur (et pas l'adresse). C'est un peu du même genre que la validation locale de WebDeveloper pour Mozilla. Opera acceptant le xhtml, tu envoie la page telle-quelle, en xhtml 1.1. Si tu le valide à partir de l'adresse, c'est le robot du W3C qui se charge d'aller chercher la page comme un grand. Il se trouve qu'il n'indique pas accepter le XHTML (comme les navigateurs KHTML, il faut donc faire attention), donc il reçoit une page xhtml 1.0. Ai-je été clair... c'est peut-être pas ça mais c'est la seule explication que je vois

Mais c'est parce que ce calcul dépend du mode de rendu utilisé. "Quirk" dans IE et "Standard" dans Mozilla probablement. Mais Mozilla peut rendre la page comme IE dans certains cas, et réciproquement. Regarde ce Tableau récapitulatif, et trouve un doctype qui soit interprété de la même manière par tous les navigateurs

Pour ma part je fais la distinction. Je préfère éviter d'utiliser le text/html si ce n'est pas obligatoire (=si le navigateur supporte le xhtml). Le fait d'être en application/xml+xhtml force à bien former le code (sinon : page jaune ) ce qui en soi est un avantage, moins besoin de valider tout le temps le code ! En plus je suis persuadé que le mode xml est plus efficace, que Mozilla le traite plus vite et mieux en parsant le xml que le sgml (tout buggué en plus). Voir par exemple cette discussion. Bref, je fais une discrimination des navigateurs (même si c'est contraire aux standards ), petite combine en php : if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml")) $xhtml=true; Ainsi, je sais si le navigateur accepte ou non le xhtml. Problème rencontré : les navigateurs de type KHTML n'indiquent pas accepter le XHTML dans leur HTTP-ACCEPT (ils ont simplement */*) Ligne supplémentaire : elseif (eregi ("KHTML",$HTTP_USER_AGENT;)) $xhtml=true; (et bien sûr else $xhtml=false;. Je pars de l'idée qu'il ne reste pas de navigateur KHTML trop vieux pour ne pas le supporter. Ce n'est pas comme IE, ce genre de navigateurs sont mis à jour régulièrement De toutes façons je ne sais pas depuis quand c'est supporté. Plus loin j'ai if ($xhtml) { header("Content-Type: application/xhtml+xml; charset=utf-8"); echo ("<?xml version=\"1.0\"?>\n"); } else { header("Content-type: text/html; charset=utf-8"); } echo ("<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">\n"); Remarque que je ne fais pas dans le xhtml 1.1, je trouve que ça sert à rien Bref, la même page est envoyée à tous les navigateurs sauf le prologue xml et l'entête. Ce n'est donc pas bien méchant. De temps en temps il me prend même l'envie d'envoyer ça en application/xhtml+xml, mais je pense à ceux qui ont des navigateurs comme Lynx, qui ne supporte pas le XHTML (ce qui est bien dommage car les standards sont tout benef pour ce genre de navigateurs), et qui n'ont pas d'autre recours. (S'il n'y avait que IE et NS4 qui ne le supportaient pas, je pense que j'aurais déjà mis en place le xhtml pour tous ) PS : j'ai entendu dire que Opera ne supportait plus le DOM en mode XHTML... je ne sais pas ce qu'il en est réellement (de toutes façons même en text/html il ne sait pas faire fonctionner le styleswitcher de mon site