LaurentDenis

Utilise un hack pour spécifier la largeur incorrecte pour IE, par exemple:

a {
width: 170px;
}

html>body a {
width: 160px;
}

Ou:

a {
width: 160px  !important;
width: 170px;

Ou utilise la propriété box-sizing pour Opera et son équivalent pour Mozilla afin de leur faire utiliser le box-model Microsoft sur les <a>, dans lequel tu pourras utiliser uniquement width:170px; ou width: 100%;

a {
box-sizing: border-box;
-moz-box-sizing: border-box;
}

Ou encore le doctype switching pour faire passer tous les navigateurs en Mode Quirks qui forcera également le box model Microsoft...

Remplace le width:100% par width:160px; (les 170px du conteneur moins le padding).

Remets ton line-height:12px (comme la taille de police) et ajoute un

p,h1 {
margin-top: 0;
margin-bottom: 0;
padding-top: 0;
padding-bottom: 0;
}

pour annuler tous les espaces verticaux et la fusion des marges.

Au minimum en effet, il faut avertir l'utilisateur de cette mise en forme automatique.

Sinon, si la mise en forme des données est nécessaire, elle peut très bien se faire sans que le résultat soit affiché.

Bienvenue, Pandrekano, dans cette bande d'huluberlus... pas si hurluberlus que ça !

Vous êtes bien gentils tous les deux, c'est vrai quand même qu'on commence à pas mal bien se débrouiller de notre côté pour des colonisés.

Vous avez de quoi nous donner quelques leçons, pour tout dire

Tiens... On pourrait créer un "Web Standards Transocéanique", histoire de stimuler un peu ce côté-ci de l'océan...

même Laurent Denis, un Dieu entre tous les dieux, en aura pas fait autant !

ça, c'est ce que j'ai toujours admiré en particulier dans ton style d'écriture, Denis : la formule juste, concise, mesurée... Tout ça

Ok, je suis déjà dehors, très loin, très très loin -------> ...

Ca me fait penser à un autre bug que j'avais sur IE et que personne n'a jamais vu... 

Ca doit donc venir de la version  :!:

Pour ma part IE 5.5. (oui, je sais, c'est une vieille version, mais c'est celle de W98...donc il doit y avoir d'autres gens qui l'ont aussi.)

Sgnwh !

Préviens quand tu testes dans IE5.x ... Aucun des 3 IE Win n'a exactement le même comportement :!:

Chez moi, le bug n'apparaît pas dans IE6, mais dans IE5.0 et 5.5

Il faut à IE une largeur spécifiée au conteneur des float, pour ne pas prendre comme base de calcul la largeur de la zone d'affichage. Ici, ajoute une <div style="width: 100%"> dans ta div #centre pour englober tes deux flottants.

J'ai peur qu'en procédant ainsi, tu ne perdes un temps considérable pour un résultat finalement décevant : pour l'instant, ta page http://stephane.gigon.free.fr/index.php?rubrique=listepays (je suppose que c'est bien celle-là ?):

- mêle tableaux de présentation, balisage de présentation du type <center> et positionnement CSS, sans compter le javascript : il est extrêment difficile de s'y retrouver, et tout cela ne fait pas bon ménage ! Difficile d'identifier le bug dans ces conditions...

- part d'un code invalide, ce qui peut fausser le comportement des navigateurs.

Si je peux me permettre, je te conseillerais plutôt:

- de redéfinir le code "utile" de ta page, c'est à dire celui du contenu brut, sans aucun souci de rendu, de dynamisme, de présentation. A base de titres <h...>, de listes <ul> et de paragraphes <p>.

- de t"assurer si possible de la validité de ce code de base.

- et alors seulement de passer à la phase "CSS" : l'ajout de <div> pour définir tes "calques" te permettra de gérér le positionnement sans tableaux.

- les effets dynamiques... viendront après.

Une bonne source de départ pour t'aider à définir ce code utile et pour l'employer sans erreur : Ecrire une page Web

Une précision au cas où : sauf grssière erreur de ma part, IE n'utilise les favicons que dans les favoris. Pas dans la barre d'adresse.

La gestion du cache du navigateur joue elle aussi son rôle dans la prise en compte d'un favicon. Et ces mécanismes ne sont pas standardisés : chaque navigateur a son comportement propre.

Bref, prends déjà la précaution de vider le cache d'IE, avant de tester un favicon...

