Xavier

  document.getElementById("ejs_logo").style.top=(w2+ejs_scy-staticlogo.height-20);

  document.getElementById("ejs_logo2").style.top=(w2+ejs_scy-staticlogo.height-15);

<{POST_SNAPBACK}>

Peut-être parce que tu as oublié les unités ? On ne t'a pas assez rappelé que les unités étaient importantes aux cours de physique ?

Si document.write fonctionne alors c'est que tu n'es pas "vraiment" en XHTML, plutôt dans un mode "compatible HTML" (= tu envoies ta page en text/html plutôt qu'en application/xhtml+xml)

PS : tu peux carrément supprimer le -moz-opacity, je ne sais même pas si Mozilla le supporte encore celui-ci (si c'est le cas ça ne va pas durer).

Pour la deuxième erreur je pencherais plutôt pour l'apostrophe de "lAllier" qui n'est pas une apostrophe autorisée dans le charset (lequel au fait ?).

Deux solutions possibles :

1. L'utf-8
   
2. L'entité correspondante ' si je ne me trompe pas.
   

Document.write est l'exemple parfait de technologie dépassée, utilisée uniquement pour le HTML et totalement inconnue de tout bon parseur XML. Pour le XML/XHTML il faut manipuler directement l'arbre DOM avec les fonctions qui vont avec comme createElement, createTextNode ou appendChild pour ne citer que celles-ci (un petit tutoriel à ce sujet).

Tout dépend si elles sont là parce qu'elles ont un sens et que les mots sont accentués (il faut imaginer qu'un lecteur vocal CRIE ! sur <strong>) ou juste pour faire joli, mettre en gras mais un texte qui n'a pas forcément plus d'importance que le reste...

Si le sens est là, alors il faut mettre <strong> (forte emphase) ou <em> (emphase). Si c'est juste pour faire joli (comme sur ce forum, tous les "Connecté en tant que", " Webmaster Hub > Création et exploitation de Sites Internet > Les langages du Net > (X)HTML & CSS" etc. sont en gras mais pas pour signaler une forte emphase), alors mieux vaut les enlever et les remplacer par du CSS (prévu pour la mise en forme)

Oui mais c'est quand il est en configuration IE-like, non ?

Euh...

Je ne sais pas. Ça se change ? Quand il est en mode quirk sans doute, pour le reste je ne sais pas, je n'ai jamais poussé les investigations à fond non plus

Je ne doute pas que la page où il y avait un de ces "window.navigate" était affichée en quirk !

Ce que je sais en tous cas, c'est que le code KHTML a été vachement modifié par Dave Hyatt et que Konqueror n'a pas exactement le même rendu que Safari bien que finalement très proches.

Avec Safari 1.3 a commencé une réelle transformation en profondeur, encore plus accentuée avec Safari 2.0

C'est bien ce que je pensais (sans avoir jamais réellement pu tester l'un ou l'autre !)

Et une est chose sûre: Safari n'a jamais accepté les scrollbar-color..

Le contraire m'aurait fortement étonné, s'il y a bien un environnement dans lequel ce n'est pas adaptable, c'est Mac

(en revanche toute la norme CSS 3 est désormais intégrée, même les multiples background et c'est un vrai régal)

Tout ? Tout tout tout ?

http://www.w3.org/Style/CSS/current-work

Même ce qui est en working draft ?

Tu ne veux pas plutôt parler de CSS2 plutôt ? (Vu que le test Acid2 vient d'être passé par une version non encore publiée de Safari ?)

Ce que je trouve intéressant en revanche, c'est de noter de quelle manière Firefox peut se permettre d'adapter le code HTML, en dehors de toute considération DOM. C'est le seul à ma connaissance qui puisse accepter de lire une page qui normalement ne passerai que sous IE en mode quirks; et de la lire de manière identique.

En même temps il y a toujours un nombre affolant de pages qui ne passent pas sous Firefox tellement elles sont mal conçues. Donc... on est encore bien loin d'un deuxième IE

N'ayant jamais testé Safari je suis bien mal placé pour faire des comparaisons, mais en même temps je doute que David Hyatt n'ait pas aussi comme but (non, pas comme but... plutôt comme obligation) d'adapter les modes quirks de Safari pour que ça passe...

[edit] selon le site de l'Apple Developer Connection, document.all n'est pas supporté par Safari [/edit]

<{POST_SNAPBACK}>

Tant mieux alors ! Je disais ça parce que j'ai pu m'entretenir avec une personne sous Linux étant obligée de passer par Konqueror pour accéder à une page windows-only pleine de document.all. En même temps, il faut bien que chaque plate-forme ait un navigateur capable d'accéder à ce genre de sites, sinon c'est vite "coinçant"

Bon plus sérieusement, il y a certainement Amaya [smiley censuré pour cause de dépassement du quotat]

Je suppose qu'il a par définition ce comportement puisque développé par le W3.

On voit ce que çà donne en terme de statistiques par contre [smiley censuré pour cause de dépassement du quotat] => jamais vu un seul Amaya dans mes stats.

Je serais curieux de le tester en tous cas. Il a forcément un mode quirks, mais avec quel comportement ?

Il passe sans sourciller sur les pages pleines d'erreurs...

- et quoi encore ?

ps : tester un site sur un navigateur qui représente 0,05 % des visiteurs ne sert pas à grand chose en soit  [smiley censuré pour cause de dépassement du quotat]

<{POST_SNAPBACK}>

N'oublie pas Opera !

Je te conseillerais en plus de jeter un coup d'oeil sous Lynx. Comme c'est un navigateur en mode texte, il te permets de saisir la structure de ton document, beaucoup mieux qu'un navigateur graphique (surtout si tu as mis beaucoup de CSS).

En lui-même il ne représente que 0.000001% (j'en sais rien, mais très peu), mais c'est utile, parce que certains moyens de "voir" les pages n'apparaissent pas dans les stats : les lecteurs d'écran. Eux ont besoin de cette structure, et je suis à peu près persuadé qu'ils représentent plus de 0.05% Avec Lynx, tu obtiens déjà une bonne idée (le texte alternatif mal choisi voir ennuyeux, la structure pas logique, etc.).

Je pense que c'était plutôt

table
{
border-collapse: collapse;
}

Si ce n'est pas ça, as-tu un exemple concret qu'on puisse regarder ?

Xavier (l'autre Xavier) risque de me tomber dessus mais Firefox gère très bien certains codes désastreux (les tiens n'en sont quand même pas à ce point-là). Un peu trop bien à mon goût.

Comme tous les navigateurs d'ailleurs (à part Amaya bien sûr ) Je ne crois pas qu'on puisse dire que tel ou tel navigateur soit moins strict (à part IE bien entendu), chacun a ses "quirks", évidemment différent des autres.

Tu parles d'Opera, or celui-ci supporte parfaitement les document.all. Je l'ai également pris en flagrant délit de réussir à suivre les liens java script:window.navigate (du propriétaire MS à 100%, absolument équivalent à location.href dont je n'avais jamais entendu parler, et dont je ne trouve toujours pas l'utilité par rapport à location.href ).

Je ne connais pas Safari (n'ayant pas de Mac) mais Konqueror est connu pour supporter parfaitement les scrollbar-color-* et document.all, je ne vois pas pourquoi il en serait autrement pour Safari qui est basé dessus (du moins pour les document.all)

Firefox est encore celui qui laisse le moins passer les document.all puisqu'ils les oublie en cas de test. Sur d'autres points il est certainement plus souple. Sur d'autres moins. Faire des comparaisons de ce type me semble plutôt vain et inutile

Je suis sur qu'on pourrait continuer des heures à chercher tout ce qui ne va pas dans tel ou tel navigateur moderne, et je suis tout aussi certain qu'on n'arriverait pas à déterminer lequel est le plus strict. Comme tu le dis, si on veut que son navigateur soit adopté, il faut qu'il réussisse à afficher les pages correctement. C'est pour ça qu'il existe des modes "quirks" ("bizarres", "étranges") dans lequel le navigateur adopte des comportements totalement inattendus et imprévisibles dans un seul but de rétrocompatibilité. Il le détermine en particulier grâce au doctype utilisé (ou à son absence).

Développer en mode quirk (sans doctype) c'est aussi ne pas être en mesure de prévoir les réactions du navigateur... un peu suicidaire non ?

(parenthèse: çà fait un bout de temps qu'on sait qu'un navigateur indulgent est mauvais pour le web. cf cet article d'alistapart, traduit par pompage. Fin de la parenthèse.)

D'ailleurs, si quelqu'un me trouve un navigateur qui supporte tous les standards et rien que les standards, je l'adopte (non Dudu, Safari aussi a ses quirks )

Pour conclure je crois qu'en attenant le navigateur parfait, ce qui est le plus important, c'est encore de connaitre tous ces petits écarts qu'autorise son navigateur, et de ne pas se laisser prendre au piège

C'est aussi de connaître ses cibles, et être capable d'anticiper les bugs d'IE (en particulier les CSS interprétés tout de travers, les height/width non respectés, etc.)

je me suis à moitié convertit : je viens d'installer Firefox, j'ai jetté un oeil sur mes sites qui sont totallement Invalide et ça passe pareil (sauf bien sur la barre de défilement de couleur)

conclusion : pas besoin d'une pseudo validation par un robot pour que ça s'affiche partout 

<{POST_SNAPBACK}>

Hum... ce serait un peu réducteur de traiter IE et Firefox de "partout"

Tu as testé Konqueror, Opera, Safari, Lynx ? Et même si tu l'as fait tu es loin d'avoir tout testé !

Si tu ne respectes pas les standards, et que tu laisse des erreurs dans ton code, tu as l'assurance que quelque part ça ne passera pas d'une manière ou d'une autre (remarque que même en respectant scrupuleusement toutes les recommandations du W3C tu n'es pas à l'abri... le risque est simplement incroyablement plus bas ! )

Quelqu'un d'ignorant en HTML tabloïde sera aussi ignorant en (X)HTML parfait-de-chez-parfait.

<{POST_SNAPBACK}>

Mais une personne qui se dit "tiens, si j'essayais" et qui se retrouve devant une magnifique page XHTML 1.0 Strict bien indenté ne pourra que se dire "ça a pas l'air compliqué" (du moins en comparaison avec une de ces bonnes vieilles pages au code (volontairement ?) illisible ).

Je suis assez d'accord avec Hadrien... quel avantage d'avoir une frame pour rediriger un truc comme ça ? De toutes façons

• Les moteurs de recherches ammèneront sur hpap.free.fr
  
• Le visiteur verra bien que les liens pointent tous vers hpap.free.fr (dans la barre d'état ou les infobulles).
  

Bref... je peine à saisir le vrai but de cette manipulation...

Pour ma part, non seulement ça ne me gène pas de voir un "free.fr" plutôt qu'un "biz", mais en plus j'aime bien connaitre le vrai domaine du site que je visite (quitte à faire un clic droit > Ce cadre > Afficher seulement ce cadre )

La "standardisation" n'a rien à voir avec le fait qu'un site soit beau ou non, c'est juste pour qu'il s'affiche partout pareil.

Bon le problème qu'il y a pour l'instant d'après ce que je commence à lire, c'est qu'Internet Explorer ne respecte pas ce standard !

Comment vouloir faire un standard, sachant que ce standard n'est pas compatible avec le navigateur le plus utilisé au monde ?

Là tu vois les choses à l'envers : c'est le navigateur qui n'est pas compatible avec le standard, et pas l'inverse

Linux c'est sans doutes bien, mais pour l'instant Microsoft à quand même un sacré monopole non ?

Oui, et surtout si de nombreux sites sont codés justement pour ne fonctionner qu'avec MSIE... c'est bien le but d'un monopole non ? Forcer les gens à forcer les autres à ne pas faire autrement

Tu parles du site qui est dans la signature en-dessous de ton message ? Il me semble que ça fonctionne correctement, mais je n'ai pas trouvé de pages dans des sous-répertoires...

Chez moi, rien ne s'ouvre du tout...

Je te renvoie vers une excellent article d'Openweb sur les popups : http://openweb.eu.org/articles/popup/

Il y a également des firewalls/antivirus/autres qui bloquent les programmes qui ont été modifiés, ce qui est exactement le cas de Firefox en cas de mise à jour. Il se peut que pour une raison ou une autre il ait oublié de te demander de valider le changement...

C'est juste Microsoft qui a inventé çà pour faire joli, mais AMHA l'intérêt cosmétique est assez limité

<{POST_SNAPBACK}>

Joli ?

C'est conçu uniquement pour des interfaces dans le style Windows-95-KGB oui ! Ça ne s'accorde avec absolument rien d'autres (et c'est pour ça que le W3C n'en veut pas).

Quiconque a un thème windows avec de jolies scrollbars sait de quoi je parle, les sites qui définissent les scrollbar-color transforment vos magnifiques barres de défilement si finement détaillées, agréable à la vue, avec des contours arrondis et adoucis et des couleurs pastels reposantes (comme celles que l'on trouve là par exemple) en des machins carrés et qui plus est souvent de couleur assez peu agréable

Franchement, le choix est vite fait

Bon, je vois qu'OpenWeb n'a pas été cité, alors je répare l'oubli en mettant un petit lien vers l'article Toi comprendre moi ? qui explique parfaitement les enjeux ! Il y en a quelques autres dans la même veine : Pourquoi les standards du W3C ? et La fin de la balkanisation du Web. Pour ma part, ce sont ces articles qui m'ont convaincu que les standards étaient nécessaires et utiles

Mouarf, en plus avec une micro capture comme celle-ci

Quelques pistes :

• C'est de l'XHTML, IE ne supporte pas le XHTML (m'enfin je pense que si tu le vois c'est que tu le "vends" comme du HTML en text/html...)
  
• Il y a des height et des width, or IE les supporte très mal (comme des min-width et min-height en fait)
  
• Quand tu as

  border-style:solid;
  border-width:1px;
  border-color:black;

  tu peux résumer en

  border: 1px solid black

  mais ça n'a rien à voir avec IE, c'est juste pour simplifier
  

• Tu as défini plein de padding, IE a quelques bugs à ce sujet (il ne tient compte que de l'externe je crois... bref il a un bug là dessus
  

T'en dire plus relèverait du mirâcle, et comme on n'est pas Dieu...

Salut Xavier,

Oui mais tu connais mes réticences face à tout ce qui est fermé (j'allais dire "proprio" mais il y a une nuance)

Dit par un utilisateur de Mac

Cela dit, je ne suis pas sûr que cet encodage soit vraiment "fermé", il est surement défini en détail quelque part (p.ex Wikipedia possède un article dessus...)

Ce qui m'a fait douter avant de tester, c'est

* que certaines pages HTML produites par Excel sont absolument illisibles. Celle-ci, par exemple est complètement explosée sous Firefox Mac (et PC aussi p-ê).

Pour rester hors sujet ( ), pas étonnant, le script continue après sa balise fermante...

}
 fnGetIEVer();
 fnBuildFrameset();
//-->
</script>
function fnInit()
{
 if

en regardant mes préférences d'encodage j'ai trouvé tout et n'importe quoi.. mais aucun windows-1252

=> Donc dans un 1er temps je préférais être prudent à l'idée de conseiller cet encodage pour le web.

Il est possible que Safari traite l'iso comme le windows-1252... parce que le windows-1252 est souvent fait passer pour de l'iso

Vive l'unicode !

Le hic, c'est que je ne sais pas si en encodant directement ta page web en windows-1252, les internautes qui n'ont pas Windows (j'en fais partie) pourront lire la page Çà peut valoir le coup d'essayer: je suis partant pour un béta-test

<{POST_SNAPBACK}>

Vu le nombre de fichiers/pages web encodés en windows-1252... je crois que ça se saurait

(il doit bien y avoir la moitié des sites qui utilisent cet encodage... même si beaucoup le déclarent comme du iso-8859-1 !)

PS : Sur PC on peut très bien lire les encodages du type MacRoman et cie

Mais s'il faut charger aussi le code, ça peut souvent être beaucoup, beaucoup, (beaucoup, beaucoup, beaucoup, [...]) plus

1. Valider (la CSS aussi !), pas étonnant qu'un code bourré d'erreurs comme ça ne s'affiche pas correctement
   
2. Mettre tous tes <li> dans un <ul> ou un <ol> - ou alors ne pas en mettre du tout
   
3. Leur appliquer display:inline pour qu'ils s'affichent en ligne.
   

Là, c'est typiquement une interprétation différente d'une erreur selon les navigateurs, IE semblant ignorer le <li> et Mozilla essayer d'afficher malgré tout ce li orphelin comme un bloc (Opera est un intermédiaire, le pied est sur 2 lignes mais agrandi comme dans IE ) bref, pas étonnant qu'avec toutes ces erreurs il y ait des problèmes un peu partout.

Faire des erreurs de code, c'est avoir la certitude que quelque chose ne va pas fonctionner correctement quelque part - tu en as la démonstration.

Validez, validez, validez, et travaillez avec des outils stricts, on ne le répètera jamais assez.

Ah, au passage tu peux supprimer 11 des 12 appels à la feuille "style.css", un seul suffit

Et aussi, visiblement la hauteur de #footer est toujours à 10px, tu devrais mettre en ligne la correction

Le problème vient (comme d'habitude) d'IE . Tu as fixé la hauteur de #footer à 10px. Clairement, dans IE, ça fait plus de 10px, alors que Firefox l'affiche bien avec une hauteur de 10px (j'ai pas pris une règle pour vérifier, mais ça me semble assez clair, il est plus grand que ton image "RSS" qui fait déjà 14px !).

Il faut savoir que IE (même si on voit parfois un "OK" dans les tables de support, ce qui est complètement faux) interprète très mal les hauteurs/largeurs et prend beaucoup de libertés. En fait, il les interprète comme des min-height.

Conseil : développe dans un navigateur respectueux des standards (Firefox, Opera, Safari), puis ensuite seulement adapte pour que ça passe dans IE. Tu évitera ce genre de petits ennuis

PS : mets 1em; comme hauteur, ça devrait aller mieux, et en plus ça s'adaptera si les gens choisissent d'agrandir le texte

Lynx n'est pas forcément le navigateur le plus rapide... au contraire, je le trouve assez lent... mais si tu payes au Ko et pas au temps il est pas mal en effet.

Il y a eu une discussion sur le hub dernièrement : http://www.webmaster-hub.com/index.php?showtopic=2920

Le lien de Clair de Lune donne accès à un installeur, avec un Lynx tout bien configuré, et celui de yobiwan mène à un tutoriel qui pourrait t'être je crois très utile

Pour Firefox, il existe l'extension LiveHTTP Headers de laquelle j'ai extrait ce que j'ai dit plus haut.

Tu pourrait nous donner un exemple, avec la requête que tu envoie, l'hôte et la réponse (erreur) ?

Ce qui devient alors intéressant c'est de savoir s'il existe désormais, réellement une différence notamment au niveau sécurité entre Firefox et Netscape 8.02  ?

Mon avis est que Netscape 8.02 est Firefox mais avec un habillage différent .

   

<{POST_SNAPBACK}>

Mais un Firefox moins à jour... (du moins toujours en retard)

- IE7 respecte mieux les standards, donc logiquement si les sites les respects il ne devrai pas y avoir de problèmes.

<{POST_SNAPBACK}>

"Mieux" n'est pas "bien" Quand on part de si bas, ça reste toujours mauvais

Il n'y aurait effectivement pas de problèmes si les sites respectaient vraiment les standards. Mais comme le web n'est que hacks, erreurs et cie, nul doute que ça va tout casser.

Sinon il y a aussi Pascal Chevrel qui en parle un peu...

Elle n'est pas valide. Embed n'existe pas. C'est le risque d'insérer le flash n'importe comment

http://www.alistapart.com/articles/flashsatay devrait contenir la solution