CSS

float ist etwas was ich überhaupt nicht gerne benutze. und nein. IE sieht nicht genauso aus wie auf Opera. IE hat bei float einen 3px-abstands-bug

Wenn du eine variante haben willst, die auch auf allen Browsern gut läuft, nimmt die hier:
http://www.bugcatcher.de/files/relative.html

Hallo hbo44,

der gelbe Kasten mit der Nummer 1 soll 296px hoch sein. Fx macht das richtig, während IE ihn vergrößert, um allen Inhalt unterzubringen. Opera macht hier den IE nach.

Soll eine float-Box nicht eigentlich nur Zeilenboxen, also Text, zur Seite schieben? Dann hätte Fx auch mit der Position von Kasten 6 recht.
Die "6" wurde nach rechts geschoben, ist aber nicht sichtbar, weil die Box nicht breit genug ist.

Versuche mal, das in den W3C-Spezifikationen nachzulesen. Vielleicht mag Bugcatcher deshalb keine floats, weil man nicht rauskriegt, wie es richtig sein soll. Der erste Absatz von "9.4.1 Block formatting contexts" fehlt in der deutschen Übersetzung, die mir auch sonst nicht weiter hilft.

Ist der Unterschied zwischen IE und Opera bei Ebene 5 und 6 wirklich der 3-Pixel-Bug? Ich dachte der tritt nur bei Absätzen auf.

Martin

Zitat von MartinH

Der gelbe Kasten mit der Nummer 1 soll 296px hoch sein. Fx macht das richtig, während IE ihn vergrößert, um allen Inhalt unterzubringen. Opera macht hier den IE nach.

Daher hab ich die höhe auch ganz rausgenommen. so passt es sich bei allen browsern einfach an. wobei der Mozilla (also die Gecko-Layoutengine) hier die logischste Darstellung bietet.

Zitat von MartinH

Soll eine float-Box nicht eigentlich nur Zeilenboxen, also Text, zur Seite schieben? Dann hätte Fx auch mit der Position von Kasten 6 recht.
Die "6" wurde nach rechts geschoben, ist aber nicht sichtbar, weil die Box nicht breit genug ist.

float ist ein allgemeiner sheet. sollte daher auch auf divs usw. anwendbar sein (alle block-elemente). was es eigendlich auch ist. aber float verhält sich meist ganz anders als man das erwarten würde.

Ich bin mir recht sicher, dass das was Gecko da baut nicht richtig ist. Ich denke Opera macht es da richtig. Und IE bis auf den 3px-bug auch...

Dann hatte ich versucht eine list anzuwenden und das <div> auf display:inline zu ändern. auch hier war ich von gecko enttäuscht. auch hier macht Opera eher das was ich erwartet hätte. Per Inline, hätten sich beide div-boxen ohne float nebeneinander setzen müssen, weil kein umbruch mehr verlangt wird.

Zitat von hbo44

Hmmm.... Zitat: "float ist etwas was ich überhaupt nicht gerne benutze"
darf man denn auch wissen warum?
Ich will mich in die Untiefen von CSS wagen, da kann ich diese Begründung natürlich nicht akzeptieren, Sorry,
aber ich glaube, Du verstehst das.

da ich aber davon ausging, dass nur eine lösung für das darstellungsproblem gesucht wurde, hab ich eine lösung angeboten... wenn auch nicht mit float, sondern über margin. die untiefen sind: etwas auf keine kuhhaut geht.

Warum ich float nicht mag? weil es mir zuwenig anpassungsmöglichkeiten gibt. warum ich Tabellenloses Design nicht mag? Weil die eltern-kind-verschachtelung bei relativen angaben nicht interpretiert werden. darum umgehe ich solches design bisher. table sind vielleicht nicht schön, aber rubuster. auch das die browser sich in der "tiefe" bei css sich gegenseitig uneinig sind.

Zitat von hbo44

Frage hierzu: kann FireFox nicht richtig mit CSS umgehen?

Ich kenne GARKEINEN Browser der richtig mit CSS umgehen kann. Die haben überall ihre macken.

Ich halte die idee von CSS für sehr gut, und auch der ansatz für tablellenlose seiten ist wunderbar. nur die spezifikationen sind unzureichent und die browserunterstürtzung ungenau/eigenwillig.

daher bin ich eher ein freund von klassischem design und wenn es dann doch xhtml/tabellfreies design soll: so einfach wie möglich.

Zitat von MartinH

Ist der Unterschied zwischen IE und Opera bei Ebene 5 und 6 wirklich der 3-Pixel-Bug? Ich dachte der tritt nur bei Absätzen auf.

