Eine der Hürden (und „Ah-ha“-Momente) beim Erlernen von CSS ist dieses Thema mit dem Leeren von Floats. Wenn Sie keine Ahnung haben, wovon ich spreche, schauen Sie sich den Klassiker Alles über Floats an.
Ich möchte speziell über das Problem des „Zusammenfallens“ sprechen, d. h. wie Elemente, die gefloatete Elemente enthalten, diese nicht bei der Berechnung ihrer Höhe berücksichtigen. Zum Beispiel hat ein Elternelement, das *nur* gefloatete Elemente enthält, eine Höhe von Null. Das ist für CSS-Neulinge überraschend und verwirrend und scheint kontraintuitiv zu sein.
Die Lösung ist normalerweise trivial. Die Verwendung eines beliebigen Overflow-Werts von hidden oder auto auf dem Elternelement „behebt“ dies. Der clearfix ist ebenfalls beliebt.
Aber diese „Fixes“ erwecken den Eindruck, dass dieses Verhalten von vornherein „kaputt“1 ist. Verwirrend? Sicher. Sollte es bessere Kontrollmöglichkeiten geben? Absolut. Kaputt? Nicht wirklich. Wenn sich alle Container ausdehnen würden, um ihre gefloateten Nachkommen aufzunehmen, würden wir uns noch mehr beschweren, und das Problem wäre möglicherweise schwerer zu umgehen.
Das klassische Beispiel
Wir verwenden dieses Beispiel, das Eric Meyer vor sieben Jahren vorgestellt hat.
<p>
...text...
<img src="sunset.jpg" class="callout" />
...text...
</p>
<p>
...text...
</p>
Diecalloutclass, würde zum Beispiel das Bild nach links fluten und einige Ränder anwenden. Das ist, was wir jetzt bekommen

Das ist genau das, was wir wollen würden, der korrekte Textfluss. Damit dies geschieht, muss der obere Absatz quasi „kollabieren“ und das geflutete Bild unten herausragen lassen.
Wenn sich der obere Absatz automatisch ausdehnen würde, um den Float zu enthalten, würde uns das hier übrig lassen

