[CSS/float] un truc qui marche sur IE mais pas sur Firefox

Le
Patrick 'Zener' Brunet
Bonjour.

Je me heurte à un problème en faisant ce pourquoi CSS est normalement conçu:
faire une nouvelle charte graphique pour un site sans adapter le contenu
HTML.

En l'occurence, la structure de ce contenu est imposée, et correspond à un
ordre de lecture logique en mode pur texte, à l'attention des lecteurs
vocaux pour déficients visuels.

J'ai fait une maquette simplifiée (un seul fichier HTML):
http://cjoint.com/?iExIMk2Cam (valide 21 jours).

Donc le but est d'empiler deux menus (en cyan et vert), de manière fiable
dans un design élastique (donc pas de position absolue),
tout en conservant ensuite une logique de placement naturelle dans le reste
du contenu (partie jaune).

Ce contenu est formé de plusieurs P, et en premier il y a une image (ici un
div rouge) qui doit être float'é.

Le problème, c'est que le clear:left qui permet de d'empiler le menu vert
sous le cyan a une portée inattendue:
- il va aussi repousser le rouge, sans pourtant impacter les P qui le
suivent et qui remontent jusqu'en haut!!!

Ceci sur Firefox 1.5 et 2.0, alors que IE 5.5 et 6.0 se comportent de la
manière intuitive. Je n'ai pas encore étendu les tests

A vrai dire, il m'importe peu que ce truc soit éventuellement (?) conforme à
la norme, c'est contre-intuitif et très .hiant.

Est-ce que vous connaissez ce problème et son workaround ?

Merci.

--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.eu/ContactMe
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
SAM
Le #22069281
Patrick 'Zener' Brunet a écrit :
Bonjour.

Je me heurte à un problème en faisant ce pourquoi CSS est normalement conçu:
faire une nouvelle charte graphique pour un site sans adapter le contenu
HTML.

En l'occurence, la structure de ce contenu est imposée, et correspond à un
ordre de lecture logique en mode pur texte, à l'attention des lecteurs
vocaux pour déficients visuels.

J'ai fait une maquette simplifiée (un seul fichier HTML):
http://cjoint.com/?iExIMk2Cam (valide 21 jours).



Mon Safari fait comme Fx (IE nous blague encore sur ce coup !)

OK pour FX.3 et Safari.3 avec :


#menu { float: left; }


<div id="outter">
<div id="menu">
<div id="menu1">Menu 1</div>
<div id="menu2">Menu 2</div>
</div><!-- menu -->
<div id="inner">
<div id="innerfloat">Inner float</div>
<p>Tagada</p>
(etc ...)
</div><!-- outer -->



ne reste qu'à régler les détails pour IE


--
sm
SAM
Le #22069271
SAM a écrit :

ne reste qu'à régler les détails pour IE




#ender
{
clear: both;
margin-top: -1em;
}
Patrick 'Zener' Brunet
Le #22069261
Bonjour SAM.

"SAM" de news: 48b9cab4$0$886$
Patrick 'Zener' Brunet a écrit :
>
> Je me heurte à un problème en faisant ce pourquoi CSS est
> normalement conçu: faire une nouvelle charte graphique pour
> un site sans adapter le contenu HTML.
>



Je dis bien: sans avoir à modifier le contenu HTML.

> En l'occurence, la structure de ce contenu est imposée, et
> correspond à un ordre de lecture logique en mode pur texte,
> à l'attention des lecteurs vocaux pour déficients visuels.
>



Donc ça ça impose l'ordre des blocs fonctionnels, mais il y a une seconde
raison pour ne pas même rajouter de conteneurs, voir plus bas.

> J'ai fait une maquette simplifiée (un seul fichier HTML):
> http://cjoint.com/?iExIMk2Cam (valide 21 jours).

Mon Safari fait comme Fx (IE nous blague encore sur ce coup !)



Certes, je voyais mal IE servir de référence :o)


OK pour FX.3 et Safari.3 avec :


#menu { float: left; }


