CSS Box Model - Ansatz nicht ideal!?

[Gunther]

Hallo zusammen!

Ich möchte mal meinen 'Unmut' über das CSS Box Model des W3C hier kundtun, und gerne eure Meinung(en) dazu hören/lesen. Vielleicht habe ich ja auch einen falschen Ansatz, oder einen Fehler in meinen Überlegungen.

Vorweg sei noch gesagt, dass sich meine 'Kritik'_nur_auf relative Größen (Prozentangaben) bezieht - nicht auf die Verwendung von absoluten Werten! Wobei es allerdings unsinnig wäre, dafür jeweils ein anderes Modell heranzuziehen.

Was mir an dem Ansatz des W3C nicht gefällt ist, dass es keine (verfügbare) Gesamt-Größe für ein Element gibt, da man mit CSS nicht Rechnen kann.

Das wirkt sich vor allem dann sehr nachteilig aus, wenn es darum geht, den verfügbaren Platz vollständig auszunutzen. Hierfür gibt es IMHO/AFAIK nur die Möglichkeit width und height gleich 100% zu setzen. Soweit so gut, nur wenn man jetzt in das äußere Element ein inneres einfügt, dessen Höhe wiederum den verfügbaren Platz komplett ausnutzen soll, gleichzeitig aber einen gewissen Abstand (margin) vom umgebenden Element haben soll, ist man mit dem Modell am Ende.

Beispiel (zur Verdeutlichung):

<div style="height: 100%; width: 100%; background-color: #fff; color: #000; padding: 0px; margin: 0px;">
 <div style="height: 100%; width: 100%; background-color: #ccc; color: #000; padding: 50px; margin: 50px; border: solid 20px #c00;">
 Inhalt des inneren DIV's
 </div>
</div>

Der entscheidende Nachteil ist, dass sich wiederum beim inneren Element die Angaben width und height nur auf den 'Content-Bereich' beziehen, sodaß sich ein Element mit der absoluten Größe von 100% + padding + border + margin > 100% ergibt. Sorry Leute, aber hier war/ist der Ansatz von Microsoft eindeutig besser. Wie uneins sich auch die Browserhersteller bei der korrekten Umsetzung zu sein scheinen, sieht man ebenfalls an dem obigen Beispiel. Von 4 getesteten Browsern (MSIE6SP1, NS7, OP6.04, OP7.02) unter Windows zeigt es nur der MSIE6 (im Standard-compliants Mode) korrekt an. Alle anderen Browser 'verschlucken' den margin-right und margin-bottom.

Wandeln wir das obige Beispiel ein wenig ab:

<div style="height: 100%; width: 100%; background-color: #fff; color: #000; padding: 50px; margin: 0px;">
 <div style="height: 100%; width: 100%; background-color: #ccc; color: #000; padding: 0px; margin: 0px; border: none;">
 Inhalt des inneren DIV's
 </div>
</div>

Auch das hält uns nicht in unserem 100% x 100% großen Container. Immerhin stellen jetzt alle 4 Browser das padding an allen Seiten dar (wenn auch der OP6 am unteren Rand zu klein). Nur leider 'vererbt' sich das Padding nicht im Bezug auf die Größe des inneren Elementes, weshalb dieses wiederum von seiner Größe her den verfügbaren Platz überschreitet.

Es gibt noch etliche weitere Beispiele dafür, wo dieses Modell einer 'effizienten' Platzausnutzung im Wege steht. Leider setzt sich nicht immer das 'geeignetste' Modell durch (nicht nur im Internet). IMHO ist das derzeitige Modell ein 'Schuß in den Ofen'.

Wie gefragt eine solche 'Raumaufteilung', bzw. 'Platzausnutzung' ist, zeigen nicht zuletzt die vielen Postings dazu hier im Forum.

Ich befürchte jedoch, dass sich an diesem Modell nichts mehr ändern wird - schade.

