ben tout est dans le titre...
 

 
avec  
 

 
provoque un retour à la ligne après chaque formulaire...
 
Une solution sans passer par une table ?  

 
Merci.  

 
C'était moins dur que tes précédents défis

 
En fait, j'avais pensé au display: inline; mais le problème c'est que j'avais eu un problème de disparition de div avec Moz. je crois, ya un moment déjà...
 
   
 
Pour les défits, je vais réfléchir à un sujet les regroupants. Le but serait de créer un sujet avec les choses irréalisables en XHTML 1.1/CSS EN RESPECTANT les normes mais EGALEMENT la sémantique.
 
En effet, un simple respect des normes permet de faire tout ce qu'on pouvait faire avant, il n'y a pas de problème avec ça.
C'est juste la sémantique et surtout "l'empêchement" d'utiliser des tables qui peut provoquer certains problèmes.

Théoriquement uniquement des éléments inline. Mais en pratique tu fait ce que tu veux, tant que ça marche.

il n'y a pas seulement des pouilleux .. il y a aussi des gens qui ont des délais de réalisations a respecter et a qui on accorde pas de temps de veille active dans le domaine.    
alors moderes tes propos quand même Mr Shot  

 
Non tu déforme ce que j'ai dit. J'ai pas dit ça de manière générale. C'est uniquement dans le cas des CSS que l'on peut dire : "en pratique tu fait ce que tu veux, tant que ça marche".
 
Une feuille de style pas sémantiquement correcte n'apporte aucun problème. Une page HTML non sémantique oui.
 
Maitenant je vais faire attention de reformuler le contexte à chaque fois pasque y en a des qui suivent pas  

LoooLLL
 
la balise b n'a aucun sens ! alors oui ce que tu viens de faire est tout à fait correcte . Ou du moins ça n'a aucun sens. M'enfin c'est pas grave puisque ça en avait pas au début.

certaine balises ont un sens. Mais pas la balise b

Houla, y confusion sur le rôle des CSS là!
 
On ne peut pas parler de sémantique pour les CSS, ils n'ont pas ce rôle, uniquement de syntaxe.
 
Quand vous dites qu'un CSS n'est pas valide parce qu'il met des éléments bloc dans des élément inline, c'est faux. Le sens des élément est préservé, c'est uniquement leur ASPECT qui est modifié. Ainsi, la solution de fastclemmy est tout à fait valide, tant syntaxiquement que sémantiquement car elle ne touche pas au sens du document ni à sa syntaxe.

 
Hum oui mais il faut avouer que la présentation des éléments produis du sens. On peu pas vraiment dire que les CSS n'ont pas sémantique.
 
Je reformule : "On peut faire ce qu'on veut dans les CSS tant que le sens de la présentation est preservé".

Ben c'est pas Valide tout simplement parce que c'est interdit, non?
Il est clairement spécifié que :
- un bloc peut contenir : des inline et/ou des blocs
- un inline ne peut contenir que des inline
 
De plus, il me semble bien que le Validateur n'accepte pas de blocs inclus dans des inline   (en tout cas pour les forms il râle)

 
Il me semble qu'il ne faut pas s'ennuyer avec de tels considérations. La sémantique doit se trouver dans le fichier HTML. Le fichier CSS est là pour appliquer des effets de présentations. La sémantique du fichier CSS par rapport au fichier HTML importe peu. L'important c'est que l'effet de voulu soit appliquée correctement.
 
Bref, je ne crois qu'on peut clairement se lâcher dans les fichiers CSS. Le seul but de ces fichiers c'est de créer des effets de présentation. Pas de créer du sens. Quoique la présentation aide à comprendre le sens. C'est ça qui est important, c'est que la présentation soit en équation avec le sens des balises, et pas garantir une pseudo sémantique entre HTML et CSS dont tout le monde se fiche royalement.

Oui mais le "tant que ça marche" n'est pas dans les specs, donc le comportement attendu n'est pas prévisible. On perd donc l'intérêt des normes.
 
Il y a une propriété pour ça, c'est "display: inline-block" mais ce n'est pas implémenté par Moz et de manière complètement foireuse par IE (à vérifier pour Opéra)

Bon, vous êtes bien gentil là... Mais en ce qui me concerne, j'ai dans une interface d'admin 3 boutons côte à côte qui renvoient chacun vers 3 pages de traitements différentes.  
 
Ce sont des choses qui peuvent arriver aussi.
 
Donc, j'ai besoin de 3 formulaires côte à côte dans ce cas (rare) et précis.
 
Que proposez-vous donc ? La solution qui m'a été donné fonctionne parfaitement en tout cas, mais si vous dites qu'elle n'est pas sémantiquement correcte, je suis ouvertà toute autre proposition...  

Mais sinon tu mets tes <form> dans des <div> et les <div> en flottant... Ca marche pas ça ?

 
En effet, c'est tout con et ça marche. Je vais donc faire ça.  

 
Et dire qu'il nous reprochait d'être dur avec les touristes ces derniers temps...  

 
   T'inquiète, je suis pas susceptible de toutes manières (enfin pas ce soir en tous cas   )
 

Oui bon c'est vrai que pour un formulaire, un tableau c'est pas grave. Surtout si que les admins qui les voient.

 
Les interdictions que tu cites sont des interdictions au niveau de la syntaxe HTML, pas CSS. Dans les CSS, tu as des interdictions d'un autre style, comme le fait qu'un élément inline ne peut pas avoir une hauteur ou une largeur, ce sont des considération purement logique sur le bloc, mais pas sur ses enfants (mis à part les sélecteurs, mais ils n'imposent pas de restriction de ce type), contrairement au HTML qui s'occupe de l'ensemble de l'arborescence.

A la rigueur, que ce soit au niveau HTML ou CSS, c'est interdit quand-même, non ?

Mais non tu fait ce que tu veux avec les CSS. Tu peux même te les mettre dans le cul que personne viendra râler que c'est interdit.

mais c'est pas semantiquement correct

non, les deux ont été conçu pour être indépendants. Ce qui s'applique à l'un ne s'applique pas à l'autre.

C'est profond, ce que vous me dites là !