LaurentDenis

Et-tu sûre de ne pas pouvoir donner tous les équivalents textuels nécessaires dans ta version graphique, à l'aide de simples alt ? Faire une seconde version texte d'un document est une pratique recommandée en dernier ressort par les directives d'accessibilité, lorsqu'aucun autre moyen n'est jugé suffisant... Un détail enfin: attention avec les techniques rendant un lien invisible... Il arrive en effet souvent que le lien se retrouve invisible également... dans les lecteurs d'écran

Tu utilises en même temps deux techniques radicalement différentes pour gérer tes images d'arrondi: - une image HTML <img> pour le coin droit - une image d'arrière-plan CSS pour le coin gauche <dt class="arrondi"><img id="droitehaut" src="hautd.gif" alt="" /> <img id="titre" src="titre.gif" alt="titre" /> </dt> <dd class="arrondi"> dt.arrondi { height: 35px; background: #fff url(haut.gif) top left no-repeat; text-align: center; /* centrage du titre, bug IE*/ } Difficile de concilier les deux... Il faudrait prendre un parti, et opter pour l'une ou l'autre technique

Il est en effet difficile de ne pas faire le parallèle avec l'histoire récente des navigateurs qui a bien montré les effets pervers d'un quasi-monopole de fait.

Tout à fait. Une récente interview d'un responsable Microsoft est d'ailleurs intéressante à ce propos (http://www.clubic.com/article-17139-1-interview-avec-cyril-voisin-microsoft-france.html): Certes, ce n'est qu'une interview... mais elle me semble assez révélatrice des effets potentiellement bénéfiques de la concurrence entre navigateurs.

Entièrement d'accord avec toi sur le fond, je me pose cependant une question: qu'est-ce que ce "niveau le plus haut" lié à la nature du document lui-même ? Comment l'inscrirais-tu dans un contenu(X) HTML ?

#evenement dt { background: none; }

Les frontières sont effectivement malaisées à tracer, et toujours sujettes à caution... J'avoue que je vois mal cette hypothèse se réaliser : les navigateurs disposent déjà d'un mécanisme effectif de bascule entre modes de rendu CSS (le doctype switching) et disposeront à terme d'une option beaucoup plus "fine" (la propriété box-sizing applicable à volonté à n'importe quel sélecteur CSS). CSS2.1 permettra justement de gérer les extensions propriétaires.

Voilà qui est chose faite, en attendant que les intervenants aient réglé leurs problèmes personnels en privé, ou nous aient expliqué l'intérêt de cet "échange".

Argument abusif: la réactivité des solutions anti-virus, pour celles qui ne doivent rien au modèle open source, n'est pas des plus négligeable Plus sérieusement, l'open source "navigateurs" ne me semble pas avoir de réactivité particulièrement meilleur que le modèle dit "propriétaire" (voir la réactivité d'Opera SA en la matière). Ce qui est en cause, en fait, c'est la complexité de la réponse à une faille d'IE, compte-tenu du modèle technique très particulier adopté pour celui-ci (intégration osmotique avec l'OS). Microsoft étant très peu réactif... on a vite fait de s'arroger en qualité propre les défauts de ses concurrents.

La différence est nulle en CSS2. Mais elle apparaîtra avec CSS2.1, qui officialise et codifie le mécanisme des extensions propriétaires CSS: pour une question de syntaxe défectueuse (en particulier), les extensions CSS Microsoft ne seront pas reconnues comme valides, tandis que les extensions Gecko et Opera le seront. Disons que ce mécanismes des extensions propriétaires valides est simplement un moyen direct et efficace de gérer les "avancées" de tel ou tel navigateur (Comment faire autrement pour permettre par exemple à Opera 7.60 d'implémenter expérimentalement les CSS vocales et la norme X-Voice ?)... Mais encore faut-il que chaque navigateur se plie aux règles communes, notamment syntaxique Rappelons que CSS2.1 n'a guère d'autre rôle que d'être l'errata (final ?) de CSS2, et d'y faire la part de l'implémenté, de l'inutile... et du concret.

Si vous me permettez une remarque sur le fond : le contrôle de l'apparence des scrollbars n'est en effet pas "valide" en HTML-CSS "standard" pour la raison suivante : il faut bien, simplement, tracer une frontière entre: - la page Web dont l'auteur définit la présentation (d'ailleurs modifiable par l'utilisateur) - l'outil de navigation sur lequel l'auteur n'a pas à intervenir, car il intervient du coup sur les préférences et les besoins de l'utilisateur, dont il serait abusif et illusoire de vouloir contrôler le comportement. Il se trouve que cette frontière exclut les barres de scroll...

Actuellement, la page (avec le #corpspage {width : 800px; height : auto; }) s'affiche correctement dans Opera 7.x... et dans IE6.0 Windows. <edit> Rapidement testé : la page s'affiche aussi correctement sous IE6.0 Windows avec #corpspage {width : 100%; height : auto; } Quelle syntaxe avais-tu utilisée, exactement ?

Il faut l'expliquer en termes... explicites dans le formulaire de recherche. Ne pas se fier à une convention... que l'utilisateur a toutes raisons d'ignorer.

En d'autres termes, à la suite de Monique : alt est obligatoire. Il donne un équivalent textuel à l'image pour les non-voyants, mal-voyants, les "machines" aveugles et ceux qui désactivent les images. title est une possibilité offerte d'ajouter une donnée supplémentaire sur l'image, c'est à dire une metadonnée. Pratiquement tous les éléments de contenu HTML supportent l'attribut title, et peuvent ainsi être enrichi d'une métadonnée. Pour une image, ce pourrait être la mention de l'auteur, des droits, d'une date... par exemple

Hum... Si je te suis, tu raisonnes en termes de contenu unique. Que fais-tu d'une page simplement bilingue : <div lang="en"> <titre>Web Standards</titre> ... </div> <div lang="fr"> <titre>Les Standards Web</titre> ... </div> Comment ne pas se fâcher avec les anglophobes ou avec les francophobes en optant pour un titre unique ? Mon exemple relève plus du gag que d'autre chose (quoique...). Mais tous les contenus ne me semblent pas pouvoir recevoir un titre unique. (Dans nos blogs, un titre unique de page = le titre du billet et un titre <h2> de menu sont déjà plutôt abusifs.)

Point de départ, à affiner à partir des articles de la rubrique CSS d'Openweb: #centre { margin: 0 25%; } #gauche { position: absolute; left: 0; top: 0; width: 23%; /* laisser du jeu pour éviter les conflits de modèle de boîte*/ } #droite { position: absolute; right: 0; top: 0; width: 23%; /* laisser du jeu pour éviter les conflits de modèle de boîte*/ } #gauche img { float: left; /* pas de largeur spécifiée : c'est une image qui a une largeur propre*/ } <body> <div id="centre"> <img scr="..." width="..." height="..." alt="..."/> Centre </div> <div id="gauche">Gauche</div> <div id="droite">Droite</div> </body>

Nous sommes d'accord sur bien davantage, mais je me suis manifestement mal exprimé à mon tour Oui, tout à fait d'accord. Sauf si le document n'a qu'une partie principale. Et mon avis mal exprimé était de limiter l'usage du <h1> comme réplique du titre de document à ce cas. Nous sommes encore d'accord, et je me suis encore mal exprimé : Solution signalée, mais pas "proposée" au sens de recommandable, pour l'excellente raison que tu explicites. Ceci mérite d'être creusé. Je crois qu'il faudrait avant tout chercher simplement un point d'appui à la réflexion du côté des langages basés sur RDF (FOAF, RSS1.0). En sachant qu'HTML ne fera jamais ce que XML pourra faire. un must, en effet... C'est actuellement la tentation du title et de CSS. Mais avec les défaut d'implémentation soulignés plus haut. (C'est une pure question de présentation: l'information est là, de toute façon). Nous sommes bien d'accord. Peut-être ai-je été plus clair dans le billet qui a suivi ce post (mais poursuivons plutôt la discussion ici svp): http://blog-and-blues.org/weblog/2004/11/0...t-le-malentendu

Hem. Il y a beaucoup de confusions potentielles sur les outils de positionnement CSS dans ton message, surtout il est impossible de déterminer exactement le problème. Pourrais-tu fournir un exemple détaillé de code, ou mieux, une url ?

Si: title. Rien n'interdit de "déborder en son niveau le plus haut sur la nature du document lui-même, s'il y a coïncidence en raison du contenu précis de cette page. En considérant qu'il ne faudrait pas déborder etc. , on quitte la problématique de ce qui est conforme ou non à une norme, pour entrer dans le domaine de ce qui relèverait d'une pratique recommandable. Cela peut paraître une nuance excessive, mais la plus grande partie du problème est là: la norme est une convention forcément restrictive pour établir un langage commun afin que tout contenu soit compréhensible. Au-delà, il y a la question de savoir si on s'exprime selon <edit:supprimé>telle ou telle convention beaucoup plus subjective</edit> tel ou tel choix structurel.

Dans le même désarroi, j'appuie la question : Hits, Files, Pages, Visits, Unique Sites, Unique URLs, Unique Referrers, Unique User Agents...... auant de termes qui n'ont rien d'intuitifs, en effet.

<modération> Titre du sujet modifié afin qu'il reflète mieux son contenu </modération>

Voilà qui ouvre une discussion intéressante Ma petite cogitation personnelle sur le sujet: ( http://www.w3.org/TR/html401/struct/global.html#edef-H1 ) Autrement-dit, la question posée est: un document HTML : - a-t-il nécessairement une section unique titrée par un <h1>, pour l'ensemble de son contenu ? - ou peut-il avoir plusieurs sections d'égale importance, chacune titrée par un <h1> ? On ne peut guère répondre que: "tout dépend du contenu". Attention ! Nous parlons de titre de section, et non du titre du document. Le titre du document lui-même, ce qu'on pourrait appeler le titre de la ressource, relève de l'élément <title>: ( http://www.w3.org/TR/html401/struct/global.html#edef-TITLE ) Ce qui est intéressant ici, c'est le It should be displayed, for example as the page header : il se trouve qu'aucun navigateur graphique n'exploite <title>pour afficher le titre de la page dans l'affichage du document lui-même. Ils se contentent de l'afficher comme titre de fenêtre, d'onglet, etc... Mais la spécification, contrairement à ce qu'on dit souvent, n'interdit en rien à un navigateur de restituer <title> comme titre du document en tête de celui-ci. Et d'ailleurs, c'est exactement ce que font les navigateurs textes et les navigateurs vocaux (Opera), qui exploitent beaucoup mieux cet élément Nous sommes donc devant le problème suivant: - le titre du document ne devrait être indiqué qu'à l'aide de <title>, et non avec <h1> qui est un simple titre de section. - Mais nos navigateurs graphiques n'exploitent pas <title> pour afficher le titre du document dans celui-ci. - donc nous nous rabattons sur un <h1>... qui, du coup, devient abusivement unique. En fait, c'est sans doute un choix tout à fait acceptable... Mais il ne doit pas conduire à déformer l'utilisation de <h1>, et à proscrire sa véritable utilisation comme titre de section, dans laquelle il peut très bien y avoir plusieurs sections de même importance, et donc, plusieurs <h1>. <edit> Notons en passant que rien n'empêche, dans un navigateur graphique supportant correctement CSS2, de rectifier le comportement du navigateur. Le non affichage du <title> dans le document vient simplement... de la feuille de style par défaut appliquée aux éléments HTML. Il suffit de supplanter celles-ci à l'aide de display: block...)

Manquant de temps hier, je m'étais arrêté au menu. Passons aux <dl> et à leurs coins arrondis: Côté structure HTML, une mise en garde : les listes de définition <dl> ne sont pas destinées à créer une pseudo-structure de sections dotées de titres, mais des couples termes - éléments de définition. Utilisées comme des <div><h...><p></div, elles sont le plus souvent abusives du point de vue du sens, n'apportent aucun gain sémantique réel, et se révèlent moins expoitables que de véritables titres (pour établir une table ds matières du document, pour naviguer de titre en titre...) Mieux vaudrait reprendre ce code avec de simples <div> conteneur (div est fait pour ça: ajouter du style et de la structure) et des titres <h...> Cela dit, le problème d'espace entre les bords arrondis et le contenu des blocs vient simplement des marges par défaut des paragraphes: dd p { margin: 0; } règlera le problème. D'une manière générale, au moins lorsqu'on débute en CSS, il est plus pratique d'utiliser en tête de feuille de style: * { margin: 0; padding: 0; } plutôt que d'appliquer ces propriétés au body ou à html, body en se fiant à l'héritage par les éléments contenus dans html ou dans body. Enfin, pour placer les deux blocs l'un à côté de l'autre: dl { width: 45%; /* dimensions et positions modifiables à loisir */ left: 10em; top: 50em; } ... n'a aucun effet et ne peut pas en avoir. Les propriétés left et top ne peuvent être utilisée que pour un élément en position absolue, fixe (ou relative, mais c'est une autre histoire). Ici, une position:absolue ou fixe rendraitla mise en page très périlleuse. Un simple float:left convient. Ce qui donne: dl { width: 40%; /* largeur réduite pour éliminer le problème de box-model IE */ float: left; margin: 0 1em; } hr { clear: both; visibility: hidden; } <dl> ... </dl> <dl> <hr /> Un séparateur <hr /> est ajouté après les éléments flottants et doté d'une propriété clear:both pour forcer le contenu à reprendre le flux en tenant compte de la hauteur des flottants. (Sinon, un flottant n'est pas pris en compte dans le calcul de la hauteur de son conteneur, et le pied de page viendrait se placer à côté des flottants, au lieu d'être en dessous. Enfin, je te conseille surtout la lecture de quelques articles de base sur le positionnement CSS, avant d'exploiter des modèles prêts à l'emploi qu'il est le plus souvent difficile de personnaliser sans erreur: - Passer aux feuilles de style - Initiation au positionnement CSS : 1.flux et position relative - Initiation au positionnement CSS : 2.position float - nitiation au positionnement CSS : 3. position absolue et fixe

Reprenons tranquillement: #menuhaut{ background-color:transparent; float:left; position:absolute; left:195px; top:90px; } ... Float et position:absolute sont incompatibles (le dernier écrase le premier). Enlever le float qui ne sert à rien. .horizontal ul { list-style-type:none; /* on supprime les puces, inutiles */ width: 100%; /* précision pour Opera */ } ... ne peut pas s'appliquer à <ul class="horizontal">, puisque le sélecteur CSS signifie "les ul qui sont dans un conteneur de classe horizontal", et non "les ul de classe horizontal". Le sélecteur doit s'écrire "ul.horizontal" ici. Plus directement, mettre ces styles dans un #menuhaut ul (les ul qui sont dans un #menuhaut) .horizontal li { float: left;} /* on aligne les listes sur la gauche */ ...Un flottant ne peut pas flotter sans propriété width spécifiée (et pas width:auto évidemment, puisque c'est l'équivalent d'une propriété width absente). Donc il manque un width:... On y verra déjà plus clair après ces corrections

Petite prévision au cas où: sans avoir jamais testé rigoureusement, j'ai souvent constaté que le classique *{ margin: 0; padding: 0; } ou ses variantes sur html et body n'annulaient pas forcément les marges verticales des titres, malgré l'héritage théorique sur ces propriétés. Il suffirait de vérifier dans les récentes CSS écrites par Yan Hixon et par Eric Meyer pour annuler les styles par défauts des navigateurs. Fichus styles par défaut, soient dit en passant !