Wie geht ihr mit diesem 'Problem' um? Habe ich etwas falsch verstanden oder fehlinterpretiert? Welche Methoden verwendet ihr, um diese Probleme zu umgehen? Wie ist eure Meinung dazu?

Vielen Dank im voraus für deinen 'konstruktiven' Beitrag zu diesem Thema -

Gruß Gunther

[Der Hans]

Moin!

Der entscheidende Nachteil ist, dass sich wiederum beim inneren Element die Angaben width und height nur auf den 'Content-Bereich' beziehen, sodaß sich ein Element mit der absoluten Größe von 100% + padding + border + margin > 100% ergibt. Sorry Leute, aber hier war/ist der Ansatz von Microsoft eindeutig besser.

Auch wenn das wieder Schelte gibt: Das sehe ich ähnlich!
Gerade dann, wenn man relative Angaben mit absoluten/festen Angaben mixt,
geht einem viel Platz verloren durch "Sicherheitsabstände" für verschiedene Fenstergrößen.

Wie geht ihr mit diesem 'Problem' um? Habe ich etwas falsch verstanden oder fehlinterpretiert? Welche Methoden verwendet ihr, um diese Probleme zu umgehen? Wie ist eure Meinung dazu?

Ich persönlich versuche paddings möglichst zu umgehen (dann wird's schon besser!).
Border habe ich selten in der von dir vorgestellten Breite. Als es mal soweit war,
habe ich einen größeren Layer in "Randfarbe" unter den Inhaltslayer gelegt, den Rand
konnte man dann sogar noch beschriften! *g*
(wobei ich mir bewusst bin, dass das nicht immer so schön geht!)

Letztlich scheint es mir, als erfordere das Problem _meistens_ nur ein wenig Umdenken
und _oft_ ein paar Zugeständnisse hinsichtlich einer optimalen Platzverwertung.
Das wirklich Traurige ist, dass der MS-Ansatz zwar im Browser falsch ist, im Kopf
aber wahrscheinlich dem W3C-Box-Modell überlegen sein dürfte.

Gruß

Der Hans

[Gunther]

Moin Hans!

Auch wenn das wieder Schelte gibt: Das sehe ich ähnlich!

Bis jetzt gab's ja noch keine... ;-)
Und warum sollte es überhaupt? Man wird ja noch ein Modell in Frage stellen dürfen.

Gerade dann, wenn man relative Angaben mit absoluten/festen Angaben mixt,

(das meinte ich u.a. damit, als ich geschrieben habe "solange man mit CSS noch nicht Rechnen kann...", also bspw. height:100%-50px)

geht einem viel Platz verloren durch "Sicherheitsabstände" für verschiedene Fenstergrößen.

Ich persönlich versuche paddings möglichst zu umgehen (dann wird's schon besser!).
Border habe ich selten in der von dir vorgestellten Breite.

das war ja auch nur zur Verdeutlichung...

Als es mal soweit war,
habe ich einen größeren Layer in "Randfarbe" unter den Inhaltslayer gelegt, den Rand
konnte man dann sogar noch beschriften! *g*
(wobei ich mir bewusst bin, dass das nicht immer so schön geht!)

Letztlich scheint es mir, als erfordere das Problem _meistens_ nur ein wenig Umdenken
und _oft_ ein paar Zugeständnisse hinsichtlich einer optimalen Platzverwertung.

Aber nimmt man nicht dadurch einer eigentlich sehr 'mächtigen' Eigenschaft ihren elementarsten Vorteil (und das nur durch das Box Model)?

Vielen Dank für dein Statement (schein' ich ja wenigstens nicht ganz alleine mit meiner Meinung dazustehen).

Gruß Gunther

[Thomas J.S.]

Hallo,

Gerade dann, wenn man relative Angaben mit absoluten/festen Angaben mixt,

(das meinte ich u.a. damit, als ich geschrieben habe "solange man mit CSS noch nicht Rechnen kann...", also bspw. height:100%-50px)

Ich finde dass das auch nicht sein sollte, schließlich ist CSS keine Programiersprache, also warum sollte man damit rechenen können?

Grüße
Thomas

[Gunther]

Hallo Thomas,

Gerade dann, wenn man relative Angaben mit absoluten/festen Angaben mixt,

(das meinte ich u.a. damit, als ich geschrieben habe "solange man mit CSS noch nicht Rechnen kann...", also bspw. height:100%-50px)

Ich finde dass das auch nicht sein sollte, schließlich ist CSS keine Programiersprache, also warum sollte man damit rechenen können?

wenn du dir mal die 'Überlegungen' zu CSS3 (den Link hat Christian weiter oben im Thread netterweise gepostet) anguckst, stellt man u.a. genau solche Überlegungen an. Das ist IMHO auch dringend nötig, da das Box Model in der derzeitigen Form eigentlich in sich unlogisch ist (im Gegensatz zu dem Ansatz von MS), denn eines der größten sich daraus ergebenden Probleme ist, dass du Elemente 'erstellen' kannst mit einer Width/Height von 100%, die dann, wenn sie noch eine Border und/oder ein Padding haben, größer sind als 100%, also auch größer als der 'Body' (body {height:100%;width:100%}), der ja eigentlich der 'Container' für alle Elemente ist.

Ferner wird doch quasi jetzt schon 'gerechnet' - bspw. width + padding + border + margin = Elementgröße

Ich würde das sehr begrüßen, denn das würde IMHO nicht nur neue 'gestalterische' Möglichkeiten eröffnen, sondern wäre auch die Lösung der Probleme, die das jetzige Modell mit sich bringt.

Gruß Gunther

[Thomas J.S.]

Hallo Gunther,

Ich finde dass das auch nicht sein sollte, schließlich ist CSS

keine Programiersprache, also warum sollte man damit rechenen können?

wenn du dir mal die 'Überlegungen' zu CSS3 (den Link hat Christian

weiter oben im Thread netterweise gepostet) anguckst, stellt man u.a.
genau solche Überlegungen an.

Ich weiss bzw. ich 'kenne' die CSS3 docs.

Das ist IMHO auch dringend nötig, da das Box Model in der derzeitigen

Form eigentlich in sich unlogisch ist (im Gegensatz zu dem Ansatz von
MS),

Welchen Ansatz von MS meinst du?
MS weiss selber nicht was sie machen und was sie machen sollten, seit
dem IE6 auf die DOCTYPE achtgibt, gibt es mindestens 3 verschiedene
Darstellungsformen die der IE einem auftischt.
Und bei Angabe der srtict html 4.01 macht der IE das selbe wie Mozilla
oder Opera.

denn eines der größten sich daraus ergebenden Probleme ist, dass du

Elemente 'erstellen' kannst mit einer Width/Height von 100%, die dann,
wenn sie noch eine Border und/oder ein Padding haben, größer sind als
100%, also auch größer als der 'Body' (body {height:100%;width:100%}),
der ja eigentlich der 'Container' für alle Elemente ist.

Dann sehen wir was Sache ist:
-------------------------------
The property 'box-sizing' was first proposed to provide an upgrade path
for certain browsers that interpreted 'width' the wrong way. 'Box-width'
and 'box-height' are proposed as improved versions of 'box-sizing'.
However, newer versions of those browsers have already fixed the bug and
it is not clear that these properties are really needed anymore.
-------------------------------

Es mag also so sein, dass die Eigenschaften kommen, es mag aber auch so
sein, dass sie nicht kommen. Und ich würde nicht so sehr auf eine
Möglichkeit innerhalb einer Möglichkeit bauen (was die Rechnerei
angeht).

Ferner wird doch quasi jetzt schon 'gerechnet' - bspw. width +

padding + border + margin = Elementgröße

Ja, richtig und daran ändern sich auch im CSS3 nichts. Aber die
"Rechnerei" passiert hier nur implizit, d.h. es gibt bestimmte vorgaben
wie diese Werte gerechnet werden sollten. Mir ist/wäre lieber, dass
diese Vorgaben (noch) genauer definiert werden, als plötzlich die Leute
anfangen  Sachen wie "width: 10% - 2 * 2px" zu notieren.
Schon heute ist die helfte der Webseiten (ich rede dabei nicht vom
"hompaidsches") unbenützbar, weil "richtige" Webmaster soviel Ahung vom
CSS haben wie ein Huhn von der Relativitätstheorie.
Außerdem ich mag Featuritis nur in bestimmten Grenzen ;-)

Die modularisierung vom CSS und die meisten neuen CSS-Eigenschaften
gehen ganz in die Richtung, dass CSS zu einer vollständigen
Layoutsprache werden soll und zwar auch für XML. Ich bin mir noch nicht
so sicher, dass dies mit all seinen Konsequenzen wirklich sinnvoll ist.

Ich würde das sehr begrüßen, denn das würde IMHO nicht nur neue

'gestalterische' Möglichkeiten eröffnen, sondern wäre auch die Lösung
der Probleme, die das jetzige Modell mit sich bringt.

Ich wollte eigentlich genau darauf nicht eingehen, da ich nicht deine
Ansicht teile was die "unfähigkeit" des Modells angeht.

Grüße
Thomas

[Gunther]

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

[Thomas J.S.]

Hallo Gunther,

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),

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.

"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)."

Also setzen wir html und body auf width:100% (wobei man eigentlich auch width:auto; nutzen sollte!) dann ist mal die "Seite" so breit wie das Fenster (theoretisch).

1. Beispiel:

<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).

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 "

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.