Ich denke das gilt für alle block-elemente?

Zitat von bugcatcher

Ich bin mir recht sicher, dass das was Gecko da baut nicht richtig ist.

Von Bugcatcher hätte ich am wenigsten erwartet, dass er den Fx unberechtigterweise eines Fehlers bezichtigt.
Er er mir doch selbst mal erklärt, dass die W3C-Leute mit den Mozilla-Leuten unter einer Decke stecken.

Zitat von bugcatcher

float ist ein allgemeiner sheet. sollte daher auch auf divs usw. anwendbar sein (alle block-elemente).

Habe ich etwas anderes behauptet?
Unstimmigkeiten gibt es bloß, wie sich solch eine Box auf den Rest des Layouts auswirkt.

http://www.w3.org/TR/CSS21/visuren.html#floats
"Since a float is not in the flow, non-positioned block boxes created before and after the float box flow vertically as if the float didn't exist. However, line boxes created next to the float are shortened to make room for margin box of the float."
Kein Wort davon, dass irgendwas anderes als "line boxes" betroffen wäre.
Kasten 6 soll so positioniert werden, als gäbe es die float-box gar nicht.

http://www.w3.org/TR/CSS21/visuren.html#block-formatting
"In a block formatting context, each box's left outer edge touches the left edge of the containing block (for right-to-left formatting, right edges touch). This is true even in the presence of floats (although a box's line boxes may shrink due to the floats), unless the box establishes a new block formatting context"
Eine ganz normale div macht keinen neuen "block formatting context", also beginnt Kasten 6 am linken Rand.

Was das Verschwinden der Ziffer 6 angeht, muss ich mich korrigieren, sie wird nicht nach rechts weggedrückt, jedenfalls nicht endgültig. Dort stellt sie nämlich fest, dass innerhalb ihrer div rechts kein Platz ist, und versucht es nochmal unten. Weil dort auch kein Platz ist, wird sie gar nicht angezeigt.

Zitat von bugcatcher

Dann hatte ich versucht eine list anzuwenden und das <div> auf display:inline zu ändern.

gemeint war wohl die (das?) div mit der Nummer 6.

Wenn Kasten 6 die Eigenschaft "display: inline;" bekommt, sind Höhe und Breite nicht mehr anwendbar, siehe
http://www.w3.org/TR/CSS21/visudet.html#propdef-width
"This property does not apply to non-replaced inline-level elements."
http://www.w3.org/TR/CSS21/visudet.html#propdef-height oder
http://www.w3.org/TR/CSS21/visudet.html#inline-non-replaced
Firefox macht es richtig. IE und Opera falsch. Oder W3C macht es falsch, weil die Vorgaben nicht so sind, wie man es erwartet.

Martin

Zitat von MartinH

Von Bugcatcher hätte ich am wenigsten erwartet, dass er den Fx unberechtigterweise eines Fehlers bezichtigt.

Irgendwie hätte ich halt was anderes erwartet. Und das was Opera liefert, war mir da das liebste...

Zitat von MartinH

Er er mir doch selbst mal erklärt, dass die W3C-Leute mit den Mozilla-Leuten unter einer Decke stecken.

Des wegen sind noch lange nicht alle dinge bei Gecko richtig.

Zitat von MartinH

Habe ich etwas anderes behauptet?
Unstimmigkeiten gibt es bloß, wie sich solch eine Box auf den Rest des Layouts auswirkt.

Hab dein "Zeilenboxen, also Text" als <p>-tag-only missverstanden.

Zitat von MartinH

http://www.w3.org/TR/CSS21/visuren.html#floats
"Since a float is not in the flow, non-positioned block boxes created before and after the float box flow vertically as if the float didn't exist. However, line boxes created next to the float are shortened to make room for margin box of the float."
Kein Wort davon, dass irgendwas anderes als "line boxes" betroffen wäre.
Kasten 6 soll so positioniert werden, als gäbe es die float-box gar nicht.

Was immer line-boxes sein sollen.... aber mit float werden auch menus an die seite geschafft. und da sollte es egal sein, was in den divs drin steht, oder? Mag sein, dass Mozilla es richtiger macht. Aber nicht wünschenswerter/paragmatischer. : /

Zitat von MartinH

http://www.w3.org/TR/CSS21/visuren.html#block-formatting
"In a block formatting context, each box's left outer edge touches the left edge of the containing block (for right-to-left formatting, right edges touch). This is true even in the presence of floats (although a box's line boxes may shrink due to the floats), unless the box establishes a new block formatting context"
Eine ganz normale div macht keinen neuen "block formatting context", also beginnt Kasten 6 am linken Rand.