Les textes mis en image ont en effet ce défaut : il faut refaire l'image pour changer le texte

Cela dit, autre défaut : même avec son texte, ton bouton n'a plus aucun sens quand les images ne sont pas affichées (navigateur texte, lecteur d'écran...). Heureusement, c'est plus simple à rectifier: recopie le texte du bouton dans l'attribut alt de l'image. Exemple pour un bouton "Accueil" :

<a href="index.html"><img src="butt_3.gif" width="190" height="25" border="0" alt="Accueil"></a>

Utiliser un tableau pour des données "tabulaires" (double entrée par exemple)... c'est très bien ! Et utiliser un tableau de mise en page en cas de force majeur, ce n'est pas un drame.

cela dit, tu trouveras les bases du stylage CSS de tableaux dans Habillage de tableaux avec des CSS, sur openweb.

Effectivement :

<link rel=StyleSheet href=..." type="text/css" media=screen>

...sera exploité par les navigateurs de génération 4, qui ignoreront en revanche:

<style type="text/css" media="all"> _AT_import "...";</style>

Il est également possible de faire seulement un <link> pour tous les navigateurs, vers une feuille de style contenant:

- directement les styles (minimaux) pour les navigateurs de génération 4

- une règle _AT_import "..."; qui importe la seconde feuille de style pour les navigateurs récents.

Tes boîtes ayant la propriété "float", elles ne sont pas prises en compte dans le calcul de la hauteur de leur conteneur. D'autre par, elles autorisent le bloc qui les suit à se placer autant que possible "à côté" d'elle. C'est pourquoi ton footer, qui se place en dessous du conteneur, est "trop haut".

Il suffit de donner à ton #footer la propriété clear:both pour qu'il lui soit interdit de se placer ainsi. Ta CSS devient simplement:

#footer {
margin: 10px 40px 10px 250px;
color: #6699CC;
font-size: 70%;
font-family: Verdana, Arial, Helvetica, sans-serif;
clear: both;
}

Pour en savoir davantage sur les flottants et sur la propriété clear, voir Initiation au positionnement CSS : 2.position float

Pour être plus explicite:

Namo te permet de créer le contenu de ton site (les pages) sur ton ordinateur. Mais ton ordinateur ne te permet pas de publier ce site : seul toi-même peut le consulter. Pour l'instant, ton site est "local".

Pour que ce site soit visible, il doit être "hébergé" sur un "serveur" qui le rendra public. ce serveur est "distant" par rapport à ton ordinateur.

Il te faut donc choisir un hébergement, puis utiliser Namo pour "expédier" (télécharger) tes pages sur ce serveur.

L'article est remarquable, en effet. A lire, relire et épingler. Merci à Eric, qui devrait écrire plus souvent

Il me semble également que c'est le cas. Mais ici, il s'agit d'un problème différent : u n très grand nombre de pages théoriquement en ISO-8859-1 étant en fait en Windows-1252 (en raison d'un problème d'encodage des caractères dans les éditeurs HTML), beaucoup de navigateurs forcent l'encodage Windows-1252 afin de compenser cette erreur.

Le test est facile à faire localement, en visualisant dans son navigateur le code suivant:

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

<title>Test</title>

</head>

<body>

<p>Ici devrait s'afficher une obèle: &#134;</p>

</body>

Si l'obèle † s'affiche effectivement... C'est que le navigateur interprète la page en Windows-1252, où l'encodage & #134; correspond à ce caractère (en ISO-8859-1, & #134; est un code de contrôle et pas un caractère)

Parmi les navigateurs qui le font:

- Opera (qui le signale dans les infos de la page)

- FireFox

- Mozilla

- IE bien-sûr...

Tiens, à propos : il serait intéressant de savoir si les robots d'indexation "forcent" le charset Windows-1252, comme le font la plupart des navigateurs quand ils sont face à un document de charset inconnu ou de charset ISO-8859-1 ?

Par contre, je suis très étonné qu'on ne puisse pas mettre d'éléments inline directement enfants de body. Sans m'être renseigné, je croyais que body était de type block (donc pouvant contenir à la fois des blocks et des inlines)  mais en fait il est hors type. Et beh !

La distinction est un peu plus complexe : il y a trois types de contenus "génériques" dans les DTD HTML:

- %block

- %inline

- %flow qui mêle les deux précédents.

Plus les exceptions définies élément par élément sur ce qu'ils peuvent contenir.