If there is exactly one value specified as 'auto', its computed value follows from the equality.

If 'width' is set to 'auto', any other 'auto' values become '0' and 'width' follows from the resulting equality.

If both 'margin-left' and 'margin-right' are 'auto', their computed values are equal. "
-----------------------------------------------------------

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.

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!

Gehen wir darauf ein:
Nehmen wir 'width'
"width (welche ja nur die Breite vom Inhalt bestimmt) refer to width of containing block."

Weiter mit 'padding'
"The padding edge (das ist die immaginäre Linie an der äußeren Seite von der padding-Breite) of a box defines the edges of the containing block established by the box."

Der "containg block" wird so definiert:
"In general, generated boxes act as containing blocks for descendant
boxes; we say that a box "establishes" the containing block for its
descendants. The phrase "a box's containing block" means "the containing block in which the box lives," not the one it generates."

Also width + padding ergeben die Breite des "containing block", das ein Element für seine Kind-Elemente erzeugt (wohlgemerkt das margin und border nicht dabei sind!).
Und da müssen wir eben unterschieden zwischen den "containing block"  in dem ein Element steht und den "containing block" den er für seine Kind-Element erzuegt.

Für die weitere Block-Level Elemente im body gilt:

"Block-level elements generate a "principal block box" that only contains "block boxes". The principal block box establishes the containing block for descendant boxes and generated content and is also the box involved in any positioning scheme. Principal block boxes participate in a block formatting context."

