Xavier

Ça ressemble pas un peu à du CP 437 ? http://www.miakinen.net/vrac/charsets/ Ou alors peut-être de l'utf-16 voire 32 ? Tu n'as pas moyen de savoir quelle est l'encodage d'entrée du script ?

Pour Firefox c'est un petit peu plus tordu car par défaut il cherche à se connecter en anonyme (et visiblement n'arrive pas à voir que ça coince). Donc tu peux forcer à demander le mot de passe en faisant ftp://login_AT_www.example.com/repertoire/ (sans le :mdp) Là il va demander le mot de passe. Donc ton répertoire reste protégé

Il y a surtout un bon nombre de personnes qui ne peuvent pas avoir de plugin flash (handicapés, ou alors simplement des personnes ayant un système pas ou plus supporté par Macromedia, et il y en a !) Une petite lecture pour incorporer du flash à une page web : http://www.ac-graphic.net/Article-3-flash-...-standards.php5 Comme tu envoies le même code pour tous les navigateurs, tu t'évites d'emblée un certains nombre de problèmes. Et comme ça tu peux facilement inclure du contenu alternatif entre <object> et </object>

<{POST_SNAPBACK}> Pas exactement, ce n'est pas aussi simple. Webalizer est vraiment mal fichu pour ce genre de taches. Il a la sale habitude de tronquer les fin des agents utilisateur. Et dans les versions qui donnent un résumé, c'est plutôt lacunaire. Ces chaines peuvent être plus ou moins n'importe quel navigateur Gecko sous Windows. Pour ma part le compteur de Webalizer indique 91.50% de Mozilla/5.0 pour octobre, stable dans le temps IE ne représente que 5% environ. (regardez ma signature pour comprendre pourquoi ) De là à estimer les parts de Firefox, il n'y a qu'un pas que je ne franchirai pas.

Effectivement, le float fait que le contenu s'écoule autour, donc la largeur est effectivement plus petite. Si le float a une largeur fixe, tu peux mettre un padding sur ton deuxième h1. Ça marchera dans l'exemple présenté. Mais peut-être pas toujours.

En l'occurence ça ne le résoudra pas. Parce que Firefox et Thunderbird gèrent eux-même le choix du programme utilisé pour ouvrir le fichier (ne me demandez surtout pas pourquoi, c'est comme ça ! - sécurité ?) Donc même s'il y a une association au niveau du système, il faudra la refaire.

Installe plutôt XnView ou IrfanView qui sont d'excellentes visualiseuses d'images supportant un nombre impressionnant de formats

Alors tu as mal comparé, parce qu'il y a une différence J'ai dit que les doctypes étaient sensibles à la casse, et tu as un "w" minuscule ! Peut-être qu'il s'arrête à la première ! Je n'en sait rien... En tous cas ce qui est sûr c'est que ton doctype n'est pas le doctype XHTML 1.0 Strict du W3C. Donc comme le validateur voit "text/html" et "XHTML" il est un peu perdu et utilise le text/html en pensant que c'est un doctype personnalisé. Et là il trouve des erreurs Corrige ton doctype

C'est quoi ce doctype ??? Pour info, les doctypes sont sensibles à la casse (Majuscules/minuscules). La liste est là : http://www.w3.org/QA/2002/04/valid-dtd-list.html C'est vrai que les messages du validateur ne sont pas toujours limpides. Ici, il faut comprendre : le doctype n'étant pas connu de ses services (du validateur), et comme il voit text/html --> il parse en SGML (HTML) où les " />" n'existent pas ! Une raison de plus pour ne pas faire de faux xhtml PS : dans les attributs height et width, pas d'unités !!! Enlève ces "px"

