Raphael

Je ne connais pas ce patch.

Par contre il n'est pas très difficile de passer SPIP en XHTML Strict, vu qu'au départ il a la bonne idée de faire une mise en page tableless.

En fait, il suffit de rajouter un fichier mes_fonctions.php3 dans la config.

Ce fichier, tu peux le construire à partir de ça : http://notabene.f2o.org/spip1-6/article.php3?id_article=2

Mon premier essai en SPIP est valide XHTML et passe le Validateur d'Accessibilité d'Acces-pour-tous : http://www.agr-fscf.fr

Bien Laurent, j'avoue que ce principe est certainement le plus convainquant que j'aie vu (j'avoue qu'en ce moment je ne vois pas grand chose en fait, vu mon manque de disponibilités).

Reste l'éternet problème de la "dégradation correcte" pour les nombreuses personnes qui veulent (et je peux les comprendre) que les colonnes s'adaptent aussi sur IE, ce qui n'est malheureusement pas le cas.

PS : j'attends un billet de ta part pour que je puisse le mentionner (pas le temps de mon côté)

Bon, je savais bien qu'il faudrait un exemple : Colonnes de même hauteur.

"en-dessous" voulait dire "verticalement", pas dans le sens d'un empilage de div

<{POST_SNAPBACK}>

Bien, voilà un joli exemple d'utilisation de table-cell en effet Il faudrait en parler un peu car ce genre de question est à la mode partout.

Sur le principe, je vois beaucoup mieux ta "dégradation correcte".

En fait, tu utilises les deux techniques cumulées : table-cell pour les navigateurs standards et un petit hack avec un simple float+clear pour IE, c'est bien ça

Dans ton exemple, tes 2 "cellules" centrales sont réparties en 70% / 30% de la largeur du conteneur.

Est-il possible d'avoir, comme il est demandé dans le cahier des charges de départ () d'avoir : une colonne de largeur fixe et l'autre qui prend le reste de la largeur ?

Puisque c'est bien le problème depuis le début. En clair est-ce que ça fonctionne avec "gauche" à 10em et "droite" à "auto" ?

PS : pourquoi un "border: 10px solid;" sur le footer, ça change quoi ?

Pour ce qui est de la mise en page et des images, pas de problème, il suffit d'afficher tes images avec un background-image.

Par contre pour créer du contenu comme un menu, le CSS n'est pas fait pour ça. Il te faudra utiliser un langage serveur pour inclure tes parties répétitives (par exemple le fameux include() en PHP)

Je pense que c'est dû au fameux Modèle de boite erroné d'IE : http://openweb.eu.org/articles/dimensions_boites_css/

Bon, maintenant, je suppose que tu ne seras pas convaincu tant que tu n'auras pas un exemple sous les yeux...

Non, non, j'en suis convaincu.

D'ailleurs tu me le confirmes : "le footer sera en dessous."... ce que tu trouves "un peu moche" pourrait très bien se révéler affreux, surprenant ou même handicapant si - comme c'est souvent le cas - ce footer affiche des informations essentielles comme les coordonnées d'une entreprise.

Je titille Sibelius pour le plaisir, mais cet excellent article est tout aussi valable en gérant son multi-colonnage... en float plutôt qu'en position:absolute

Exact (merci pour le compliment au passage).

Le multicolonnage aurait apporté à cet article :

- un gros avantage : celui d'avoir plusieurs "colonnes" extensibles (et non pas une seule comme dans l'article)

- un inconvénient : celui de ne plus profiter de la fluidité des blocs en largeur, étant donné qu'un élément flottant ne peut avoir de largeur automatique.

Sans positionnement spécifique, les différents blocs s'afficheraient dans le flux normal, donc l'un en dessous de l'autre.

- il se dégrade tout à fait correctement (sans obstruction) dans les navigateurs qui ne le peuvent pas, en attendant qu'ils améliorent leur support de CSS

Tu parles de "dégradation correcte", alors que si je ne me trompe pas (on me corrigera au besoin), il me semble que l'effet qui peut se produire sur IE est loin de ce qu'on peut appeler "correct" : il se peut très bien qu'un bloc passe complètement pardessus le footer, ou pire, que le footer s'affiche au-dessus d'une partie de contenu importante.