Und der "block formatting context" sagt:

"In a block formatting context, boxes are laid out one after the other, vertically, beginning at the top of a containing block. The vertical distance between two sibling boxes is determined by the 'margin' properties.

In a block formatting context, each box's left outer edge touches the left edge of the containing block [...]"

Was eben bedeutet, dass die Gesamtbreite des Boxes nicht gleich die Inhaltbreite des Boxes ist, aber das wussten wir ja ohne hin.

Beispiel 2:
(Dieses Beispiel wird übrigens von allen Browsern 'korrekt' angezeigt!)

Postionierte elemente sind wieder ein ganz anderer Käse.

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.

Ja, aber das ist doch nicht das Problem, oder? ;-)

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.

Grüße
Thomas

[Gunther]

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

[Thomas J.S.]

Hallo Gunther,

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).

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
   <head>
      <meta http-equiv="content-type" content="text/html;charset=iso-8859-1" />
      <title>
         Untitled
      </title>
      <style type="text/css">
      html, body { width:auto; height:100%; padding-top:100px; padding-right:20px; padding-bottom:30px; padding-left:160px; margin:0px; border:0px; background:#ccc; }
      #box1 { height:inherit; width:inherit; padding:0px; margin:0px; border:solid 1px green; }
      </style>
   </head>
   <body>
      <div id="box1">
            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).
      </div>
   </body>