Les déclarations META devraient apparaître le plus tôt possible dans l'élément HEAD.

La citation est tronquée, faute de quoi il faudrait citer un tiers du chapitre. Dans le contexte de la spec (voir le lien ci-dessus), c'est aussi explicite que possible... dans la mesure où la spec HTML4.01 est capable d'être explicite. Et il est vrai que nous traînons beaucoup de questions à cause de ses imprécisions, ou de ses difficultés de lecture

En fait, on ne peut pas s'empêcher d'y regarder d'un peu plus près :

<div id="toc">

  	<ul>
      <li><a href="#contenu" accesskey="k" title="Le contenu. Key : k">aller au contenu</a></li>
      <li><a href="#menu" accesskey="l" title="Navigation du site. Key : l">aller au menu</a></li>
      <li><a href="#recherche" accesskey="s" title="Rechercher dans le site. Key : s">rechercher</a></li>
      <li><a href="#pieddepage" accesskey="0" title="Informations sur le site. Key : 9">info legales</a></li>
    </ul>
  </div>

les acceskeys sous forme de lettres sont actuellement abandonnés au profit d'une liste limitée d'accesskeys numériques, en raison des problèmes d'accessibilité qu'ils créent au lieu d'en résoudre. Voir http://openweb.eu.org/articles/accesskey_e...non_transforme/

dans le fichier css :

#toc{

...

margin-left:700px;

position:absolute;

...

top:0;

...

}

Cette position absolue est-elle nécessaire ? Si ton menu d'accessibilité est, comme logiquement, en tête de contenu, elle est inutile et te complique la vie pour rien.

Le margin-left de 700px est un peu surprenant. Une marge de 700px, c'est presque la largeur d'un "petit" écran (800x600) ?

#toc a{

display: inline;

...

}

Les éléments <a> sont déjà des éléments en-ligne par nature. Cette propriété est inutile.

#toc a:hover{

display: inline;

}

re-belote. De toute façon, une propriété définie pour xxx s'applique par héritage à xxx:hover. Inutile de la répéter.

Aurais-tu l'url d'une page de test ?

Sans chercher plus avant, as-tu démarré ta feuille de style en annulant les marges et remplissage créé par défaut par les navigateurs, chacun à leur manière, y compris sur les éléments html et body ?

html, body {

margin: 0;

padding: 0;

}

ou

* {

margin: 0;

padding: 0;

}

Allez, on va enfoncer encore un peu le clou. C'est en fait une vieille recommandation... de la vénérable spécification HTML4.01 elle-même

La déclaration META doit seulement être utilisée lorsque l'encodage est organisé de telle sorte que les octets en valeurs ASCII représentent des caractères ASCII (au moins jusqu'à ce que l'élément META soit analysé). Les déclarations META devraient apparaître le plus tôt possible dans l'élément HEAD.

http://www.la-grange.net/w3c/html4.01/charset.html

Distinguons deux choses:

- la manière dont les robots d'indexation aiment ou n'aiment pas les caractères littéraux / en entités caractères / en entités numériques. Quelqu'un a un avis clair et compétent là-dessus ?

- le problème de spécifier le charset utilisé pour le contenu html. Celui-ci inclut le contenu de <head>. Donc le charset s'appliquera aux balises <meta>: dès lors que le charset est défini par en en-tête HTTP (qui l'emporte sur tous les autres moyens de le définir), il n'y a aucun problème si les caractères sont entrés littéralement par un éditeur qui respecte l'encodage en question. Autrement-dit, si vous pouvez gérer vos en-tête HTTP pour spécifier le charset de votre choix, et si votre éditeur HTML respecte l'encodage en question, tout va bien. D'autre part, par précaution, placez la <meta> content-type avant vos <meta> pour fournir l'information de charset en premier.

Excusez-moi, mais comme je n'ai jamais cette uri sous la main, je vais prendre une petite liberté et me permettre un Monîîîque ? Help !

Pourrais-tu nous rappeler, s'il te plaît, l'uri de ce post de K. Dubost (lagrange.net) sur les petits drapeaux et les hreflang, qui semble tout à fait à propos ?

(l'uri en question a été citée très récemment sur un fil de ce forum par notre indispensable administratrice. Chapeaux bas, messieurs, devant celle-ci, et ses signets imparables bien plus rigoureusement organisés que les nôtres !).