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é

Je sais qu'il reste un bon nombre de réfractaires à flash... Je pense  faire une version html pour ceux la ...

<{POST_SNAPBACK}>

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>

Bonjour,

Ceux-là 

Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7.12) Ge

Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.10) Ge

Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.12) Ge

<{POST_SNAPBACK}>

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

Salut Xavier,

Je suis allée voir les doctypes, j'ai comparé et je n'ai pas vu de différence de casse avec le mien.

J'ai dit que les doctypes étaient sensibles à la casse, et tu as un "w" minuscule !

Mais je ne comprends toujours pas : si le doctype n'était pas reconnu et que le validateur n'acceptait pas les " />", ce n'est pas une seule erreur que j'aurais, mais plein, vu que toute ma page est en xhtml.

<{POST_SNAPBACK}>

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"

Lu.

je crois qu'un texarea n'est pas autorisé en dehors d'un < form> et pour la balise <b> il est  preferable d'utiliser <strong>

<{POST_SNAPBACK}>

(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

Certains éléments et attributs sont déconseillés (deprecated) en HTML 4.01, (ils risquent de devenir obsolètes donc sans aucune garantie de gestion de la part de l'agent utilisateur), ils ne font plus partie de XHTML 1.0. C'est le cas de l'élément CENTER.

<{POST_SNAPBACK}>

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 :

1. Les éléments et attributs de mise en forme sont, comme l'a dit Monique, déconseillés.
   
2. 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.
   
3. 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

style="filter :alpha(opacity=0); -moz-opacity:0;"

<{POST_SNAPBACK}>

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 ?

style="filter :alpha(opacity=0)"

<{POST_SNAPBACK}>

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...).

L'obligation d'avoir un navigateur interprétant le JavaScript pour pouvoir accéder au catalogue est par contre contestable (pas de version alternative).

<{POST_SNAPBACK}>

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

C'est une application, donc il faut relativiser le niveau d'accessibilité.

<{POST_SNAPBACK}>

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"...

Vos remarques sur l'accessibilité sont pertinentes.

Maintenant faire de l'aJAx sans JAvascript, ça ne me paraît pas évident !

<{POST_SNAPBACK}>

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é

Merci ca a tout à fait fonctionné.

Mais pourquoi faut il utiliser cette ruse, as tu une explication ?

Y'a t'il un site qui répertorie ces petits hacks ?

Encore une fois merci,

Bonsoi.

Bridou

<{POST_SNAPBACK}>

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

.

Ce problème est évoqué ici : No to XHTML - Spartanicus' Web tips

Servir du XHTML en tant que text/html jugé néfaste

<{POST_SNAPBACK}>

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

Bonsoir,

mouais... tant qu'on ne m'interdit pas d'utiliser quelque chose qui permet une meilleure compatibilité entre les navigateurs sans envoyer un contenu différent en fonction du navigateur je ne me gêne pas pour utilisé cette possibilité... Pour la bonne et simple raison qu'en l'occurence, le type text/html est supporté par TOUS les navigateurs que je connais...

<{POST_SNAPBACK}>

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

1) Le Xhtml, par définition (et ça c'est pas moi qui le dit, c'est le w3c) est une extension et une évolution du html.

Ben oui, une évolution du HTML, rien ne l'empêche de partir dans une autre direction (en particulier le HTML 5).

2) Le Xhtml, comme le xml, étant un langage de description de structure de document, j'ai du mal à comprendre la différence que tu fais entre "faire du xhtml" et "utiliser une syntaxe xhtml". NB : Je suis parfaitement conscient qu'il y a l'esprit visant à séparer le contenu de sa présentation, pas la peine d'aller sur ce terrain.

Il n'a pas dit ça ! Il a dit

Puis çà apprend à être strict dans sa syntaxe ce n'est pas plus mal.

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...

3) Depuis quand les équipes de développement d'IE sont-elles considérées comme ne disant pas de bêtises ? Troll mis à part, je pense qu'il est question là (bien que je ne dispose pas du contexte), de xhtml servi en tant que application/xhtml+xml, ce qui est certes souhaitable (si on s'en réfère au sacro-saint tableau à ce sujet sur le site du w3c), mais pas obligatoire : du contenu xhtml peut être servi en tant que text/html, c'est marqué en toutes lettres : MAY. Et il ya aussi SHOULD dans la case application/xml+xhtml, je l'ai lu aussi  .

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.

4) "Et IE comprend très bien xhtml" "Non c'est faux, archi-faux". OK, cette fois c'est mon tour (cf la suite) : j'aurais dû préciser "servi en tant que text/html".

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"

6) "IEWin fait une demande de téléchargement". Alors là c'est pas mon tour, puisque c'est toi même qui rajoute "page envoyée en application/xhtml+xml", précision qui n'était pas dans le post d'origine. Je le re-dis : servir un document xhtml en tant que text/html est possible, ce n'est pas l'idéal (SHOULD), mais c'est possible (MAY).

Bon et maintenant, pour l'entente cordiale :  

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