Hallo Thomas,
also zuerst einmal vielen Dank für deine Geduld :-)!
Mag ja sein, dass ich etwas 'begriffsstutzig' bin,_aber_dann poste doch bitte mal ein konkretes (Code-)Beispiel, für ein DIV-Element, welches bei jeder Fenstergröße nach oben einen Abstand von 100px, nach rechts von 20px, nach unten von 30px, und nach links von 160px hat (mal abgesehen davon, ob es einen Browser gibt, der das richtig darstellt - also rein nach Standard).
Da wäre schon mal der 'canvas' der in alle Richtungen unendlich ist (Enterprise läßt grüßen), dann kommt der viewport (z.B. ein Fenster), erst da kommen wir zum Root-Element (das wäre bei uns also html), das den sogenannten "initial containing block" für alle anderen Elemente erzeugt.
Es ist schon richtig, dass man den Canvas unendlich in alle Richtungen (eigentlich ja nur nach rechts und nach unten bei ltr) ausdehnen kann, trotzdem entsprechen 100% immer dem gesamten sichtbaren Bereich (also deinem viewport - Werte über 100% liegen außerhalb / Werte unter 100% nutzen nicht den gesamten sichtbaren Bereich aus). Nach meinem Verständnis ist das Root-Element (also das HTML-Element) gleich dem Canvas! Denn was sollte bitte größer sein, als das Document-Root-Element?
"The width of the initial containing block may be specified with the 'width' property for the root element. If this property has the value 'auto', the user agent supplies the initial width (e.g., the user agent uses the current width of the viewport)."
bestätigt doch meine Aussage von oben, oder? (Root-Element = HTML-Element! nicht body)
Da machen eben die Browser schon schlapp; und deine Interpretation läßt einiges außer Acht:
Es geht hier um ein normales <div> im normalen Kontext, also es geht um ein "Block-level, non-replaced elements in normal flow"Für solche Elemente gilt:
"'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' = width of containing block "
ja richtig, und was ist der 'containing block' hier? Doch das body-Element, und das hat laut unserer vorherigen Angabe eine width von 100% = Fensterbreite. Setzt du aber width:auto und gibst für die anderen Eigenschaften konkrete Werte an, wird die Weite aber noch lange nicht auf die Weite des des containing block's gesetzt (gleiches gilt für die Höhe).
Aber es gilt dabei folgendes (Sorry für die langen Zitate):
"If all of the above have a specified value other than 'auto', the values are said to be "over-constrained" and one of the computed values will have to be different from its specified value. If the 'direction' property has the value 'ltr', the specified value of 'margin-right' is ignored and the value is computed so as to make the equality true.
Nach dem für direction ltr als initial Wert gilt und in deinem Beispiel alle Eigenschaften einen Wert anders als "auto" haben, _muss_ "margin-right" ignoriert werden, d.h. Opera 7 macht es richtig.
Falsch - demnach müssten alle Angaben ignoriert werden, da bereits der Content-Block mit width:100% die Größe des Containing Block's hat. Außerdem hält das auch keinen der Browser davon ab, das DIV-Element trotzdem größer zu machen als den Containing Block (Body-Element). Aber um die Darstellung der Browser geht es mir ja gar nicht, sondern um das Box Model. Und das steht z.B. zu diesen Regeln hier im Widerspruch. Das Problem ist doch, dass man mit 100% nicht das ganze Element erfasst, sondern nur den 'inneren' Teil (Content-Bereich).
.
.
.
[Danke für die ausführlichen Zitate, aber ich kenne die Seiten vom W3C ;-)]
.
.
.
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)!
Das macht es eben nicht!
Wenn man sowohl margin, padding und border mit anderen Werten als "auto" definiert, _müsste_ man "width" auf "auto" setzen, damit gemäß den Regel der Spez. die Rechung richtig ist.
Ja, theoretisch richtig! Jetzt zitiere ich mal ;-)
"10.3.3 Block-level, non-replaced elements in normal flow
... If 'width' is set to 'auto', any other 'auto' values become '0' and 'width' follows from the resulting equality ..."
also macht es_kein_Browser richtig. Vielmehr verhalten sich eher alle wie bei
"10.3.4 Block-level, replaced elements in normal flow
...If 'width' is specified as 'auto', its value is the element's intrinsic width. ..."
und
"Intrinsic dimensions
The width and height as defined by the element itself, not imposed by the surroundings. In CSS2 it is assumed that all replaced elements -- and only replaced elements -- come with intrinsic dimensions."
Deshalb ist das von mir geforderte DIV-Element nicht darstellbar, weil du eben eine Angabe für width und height machen mußt, und wenn diese 'fluid' sein soll, kann es nur eine Prozentangabe sein, und da du aber die Gesamtgröße des Elementes nicht direkt angeben kannst und alle Werte für Padding, Border, und Margin noch 'obendrauf' gepackt werden, ist es nicht möglich. Ich lasse mich ja gerne vom Gegenteil überzeugen (aber mit Code-Beispiel).
Gruß Gunther