</html>

Opera 7.03 Stellt es richtig dar.

Grüße
Thomas

[Gunther]

Hallo Thomas,

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).

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
   <head>
      <meta http-equiv="content-type" content="text/html;charset=iso-8859-1" />
      <title>
         Untitled
      </title>
      <style type="text/css">
      html, body { width:auto; height:100%; padding-top:100px; padding-right:20px; padding-bottom:30px; padding-left:160px; margin:0px; border:0px; background:#ccc; }
      #box1 { height:inherit; width:inherit; padding:0px; margin:0px; border:solid 1px green; }
      </style>
   </head>
   <body>
      <div id="box1">
            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).
      </div>
   </body>
</html>

Opera 7.03 Stellt es richtig dar.

Nö,nö...! So nicht ;-)

html, body { width:auto; height:100%; padding-top:100px; padding-right:20px; padding-bottom:30px; padding-left:160px; margin:0px; border:0px; background:#ccc; }

Du trickst hier aber rum, denn das HTML-Element ist das Document-Root-Element und
----------------------------------- [Zitat(e) Anfang] -------------------------------------------
"The CSS box model describes the rectangular boxes that are generated for elements in the document tree ..."

"Document tree
The tree of elements encoded in the source document. Each element in this tree has exactly one parent, with the exception of the root element, which has none.
"

"The root of the document tree generates a box that serves as the initial containing block for subsequent layout.
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)."
----------------------------------- [Zitat(e) Ende] -------------------------------------------
So und nach der Theorie ist der Viewport wie breit (siehe *)? "The current width of the viewport" und das sind bei mir 100%. Folglich müssten deine Padding-Angaben noch obendrauf gerechnet werden (nach dem Box Model), also zeigt es OP7 nur vermeintlich richtig an, da Opera7 das Box Model falsch interpretiert im Bezug auf das HTML-Element (nämlich eigentlich genau nach dem MS-Ansatz).

Und hier sind wir eigentlich auch schon bei einem anderen Thema, nämlich dem HTML- und BODY-Element. Darüber gibt es auch schon einen kurzen Thread von mir mit Cheatah (http://forum.de.selfhtml.org/archiv/2003/3/42044/).
Hierbei besteht im Prinzp das selbe Problem, wie bei vielen anderen Dingen auch, nämlich bei der Browserimplementierung - jeder macht es wieder ein bis'chen anders, und eigentlich keiner richtig.

Ich finde gerade im Bezug auf das HTML-Element legt sich das W3C auch nicht genau fest (jedenfalls habe ich keine 'exakte' Aussage gefunden - vielmehr dreht man sich im Kreis, wenn man den jeweiligen Links folgt, ohne dabei jedoch eine 'eindeutige' Definition zu finden). Ich kann mir gut vorstellen, dass dies u.a. ein Grund mit dafür ist, dass selbst neuere Browser solche Unterschiede in der Darstellung/Umsetzung von validem Code produzieren.

Ich bin nach wie vor der Meinung, dass das derzeitige Box Model zumindest nicht ideal ist (man könnte auch sagen 'unlogisch', bzw. dass zusätzliche Eigenschaften her müssen).

Auf jeden Fall danke ich dir noch mal für deine Mühe, Ausdauer, und Geduld. Bitte sei nicht 'enttäuscht' darüber, dass du mich (zumindest bis jetzt) nicht von (d)einer anderen Meinung überzeugt hast ;-). Ich möchte nicht, dass der Eindruck entsteht, ich 'wollte' mich nicht überzeugen lassen. Dies ist_keineswegs_der Fall.

