Die Verwendung von Prozentwerten für bestimmte Dinge kann in WebKit-basierten Browsern zu leicht unerwarteten Ergebnissen führen. Wenn Sie beispielsweise eine Reihe von Spalten haben, die in Prozentbreiten mit Prozent-Padding eingestellt sind, kann WebKit deren Größen auf ziemlich seltsame Weise berechnen.
Es sind im Allgemeinen Prozente, die das Problem zu sein scheinen. Ich konnte nicht viele Informationen darüber finden, obwohl ich mich erinnere, vor einiger Zeit etwas darüber gelesen zu haben. Ich denke, es hängt damit zusammen, wie Subpixelwerte berechnet werden. Wenn ein Container beispielsweise derzeit 657 Pixel breit ist und vier Spalten mit jeweils 25 % hat, wären diese jeweils 164,25 Pixel breit, und WebKit kommt damit nicht gut zurecht (Rundungsfehler?). Andere Browser kommen mit dem „Subpixel“-Wert gut zurecht.
Vielen Dank an Nicolas Gallagher, der mich darauf aufmerksam gemacht hat. Wenn ich hier zeitlich weit zurückliege, können Sie mich gerne anschreien, aber geben Sie mir Links und Informationen, damit ich diesen Beitrag mit den genauesten Informationen aktualisieren kann, die ich habe. Dieser Link scheint darauf hinzudeuten, dass das Problem schon eine Weile besteht.
Denken Sie daran, dass dies nur dann wirklich ein Problem darstellt, wenn Sie etwas wie in diesen Beispielen mit durchgehenden Farbsäulen tun. Wenn Sie keine visuellen Trennzeichen hätten, wäre es vielleicht kein großes Problem, nur ein geringfügiger Unterschied zwischen den Browsern, den nur wenige bemerken würden.
ne kadar boş işlerler uğraşıyorsun chris bırak bunları yav
Englisch?
i dont know englis, u speak turkis ok?
Google Translate gibt mir: `Lass leere Arbeit sie verrichten, wie sie streben, Chris yav`
auf Türkisch -> sag nicht leere Arbeit, solche Dinge können in großen Projekten wichtig sein
Ich habe das schon früher bemerkt, hatte aber keine Ahnung, dass es sich um ein „Subpixel“-Problem handelt. Ich denke, ich bin einfach von Prozent- zu Pixelabständen gewechselt, nur um es ganz zu umgehen!
ups, was für ein Mist?!
Sie sollten es schnell beheben. Ich verwende Prozente nicht so oft, bin aber auch auf seltsames Verhalten gestoßen.
Hoffentlich gibt es keine Probleme mit em’s vertikal?
John Resig schrieb vor einiger Zeit darüber
Sub-Pixel-Probleme in CSS
Ich habe mir die Demo auf dieser Seite angesehen – IE8 macht es immer noch falsch! Erstaunlicherweise rundet es immer noch auf und bricht das Layout, und dieser Artikel wurde vor 2,5 Jahren geschrieben.
Falsch? Die Entwickler von Microsoft haben eine andere Lösung gewählt. Meiner Meinung nach die am wenigsten bevorzugte, aber man kann es nicht falsch nennen. Wie der Artikel übrigens auch besagt!
… Seltsam, ich habe gerade versucht, ein Div zu erstellen, das 50 Pixel breit war, und 4 Divs, die mit jeweils 12,5 Pixel links floateten, und es gab immer noch eine Lücke.
Wie sich herausstellt, scheint Webkit keine Dezimalpunkte für CSS zu rendern, es rundet diese ebenfalls automatisch.
Ja, es hat mich immer frustriert, dass 3 Spalten mit 33,3 %, 33,3 % und 33,4 % in Webkit funktional dasselbe sind wie die Angabe von 33 % auf jeder ohne Dezimalstelle. Die einzige Lösung ist, auf 33 %, 33 %, 34 % oder eine ähnliche Variante zurückzugreifen.
Ich bin in der Vergangenheit schon mehrmals auf dieses Problem gestoßen, als ich mit flüssigen Gittern gearbeitet habe. Firefox und Opera versuchen, korrekt zu runden, und selbst wenn es ein seltsames Pixel übrig bleibt, finden sie einen Weg, es richtig anzuzeigen. IE und Webkit hingegen schneiden jede Fraktion/jedes Subpixel ab, was dazu führt, dass gefloatete Elemente ihren Container nicht richtig ausfüllen, wenn die Mathematik nicht sauber aufgeht. Wenn Sie sich fast alle derzeit verfügbaren Systeme für flüssige Gitter ansehen, liefern IE und Webkit unterdurchschnittliche Ergebnisse.
Wie John Resig zusammenfasste, gibt es wirklich kein Richtig oder Falsch. Es ist frustrierend, dass nicht alle Browser dieselbe Methode verwenden. Im Fall von Firefox folgt er nicht mehr der CSS-Regel, die besagt, dass beispielsweise vier gefloatete Divs gleich breit sein sollen, während Webkit dies tut. Es gibt Fälle, in denen eine Methode visuell besser funktioniert als die andere, aber das ist nicht universell.
Ich stimme zu, aber es ist definitiv frustrierend, dass, wenn die Prozente mehrerer Spalten sich zu 100 % addieren, man erwarten würde, dass sie 100 % der Zeile ausfüllen, anstatt 98 % (oder weniger in einigen Beispielen) aufgrund des Abschneidens von Bruchteilen von Prozenten.
Selbst wenn die Spezifikation nicht klärt, welcher Ansatz der richtige ist, würde ich vermuten, dass, wenn sich die Prozente zu 100 % addieren, der Designer wahrscheinlich möchte, dass sie die gesamte Zeile ausfüllen, anstatt die Anforderung durchzusetzen, dass sie alle gleich sind, da es weniger auffällt, wenn ein paar Kästchen ein paar „Rundungs-Pixel“ haben, als wenn am Ende einer Zeile viel Platz ist.
Immerhin runden keine der Browser auf und verursachen einen Float-Abbruch!
Nimmt hier jemand am HTML5-Standard teil, damit er versuchen kann, hier etwas Definition hinzuzufügen?
Schauen Sie sich dies in IE/WebKit an, um ein besser illustriertes Beispiel des Problems zu sehen: http://www.designinfluences.com/fluid960gs/12/fluid/none/
Hallo Chris,
wir haben die Subpixel-Rundungsalgorithmen für die wichtigsten Browser für die Entwicklung des Elastic CSS Frameworks behandelt.
Sie können es hier lesen: http://elasticss.com/determination-of-algorithms-used-for-percentage-based-rounding-divs-on-browsers-and-css-frameworks/
Prost
Sergio, ich hatte dieses Framework in der Vergangenheit nicht gesehen, danke für den Link.
Für einige ist die Einbeziehung von JavaScript zur Behebung von Rundungsfehlern aufgrund von Leistungsproblemen auf komplexen Seiten möglicherweise nicht wünschenswert, insbesondere abhängig vom durchschnittlichen Seitenbesucher (langsame Computer), aber es gibt viele Situationen, in denen ein flüssiges/elastisches Raster wünschenswert ist und eine großartige Lösung darstellt.
Wie in Ihrer Überprüfung des Problems vorgeschlagen, wäre es natürlich großartig, wenn die Browseranbieter zumindest dokumentieren würden, wie sie mit Rundungen umgehen. Vielleicht würde es dadurch deutlicher, dass ein Problem vorliegt, und die Chancen wären größer, dass es eine Standardisierungsbemühung gäbe.
Ich habe *margin-right:-1px; fix(IE6/7) für 1-Zeilen-CSS-Grid-Framework verwendet http://www.vcarrer.com/2009/06/1-line-css-grid-framework.html
Ich versuche, das Padding bei Elementen, deren Breiten definiert sind, zu vermeiden, um Komplikationen wie diese zu vermeiden. Wenn möglich, füge ich das Padding dem Kindelement hinzu.
Ich denke, der einzige Weg, dieses Problem zu vermeiden, ist sicherzustellen, dass Sie den Container in ganzen Pixeln teilen können. D.h. wenn Sie in 4 gleich große Spalten aufteilen wollen, müssen Sie die Containergröße von 657 Pixel auf 656 Pixel anpassen.
Technisch gesehen müssen Sie diese Regel befolgen: container.size%number_of_columns = 0
Übrigens ist mir das gleiche Problem bei IE6 und IE7 aufgefallen, wenn Sie beispielsweise eine Containergröße von 101 Pixel in zwei 50% Spalten aufteilen, wird jede davon in IE6 und IE7 51 Pixel sein. Ich schätze, es rundet 50,5 Pixel auf 51 Pixel auf.
Wie einige andere oben erklärt haben, gibt es 3 Arten der Berechnung für Subpixel.
IE-Methode
– klassisches Runden für Subpixel
– abrunden<0.535 ///// 32.3=>32
– führt zu dem Problem, dass gefloatete Divs das Layout brechen, wenn IE zu oft aufrundet.
Opera/Safari-Methode
– immer abrunden von Subpixeln
– z.B. 34,6=>34 ///// 32,3=>32
– führt zu einigen leeren Pixeln links, wenn Divs nach links und rechts gefloatet werden, wenn sie nach rechts gefloatet werden
Firefox-Methode
– komplexer Algorithmus für das Runden
–>http://elasticss.com/determination-of-algorithms-used-for-percentage-based-rounding-divs-on-browsers-and-css-frameworks/
– führt zum besten Ergebnis für Layouts, aber es ist nicht transparent, welches Div welche genaue Größe bekommt.
Sehr cool, danke für die Zusammenfassung, Patrick.
Interessantes Thema, danke
Hallo, das ist ein sehr schöner Beitrag
Wir versuchen sicherzustellen, dass wir den Container bei Bedarf in ganze Pixel für 3 bis 4 Spalten teilen können, aber das ist nicht immer der Fall mit den Bedürfnissen der Kunden, daher ist es gut, Workarounds zu haben, danke. LT
Bitte verwenden Sie Ihr altes CSS-Tricks-Layout…
Opera hat auch Probleme mit Dezimalstellen in Prozent
http://www.brunildo.org/test/percwidth2.pl
Gute Seite und hat auch den Web-Bug mit Webkit behalten. Es ist nützlich mit Browsern und hat den Web-Bug mit Webkit behalten und Padding und Prozentbreiten für Web-Bugs und auch leicht unerwartete Ergebnisse in WebKit-basierten Browsern.
Ich bin auf dieses Problem gestoßen, als ich ein CSS-Gitter geschrieben habe, es nervt
Safari hat das Problem immer noch, aber Chrome ist jetzt gut.
Ich habe einen Comic über die prozentualen Fehler und die Browser gemacht, wenn Sie über die Situation lachen möchten
http://www.digitalpod.co.uk/blog/web-browser-comic-percentage-layouts-with-gaps/
Zum Zeitpunkt des Schreibens hat Chrome (v 35.0.1916.114) immer noch Probleme mit Prozent-Padding, wenn es verwendet wird, um Elemente mit Prozent-Floats zu umschließen.
Schauen Sie sich dieses Fiddle an und erweitern Sie Ihr Fenster.
http://jsfiddle.net/mUudt/
Sie werden feststellen, dass das dritte Kind in die nächste Zeile fällt, sobald der Bereich des Fensters erweitert wird. Der Grund dafür ist, dass das übergeordnete Element ein 1%iges Padding am Container hat und die Prozent-Padding sich ausdehnen, um das letzte (3.) Element nach unten zu verschieben.