En l'occurence il me semble plus adapté d'utiliser un span et de lui appliquer font-weight:bold. Parce que je ne vois pas en quoi "Logo 88x31" est si ultra-important que ça (Il faut bien se rendre compte que <strong> c'est pas pour mettre en gras, c'est pour faire une emphase forte... un peu comme s'il fallait crier sur ce texte.) Pour Light_at_the_end : utilise un bloc <pre> que tu pourra styler comme tu le souhaites grâce aux CSS

Les tableaux c'est pas fait pour la mise en page. Passe aux CSS http://cybercodeur.net/weblog/presentation...bold/index.html

Si si, on peut tout à fait utiliser center en XHTML 1.0 Ce qu'on a pas le droit c'est de l'utiliser dans les variantes strictes de HTML 4x et XHTML 1.0. Mais en transitionnal on peut parfaitement. De même on ne peut plus utiliser center en XHTML 1.1 qui est une extension de XHTML 1.0 Strict. C'est un peu le bordel... ce qu'on peut dire c'est que : Les éléments et attributs de mise en forme sont, comme l'a dit Monique, déconseillés. Ces attributs et éléments déconseillés ne peuvent être utilisés qu'en HTML 4.01 Transitionnal et en XHTML 1.0 Transitionnal. Ils sont en revanche interdits dans toutes les variantes Strict et dérivées de Strict dans lesquelles il faut utiliser les CSS pour obtenir le même résultat, mais de manière plus propre. Pour remplacer center, alsacréations propose un excellent tutorial : Centrer les éléments ou un site web en CSS

Ou plutôt : style="filter :alpha(opacity=0); opacity:0;" (il n'y a pas que Mozilla dans la vie ) Je ne sais pas si c'est géré par KHTML ou s'il faut rajouter -khtml-opacity. Pour Opera il me semble que ce n'est pas géré... mais pourquoi ne pas mettre un visibility : hidden qui fonctionne partout ?

Filter c'est IE-only, donc pas étonnant que ça ne soit pas caché dans les autres navigateurs... Il faut utiliser la propriété CSS3 "opacity" (ou -moz-opacity ou -khtml-opacity...).

Il me semble que c'est bel et bien ça que je critiquais À choisir entre empêcher l'accès purement et simplement à 10% des internautes et priver autres d'une interface plus rapide, mon choix est vite fait : il est urgent d'avoir une version alternative

Ah bon ? Pourquoi ? L'accessibilité c'est pour tous et tout le temps, pas juste quand on a envie... Il n'y a aucune raison d'empêcher qui que ce soit d'accéder à un catalogue sous prétexte que "c'est une application"... Là n'est pas la question. Faire du DHTML sans javascript ne l'était pas non plus. Ce qui n'empêche pas que le site doit rester accessible dans toutes les configurations. Cela peut passer par mettre en place une version alternative la plus transparente possible pour ceux qui n'ont pas JS (donc rechargement complet des pages). Ajax n'est pas une excuse pour piétiner l'accessibilité. Je le répète, l'accessibilité c'est pour tous, tout le temps. Au passage je rappelle le lien Ajax Mistakes, les erreurs à ne pas faire avec Ajax. En particulier le bouton retour cassé me rebute toujours autant sur les sites en ajax...

Par contre ça ne fonctionne pas sans javascript... merci l'accessibilité

En fait, IE ne connait pas la propriété min-height. Donc il l'ignore.Deuxièmement, IE interprète la propriété height comme un min-height. La ruse consiste à mettre "_" devant une propriété pour qu'elle ne soit interprétée que par IE. C'est parfaitement invalide, il n'existe pas de propriété "_height", c'est le troisième bug d'IE dans ce cas... qui fait comme si le "_" n'existait pas. Ça fait beaucoup, mais ça permets de s'en tirer. Tous les autres navigateurs n'interprèteront que le min-height. IE interptétera le _height comme un min-height. Au final ça marche !

Avec l'entité ­ si je ne me trompe pas

C'est quoi un flux XML pour toi ?

Oui, il existe une excellente solution

. Je ne connaissais pas ce document. Il rejoins bien ce que je dis (enfin... il m'arrive de passer outre les "problems caused by serving XHTML as application/xhtml+xml" . Et puis sur le "users shouldn't be bothered with useless information about the site's mechanics onto the main content pages" je ne suis pas d'accord du tout. ) OOooh ! Je n'avais pas vu qu'il y avait une traduction française Elle est toute neuve. J'aime bien cet article parce que je suis effectivement passé par les points 1 à 5, donc je m'y reconnais assez bien (pas dans le point 6, et je ne l'ai pas évité comme le pense l'auteur parce que j'étais un "utilisateur avancé", plutôt parce que je n'ai simplement pas fait le lien entre XHTMl et les problèmes rencontrés - en l'occurence c'était les marges sur le <html> ) Merci pour tous ces liens !

Par "Flux XML" tu veux dire "Flux RSS" ? Dans ce cas regarde du côté de MagpieRSS

Ben... dans ce cas je ne vois pas trop d'argument pour ne pas faire de HTML 4.01... j'ai peut-être raté quelque chose mais vu que le XHTML 1.0 (en text/html) n'apporte rien de plus que le HTML 4.01, je peine vraiment à comprendre pourquoi on ne ferait pas tout simplement du HTML, renseigné comme tel... Pourquoi vouloir essayer de mentir aux navigateurs ? Vu que de toutes façons si on envoie en text/html le XHTML n'a aucun avantage ? C'est surement une question de goût, pour ma part soit je fais du text/html et j'assume jusqu'au bout en faisant du HTML 4.01, soit alors du application/xhtml+xml obligatoire et là je peux vraiment faire ce que je veux (entités personnalisées, svg, mathml et cie), mais pas question d'envoyer ça en text/html à qui que ce soit. Mais un XHTML 1.0 bridé par le text/html vraiment je trouve ça démoralisant

Ben oui, une évolution du HTML, rien ne l'empêche de partir dans une autre direction (en particulier le HTML 5). Il n'a pas dit ça ! Il a dit Strict dans le sens «guillemets obligatoires», «";" à la fin des entités» etc. Disons que ça "oblige" à une certaine discipline, car c'est tout à fait valable en HTML aussi, et que si ce n'est pas déclaré en XML alors on peut tout aussi bien se laisser aller... Pour autant qu'il respecte les 13 Règles de compatibilités du HTML. Ce qui est loin, très loin d'être le cas de toutes les pages XHTML servies en text/html. Malheureusement. Parce qu'un xml:lang sur une page text/html, s'il n'y a pas le lang qui va avec... le validateur ne dit rien (d'ailleurs il ne dit rien s'il n'y a pas le lang du tout), mais c'est totalement inutile. Oui mais dans ce cas il le comprend comme du HTML, donc plutôt qu'il "comprend" c'est "il arrive à s'en sortir plus ou moins correctement" Le post d'origine parlait en fait de XML, puis ça a dérivé sur le XHTML. Pour moi du XHTML servi en tant que text/html ce n'est pas vraiment du XHTML, ça n'en a pas les avantages en terme d'évolutivité (SVG, MathML etc.) ou de syntaxe XML (arrêt sur erreurs, commentaires XML, sections CDATA etc.) pour ne citer que ça, et si c'est pour qu'au final le navigateur commence par corriger ce code bourré d'erreurs, bof bof ! Je préfère conseiller de prendre du temps pour séparer le contenu et la mise en page (CSS), c'est bien plus utile, du temps mieux investi à mon avis, et aussi et surtout pour travailler l'accessibilité de son site