Wie Eric sagte
Das hätten Designer niemals akzeptiert.
Und ich stimme zu. Das hätte ein noch größeres Problem sein können, vorausgesetzt, es hätte kein ausgefallener Workaround gefunden werden können, um es zu umgehen.
Sollte es eine bessere Lösung geben?
Ja, wahrscheinlich. Ich habe Vorschläge gesehen
overflow: contain;
Das könnte funktionieren, aber was ist, wenn Sie den horizontalen Überlauf ausblenden möchten? Wir haben bereits overflow: hidden, das Floats bereits enthält, was funktioniert, aber das ist dann semantisch etwas verwirrend. Es könnte ein ganz neues Attribut geben, wie z. B.
contain: floats | collapse | inherit;
Aber ich weiß nicht, sie können nicht einfach ständig neue Attribute hinzufügen, daher müsste das ernsthaft geprüft werden.
1 Ich möchte hier auch hinzufügen, dass ich oft höre, wie Leute sagen, dass „Floats das Element aus dem Dokumentenfluss nehmen“, was nicht stimmt. Gefloatete Elemente beeinflussen immer noch Inline-Elemente (das ist sozusagen der Punkt) sowie andere geflutete Block-Level-Elemente. Wenn geflutete Elemente „aus dem Dokumentenfluss entfernt“ würden, würden sie nichts beeinflussen (wie absolut positionierte Elemente).
Benutzen wir nicht einfach die Float-Eigenschaft missbräuchlich für einen Zweck, für den sie nicht gedacht war? Vielleicht sollte es eine layout-flow-Eigenschaft geben, die sich automatisch leert. Die clearfix-Klasse ist nützlich, aber nicht die eleganteste Lösung.
Es scheint viel HTML und CSS zu geben, das wir missbräuchlich auf eine Weise verwenden, für die es nicht gedacht war, weil es der einzige gute Weg ist, das zu tun, was wir brauchen.
Ja, genau das denke ich. Es scheint nicht, dass Floats ursprünglich für Layouts gedacht waren, wegen der vielen Probleme, die damit einhergehen – Clearing, gleiche Höhe, nach unten stoßen, usw., daher wurden viele „Fixes“ gemacht. Tabellen scheinen in vielen Situationen viel einfacher, aber sie sind auch nicht für Layouts gedacht (aus guten Gründen).
Es sieht so aus, als gäbe es einige Vorschläge, um mehr layout-basierte CSS zu integrieren: http://www.w3.org/TR/2009/WD-css3-layout-20090402/. Es sieht nicht perfekt aus, aber es könnte besser sein als das, was wir jetzt haben. Aber wer weiß, wann das ein Standard wird…
Nein, wir missbrauchen Float nicht. Es ist unmöglich, die Präsentationsschicht für die Beschreibung der Präsentation zu missbrauchen.
Beste Idee, die ich heute gehört habe!
Könnte diese Idee dem W3 einreichen.
„Die Lösung ist normalerweise trivial. Die Verwendung eines beliebigen Overflow-Werts von hidden oder scroll auf dem Elternelement behebt dies.“
Overflow:auto ist die richtige Lösung hier.
Ja, ich meinte eigentlich „auto“. Aber tatsächlich verwende ich „hidden“ öfter als „auto“ in Situationen, in denen ich das verwende. Es hängt vom Kontext ab, aber hidden finde ich für IE6-Land etwas kugelsicherer, wenn man keine feste Höhe einstellt, und verhindert einfach, dass Dinge horizontal herausragen und das Layout durcheinanderbringen.
Gute Gedanken! Ich habe mir immer einen schnellen HTML-Nicht-abschließenden Tag gewünscht, um Clears durchzuführen. Wie ein „clear“-Tag, dann „rtclear“ und „ltclear“… usw. Aber wenn es im Stylesheet wie oben erwähnt wäre, wäre es wahrscheinlich eine flexiblere Lösung.
Ich verwende eine Methode, die ich von Ed Elliot habe, die bei mir immer funktioniert.
Fügen Sie einfach die Klasse „container“ zu jeder Div hinzu, die alle ihre Inhalte enthalten soll, und es funktioniert einfach… Es bedeutet, eine Klasse zum HTML hinzuzufügen, aber für mich ist das semantischer, als ein Clearing <br /> oder was auch immer hinzuzufügen.
Aber *viel* weniger semantisch als nur overflow: auto zu verwenden;
Das ist normalerweise das, was ich gerne benutze, aber die :after Pseudo-Klasse funktioniert in den meisten älteren Browsern nicht.
Ist das nicht der erste Teil der „clearfix“-Technik?
Ja, das ist nur der clearfix
Ich sage das oft in diesen Blogbeiträgen über „CSS für Neulinge“ (und davon gibt es heute viele) –
1. Es ist großartig, dass Leute über diese Themen für die „jüngere“ Generation von Webdesignern schreiben, die diese Dinge nicht gelernt haben, als sie zum ERSTEN MAL von den eigentlichen Erfindern/Innovatoren der Technik geschrieben wurden.
2. Nichtsdestotrotz, lassen Sie uns fair sein und die Anerkennung dort geben, wo sie hingehört … der sogenannte „clearfix“-Ansatz wurde zuerst weithin dokumentiert und popularisiert von den guten Leuten bei Position is Everything – http://www.positioniseverything.net/easyclearing.html
Weiter lernen – das ist großartig.
Ich würde in Bezug auf eine CSS-Korrektur weiter gehen. Ein Problem, auf das ich häufig stoße, ist, dass ein Element in einer Seitenleiste in eine zentrale Spalte mit Text eindringt und der Designer erwartet, dass der Text um das Element herum fließt. (Stellen Sie sich das obige Beispiel vor, aber das Bild ragt nach links.) Das passiert mir oft bei Designern, die an Print gewöhnt sind. (Ich habe auch in Desktop Publishing angefangen.)
In einem Seitenlayout-Programm können Sie ein Element, z. B. ein Bild, nehmen und Textumbruch darauf anwenden. Das bedeutet, dass egal wo Sie das Element auf einer Seite platzieren, wenn es mit einer Textbox kollidiert, der Text ausweicht und darum herumfließt. Designer erwarten dieses Verhalten von HTML-Seiten, und ich muss erklären, dass es nicht so funktioniert.
Damit Text um ein Element in HTML fließt, muss sich das Element *innerhalb* des Textes befinden. Für das obige Beispiel befindet sich das Bild-Tag tatsächlich zwischen den Wörtern „egestas semper“. Damit das Bild linksbündig in einer Spalte links vom Text ausgerichtet ist, muss es einen negativen linken Rand haben, um es nach links zu ziehen. Das bedeutet, es besteht die Gefahr, dass Inhalte in der linken Spalte überlappt werden.
Ich denke, es muss vielleicht ein float:all oder ein text-wrap:left geben, um diese Situation zu bewältigen.
Wow Chris,
Sie erwähnen es am Rande, aber NUR overflow:hidden (oder auto) auf dem Elternelement als 1-Zeilen-Arbeitslösung für Float ist wahnsinnig gut.
Selbst der „einfache“ Float (clearfix/after + zoom:1 IE) wird dadurch geschlagen.
Ich war (bin) kann nicht glauben, dass das in allen „akzeptablen“ Browsern (IE6+, Mozilla FF2+, WebKit) funktioniert.
Danke!
Es ist irgendwie nett, aber das Problem ist, dass sowohl overflow: hidden als auch auto sehr spezifische Funktionen haben, die ANDERES sind als die Float-Sache zu beheben. Nehmen wir an, Sie haben ein Bild in einem gefluteten Div, das absichtlich über die Breite des Divs hinausgehen soll (im Allgemeinen eine schlechte Idee, aber bleiben wir dabei). Overflow: auto würde eine horizontale Scrollleiste auslösen. Overflow: hidden würde es abschneiden. Beide Optionen fallen also aus. Aber Sie müssen immer noch den Float leeren, also sind Sie entweder gezwungen, ein zusätzliches Clearing-Element oder den clearfix zu verwenden. Es gibt auch andere Situationen... der Overflow-Aspekt ist generell nicht ideal.
Man könnte auch das Elternelement fluten, um dasselbe zu erreichen, aber ohne Scrollbalken zu verursachen oder das Bild abzuschneiden. Google: „CSS Shrink Wrapping“
Natürlich ist das auch nicht immer ideal
Dann hängt alles von der Situation ab, in der man sich befindet.
Ich benutze ein zusätzliches Clearing-Element, wenn Inhalt aus dem enthaltenden Div herausragt. Oder, besser, wenn das enthaltende Div der Haupt-Container mit 960 Pixeln Breite und zentriert ist und ich möchte, dass die horizontalen Scrollbalken erscheinen, wenn das Fenster neu dimensioniert wird. Die Scrollbalken werden nicht angezeigt, wenn overflow:hidden verwendet wird.
Andernfalls verwende ich overflow:hidden.
Aber niemals mit overflow:auto, da es zu unerwünschten vertikalen Scrollbalken führen kann, wenn zusätzlicher Inhalt hinzugefügt wird.
„Ich höre oft, wie Leute sagen, dass „Floats das Element aus dem Dokumentenfluss nehmen“, was nicht stimmt.“
Das höre ich auch oft und habe die Aussage bisher einfach akzeptiert. Jetzt bin ich mir nicht mehr sicher, was ich denken soll. Selbst wenn Floats das Element nicht aus dem Dokumentenfluss nehmen… sie beeinflussen immer noch den Fluss des Dokuments. Anstatt zu sagen, dass Floats das Element aus dem Dokumentenfluss nehmen, wäre es vielleicht besser zu sagen, dass sie das Element von seinem natürlichen Standort verschieben und die Position der nachfolgenden Elemente beeinflussen???
Ich glaube, die Verwirrung entsteht aus den Unterschieden zwischen dem ähnlich benannten „Dokumentenfluss“ und „Textfluss“. Sehen Sie sich diesen Abschnitt der Spezifikation an, um weitere Informationen zu erhalten
http://www.w3.org/TR/CSS2/visuren.html#comparison
Endlich! Eine sehr gute Erklärung!
Wenn der Text „kollabieren“ soll, warum dann nicht einfach rechts leeren?
Z.B. img { float: left; clear: right; }
Das Problem bei der Hinzufügung neuer Regeln zu CSS oder neuer Elemente ist eindeutig inakzeptabel. Wenn wir das tun würden, wären alle aktuellen Browser veraltet und wir müssten die aktuellen Fixes sowie die „neuen“ Fixes bis 2018 hinzufügen, wenn niemand mehr IE9 verwendet. Das, wenn das W3C die Regeln innerhalb von 2010 anwendet, was wahrscheinlich nicht der Fall wäre. Ich glaube nicht, dass wir darauf warten, eine neue Regel und einen alten Hack zu unterstützen, bis die Hälfte von uns als Entwickler in Rente geht.
„aber was ist, wenn Sie den horizontalen Überlauf ausblenden möchten“
Ein perfekter Anwendungsfall für overflow-x und overflow-y.
Es tut mir leid, wenn das Thema verfehlt ist
Ich habe eine Frage zu gefluteten Elementen im Vergleich zu Listenelementen (ul oder ol).
Wenn die Liste list-style-position „outside“ hat, werden die Aufzählungszeichen nicht von den gefluteten Elementen beeinflusst und liegen dahinter. Gibt es dafür eine Umgehung? Da die Position „inside“ nicht so ordentlich ist wie „outside“.
Guter Artikel, das kann vielen meiner Freunde helfen, weil sie immer Fehler beim Leeren machen…
Ich habe mich gefragt, warum diese Beiträge eine unnötige Lücke hinterlassen. Gute Lösung.
Ich denke, das W3C widerspricht Ihnen.
http://www.w3.org/TR/CSS2/visuren.html#floats
sagt
„Da ein Float nicht im Fluss ist, fließen nicht-positionierte Blockboxen, die vor und nach der Float-Box erstellt werden, vertikal, als ob der Float nicht existieren würde. Linienboxen, die neben dem Float erstellt werden, werden jedoch verkürzt, um Platz für die Margin-Box des Floats zu schaffen.“
Sie präsentieren hier also Pseudo-CSS?
Ich glaube nicht, dass Chris falsch liegt, aber ich denke, eine weitere Erklärung ist notwendig. Wie jemand anderes bereits erwähnt hat, bezieht sich der „Fluss“, von dem gesprochen wird, nicht auf den „Dokumentenfluss“ (wie selbst ich manchmal fälschlicherweise gesagt habe), sondern auf den Fluss von Block-Level-Elementen. Inline-Elemente fließen um geflutete Elemente herum. Sogar SitePoints Referenz macht nicht wirklich klar, ob sie sich auf den „Dokumentenfluss“ beziehen, indem sie nur das Wort „Fluss“ verwenden.
Man könnte also sagen, ein Float wird aus dem „relativen“ Fluss genommen, mangels eines besseren Ausdrucks.
Ich glaube wirklich, dass das hier komplizierter gemacht wird, als es ist. Floats sind Floats, Box/Element, was auch immer. Floats sollten selten verwendet werden.
Jemand gab die einfache und praktische Idee, Floats zur Erstellung von Vorlagen zu verwenden, und es wurde schnell vorangetrieben. Ich finde keinen normalen Anwendungsfall für Floats. Es ist nur Gewohnheit bei manchen Leuten und ein Trend, der bald abflaut, denke ich. Display und Position reichen aus. Man braucht nur die richtige Anwendung.
Wenn Sie niemals Floats verwenden und nur Positionierung nutzen, werden Sie, es sei denn, Sie sind ein CSS-Super-Experte, unwartbare Website-Layouts erstellen. Und ich vermute, selbst wenn Sie ein Super-Experte sind, werden Sie immer noch Schwierigkeiten haben, wartbare Layouts zu erstellen.
Wie wäre es mit „block-flow“ und „inline-flow“ als Unterscheidung?
Also ist Float, eine Ausnahme bei der Positionierung, Ihre Basis für ein CSS-Layout? Ich glaube, Sie ersetzen nur einen schlechten Stil (tabellenbasiert) durch seinen bösen Zwillingsbruder :)
Das ist es, was Tabellenbefürworter gegen CSS-Div-Layouts verwenden.
Ein großer Grund, warum Floats besser sind als Tabellen für Layouts, ist, dass ein Tabellenlayout nicht-semantisch ist und Suchmaschinen und Text-Reader-Browser usw. verwirrt. Mit Floats kann Ihr HTML-Code richtig strukturiert sein. Jeder, der argumentiert, dass Floats der böse Zwilling von Tabellen sind, versteht Semantik und Codierungsstandards nicht, und ich würde vermuten, ist nur ein Amateur-Designer/Entwickler.
@Richard aus Norwegen: Zwei große Gründe, warum Sie ein Amateur sind
– Sie verwenden XHTML, und das ist eine Tag-Suppe für IE, den meistgenutzten (ob man es mag oder nicht) Browser
– Ihre Seite http://www.richardharris.no/ ist nicht semantischer mit Floats: Sie verwenden ein Container-Div, ein Wrapper-Div, bevor Sie überhaupt mit der Eingabe von SEMANTISCHEN Inhalten beginnen.
Ich sehe, dass Sie Tabellen-Style-Code in Ihrem Homepage-CSS haben, aber er wird nicht mehr verwendet, daher glaube ich, Sie sind gerade von ihnen gewechselt. Sie sollten definitiv mehr CSS lernen, bevor Sie Aussagen machen :)
Ulyses: Tag-Suppe bedeutet anscheinend nicht, was Sie denken. Das ist der beliebteste Scheinbeweis der letzten zwei Jahre, daher verständlich, aber es ist immer noch ein Scheinbeweis.
Okay, es scheint, als ob Sie mich hier zu einem Bösewicht machen. Nehmen wir es also Schritt für Schritt. Ich glaube nicht, dass es schlecht ist, die Wahrheit über diesen Artikel zu sagen.
Der Titel ist ein Witz. Ich sehe hier, dass jemand zu den Grundlagen zurückkehren muss und lernen muss, dass selbst eine Inline-Box ein Container sein kann und Auto-Clearing für eine Inline-Box… dumm ist?
Dann erklärt der Autor Chris Coyier:
„Ich möchte speziell über das Problem des „Zusammenfallens“ sprechen, d. h. wie Elemente, die gefloatete Elemente enthalten, diese nicht bei der Berechnung ihrer Höhe berücksichtigen.“
und dann
„Ich möchte hier auch hinzufügen, dass ich oft höre, wie Leute sagen, dass „Floats das Element aus dem Dokumentenfluss nehmen“, was nicht stimmt“
was sich in DIREKTEM WIDERSPRUCH befindet. Wenn Elemente nicht aus dem Fluss genommen würden, würde das nicht passieren.
Eine weitere halbe Wahrheit, die hier gesagt wird, ist die nächste
„Zum Beispiel hat ein Elternelement, das nur geflutete Elemente enthält, eine Höhe von Null.“
Das ist NICHT WAHR, wenn das Elternelement auch geflutet ist.
Dann fährt er fort und sagt
„Die Lösung ist normalerweise trivial. Die Verwendung eines beliebigen Overflow-Werts von hidden oder auto auf dem Elternelement behebt dies. Der clearfix ist ebenfalls beliebt.“
und er gibt den Leuten, die sie entdeckt haben, keine Anerkennung, wie besser in diesem Artikel aus … 2005 hervorgehoben wird: http://www.sitepoint.com/blogs/2005/02/26/simple-clearing-of-floats.
Außerdem erwähnt er keine SEHR GUTE Umgehung (kein Hack) zum Leeren eines Floats, nämlich „Floating nearly Everything“ (FnE).
Und schließlich, was Ihren sogenannten Scheinbeweis betrifft, Tag-Suppe ist GENAU das, was ich denke, aber damit Sie es lernen. Brauchen Sie mehr Details, ich werde Ihnen die WAHRHEIT liefern. Selbst wenn der User-Agent von IE Ihnen hilft, wenn Sie XHTML schreiben, sehen Sie kein XHTML, sondern eine Tag-Suppe, die freundlich als HTML behandelt wird, einfach weil IE keine Dokumente unterstützt, die als application/xhtml+xml ausgeliefert werden. Das habe ich (auf die harte Tour) auch dank http://www.sitepoint.com/forums/showthread.php?t=393445 gelernt.
@Luis: Es ist nicht wartbar, es sei denn, es ist fließend? Kein gutes Konzept.
Ulyses, können Sie mir eine dokumentierte Methode zeigen, um ein wartbares CSS-Layout zu erreichen, das keine Floats verwendet? Ich spreche nicht von einmaligen Tutorials, die die *Möglichkeit* eines Layouts ohne Floats zeigen. Ich bitte Sie, mir in der Praxis zu zeigen, wo ein solches Konzept erfolgreich war.
Ich sage nicht, dass ein Layout mit Floats übersät sein sollte. Ich sage, dass ein paar Floats zusammen mit einer guten Mischung aus Positionierung und sorgfältiger Berücksichtigung anderer Cross-Browser-Prinzipien die praktikabelste Lösung sein werden. Wenn Sie einige reale Beweise liefern können, dass Layouts *keine* Floats benötigen, dann legen Sie los, aber ich bezweifle, dass Sie das können.
Geben Sie mir ein Projekt und ich werde es ohne Floats machen. Und eine bezahlte wäre nett :)
Ich habe eine Reihe von Vorlagen entwickelt, für den Druck oder für den Bildschirm, die keine Floats verwenden. Ich verstehe nicht, warum Sie sie so sehr brauchen. Einen Float braucht man nicht, wenn man Spalten definiert :)
Nur weil w3cschools Ihnen beibringt, Floats für die Definition von Spalten in Ihrem Layout zu verwenden, macht das das nicht zum Gesetz.
@Richard aus Norwegen: Sagen Sie was? Wenn Sie Wrapper-Divs für die Verwendung mit Floats einfügen, macht das Ihr HTML semantisch? Überprüfen Sie das noch einmal :)
Und Ihr CSS ist nicht das, was es sein soll, selbst wenn Sie Ihr HTML helfen. Ein guter Entwickler versucht, gutes HTML UND GUTES CSS zu machen. Vielleicht gehören Sie nicht dazu.
Ulyses, ich spreche nicht von dem, was möglich ist. Und tatsächlich glaube ich, dass es einfacher wäre, ein Layout ohne Floats zu erstellen. Das ist hier nicht das Problem.
Das Problem ist, ob ein Float-freies Layout in einer realen Situation praktisch und wartbar ist.
Nun, ich versuche, keine Floats zu verwenden, und vor allem nicht für das Hauptlayout. Es ist eine Meinung und in der Praxis zuverlässig.
Bisher für mich. Der Tag wird kommen, an dem ich hier keine vollständigen Details mehr poste.
Sie sind derjenige, der in Schwierigkeiten gerät, wenn Sie von Floats wechseln müssen (wie die, die von Tabellen wechseln mussten).
Floats simulieren nur ein Layout, ein Layout, das mit anderen, natürlicheren, „CSS-semantischeren“ Mitteln möglich ist.
Es ist nur grundlegendes CSS, das Ihre Float-Gewohnheiten durch die richtigen ersetzt. IMHO :)
Dieser Kerl ist nur ein Troll. Hören Sie auf, ihn zu füttern.
Seien Sie so freundlich und erklären Sie Troll :)
Ich fühle mich verrückt, das zu sagen, aber ich wünschte mir eigentlich, dass schwebende Objekte die Abmessungen ihres übergeordneten Containers erweitern würden. Ich denke wohl zu „realistisch“. Wie das Einlegen von Schachteln in eine Mülltüte. Man würde niemals erwarten, dass die Beutel durch die physische Materie der Beutelwände driften. Es wäre cool, wenn es eine CSS-Eigenschaft gäbe, die wir dem übergeordneten Element zuweisen könnten, um ein- oder auszuschalten, ob schwebende Kinder es erweitern oder nicht.
Das Problem ist nicht die „float“-Eigenschaft an sich.
Im Kontext Ihres Beispiels – Ausrufungsbild, wie in der Druckgestaltung – funktioniert es einwandfrei. Tatsächlich ist es der vorgesehene Zweck.
Sie haben Probleme, wenn Sie „float“ außerhalb dieses Nutzungskontexts verwenden. Wenn Sie zum Beispiel „float“ verwenden, um Spalten zu erstellen.
Es ist einfach unintuitiv, weil „float“ ein fehlerhaftes konzeptionelles Modell für alles andere ist, außer um ein Element in der Mitte eines Absatzes oder eines anderen Inhaltsflusses schweben zu lassen, um den herum die Browser-Engine weiß, wie sie das Element „umfließen“ kann.
Ganz zu schweigen davon, dass das Verhalten des Float-Clearing zwischen den Browsern völlig nicht standardisiert ist, und man kann ihnen das nicht verübeln. Jeder wird ein anderes Verhalten implementieren, wo die Spezifikationen nicht handhaben, was passieren soll, wenn verschiedene gefloatete Elemente interagieren. Es ist einfach unmöglich, den „richtigen Weg“ zu finden, weil, wiederum, das konzeptionelle Modell kaputt ist.
Deshalb ist es die größte Hürde in CSS.
Ausgezeichneter Beitrag. Ich stimme Ihrer Meinung zu Floats zu. Ich glaube, das WC3 stellte sich eine Möglichkeit vor, align=”right|left” bei Bildern durch eine CSS-Alternative zu ersetzen. Ich denke nicht, dass sie es gut genug durchdacht haben, aber da ich nicht Teil der Diskussionen war, kann ich mir nicht vorstellen, wie schwierig es gewesen sein muss, und ich werde sie nicht verurteilen. Ich freue mich lediglich auf den Tag, an dem diese Art von Problemen hinter uns liegt. :)
Ich stimme zu. Float ist ein falsches Werkzeug, um... zu positionieren. Deshalb gibt es CSS-Eigenschaften wie display und position.
Exzellente Erklärung. Das ist etwas Grundlegendes, das viele Neulinge eine Weile lang nicht begreifen können.
Ich denke, das einzige Problem hier ist, dass die Clear-Methoden als „Fixes“ bezeichnet werden, was, wie Sie sagen, darauf hindeutet, dass etwas kaputt ist.
Nichts ist kaputt, nichts muss behoben werden, es muss nur klar gemacht werden.
Zu viel „float“ zu benutzen, nachdem man zu viel „table“ hinter sich gelassen hat, ist genauso eine große CSS-Sünde.
Float-Gore ist keine gute CSS-Praxis.
Meiner Meinung nach.
Es ist wie der Kampf um semantisches HTML. Wie wäre es mit semantischem CSS?
Ich stimme zu, es ist einfach nicht intuitiv!
Schöner Artikel, Chris,
Ich habe festgestellt, dass der beste Weg, einen Container auf die Höhe seines gefloateten Inhalts zu dehnen, darin besteht, auch den Container zu floaten.
So funktioniert meine Methode für gleich hohe Spalten.
An diejenigen unter Ihnen, die gegen die Verwendung von float für Layouts argumentieren: Was würden Sie stattdessen empfehlen? display und position können Sie nur bis zu einem gewissen Grad bringen. Was ist, wenn Sie...
Eigentlich, je mehr ich versuche, mir eine Situation vorzustellen, in der float die einzige Lösung ist (und einige schnelle Recherchen zu den Optionen mache, damit ich nicht dumm dastehe), desto mehr erkenne ich, dass das Nichtverwenden von floats und das Beibehalten von Flexibilität etwas ist, das einer echten Untersuchung bedarf. Das ist wirklich Stoff zum Nachdenken.
Außerdem sieht dieses CSS-Layout-Modul wirklich gut aus.
Perfekt! Wir haben das gerade heute im Unterricht behandelt, und das wird mir wirklich helfen, meine Hausaufgaben zu beenden. Ich schätze es, Chris! Großer Fan hier.
Ja, ich werde mich cyborg_572 anschließen.
oder man könnte Frameworks wie blueprint oder
960
Hmm... vielleicht lebe ich in einer anderen CSS-Welt, aber meine klassische Lösung, damit gefloatete Elemente nicht frei liegen, ist die Verwendung von clear:both;
IE: Das ist gefloatet! clear both erzeugt die Trennung, die Sie wahrscheinlich erwartet haben
Ups.
Dies ist gefloatet!
clear both erzeugt die Trennung, die Sie wahrscheinlich erwartet haben
Ich benutze Floats, wenn ich genau das tun muss... einige Inhalte zu haben, die sich wie eine Wolke verhalten, einfach da liegen und zulassen, dass Dinge um sie herum geschehen. Es ist sinnvoll, kein Höhenelement zu haben (sofern nicht anders angegeben), da Sie diesem Abschnitt sagen, dass er im Wesentlichen formlos ist und Dinge um ihn herum geschehen lässt.
Ich finde eine Mischung aus absoluter/relativer Positionierung und der Verwendung von Floats, um die Ränder aufzufüllen, als meine persönliche „korrekte“ Vorgehensweise, anstatt eines Layouts, das auf reinen Floats oder reiner Positionierung basiert. Keines von beiden kann noch wirklich korrekt sein, da CSS noch seinen Platz in der Design-/Layoutwelt von Websites findet. Ich denke, in seinem jetzigen Zustand ist es am besten, die Sache ganzheitlich zu betrachten.
Das gesagt, es wäre schön, Spalten und Seitenleisten erstellen zu können, ohne etwas so Mehrdeutiges wie einen „Float“ oder etwas so Exzessives wie die vollständige Positionierung von Elementen angeben zu müssen. Hier kommt CSS3. Je mehr ich mich damit beschäftige, desto mehr bin ich auf der Hut, dass die Mehrheit der Nutzer ihre Browser aktualisiert, da es viele der Probleme löst, die CSS plagen.
Ich denke, was ich sage, ist, dass mit CSS offensichtlich nichts „kaputt“ ist. Wie in diesem Artikel, wenn man es sich genau ansieht, funktioniert es genau so, wie es beabsichtigt war. Aber es ist nur eine neue(re) Technologie in einer der am schnellsten wachsenden Branchen, und die meisten dieser sogenannten Probleme werden mit dem Aufkommen und (am wichtigsten) der Unterstützung neuerer Attribute gelöst, die uns zu einer Welt des rein semantischen Codes führen. :)
Ich erinnere mich nicht mehr, wo ich es gelesen habe (vielleicht ein Sitepoint-Buch), aber jemand schlug die Tabellenlayout-CSS-Eigenschaften vor, um das Problem der Verwendung von Floats für komplexe Layouts zu überwinden.
Man bekommt die Struktur und das Verhalten einer Tabelle – was zugegebenermaßen manchmal für Layouts nett ist – aber ohne das beschissene Markup einer tatsächlichen Tabelle.
Was die Verwendung von overflow zum Clearen eines Floats angeht, für mich ist das ein großes No-Go. Erst letzte Woche musste ich das Float-Clearing auf ein paar gerade begonnenen Templates überarbeiten, weil overflow verwendet wurde, aber es funktionierte überhaupt nicht mehr, als ich die restlichen Elemente zur Seite hinzufügte.
:after-Regeln, obwohl eine Art Contain-Regel schön wäre.
Ja, wirklich eine tolle Idee
Ich habe mich das immer gefragt und jetzt habe ich die Antwort. Danke für die Informationen, und ich werde diesen Leitfaden auf jeden Fall im Hinterkopf behalten, wenn ich das nächste Mal in CSS arbeite!
Ich dehne meine nicht gefloateten Container, indem ich vor dem schließenden Tag ein <div class="clear">
Warum man Floats für Positionierung verwenden sollte, verstehe ich nicht. Floats sind für Elemente, die gefloatet werden sollen. Wenn Sie nicht möchten, dass Ihr nächstes Element Teil des „Flows“ ist – clearen Sie es.