Je suis entièrement pour une dégradation souple et ne pas chercher un affichage identique... mais dans ce cas précis, je pense sincèrement que en pratique les CSS ne permettent pas de résoudre ce problème.

EDIT : euh... tu n'avais pas séparé le sujet pour plus de clarté ?

CSS permet de faire cela. Je te renvoie au chapitre 17 de la spécification

Tu sais très bien ce que je veux dire, je connais aussi les table-cell...

C'est ce qui m'énerve le plus chez les puristes des specs : oui les CSS sont fabuleuses et omnipotentes, et non elles ne s'appliquent pas encore à la réalité actuelle parfois.

Admettons-le un jour !

Je parle des CSS d'aujourd'hui, qui fonctionnent sur les navigateurs d'aujourd'hui (dont IE fait partie).

Bien sûr qu'en théorie les CSS permettent de TOUT faire, mais en pratique tu ne peux pas dire aujourd'hui :

"Je vais résoudre ce problème en utilisant les CSS, tout en ayant un site qui s'affiche chez mes clients (qui utilisent IE)"

Quelle carence ? Laurent Denis a indiqué les mécanismes prévus pour ce type de mises en page dans le message qui précède le tien.

Les mécanismes CSS ne permettent pas de résoudre le problème initial :

- avoir des cellules adjacentes qui se suivent l'une l'autre (lorsque gauche s'allonge, droite s'allonge aussi et vice-versa) + un pied de page

- avoir une partie de largeur fixe (ex: gauche) et l'autre qui s'adapte au reste de la largeur d'écran

Le code de Laurent ne résoud manifestement pas ces problèmes, comme tout le monde l'a reconnu.

C'est vrai que c'est un vaste sujet.

Désolé d'avoir débordé.

Ma question était toute simple en fait, mais mal formulée : sémantiquement parlant, un élément structuré sous forme de DL est-il compris comme tel par les différents agents utilisateurs ou non ?

<modération>Ce fil a été créé à partir d'une parenthèse ouverte dans pb avec les boites verticales, sur exemple alsacreations</modération>

Ma formulation était humoristique : loin de moi l'idée de dire que "c'est mal de penser comme ça"

Venant de toi je n'en doute pas... mais c'est une impression globale qui a tendance à s'installer : on dit que c'est mal de penser comme ça pour trouver une justification à un problème actuellement non réalisable correctement en CSS.

Tu feras un tour de ma part sur le forum HTML de Hardware.com où tu trouveras bon nombre de puristes / ayatollah dont le discours va dans ce sens.

Je trouve ça dommage : les CSS ne sont pas parfaits ? soit. Acceptons-le, plutôt de dire qu'il faut penser différemment pour s'y adapter.

Bonne question : quel(s) outils, à part Google:definition, prennent-ils en compte les listes de définitions à l'heure actuelle ?

... Les navigateurs, j'espère !

Tu parles d'Outil dans toute sa dimension, c'est à dire l'utilisabilité des listes de déf dans une recherche spécifique sur un moteur, ce qui est effectivement un outil formidable sur Google, je trouve !

Moi je parle simplement de prise en compte globale : un élément définit par dfn ou dl est compris comme tel (définition) par les agents utilisateurs, ou alors cette structure n'est-elle pas prise en compte du tout (comme si on n'avait utilisé que des span par exemple) ?

Y a-t-il des tarifs "normalisés" en fonction du nb de page et des langages utilisés ou est-ce que chacun fait ce qu'il veut???

C'est très dépendant, il n'y a pas de règles précises.

Certains facturent en heures, en demi-journées, en jours

D'autres par forfaits (petit site, boutique en ligne, ....)

Certains facturent à la page, d'autres non, etc.

Personnellement, je n'ai jamais compris ce principe du tarif à la page.

Pour ma part, je prévois un tarif global en estimant le temps à passer, mais la plus grosse partie du prix (80%) est basée sur la feuille de style et le design, ensuite chaque page prend entre 5 et 30 minutes de temps donc que le site fasse 10 pages ou 50, ça revient presque au même pour moi alors qu'en se fixant un tarif à la page, ça devient vite exorbitant en effet !

Quelques liens vers des tarifs :