Gruß Gunther

[Thomas J.S.]

Hallo Gunther,

Nö,nö...! So nicht ;-)

Tz,tz tz! Erst haben wollen und dann doch nicht wollen?! ;-)

Du trickst hier aber rum, denn das HTML-Element ist das Document-Root-Element

Ja, nur jeder Browser, wie du sagst, versteht das anders oder gar nicht.

So und nach der Theorie ist der Viewport wie breit (siehe *)? "The current width of the viewport" und das sind bei mir 100%. Folglich müssten deine Padding-Angaben noch obendrauf gerechnet werden (nach dem Box Model),

Das ist glaube ich der Punkt, so sich die Geister scheiden.
Wir reden noch immer vom Root-Element. width bezieht sich normalerweise auf die größe des "containing blocks", den es beim Root-Element nicht gibt bzw. es wäre das viewport, was aber nicht sein soll. Demnach kann beim Rootelement padding auch nicht daraufgerechnert werden (so wie margin und border eben falls nicht daraufgerechnet werden sollten).

»»also zeigt es OP7 nur vermeintlich richtig an, da Opera7 das Box Model falsch interpretiert im Bezug auf das HTML-Element (nämlich eigentlich genau nach dem MS-Ansatz).

Das sehe ich eben anders. ;-)

Ich bin nach wie vor der Meinung, dass das derzeitige Box Model zumindest nicht ideal ist (man könnte auch sagen 'unlogisch', bzw. dass zusätzliche Eigenschaften her müssen).

Die Spez ist hier wollkommen wirr geschrieben, keine Frage und es werden viele Definitionen mehrfach und dabei leicht unterschiedlich beschrieben. Und ich habe ja auch nicht gesagt, sie wäre Perfekt, sonder nur, dass ich damit klar komme.

Ich möchte nicht, dass der Eindruck entsteht, ich 'wollte' mich nicht überzeugen lassen. Dies ist_keineswegs_der Fall.

Das war mir schon klar. ;-)

Grüße
Thomas

[Auge]

Hallo (unter anderem Ihr beiden)

Nachdem ich euch in den letzten Tagen interessiert zugehört
... äähhh zugelesen habe, mal eine Anmerkung von mir.

Hat aber nur grundsätzlich etwas mit dem diskutierten,
konkreten Problem zu tun.

Auch ich habe Probleme bei der Logik des Boxmodells.
Logisch fände ich, wenn margin und border zur Breite/Höhe
hinzugerechnet würden, padding aber innenliegend von der
Breite/Höhe abgerechnet würde.
Da aber padding zur Breite/Höhe hinzuaddiert werden, ergeben
sich optische "Ungereimtheiten" (gerade bei Verwendung von border),
welche padding schwer benutzbar machen.
Wurde hier ja auch schon als "böse" bezeichnet. Nur GWB weiß noch nichts davon. ;-)
http://forum.de.selfhtml.org/archiv/2003/1/35716/#m195014

Tschö, Auge

[Jens W.]

Hi Gunther,

ich sehe das genauso.
Wenn man einem Element eine prozentuale Größe vorgeben und nach der Darstellung die absolute Pixelzahl auslesen könnte, dann würde mir das sehr viel ärger ersparen.

Gruß
Jens

[Gunther]

Hi Jens,

ich sehe das genauso.

das freut mich... ;-)

Wenn man einem Element eine prozentuale Größe vorgeben und nach der Darstellung die absolute Pixelzahl auslesen könnte, dann würde mir das sehr viel ärger ersparen.

Wie meinst du das (vor allem das 'Auslesen')? Bitte erläutere das mal etwas ausführlicher - Danke!

Gruß Gunther

[Christian Seiler]

Hallo Gunther,

Wie geht ihr mit diesem 'Problem' um?

Auf CSS3 warten:
http://www.w3.org/TR/css3-box/#the-box-width