Was jetzt wieder ein block formatting context ist, würde ich auch gerne erklärt haben. aber div ist schon ein block-element. erkennbar durch den umbruch... oder nicht?

Zitat von MartinH

Was das Verschwinden der Ziffer 6 angeht, muss ich mich korrigieren, sie wird nicht nach rechts weggedrückt, jedenfalls nicht endgültig. Dort stellt sie nämlich fest, dass innerhalb ihrer div rechts kein Platz ist, und versucht es nochmal unten. Weil dort auch kein Platz ist, wird sie gar nicht angezeigt.

Jo. So hab ich das auch vermutet.

Zitat von MartinH

Wenn Kasten 6 die Eigenschaft "display: inline;" bekommt, sind Höhe und Breite nicht mehr anwendbar, siehe
http://www.w3.org/TR/CSS21/visudet.html#propdef-width
"This property does not apply to non-replaced inline-level elements."
http://www.w3.org/TR/CSS21/visudet.html#propdef-height oder
http://www.w3.org/TR/CSS21/visudet.html#inline-non-replaced
Firefox macht es richtig. IE und Opera falsch. Oder W3C macht es falsch, weil die Vorgaben nicht so sind, wie man es erwartet.

Ist richtig. Aber trotzdem doof.

Ich mache auch keinen Geheimnis draus, dass ich mit einigen W3C-Vorgaben unzufrieden bin.

Zitat von bugcatcher

Was jetzt wieder ein block formatting context ist, würde ich auch gerne erklärt haben.

In der deutschen Übersetzung fehlt der wichtigste Teil, ist wahrscheinlich erst später dazugekommen. Das hier soll wohl eine vollständige Liste sein: Floats, absolutely positioned elements, inline-blocks, table-cells, and elements with 'overflow' other than 'visible' establish new block formatting contexts.

Hier mal ein Link auf die richtige Darstellung im IE6 und FF:
http://www.indibalou.de/tp/hbo44/

Wo lag der Fehler ? Ganz sicher nicht beim FF. :wink:

U.a. waren die floats (und clear) nicht richtig.
Die Abstände entstanden durch das falsche Boxmodel des IE, nur waren die Werte eben für den IE optimiert, also falsch.
Grund war der Rand um die Box 6: Wenn ich einen Rahmen definiere, muss ich die Beite von width abziehen, für den Rahem mit 2px also 4px (2px links, 2px rechts).

Gruß
Uba

2 mal float? ich peil das mit den floats wohl nie....

Alle Rahmen, die nebeneinander erscheinen sollen, erhalten ein float.
Der erste, der tiefer erscheinen soll, ein clear, um die floats aufzuheben.
clear am Ende der Reihe ist genauso wichtig, wie das zweite float.

Ja. Das hab ich schon verstanden.

das mit dem Clear ist klar.

Nur müsste es nicht reichen, wenn nur ein float:left benutzt wird? Irgendwie bekomme ich das Verständnis dafür nicht zusammen.

Damit der Kasten 6 rechts neben den Kasten 5 kommt, würde eigentlich ein float reichen.

Aber wir haben ja schon gesehen, was passiert, wenn 6 einfach nur eine div bleibt, und mit "display: inline" war es ja auch nicht viel besser. "display: inline-block" oder "display: block" führt auch nicht zum Erfolg, "display: table" schon eher.

Da scheint ein weiteres float (neuer block formatting context) schon die einfachste Lösung zu sein, auch wenn man damit einen float-Effekt zu viel erzeugt, den man dann mit clear wieder beseitigen muss.

Das clear wegzulassen, hat besonders spaßige Folgen: Die Hintergrundfarbe von 7 befindet sich da, wo 5 sein soll, und die Ziffer 7 steht nackt da.

Ich kenne auch ein Beispiel, bei dem ich glaube, dass der Fx es falsch macht:

http://www.hallofreun.de/temp/test1.html beziehungsweise
http://www.hallofreun.de/temp/test2.html

So wie ich die Spezifikationen verstehe, gehört das clear auch dann unter das float, wenn sie sich gar nicht berühren. Wer in der Lage ist, das nachzulesen, möge mich bitte aufklären.

IE macht es natürlich wieder ganz anders (ein Text wurde in der Abbildung sogar durch den peek-a-boo-Bug verschluckt):
[Blockierte Grafik: http://www.hallofreun.de/temp/test1-IE.jpg]
Opera 7.52 kann sich nicht entscheiden und setzt den Absatz unter das float, aber das span neben das float.

Ich sag ja... ich mag float nicht. jetzt wisst ihr warum ; )