Hallo Thomas,
Ich wollte eigentlich genau darauf nicht eingehen, da ich nicht deine
Ansicht teile was die "unfähigkeit" des Modells angeht.
dann möchte ich dir mal ein paar (das ließe sich fast beliebig fortsetzen) kurze Beispiele dafür geben, warum ich das derzeitige Modell für 'schlecht' halte.
Grundlage für alle Beispiele ist, dass html und body jeweils eine Höhe und Breite von 100% haben (da ansonsten prozentuale Höhenangaben nicht relevant sind, was ich übrigens auch schon für falsch halte, denn 'logisch' wäre, wenn sie auf das Elternelement bezogen würden, was nach neuerer Denke das html-Element wäre, was ja letztendlich das Fenster repräsentiert und was sonst sollte 100% sein), und Margin und Padding gleich null! Der MSIE6 ist per Doctype-Angabe auf den 'Standard-compliants Mode' gesetzt.
1. Beispiel:
<div id="d1" style="height:100%;width:100%;margin:0px;padding:0px;border:none;background-color:#ccc">
Inhalt von DIV 1
</div>
Die Hintergrundfarbe ist nur zur besseren Erkennbarkeit. So weit ist noch alles OK. Alle neueren Browser stellen das DIV 'fensterfüllend' dar.
Wenn wir unserem Div nun allerdings an allen vier Seiten einen Margin von je 20px verpassen wollen, fangen die Probleme schon an.
<div id="d1" style="height:100%;width:100%;margin:20px;padding:0px;border:none;background-color:#ccc">
Inhalt von DIV 1
</div>
Der NS7 und OP6 zeigen beide nur den top- und left-margin an. OP7 immerhin zusätzlich auch noch den bottom-margin, und der MSIE6 zwar nicht den bottom-margin, dafür aber den right-margin (das sind meine 4 Test-Browser + NS4 - alle auf Win32-Plattform).
Und was haben wir jetzt (nach dem W3C Box Model)? Ein DIV-Element, welches eine Gesamt-Größe von 100%(Fenstergröße)+je 2*20px hat. Bei Padding und Border verhält es sich analog (nur mit ein paar anderen 'Browserabweichungen' in der Darstellung).
Wenn ich jetzt aber bspw. innerhalb dieses DIV's ein weiteres DIV-Element setzen möchte, das zu allen Seiten einen festen Abstand von 50px hat, dann bist du mit dem Modell am Ende, denn das Padding (Innen-Abstand!) wird IMHO fälschlicherweise auf die Elementgröße draufgerechnet. Das ist das selbe, als wenn eine Tabellenzelle durch eine Padding-Angabe auf einmal größer würde!
Beispiel 2:
<div id="d1" style="position:absolute;top:0px;left:0px;height:100%;width:100%;margin:0px;padding:50px;border:none;background-color:#ccc">
<div id="d2" style="height:100%;width:100%;margin:0px;padding:0px;border:none;background-color:#999">
Inhalt von DIV 2
</div>
</div>
(Dieses Beispiel wird übrigens von allen Browsern 'korrekt' angezeigt!)
Daher war/ist der MS-Ansatz nicht nur logischer, sondern auch konsequenter und sinnvoller. Leider (du hast es ja angesprochen) beugt sich MS diesmal dem Standard (ausgerechnet da, wo er 'falsch' ist). Und die Überlegungen des W3C bezüglich dieser Dinge bei CSS3 zeigen doch eindeutig, dass man sich scheinbar auch im Klaren darüber ist, dass das, was man da mit dem Box Model gemacht hat, nicht der Weisheit letzter Schluß war.
Und das ist mein Hauptkritikpunkt: Dieses Modell macht es unmöglich ein 'größenvariables' Element mit absoluten Rand-, Rahmen- und/oder Innenabständen/größen zu definieren, welches nicht die Fenstergröße sprengt und diese dabei aber wie gesagt voll ausnutzen soll (was wie ich finde doch eine mehr als nützliche & sinnvolle Möglichkeit darstellt)!
IMHO müsste das Box Model so aussehen:
Alle Angaben zu margin, border, und padding müssten jeweils von width und height abgezogen werden. So einfach wäre das, und man hätte keine Probleme! Somit wäre alles machbar, und auch negative Werte für margin ließen sich völlig logisch umsetzen. Probleme zu anderen Dingen des Standards sehe ich auch keine.
Gruß Gunther