<div id="outter">
<div id="menu">
<div id="menu1">Menu 1</div>
<div id="menu2">Menu 2</div>
</div><!-- menu -->
<div id="inner">
<div id="innerfloat">Inner float</div>
<p>Tagada</p>
(etc ...)
</div><!-- outer -->




Certes, mais pour ça il faut "deviner" à l'avance qu'un jour on aura besoin
de float'er ensemble les deux menus, et prévoir un sous-conteneur pour ce
cas. Déjà le DIV "inner" ne devrait pas exister: c'est un pur emballage du
"contenu hors navigation", qui fait double emploi avec le principe
d'extraction des éléments de navigation.

Dans une autre charte graphique (qui est celle de mon site perso), seul le
menu1 est float'é, et le menu2 (sommaire de la page) apparaît comme une
section h2+contenu supplémentaire en tête de "inner float".

Je pourrais aussi envisager une autre charte où menu1 serait float'é à
gauche et menu2 à droite, le "inner float" coulant librement au milieu, tout
ça avec le même contenu (c'est le but de CSS, non ?).

Le pauvre DIV "menu" va se retrouver le Q entre deux chaises là...

Bref, à l'époque des Joomla et autres Yoplaboom dans lesquels on professe le
principe de "modules" fonctionnels qui sont simplement enfilés pour former
le flot, permettant ensuite de les disposer librement par CSS indépendante,
j'ai soudain un doute:
- Est-ce que ça nous condamne à tout faire par position absolue (donc aussi
avec des dimensions estimées à partir du strlen du contenu) ?

J'ai repéré une page bien pratique:
http://tinyurl.com/5wxvfb pointant vers:
http://ddata.over-blog.com/xxxyyy/0/38/68/97/CSS-mise-en-page/demo-float.htm
l

En jouant avec, bien que je ne puisse pas reproduire exactement le même cas,
il semble bien que le principe soit que tout ce qui n'est pas clear'é
remonte le plus haut possible dans son container.
Comme le font mes P...
Mais pas un float apparemment :-@

Si c'est vraiment nécessaire, je devrai rajouter une nouvelle techno dans
laquelle tout le layout est appelé, composant par composant, par un
maître-script PHP fourni dans le répertoire de la charte graphique.
Ca me permettrait effectivement d'injecter des conteneurs sur mesure pour
"aider" la CSS. Mais ça constituerait aussi un constat d'échec pour la
philosophie de CSS...

Bref je dois trouver un workaround en pur CSS.
Par exemple un truc pour empiler mes deux menus:
- sans utiliser de clear pour le second,
- qui soit fiable en design élastique (ça ne doit pas se juxtaposer quand la
page est plus large),
- sans positionner le "inner" en absolu, car c'est lui qui dimensionne le
"outter" verticalement, et la hauteur des menus est imprévisible.

Pas simple, pourtant ça avait l'air si basique...

Merci pour ton soutien :)

--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.eu/ContactMe
Patrick 'Zener' Brunet
Le #22069251
Hello All.

"Patrick 'Zener' Brunet" le message de news: g9cfvt$dtd$

Je me heurte à un problème en faisant ce pourquoi CSS est
normalement conçu: faire une nouvelle charte graphique pour
un site sans adapter le contenu HTML.




J'ai obtenu encore plus tordu (et correct au sens humain sur IE):
- là le DIV est à sa place, mais ça repousse son contenu hors de son propre
corps :o)

J'ai fait une autre maquette simplifiée (un seul fichier HTML):
http://cjoint.com/?iFjgwsb55P (valide 21 jours).

Dites, vous êtes sûr que c'est normal ça ?

--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.eu/ContactMe
mcc
Le #22069231
Le Sun, 31 Aug 2008 00:01:38 +0200, Patrick 'Zener' Brunet a écrit :

Bonjour.


Hello
Donc le but est d'empiler deux menus (en cyan et vert), de manière
fiable dans un design élastique (donc pas de position absolue), tout en
conservant ensuite une logique de placement naturelle dans le reste du
contenu (partie jaune).