Man darf gespannt sein... (und ein paar Jahre warten)

Viele Grüße,
Christian

[Christian Seiler]

Hallo Gunther,

Hallo nochmal,

Auf CSS3 warten:

Mir ist gerade noch etwas eingefallen, das zumindest dann funktioniert, wenn es um den gesamten Anzeigebereich geht:

http://www.christian-seiler.de/temp/test-full-width.html

Setzt allerdings Browser vorraus, die right/bottom verstehen.

Viele Grüße,
Christian

[Gunther]

Hallo Christian,

Auf CSS3 warten:

Danke für den Link (hab' zugegebenermaßen vorher nicht bei CSS3 nachgelesen, ansonsten hätte ich mir mein Posting ja glatt sparen können). Es läßt ja zumindest hoffen, dass sich an dem 'Modell' in Zukunft doch noch etwas ändert. Was dort beschrieben ist, wäre die Lösung der von mir gemeinten Probleme des derzeitigen Modells.

Mir ist gerade noch etwas eingefallen, das zumindest dann funktioniert, wenn es um den gesamten Anzeigebereich geht:

http://www.christian-seiler.de/temp/test-full-width.html

Setzt allerdings Browser vorraus, die right/bottom verstehen.

hmmm..., hab's mir angeguckt (verstanden scheinbar nicht so ganz). 4 Browser - 4 verschiedene Ergebnisse (wobei der MSIE6 ganz aus dem Rahmen fällt). Was hat das mit den Größenangaben von 100% zu tun?

Gruß Gunther

[Christian Seiler]

Hallo Gunther,

hmmm..., hab's mir angeguckt (verstanden scheinbar nicht so ganz). 4 Browser - 4 verschiedene Ergebnisse (wobei der MSIE6 ganz aus dem Rahmen fällt). Was hat das mit den Größenangaben von 100% zu tun?

Ich habe es nur im Mozilla 1.3 getestet, vor anderen Browsern hatte ich zuviel Angst. Konqueror 3.1 macht es übrigens nur beim ersten Rendern der Seite richtig, resizen bringt ihn dann auch durcheinander. Opera 6.11 spinnt, was klar war, da Opera 5/6 right/bottom nur dann richtig versteht, wenn ich auch eine Breite angebe, was ich hier ausdrücklich _nicht_ will, die Breite soll sich ja automatisch anpassen.

Ich positioniere beide <div>s absolut. Die absolute Positionierung bezieht sich immer auf das nächsthörere absolut positionierte Element oder halt den Anzeigebereich. Ich lege dann per top/right/bottom/left die Koordinaten der "Eckpunkte" fest, was in diesem Fall zumindest unter Mozilla und Konqueror zum gewünschten Ergebnis führt. (in letzterem mehr oder wengier)

Hoffe, das war verständlich...

Viele Grüße,
Christian

[Gunther]

Hallo Christian,

Ich positioniere beide <div>s absolut. Die absolute Positionierung bezieht sich immer auf das nächsthörere absolut positionierte Element oder halt den Anzeigebereich. Ich lege dann per top/right/bottom/left die Koordinaten der "Eckpunkte" fest, was in diesem Fall zumindest unter Mozilla und Konqueror zum gewünschten Ergebnis führt. (in letzterem mehr oder wengier)

Hoffe, das war verständlich...

Ja war es - Danke! Hat einen Moment gedauert bis der Groschen (Cent) gefallen ist ;-)
Der NS7 beherrscht diese Methode problemlos - der MSIE6 (in beiden Modi) leider überhaupt nicht, weshalb ein Einsatz dieser Methode wohl kaum sehr praktikabel sein dürfte.

Wieder das altbekannte Problem: Auf der einen Seite der Standard, auf der anderen Seite die Browser ;-)

Trotzdem vielen Dank für deine Ausführungen (immer interessant zu sehen, was anderen Leuten so einfällt...)

Gruß Gunther