LaurentDenis

rajoute clear: both; dans ton footer

Non : le menu (#menu_global) étant en position absolue, cela n'aura aucun effet. La propriété clear permet d'empêcher un bloc d'être adjacent à un autre bloc flottant.

En fait, la solution des positions absolues est presque toujours la mauvaise lorsqu'on cherche à faire plusieurs colonnes et un pied de page sur toute la largeur disponible : la colonne en position absolue n'a plus aucune interaction avec les autres éléments de la page (elle est totalement retirée du flux), et les chevauchements sont alors tout à fait logiques

Ce type de mise en page n'est possible avec la position absolue que lorsque l'on est sûr que la colonne positionnée sera plus "courte" que la colonne en flux. Cette dernière maintient alors le pied en page en bonne place.

Pour que des colonnes de hauteur imprévisible "repoussent" toujours un pied de page plus bas que la plus grande, il faut que chaque colonne puisse encore interagir avec ce pied de page. D'où la combinaison classique:

- colonne de contenu flottant

- colonne de menu en flux

- pied de page avec clear:both

Le pied de page en flux :

- sera forcément plus bas que le menu en flux

- sera forcément plus bas que le contenu flottant grâce à sa propriété clear.

Remarque: le fait de faire flotter le contenu et non le menu permet de respecter un ordre plus logique et accessible dans le code html: le contenu avant le menu.

Mais la question du feignant (feignant mais aussi celui qui veut utiliser les capacités des langages qu'il utilise), n'y a t il pas une solution pour définir automatiquement l'attribut hreflang des liens en analysant les meta du site d'arrivée par exemple ou les meta Dublin Core, ou les entetes ...

L'outil reste à créer Il serait surtout intéressant pour avoir une idée du nombre de sites qui emploient correctement les indications de langue.

Evidemment, dans un Web idéalement bien codé, le test de l'en-tête HTTP content-language (qui devrait être systématiquement présent) serait des plus économiques...

Cela ne se produit que dans IE, qui a souvent des difficultés avec le texte justifié.

En fait, ta css print est inutilement complexe:

- supprime toute mention de largeur saf pour rétablir des width 100%

- ramène les paddings et margin à zéro

- ramène les flottants en static (float:none) sauf ton image bien-sûr

- etc.

Par exemple:

.volume5 {
float: none;
width: 100%;
text-align: justify;
margin: 0;
padding: 0;
}

Et IE arrivera à justifier le texte

... ... ... pour les dames

Vous trouvez pas ça agaçant, vous, le virtuel, des fois ?

Sinon, ça ne s'invente pas:

Nos membres ont écrit un total de 50 013 messages

Nous avons 3 180 membres inscrits

Le membre le plus récent est allergique

Laurent, tu es un grand malade 

Je comprend pourquoi certains élèves prennent leur professeurs pour des extra-terrestres (cf MIB entre autre), c'est parceque leurs enseignant sont strange !!!!

Je te rassure : c'est un aspect de ma personnalité que je réfrène avec succès dans l'exercice de mon métier civil

Je te comprend pas toujours...

désolé si mon message n'était pas clair. Je reprends:

- hreflang est encore quasiment inexploité par les applications liées au Web, en dehors de l'affichage de la langue de la cible via CSS dans un navigateur graphique. Mais cet attribut recèle des perspectives d'exploitation importantes pour l'avenir : donc, oui, il faut l'utiliser.

- l'exploitation de l'hreflang via CSS utilise un sélecteur d'attribut... ce qui fait que cela ne donne rien dans IE. Ce n'est pas un souci : celui qui utilise un navigateur, quel qu'il soit, doit faire avec les limites de capacités de celui-ci, dès lors que de son côté, l'auteur du site ne conditionne pas l'accès au contenu à l'utilisattion d'un navigateur doté de fonctionnalités précises. Ici, ne pas voir le rendu CSS de l'attribut hreflang n'empêche pas les utilisateurs d'IE d'accéder pleinement au contenu. Donc, il n'y aucun état d'âme à avoir à ce sujet.

voici le style de ma balise p

p{

font-family: Verdana, Arial, Helvetica, sans-serif;

font-size: 10pt;

text-justify: auto;

}

Utilise text-align: justify qui est conforme à CSS2, alors que text-justify est actuellement une propriété CSS purement microsoft

(A ne pas confondre avec la propriété homonyme de la future CSS3, qui ne sert pas du tout au même usage, mais spécifie après un text-align:justify l'algorithme précis de justification du texte selon la langue).

Pour une simple couleur, en effet, ne nous cassons pas la tête. Mais la redondance pourrait produire des effets inattendus sur d'autres propriétés. Ce n'est pas à encourager...

Un navigateur vraiment intelligent (comme nous en aurons dans quelques années, je crois), ajoutera lui-même au survol d'un lien (ou lors d'une autre fonction sur un lien tel que la carte des liens externe d'une page / d'un site) le signalement de la langue, sous la forme choisie par l'utilisateur selon ses préférences (un p'tit drapeau, un code ISO langue, un nom de langue explicite, etc).

De même, un moteur de recherche intelligent (si, si, il y en aura un jour ) pourra exploiter l'attribut hereflang des liens en rapport avec la pertinence d'un lien dans une requête faite à partir d'une langue donnée vers une autre langue donnée.

Une machine traductrice pourra anticiper l'éventuelle demande de l'utilisateur de consulter la cible d'un lien dans une version traduite, dès lors que l'attribut hreflang du lien sera explicité. Et à la manière de la navigation rapide dans Opera, il aura préparé cette traduction avant que l'utilisateur ne clique.

Mais encore faut-il pour cela que l'attribut en question soit spécifié, lorsque c'est possible. Donc, oui, hreflang doit figurer dans le code.

Peut-on s'en abstenir pour les liens dans la langue de la page elle-même ? Par paresse, oui. Mais rien n'obligerait un des outils ci-dessous à extrapoler la langue cible d'un lien à partir de la langue primaire de la page d'origine... Disons que c'est un pas de plus à franchir aujourd'hui, si on le souhaite.

Expliciter via CSS cet attribut pour renseigner immédiatement l'utilisateur sur la langue du document-cible ? C'est actuellement la seule application pratique de cet attribut. Pourquoi s'en priver ?

J'oubliais l'utilisateur d'IE: lorsque je surfe avec Lynx (ce que je fais souvent, ayant des goûts un peu pervers), je ne m'attends pas à trouver sur les pages que je consulte autre-chose que ce que Lynx (un navigateur texte) peut m'apporter...

Je te promets, je te jure, solennellement, devant témoins, ElMoustiko... que mon article n'avait rien à voir avec une quelconque "boulette" de ta part

Cela dit, s'il est complet, c'est simplement que le W3C et particulièrement sa branche Internationalisation (i18n) fontt depuis peu un effort particulièrement percutant d'explication à travers une série d'articles qu'il suffit de lire... ou de faire connaître.

Enfin, pour en revenir au sujet de ce fil, j'ai été en fait assez surpris par cette remarque de détail sur les drapeaux et hreflang dans ce document du W3C : hreflang pose en fait d'autres problèmes bien plus importants dans le contexte d'un site "internationalisé", et l'employer dans un lien vers un tel site n'est pas si évident:

- il suppose que vous vérifiez régulièrement le site en question, pour vous assurer qu'il ne se met pas à pratiquer le content-negociation sur la langue de préférence de ses visiteurs... auquel cas, un site avec un hreflang="en" pourra très bien se retrouver du jour au lendemain à adresser une page en français à ses visiteurs.

- Quid d'une page dont la langue primaire est en français, mais dont le contenu est essentiellement composé de citations dans l'autres langues ?

- Inversement, comment faire l'hreflang d'un site ayant plusieurs langues primaires ?

Pas si simple, cet attribut Tiens, il me semble avoir vu un autre article de l'i18n qui abordait ces questions... Mais où, déjà ?

Pour gérer le pied de page, tu dois passer obligatoirement par des colonnes en float, puisque la position absolue rend les colonnes totalement sans effet sur l'emplacement vertical du pied de page.

Pour conserver un ordre centre > gauche > droite de tes colonnes dans le HTML, voici une solution rapide : http://blog-and-blues.org/test/3_colonnes_float/ qui utilise la position relative en plus du float, comme je le suggérais plus haut.

(Pas le temps d'écrire les explications... Elles viendront demain matin )

Les contenus alternatifs de tous les éléments non-textuels sont correctement indiqués.

A ceci près que faire fonctionner l'élément object correctement dans les navigateurs actuels pour qu'il restitue le contenu alternatif, à partir de certains serveurs (Microsoft) n'a rien d'évident.

Le "squelette" que tu reproduis montre bien la limite des mises en pages dans lesquelles les colonnes sont de largeurs mixtes (largeur fixe en pixel et largeur relative): l'ordre HTML des colonnes est figé gauche > centre > droite.

Dans une mise en page de ce type, mais avec 3 colonnes de largeurs relatives (type 25% 50% 25%), il suffit d'utiliser la position relative sur les 2 premières colonnes pour :

- avoir un ordre HTML Centre > gauche > droite

- échanger les emplacements à l'écran des colonnes centre et gauche (la colonne centre est déplacé vers la droite de la largeur de la colonne gauche, et la colonne gauche est déplacé vers la gauche de la largeur de la colonne centre).

En effet, appliquer le fond à html rétablit le background. Merci beaucoup !

Vérifie le résultat dans IE avec les propriétés transposées sur html au lieu de body : le résultat est parfois curieux au moins avec IE Win 5.x

Logiquement, en fait, il faudrait les appliquer au body (l'élément magique en HTML) quand la page est servie en text/html, et sur html (l'élément magique en XHTML) quand la page est servie en application/xhtml+xml.

Par acquis de conscience, avant de creuser :

- Que donne une vraie feuille de style xml ? (<?xml-stylesheet type="text/css" href="/style/fixed.css" ?>)

- Que donne ton image d'arrière plan sur html plutôt que sur body ?

Tu as donné en fait la réponse à ta question : les navigateurs comme IE qui ne connaissent pas le type mime application/xhtml+xml recevront nécessairement tes pages (éventuellement adaptées) en text/html.

Le test permettant le choix du type mime reposant sur l'en-tête HTTP_accept... Google et autres moteurs de recherche :

- recevront du "vrai" XHTML s'ils déclarent l'accepter... et devront donc savoir l'indexer et le référencer.

- recevront du HTML dans le cas contraire.

En l'occurence, Google recevra du HTML.

Pou qu'une balise HTML ne soit pas interprétée, mais juste affichée comme n'importe quel texte, il faut l'encoder :

- < devient &lt;

- > devient &gt;

D'autre part, les exemples de code ont avantage à être indiqués comme tel à l'aide des éléments <code> (exemple en ligne) ou <pre> (un bloc de code). De la sorte, il est plus facile d'en gérer la présentation dans les navigateurs graphiques, et ils auront une présentation par défaut spécifique dans les autres navigateurs.

Ton exemple s'écrit donc au choix : ex: <code>&lt;body&gt; &lt;/body&gt;</code>

ou :

<pre>

&lt;body&gt;

&lt;/body&gt;

</pre>

La technique a ses limites: en CSS2, une image d'arrière-plan n'est pas "étirable", et ses dimensions ne peuvent pas être manipulées via CSS.

Ce n'est donc pas faisable.

Une remarque par ailleurs: l'unité "point" (pt) est adaptée au media print (CSS d'impression), mais pas à l'écran (media screen). Les unités pour CSS d'affichage sont plutôt le px ou em.

Ah, je vais encore jouer les casse-pieds :

Que tu ne connaisses pas une cetaine fonctionnalité d'un outil que tu utilises quotidiennement ne fais pas de toi une idiote... ça fait simplement de toi quelqu'un qui n'a pas fouillé son outil autant qu'un autre.

Un utilisateur a d'ailleurs tous les droits de ne pas utiliser à fond ses outils... Généralement, c'est par la frustration et l'impression d'insatisfaction que de telles découvertes se produisent... à force de souffrir d'une situation, on finit par vouloir la régler.

Il me semble difficile de diffuser des bonnes pratiques (car c'est de cela dont on parle, et non de normes) et d'en limiter la cible aux auteurs.

Ce "Web plus fun" des standards et de la qualité veut, entre-autres buts, mieux respecter l'utilisateur.

Mais il faudrait alors qu'il se pose aussi la question d'expliquer à l'utilisateur, et pas seulement à l'auteur, quel outil celui-ci a-t-il a entre les mains et comment s'en servir.

En d'autres termes, il ne sert à rien d'expliquer aux auteurs comment mieux coder si on n'explique pas en même temps aux visiteurs comment mieux visiter. C'est à dire dans ce cas, en gérant le fenêtrage de sa navigation, et comment le faire.

Le standard qui permet l'ouverture d'une nouvelle fenêtre sur un clic, c'est le (x)HTML transitionnel, qui permet l'utilisation du target="blank".

C'est un petit peu plus amusant que cela. XHTML est modulaire. Il se trouve que la collection de modules retenus pour définir XHTML1.0 strict ne retient pas le module intégrant l'attribut target. Mais rien n'empêche de se construire une DTD additionnant XHTML1.0 strict et ce module précis qui du coup devient valide

En fait, la "logique des standards" conduit plutôt à dire aux amateurs de ce "target="_blanck" : "allez-y, servez-vous en autant que vous voulez... dans le cadre de la DTD que vous êtes en droit d'assembler pour cela" et que le W3C aurait très bien pu concevoir.

Il reste que target=_blanck pose des problèmes d'accessibilité, de navigabilité, d'interopérabilité... immédiats.

Pour les pages mal affichées par Firefox, je demande à voir.

Des pages codées de manière à ne pouvoir être bien lu par IE (attention, je n'ai pas dis que c'était fait exprès), ça existe (même si c'est de plus en plus rare).

Mais si tu as un exemple ou Firefox est en faute, je suis preneur

Juste pour le fun, celui-ci est historique : http://www.positioniseverything.net/gecko/mozbug-clear.html

Il y en a quelques-autres, tout comme pour Opera et Safari, en nombre et en importance égales.

La qualité de support CSS de ces navigateurs est équivalente, quoiqu'elle diffère sur tel ou tel point de détail. A ce stade, elle n'a guère d'importance.

La qualité de support de tags propriétaires est également à peu près équivalente, et n'a guère d'importance non plus.

Comme le dit excellement Monique, le choix d'un navigateur repose sur une appréciation subjective de critères parfois objectifs, parfois subjectifs. D'où la stérilité de beaucoup de discussions sur le sujet.

Pour ma part, je me contente de rêver d'un Web où je pourrais raisonnablement oublier les navigateurs

Tiens, et si on ne publiait plus que du RSS, du FOAF ou du X-Voice, pour voir ?

Ah, j'oubliais la seconde cause d'invalidité : ton checked.

Si on y réfléchis un peu, cette syntaxe HTML est tout de même un peu bizarre :

<input type="radio" value="abonne" checked name="choix" />

On a l'habitude des noms d'éléments (<input>) et des attributs auxquels on donne une valeur (type="radio").

Mais un mot tout seul, comme ça "checked", c'est quoi au juste ?

En fait, en HTML, c'est une forme abrégé d'une syntaxe plus complète (La forme abrégée est valide en HTML).

XHTML n'autorise pas ce type de syntaxe abrégée, et exige la syntaxe complète donnant:

-le nom de l'attribut: "checked"

-la valeur de l'attribut: "checked" encore !

Donc il faut réécrire cette ligne sous la forme :

<input type="radio" value="abonne" checked="checked" name="choix" />

Le code de ton formulaire :

<p><form method="post" action="mailinglist3/inscription.php3">
                <input type="text" name="mail" size="20" />
                <input type="submit" value="Go !" name="B1" />
                <br />
                <input type="radio" value="abonne" checked name="choix" />
                <font face="Arial" color="black" size="2">S'abonner 
                <input type="radio" name="choix" value="desabonne" />
                Se Désabonner</font> 
  </form></p>

L'élément <form> ne peut pas contenir de contenu en ligne, et les <input> sont des éléments en ligne.

Il ne peut contenur que des éléments blocs, et il faut donc inclure le contenu de <form> dans un <table, ou un/des <div>, <p>, <ul><li>, <dl><dt><dd>, etc.

Ce qui donnerait pas exemple, au plus simple :

<form method="post" action="mailinglist3/inscription.php3">
   <p>
      <input type="text" name="mail" size="20" />
      <input type="submit" value="Go !" name="B1" />
      <br />
      <input type="radio" value="abonne" checked name="choix" />
      <font face="Arial" color="black" size="2">S'abonner 
      <input type="radio" name="choix" value="desabonne" />
      Se Désabonner</font> 
   </p>
</form>

Par ailleurs, un petit gain d'accessibilité facile à mettre en oeuvre : ton titre <h2> est l'étiquette naturelle de ton champ de formulaire. Pourquoi ne pas l'indiquer comme tel, ce qui facilitera l'utilisation du formulaire par les utilisateurs handicapés visuels ou moteurs ?

Le code devient alors :

<form method="post" action="mailinglist3/inscription.php3">
  <h2><label for="mail">S'inscrire à la mailing-list</label></h2>
   <p>
      <input type="text" name="mail" id="mail" size="20" />
      <input type="submit" value="Go !" name="B1" />
      <br />
      <input type="radio" value="abonne" checked name="choix" />
      <font face="Arial" color="black" size="2">S'abonner 
      <input type="radio" name="choix" value="desabonne" />
      Se Désabonner</font> 
   </p>
</form>

Le mot d'ordre officieux (à vrai dire, meme pas un mot d'ordre car tout nous empêche de faire autrement) c'est de ne pas s'occuper si y'a moins de 5% (comme les 5% sans javascript, les 5% en 256 couleurs, les 5% qui n'ont pas de souris, les 5% sous safari .... etc.)

- les 5% en 256 couleurs n'ont a priori rien à voir avec l'accessibilité (sauf si cette donnée technique est liée à un périphérique spécifique requis par un handicap)

- les 5% sous Safari... idem

Il peut y avoir une (rare) problématique d'accessibilité pour les 5% sans javascript ou plus probablement pour les 5% sans souris (handicapés moteurs). Mais pour le reste, on parle d'interopérabilité.

Les problématiques interopérabilité et accessibilité sont parfois similaires, mais divergent sur le fond:

- l'accessibilité requiert des mesures d'adaptation spécifiques (permettre à un site d'être accessible à un daltonien requiert une validation très particulière des contrastes de couleurs ; en l'état actuel de la technique, permettre à une image complexe d'être accessible requiert un lien vers un contenu textuel spécifique via un attribut longdesc, un lien D...)

- l'interopérabilité ne requiert que le respect le plus étroit d'un standard de base (HTML brut) .

Je vais franchement m'inscrire en faux contre ce qui précède : une version spécifique "accessible" est un premier pas vers l'accessibilité. A encourager plutôt qu'à refuser, surtout sans connaître les contraintes propres au site en question:

- compétence et possibilité de formation ?

- problèmes spécifiques liés au contenu ?

- projets à long terme en matière d'accessibilité ?

D'autre-part, le mythe de l'accessibilité pour tous grâce aux Standards miracles se heurte à quelques écueils immédiats en l'état actuel de la technique :

- une accessibilité déjà problématique pour les non-voyants et mal-voyants qui sont l'objet de toutes les attentions, leurs promoteurs étant les plus actifs.

- une accessibilité beaucoup plus problématique pour les handicapés moteurs, nettement moins choyés.

- une accessibilité utopique pour les "personnes ayant un handicap de compréhension" (pour reprendre l'euphémisme en vigueur), qui sont par ailleurs les laissés pour compte obligés de l'accessibilité officielle.

Tout ceci pour dire que ce n'est pas aussi simple, que l'accessibilité est un effort (frustrant), et qu'un "effort vers..." ne se juge pas aussi radicalement.

Pour info: j'ai réussi à faire valider ma home par le W3C en otant les attributs height et bordercolor qui bloquaient la validation 

Pourquoi   

Le fait de ne pas renseigner ce qui ,à mon sens,devait l'être a débloqué cette valid

La validité HTML, c'est simplement le respect d'une norme de syntaxe et de vocabulaire HTML (la spécificiation HTML 4.01). Comme toute norme, elle repose sur des choix justifiés, mais qui peuvent paraître arbitraires.

L'un de ces choix est de séparer autant que possible:

- les données structurelles (l'élément <table>)

- les données de présentation visuelles (les attributs height, bordercolor, etc).

Cette séparation a conduit à déclarer invalides les attributs de présentation que tu utilisais.

Les données de présentation sont effectivement nécessaires, mais elles doivent prendre place au choix :

- dans un attribut style="height: ...; border-color: ...;" de l'élément concerné.

- ou dans un élément de style interne au document HTML, dans la section <head>: <style type="text/css">table {height: ...; border-color: ...;}...</style>

- ou mieux dans une feuille de style externe, la séparation entre contenu structuré et données de présentation étant alors complète.

FireFox n'a rien à voir là-dedans, ni aucun navigateur en fait : l'auteur utilise simplement un mauvais script serveur de discrimination des navigateurs, qui assimile tout ce qu'il ne connaît pas à NS4.7.

Il se trouve qu'il se sait pas reconnaître FireFox, soit parce qu'il n'est pas à jour, soit parce qu'il a été codé avec les pieds.

De toute façon, il ne peut pas reconnaître non plus IE, Mozilla ou Opera dans ma configuration, l'identité du navigateur étant masquée par mon Firewall

Ce type de script de content negociation reposant sur l'identification du navigateur est à proscrire. A l'inverse, un script vérifiant que le navigateur implémente les fonctions utilisées par le site est totalement fiable et facile à gérer.