Ce contenu est formé de plusieurs P, et en premier il y a une image (ici
un div rouge) qui doit être float'é.



Un essai avec :

#inner
{
/*clear: none; */
background-color: yellow;
margin-left : 40ex ;/* IMPORTANT largeur des menus 1 et 2*/
}
et

#innerfloat
{
background-color: red;

position : relative ; /* relative au conteneur jaune */
top : 1ex ;

/* OU alors
display : in-line ;*/

width: 15ex;
height: 15ex;
margin: 2ex;
}

remplirait-il les conditions ?



--
mcc
Patrick 'Zener' Brunet
Le #22069221
Bonsoir.

"mcc"
Le Sun, 31 Aug 2008 00:01:38 +0200, Patrick 'Zener' Brunet a écrit :

> Donc le but est d'empiler deux menus (en cyan et vert), de manière
> fiable dans un design élastique (donc pas de position absolue), tout en
> conservant ensuite une logique de placement naturelle dans le reste du
> contenu (partie jaune).
>
> Ce contenu est formé de plusieurs P, et en premier il y a une image
> (ici un div rouge) qui doit être float'é.
>
Un essai avec :

#inner
{
/*clear: none; */
background-color: yellow;
margin-left : 40ex ;/* IMPORTANT largeur des menus 1 et 2*/
}
et

#innerfloat
{
background-color: red;

position : relative ; /* relative au conteneur jaune */
top : 1ex ;

/* OU alors
display : in-line ;*/

width: 15ex;
height: 15ex;
margin: 2ex;
}

remplirait-il les conditions ?




Merci. Pas mal essayé...

Donc avec la première solution:
- le "innerfloat" se place là où on veut le mettre,
- par contre hélas les P ne coulent pas autour comme avec un float.

Avec display: inline:
- là les dimensions sont ignorées, c'est pas terrible
(pour une image sans légende peut-être, mais bofff).

J'ai essayé avec display: inline-block (sans position):
- là les dimensions sont prises en compte,
- mais les P restent en dessous, même en leur appliquant aussi cette option.
- ou alors il faudra estimer le nombre de P à décaler pour simuler un float,
bêêêrk !

De plus, dans la mesure où la partie spéciale du layout concerne les deux
menus, j'aimerais bien ne pas propager cette contrainte de design dans tout
le contenu du "inner" et pour toutes les pages.

Je pense que la seule solution de contournement qui soit raisonnablement
pratiquable est de trouver un moyen de remplacer le clear:left du "menu2".

Une position relative pourrait suffire pour ça, si je pouvais seulement
prévoir la hauteur du "menu1", mais elle dépend de son contenu qui varie
dynamiquement (expansion/condensation de noeuds).

Si je pouvais comprendre par quelle interprétation IE arrive à produire le
bon résultat, je pourrais essayer de la recréer en CSS valide...
A priori c'est pas une histoire de "HasLayout": j'ai tenté de rajouter du
border à tous les DIV et le "innerfloat" reste en place (même si les P vont
se cacher)...

Que c'est nuuuuuuuul ! :-(

--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.eu/ContactMe
SAM
Le #22069111
Patrick 'Zener' Brunet a écrit :

Donc avec la première solution:
- le "innerfloat" se place là où on veut le mettre,
- par contre hélas les P ne coulent pas autour comme avec un float.

Avec display: inline:
- là les dimensions sont ignorées, c'est pas terrible
(pour une image sans légende peut-être, mais bofff).

J'ai essayé avec display: inline-block (sans position):
- là les dimensions sont prises en compte,
- mais les P restent en dessous, même en leur appliquant aussi cette option.



Bon ! outre que Fx est d'accord avec Safari,
la soluce non testée IE, mais déjà donnée au cours de l'année, est :
overflow: auto;
pour le div 'inner'

Démos :
(code-source du cadre bas)

Si cet overflow gène IE (normalement : non) :
- le mettre à hidden
ou
- utiliser les commentaires conditionnels de M$