- http://www.ultra-fluide.com/savoir-faire/web/tarif.htm

- http://www.aquiweb.com/cle.htm

Le "pseudo-titre" en <dt> sera actuellement ignoré par les mécanismes qui extraient les titres d'une page afin d'en donner un sommaire :

- extentions pour les navigateurs graphiques destinés à faciliter la navigation

- lecteurs d'écrans en mode "navigation dans les titre"

- scripts générant des tables des matières

- etc.

Qu'il soit ignoré en tant que titre (Hn) me paraît tout à fait logique et normal.

Par contre, tu me confirmes (j'espère) qu'il reste pris en compte comme "titre" (ou "élément renforcé" si le terme de titre ne convient pas) des élements dd qui le définissent, ce qui est le but ?

Je veux dire : dt signifie bien "definition title" et qu'il est reconnu comme tel ?

ais cette fichue idée d'avoir des arrière-plan et des bordures de colonnes de même hauteur, quelque-soit le contenu !

Le problème est qu'il s'agit d'une "fichue" idée extrêmement courante.

Le fait de dire : "oui mais c'est mal de penser comme ça, il faut penser différemment" ne résoud pas le problème.

Au contraire, je trouve que c'est une façon de justifier une carence évidente des CSS.

Bien sûr cette carence s'explique aisément par le fait qu'un document n'est pas uniquement destiné à s'afficher sur un écran et que dans tous les autres cas le concept de hauteur n'a pas toujours lieu d'être.... mais en attendant le media screen doit-il être sacrifié ?

#centre {

margin: 0 130px;

border: 1px solid;

}

On en revient au problème de départ, non ?

Si "centre" s'allonge, les blocs de côté ne suivent pas le mouvement

Ex :

<div id="centre">

<p>centre</p>

<p>centre</p>

<p>centre</p>

<p>centre</p>

</div>

Loupilo : comme Laurent l'a dit, les specs du W3C sont elles-mêmes assez floues sur la définition des DL.

On peut y comprendre qu'ils peuvent structurer n'importe quel élément de la forme "titre / contenu se rapportant au titre"

Sémantiquement parlant, je trouve justement que c'est plus sensé que de strucutrer ce genre de choses avec des divs ou d'autres balises génériques sans sens.

Bien sûr, je ne dis pas qu'il s'agit de la meilleure méthode, mais c'est celle qui me paraît être la plus porteuse de sens.

MERCI

C'est ce que je viens de faire, et çà marche ! Mais si je veux une colonne centrale variable en fonction de la page, là çà ne va plus le faire, non ?

Non c'est justement le problème avec cette méthode en flottants : ils ne vont pas s'adapter automatiquement à la largeur de l'écran.

C'est pourquoi je les ai évités.... mais sache qu'il n'y aura PAS de solution miracle en CSS.

Explorer SP2, A t-il des particularités ?

Oui :

- beaucoup de webmaster devront revoir leurs sites au code propriétaire

- il est très lourd pour une màj : 300Mo (autant faire un IE7)

- Il y'a toute une liste (des centaines) de logiciels incompatibles avec SP2 :

- Microsoft Outlook 2000, 2002 et 2003

- Microsoft Office XP

- Symantec Norton Systemworks 2003 Professional Edition

- Yahoo Instant Messanger

- Nero Bruning ROM

- Photoshop Elements

- Pagemaker

- AutoCAD 2004

- JAWS 5.0

- Imesh, Kazaa, ...

- etc.

-> http://www.alsacreations.com/blog/index.ph...merci-microsoft

Merci pour ces explications.

Heu... le clavier de Sibelius a fourché et trahit son maître, qui voulait dire que display:none est pris en compte par les lecteurs d'écran et autres médias vocaux. Les navigateurs textes n'étant pas graphiques, ignorent tout CSS

Oui, maintenant que tu le dis, ça paraît plus que logique en effet.

J'ai vraiment des problèmes psychomoteurs avec mon clavier en ce moment.

Quel est donc le problème du display: none alors ?

avec en CSS :

.textcomment {

display:none;

}

Non justement : le display none pose des problèmes car il est pris en compte aussi par les navigateurs textes.

Il vaut mieux utiliser la propriété clip : http://www.blog-and-blues.org/weblog/2004/...iere-accessible