Display vs. float

J'ai vu quelque sujets sur les forums, sites, ici et ailleurs, qui traite du choix display et float mais souvent appliqué à un menu.
Si pour un menu, je pense que le display:inline est totalement adapté, je me suis dit :
Pourquoi ne pas se servir de ca pour le contenu global d'un site.
Car après tout, le float est puissant mais retire automatique l'élément du flux, ce que ne fait pas le display.
Du coup, par ex, imaginons que j'ai (attention, c'est ptet pas le meilleur ex vu sa simplicité):
<div id="contenu"> <div id="sidebar>

Pour les avoir côte à côte, on va faire un float:left et ca sera fait.
mais pourquoi on ne ferait pas un
<ul><li><div id="contenu"> </li>
<li><div id="sidebar></li>
</ul>
avec de ce fait un ul li{display:inline}

le résultat sera le même à la différence que dans le 2e cas, on reste dans le flux.

Je me suis donc posé cette question et j'expose cette théorie ici pour avoir les retours des spécialistes de l'intégration.

Bonjour,
une liste non ordonnée (UL) n'est clairement pas appropriée dans ce cas de figure.
Un UL caractérise une liste d'éléments classés de manière non ordonnés et non de grandes catégories de contenus.
Le display:inline n'est pas adapté car il ne permet pas de dimensionner un bloc (entre autres).


3 solutions:
> Mettre les 2 div en flottant + des clearfix : http://nicolasgallagher.com/micro-clearfix-hack/
> En display:table-cell (mais non implémenté dans IE7-) Pour IE7- :
http://webcache.googleusercontent.com/search?q=cache:sAjpPbVmeiIJ:tanalin.com/en/projects/display-table-htc/&hl=fr&gl=fr&prmd=imvns&strip=1
> Display:inline-block (display:inline; zoom:1 pour IE7- qui ne comprends pas la valeur inline-block).

La méthode à base de positionnement absolu est à éviter.

Voir les tutos d'Alsa pour les détails.
Modifié par Hermann (02 Jul 2012 - 00:06)

Lu

donc ma théorie d'un soir tombe vite à l'eau. En même temps, je m'en doutais avant même de poster parce que sinon, c'est ce qu'on utiliserait depuis bien longtemps

Pour les solutions, pas de problème, c'est ce que j'applique déjà

Hermann
je ne connaissais pas cette alternative de table cell pour ie7 a l aide d un behavior

esr ce vraiment efficace?
Modifié par phpCbien (13 Jul 2012 - 12:55)

phpCbien a écrit :
Hermann
je ne connaissais pas cette alternative de table cell pour ie7 a l aide d un behavior

esr ce vraiment efficace?

Pour l'avoir testé rapidement, les mauvaise surprises peuvent être nombreuses si tu n'es pas habitué à rentrer dans cette logique de structuration sachant que le fichier HTC génére des table pour IE7-, ce qui pourrait au passage être géré via des commentaires conditionnels si le table-cell est utilisé ponctuellement. Bref c'est assez casse gueule au premier abord.
Après à toi de voir, je n'ai pas beaucoup de recul dessus. Tu peux demander à Raphael ce qu'il en pense (c'est lui qui en avait fait la promo l'automne dernier).
Modifié par Hermann (16 Jul 2012 - 12:15)

Oui et il en parle dans son bouquin

Par contre, j'ai converti récemment un header contenant :

-logo
-slogan
-pub
-formulaire

Tous cote à cote et devant être centrés les uns des autres à l'aide d'une classe

.align{
display:inline-block
vertical-align:middle
}

Et pour ie7 à l'aide d'une conditionnelle sur l'élément body

.ie7 .align{
display:inline;
zoom:1;
}

Et ben comment dire.... C'est 100 fois mieux et plus propre !
De plus ça évite des margin-top ou des padding-top supplémentaires, et bien d'autres.

Concernant table css, c'est vrai qu'il vaut mieux l'utiliser avec modération !

a écrit :
ce qui pourrait au passage être géré via des commentaires conditionnels si le table-cell est utilisé ponctuellement

Merci de partager ton expérience.

Qu'en pensez vous ? Ce sujet intéresse certains ? Pour ma part, on devrait se passer des flottements sauf quand cela s’avère nécessaire(le cas image et texte à droite-> (et encore car ça vaut le cout si on décide de laisser le texte déborder sous l'image pour remplir le flux).

Sinon, NON
Modifié par phpCbien (16 Jul 2012 - 19:08)

phpCbien a écrit :

Qu'en pensez vous ? Ce sujet intéresse certains ? Pour ma part, on devrait se passer des flottements sauf quand cela s’avère nécessaire(le cas image et texte à droite-&gt; (et encore car ça vaut le cout si on décide de laisser le texte déborder sous l'image pour remplir le flux).

en 2006 , j'ai commencé a parler de ce display:inline;+zoom; pour du centrage vertical, (arriver de FF1 + display:table; enfin utilisable) cela à était pris pour de la bidouille, complétement incompris ou confondu avec les tableaux que tout le monde chassait à l'époque .
Incompréhension principalement du au fait que ça jouait sur le "haslayout" et que cette bête était difficile à appréhender sous IE 6 et inf , ainsi que sous IE7 par la suite. Dans les autres navigateur, on parle de contexte de formatage (layout tout court ).
En fait , il faut rester cohérent avec le reste de la feuille de style en pensant "contexte de formatage" et haslayout, pour un comportement similaire proche des deux coté.
J'imagine que "border.htc", ne gere aucun ou trés peu des multiples bug ou défaut CSS de ces vieux IE et a tendance a amplifier ces incohérences ou différences.

Ce que j'en pense , c'est que cette méthode de centrage (inline-block/inline-zoom ) est applicable depuis IE5 jusqu'a IE7 et qu'il n'y aucune raison de la bouder, sauf à faire gaffe a ce qu'elle implique sur le "haslayout" or not chez ces vieux IE.

Bon aujourd'hui on ne code plus pour IE6/7, on adapte éventuellement ce qui est plus léger dans ce sens et le "haslayout" soudain , risque moins de faire "sauter" la page .

Cordialement