--
sm
Patrick 'Zener' Brunet
Le #22069041
Bonsoir.

"SAM" de news: 48bc6fe6$0$863$
Patrick 'Zener' Brunet a écrit :
> [...]

Bon ! outre que Fx est d'accord avec Safari,



Pour citer Maître Coluche:
"C'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont forcément
raison".
Non mais vous avez-vu de quoi ça a l'air ce truc ? C'est inepte...

la soluce non testée IE, mais déjà donnée au cours
de l'année, est :
overflow: auto;
pour le div 'inner'

Démos :
(code-source du cadre bas)




Tu y vas fort là !
En général, est-ce que tu es capable de prévoir la hauteur de tes menus et
surtout celle du contenu de la page ?

En fait, si on connaisait les dimensions des blocs, il y aurit encore plus
simple:
- on fait tout en position:absolute et plus de problème...

Alors en fait j'ai fait l'effort d'essayer en vraie grandeur ta première
solution (avec le DIV englobant les deux menus).

Remarque 1:
======= Pour les raisons que j'ai évoquées plus haut, ça nécessite a priori
d'injecter du contenu dépendant de la charte graphique.
De toute manière, pour faire des coins "Nifty Corners" ou autres, on est pas
mal obligés, a fortiori du fait du mauvais support des sélecteurs :before et
:after et compagnie...

Donc j'avais déjà sauté le pas du maître-script PHP fourni par la charte
graphique et qui assemble les blocs principaux en se réservant le droit d'y
insérer des containers, mais bon ce n'est tout de même pas une recompilation
ligne à ligne...

Remarque 2:
======= En fait cette histoire de container pose d'autres problèmes. J'avais déjà
évoqué les chartes alternatives mais ce point est couvert par la remarque 1.

Là je pense plutôt à des éléments qui n'apparaissent pas sur la maquette
mais qui vont aussi se retrouver piégés dans ce container parce que dans le
flot logique, ils viennent entre le menu1 (menu principal du site) et le
menu2 (sommaire de la page).
Il s'agit notamment du titre h1 de la page, mais il peut aussi y avoir des
choses telles que les FriendLogos de la page d'accueil de mon site perso...

Pour bien comprendre pourquoi ils doivent être là, lire la page sans CSS (en
s'imaginant qu'on en découvre la logique linéairement du fait d'une
transcription vocale)...

S'ils sont coincés dans le float:left, ça devient graphiquement
impraticable.

Ma solution:
======= J'ai refait une maquette plus élaborée qui met ces détails en évidence:
http://cjoint.com/?jctCAKOdpV (valide 21 jours)

Et donc elle montre l'astuce plus puissante que j'ai trouvée:
En fait je prévois d'insérer (grâce au maître-script) un DIV vide qui va se
retrouver dans le flot au-dessus du second menu (vert) et qui se fait
oublier...
Ensuite si j'en ai besoin dans une page, dans la variante CSS de cette page
je le dimensionne et je le float'e en transparent pour réserver la place
dans le texte, et il ne me reste plus qu'à positionner le faux-float
"innerfloat" par dessus en absolu. Visuellement l'illusion est parfaite.

Dans l'exemple il est float'é à gauche, mais à droite c'est tout aussi
facile.
Et l'ensemble reste totalement élastique et sans contrainte de hauteurs
fixes (normalement les menus sont dimensionnés par leur contenu).

Seuls défauts résiduels:
==============
1) Si ce float est plus haut que le menu principal (très peu probable),
alors (dans le cas en plus où il est à gauche) c'est lui qui chasse un peu
le second menu par le bas.
=> Si les couleurs sont choisies adroitement, c'est très supportable.

2) Comme vous le voyez, IE nous fait une petite crasse avec la référence de
la coordonnée left du "innerfloat", il faut donc une règle de correction,
mais ça on a l'habitude :-)

Si cet overflow gène IE (normalement : non) :
- le mettre à hidden
ou
- utiliser les commentaires conditionnels de M$




