Et si Microsoft avait raison...

Bonjour à tous,
Laurent Denis, pour qui j'ai le plus grand respect, écrit dans ce post

a écrit :
Le 1% manquant est supposé permettre de gérer les bordures de 1px qui s'ajoutent à la largeur fixée pour chaque flottant. Mauvais calcul.

Comment faire des calculs avec des unités en % et d'autres en pixels, le calcul ne peut être que mauvais surtout s'y si on ajoute des em.
Ceci pour illustrer les problèmes que posent les boîtes dans la définition du W3C et comment c'est compliqué de faire du CSS-positionning pour tous ceux qui s'y essaient.
En effet, et je suis surpris que ça n'est frappé personne (pas la pelle ), le W3C nous oblige à créer les boîtes en partant du particulier pour aller au général. Cette manière de procéder qui va du contenu au canevas est compliquée et demande en permanence de compter en empilant le width + les paddings + les borders + les margins pour connaître la taille des boîtes, sans compter sur les unités qui viennent encore ajouter de l'inconsistance.
Dans cette optique, le width représente la taille du contenu et non la taille de la boîte.
Dans les professions qui mettent du texte en forme, on part complètement à l'inverse. On commence par tracer les boîtes sur la page (définition des gabarits) et on s'occupe du placement du contenu dans les boîtes, après. Du général vers le particulier.
Dans cette optique, le width représente la taille de la boîte et non la taille du contenu.
Ainsi, tout devient simple, une modification de la largeur de bordures ou de la marge de remplissage ne pose aucun problème de présentation, tout reste à l'intérieur des gabarits fixés au départ, le texte s'adapte.
Il devient facile de faire des sites en fixe mais surtout, c'est autrement plus facile de faire du fluide. La citation de Laurent n'aurait plus lieu d'être : colonne à 25% + principal à 75% et voilà, le reste suivra facilement.
Je ne soupçonne pas le W3C de sadisme particulier, il doit y avoir une histoire que je ne connais pas et peut être que les anciens l'expliqueront.

Qu'en pensez-vous, que peut-on faire ?

Ce post n'est pas un troll et s'il se comporte comme tel que les modos le ferment, je m'en remettrais, mais pas taper !

Mmh, l'important est-ce l'objet ou la boîte? Le contenu ou la forme? Prend-on un objet que l'on va mettre en forme ou bien part-on de la mise en forme pour placer un objet au milieu?


Pour ce qui est du problème des arrondis, il y a avant tout de mauvais programmeurs. Sans aller jusqu'aux normes Posix ou IEEE (me rappelle plus) de calcul, de notation des nombres qui sont en vigueur en calcul scientifique, c'est quand même pas compliqué que tout le monde arrondisse 10,500000001 à 11 et pas 10 Il restera toujours des problèmes (le total fait 99 pixels mais il en faut 100, à quel élément colle-t'on le pixel manquant?) mais là c'est limite

papyjo a écrit :
Bonjour à tous,
Laurent Denis, pour qui j'ai le plus grand respect

Est-ce bien raisonnable ?

Plus sérieusement, le côté déroutant du modèle de boîte CSS a souvent été souligné, y compris par de vieux habitués comme Paul-Peter Koch (en anglais)

Mais, je relèverais deux choses:

- le modèle de boîte Microsoft impose certaines limitations, comme l'illustre un sujet récent dans ce forum : image avec cadre noir + liseret blanc. Faire apparaître un double contour en jouant sur les propriétés border et padding d'un élément img est relativement intuitif... Mais impossible dans le modèle Microsoft.

- D'autre part, ce modèle Microsoft s'avère lui-même tout aussi déroutant dans d'autres cas de figures. Par exemple, avec le code suivant, qui veut simplement disposer côte à côte deux blocs en ligne dimensionnés dans un paragraphe lui-même dimensionné :

p {
background-color: yellow;
padding: 0 20px;
width: 400px;
}
p span {
display: inline-block;
width: 200px;
}
<p>
   <span>foo</span>
   <span>foo</span>
</p>

Hum... Mon paragraphe a une largeur de contenu de 400px. Mes deux <span> doivent être de même largeur. Ils font donc chacun 200px. : simple, n'est-ce pas ?

Avec le box-modèle Microsoft, ce raisonnement devient : Mon paragraphe a une largeur de contenu de... 400px moins deux fois 20px de padding, donc 360px. Mes deux <span> doivent être de même largeur. Ils font donc chacun 180px. : est-ce bien intuitif ?

(J'ai pris l'exemple d'un display:inline-block, bien qu'il ne soit pas implémenté dans Firefox, car avec des flottants, l'exemple serait faussé par des bugs d'IE sans rapport avec la question)

papyjo a écrit :

Dans les professions qui mettent du texte en forme, on part complètement à l'inverse. On commence par tracer les boîtes sur la page (définition des gabarits) et on s'occupe du placement du contenu dans les boîtes, après. Du général vers le particulier.
Dans cette optique, le width représente la taille de la boîte et non la taille du contenu.

le problème de fond est peut-être là : l'approche "traditionnel" de la mise en page dans les métiers du design est très souvent problématique lorsqu'il s'agit de mise en page Web, bien au-delà de ce problème précis du box-model (elle a produit, par exemple, ces catastrophiques découpages de layout réalisés dans photoshop et plaqués sur les écrans à l'aide de cellules de tableaux, ce qu'on reconduit hélas aujourd'hui à coup de <div>).

Le media screen est un media au rendu nécessairement fluide et variable selon le client. Cette question des deux box-models me semble illustrer aussi deux approches du media screen:
- l'approche CSS, qui favorise la fluidité et l'adaptation aux paramètres propres au client
- une approche plus figée qui devient du même coup beaucoup moins "interopérable". Moins réaliste, en fait.

Finalement, cette "complexité" du box-model CSS est un des prix à payer pour un peu plus d'interopérabilité du rendu

<edit>Mon exemple ci-dessus me fait également penser que la comparaison entre les deux modèles de boîte est très souvent faussé par l'implémentation aberrante d'autres parties de CSS2 par IE Windows : le box-model microsoft s'avèrerait très problématique, je crois, s'il n'était pas mis en oeuvre avec, par exemple, le mode de calcul des largeurs en % et des padding en % pifométrique d'IE - en anglais). Plus on élucide le fonctionnement de Trident -en anglais - , le moteur de rendu d'IEWin, et plus on se dit qu'un affichage réussi dans IE relève en fait d'une formidable dose d'acrobatie et d'imprévisible...
Modifié par Laurent Denis (10 Aug 2005 - 05:44)