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

Ya un décalage a droite de l'arrondi, une espece de ptite tache en haut a droite du cadre, et ce blanc a gauche du cadre !

<{POST_SNAPBACK}>

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.

L'idée n'est pas de renverser un navigateur quel qu'il soit, mais de ramener une saine compétition dans ce domaine pour que nous, utilisateurs, puissions reprendre contrôle de cet outil fondamental à l'exploitation du Web.

Avec un opposant fort à MSIE qui est respectueux des normes et incontournable, les concepteurs devront de nouveau en tenir compte comme ce fut le cas il y a quelques années avec Netscape.

<{POST_SNAPBACK}>

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

Pour ce qui est de la navigation par onglets qui semble appréciée des spécialistes et que l'on retrouve dans pas mal de navigateurs libres, c'est quelque chose que l'on étudie mais on ne se concentre pas que sur ça. Nous ne sommes pas là pour être des copieurs ou des suiveurs. Si il y a des choses biens, absolument souhaitées et requises, elles seront dans notre navigateur maintenant nous voulons apporter des innovations dans des secteurs qui ne sont pas encore défrichés aujourd'hui.

(...)

En gros sachez qu'Internet Explorer n'est pas un produit abandonné et que nous rattraperons notre retard fonctionnel sur les autres navigateurs mais il n'y a pas que ça.

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.

Les éléments hx devraient servir à baliser la structure "didactique" du document (en faire un plan), sans déborder en son niveau le plus haut sur la nature du document lui-même (c'est le rôle du titre d'indiquer ce dont parle, globalement, le document).

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 ?

Le probléme est que mon agenda est condenu dans un div appelé événement et que ce div utilise les balises dt et dl qui sont également utilsées plus bas pour faire des div arrondis.

Le probléme est que le div événement fait apparaitre l'image arrondi alors que je n'en veux pas.

#evenement dt 
{
background: none;
}

Sans aucune envie de troller, je suis d'accord sur le fait qu'il faille bien définir une frontière entre le navigateur et son contenu, mais je ne vois pas en quoi les scrollbars internes feraient plus partie du logiciel que du site consulté.

Les frontières sont effectivement malaisées à tracer, et toujours sujettes à caution...

Par contre, effectivement, c'est dommage que leurs syntaxes propriétaires ne soit pas conforme... Qui sait si un jour elles ne feront pas basculer un navigateur en mode quirk.

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.

J'avou ne pas voir ou est le problême, je trouve vraiment dommage que le Hub tolère une telle chose et préfère supprimer les posts expliquant la vérité plutot que de fermer le topic complètement.

<{POST_SNAPBACK}>

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

L'open source, c'est en plus du travail collaboratif de plusieurs experts sur un projet, un développement optimisé et stable, et surtout une réactivité qu'on ne peut trouver dans aucunes autres méthodologies de développement.

<{POST_SNAPBACK}>

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.

C'est vrai avec les CSS pour modifier les scrollbars chez MSIE, et c'est aussi vrai pour les éléments de CSS-3 à venir et qui sont tout aussi propriétaires comme tous les -moz qui ne fonctionne que pour Gecko...

C'est tout aussi propriétaire, quoi qu'on en dise.

Justement.... quelle différence avec -moz-border-radius et tous les autres ?

<{POST_SNAPBACK}>

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

Je crois aussi qu'il y a toujours un titre pour le contenu (à ne pas confondre avec un titre pour la page) de manière globale

<{POST_SNAPBACK}>

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>

Mes excuses, par "spécification dans son ensemble", je parlais de la partie concernant les éléments hx (ayant tronqué ma citation). Nous sommes d'accord sur ce point.

Nous sommes d'accord sur bien davantage, mais je me suis manifestement mal exprimé à mon tour

Pour le problème qui nous intéresse, on se rend compte qu'il y a grosso modo deux approches :

* non-confusion entre le document dans son ensemble et ses parties

* confusion entre le document et ses parties (parce qu'il n'y en a pas d'explicites, par exemple)

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.

(La solution que tu proposais (faire s'afficher le 'title' comme titre du document, dans le document) ne fonctionnera pas non plus partout.)

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.

...en considérant qu'un document organisé en une section unique revient à parler d'un document sans section - alors qu'en définitive, il y a d'abord ce qu'est le document, puis ce qu'a le document.

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.

Le must serait - selon moi - de pouvoir choisir simplement si on souhaite rappeller le titre du document, dans le corps du document, avant de passer à un/des éventuel(s) titre de section(s).

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

C'est pour ça que je dis qu'il ne faudrait pas faire l'amalgame entre titre du document et titre de section

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 ?

La spécification dans son ensemble parle de titre de rubriques ou sections, et pas de titre de (la) page.

Si: title.

Les éléments hx devraient servir à baliser la structure "didactique" du document (en faire un plan), sans déborder en son niveau le plus haut sur la nature du document lui-même (c'est le rôle du titre d'indiquer ce dont parle, globalement, le document).

Seulement, pour le moment ce n'est pas très pratique...

<{POST_SNAPBACK}>

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>

je suis de ceux qui soutiennent qu'on ne devrait utiliser qu'un seul h1 par page, pas plusieurs.

Voilà qui ouvre une discussion intéressante

Ma petite cogitation personnelle sur le sujet:

A heading element briefly describes the topic of the section it introduces. Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.

( 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>:

<!-- The TITLE element is not considered part of the flow of text.

       It should be displayed, for example as the page header or

       window title. Exactly one title is required per document.

    -->

(...)

Every HTML document must have a TITLE element in the HEAD section.

Authors should use the TITLE element to identify the contents of a document.

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

Mais, si je ne vous embête pas trop un de mes problemes etait de positionner les 2 cadres tout en bas de la page afin d'avoir une zone actualites, une zone forum , etc ... avec des cadres arrondis.

<{POST_SNAPBACK}>

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

Second probleme, je n'arrive pas à positionner 2 cadres arrondi cote à cote, il se mettent l'un en dessous de l'autre.

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 !