En fait j'ai trouvé beaucoup plus puissant: rajouter des valeurs d'attribut
class au BODY lors de la génération de la page en PHP, ce qui permet de
séléctionner des règles CSS spécifiques...

Ben voilà, si ça peut vous dépanner...

--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.eu/ContactMe
Pierre Goiffon
Le #22068951
Patrick 'Zener' Brunet wrote:
Si c'est vraiment nécessaire, je devrai rajouter une nouvelle techno dans
laquelle tout le layout est appelé, composant par composant, par un
maître-script PHP fourni dans le répertoire de la charte graphique.
Ca me permettrait effectivement d'injecter des conteneurs sur mesure pour
"aider" la CSS. Mais ça constituerait aussi un constat d'échec pour la
philosophie de CSS...



L'opposition entre la vue "page" de CSS et les modules indépendants
constituant une page de la majorité des cms ou applications en ligne est
une vraie épine à traiter pour les développeurs. Conserver une logique
qui va bien au "niveau page" n'est vraiment pas toujours simple...

Mais il existe déjà des moteurs de templates qui permettent de gérer
cette contradiction. C'est le cas de Wicket par exemple, où une page est
faite de différents composants, chacun étant dépendants, et le moteur
reconstituant le tout à la fin. On peut par exemple avoir une quinzaine
de form avec chacun leurs propriétés (contrôle de saisie, ...) alors que
ce qui sera renvoyé au client ne contiendra bien qu'un form HTML.
Patrick 'Zener' Brunet
Le #22068641
Bonsoir.

"Pierre Goiffon" 48be8aa6$0$24303$
Patrick 'Zener' Brunet wrote:
> Si c'est vraiment nécessaire, je devrai rajouter une nouvelle
> techno dans laquelle tout le layout est appelé, composant par
> composant, par un maître-script PHP fourni dans le répertoire
> de la charte graphique.
> Ca me permettrait effectivement d'injecter des conteneurs sur
> mesure pour "aider" la CSS. Mais ça constituerait aussi un
> constat d'échec pour la philosophie de CSS...


L'opposition entre la vue "page" de CSS et les modules indépendants
constituant une page de la majorité des cms ou applications en ligne est
une vraie épine à traiter pour les développeurs. Conserver une logique
qui va bien au "niveau page" n'est vraiment pas toujours simple...




Il n'y a pas si longtemps qu'on développait des versions du sites pour
chacun des navigateurs connus, avec un effort correspondant à sa part de
marché :-)
CSS était destiné à nous sortir de là...

Amha ce sont surtout les bugs ou principes spartiates qui bloquent toute
chance de le faire proprement...
Si les position: et autre float:/clear: marchaient à 100%, on pourrait le
faire.
Je m'y suis forcé pour mon site perso, et je l'ai testé aussi bien avec Lynx
qu'avec Opera en commande vocale et sans les mains (mais en anglais)...

Mais il existe déjà des moteurs de templates qui permettent de gérer
cette contradiction. C'est le cas de Wicket par exemple, où une page est
faite de différents composants, chacun étant dépendants, et le moteur
reconstituant le tout à la fin. On peut par exemple avoir une quinzaine
de form avec chacun leurs propriétés (contrôle de saisie, ...) alors que
ce qui sera renvoyé au client ne contiendra bien qu'un form HTML.



Certes, mais même si le serveur est capable de pondre une page sur mesure
selon le contexte du visiteur, ça nécessite déjà de détecter complètement ce
contexte, et de préférence une seule fois au début, pas à chaque page...

Avec les navigateurs qui se font passer pour d'autres, les recommandations
de prudence consistant à tout cacher de sa configuration, et même les robots
qui viennent buriner le serveur en essayant de rentrer comme des humains,
c'est pas triste :-)

Franchement je trouve heureux que le Web ne soit qu'une corvée nécessaire
mais annexe pour mon activité, parce que même par rapport à du bon logiciel
bien complexe, c'est une source inépuisable de crises de nerfs...

--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.eu/ContactMe
Publicité
Poster une réponse
Anonyme