Code Styling Project

Während der Arbeit an meinem neuen, erweiterten Plugin Page Columnist hab ich schmerzhaft zur Kenntnis nehmen müssen, daß Browser eine eigene Vorstellung von Mathematik, Prozentrechnung und Fehlerkorrektur haben.
Es ist ja schon länger bekannt, daß es Probleme gibt, wenn man mit prozentualen Angaben arbeitet. Wenn man jedoch versucht, auf die Eigenheiten der Browser einzugehen, erlebt man ungeahnte Überraschungen.
Eine allgemein gültige Lösung des Problems scheint unmöglich, man kann sich dem nur annähern.

Ziel meines neuen Plugins ist es ja, die nextpage Funktionalität von WordPress im Bereich der Seiten sozusagen zu erweitern, damit diese wahlweise die Unterseiten als Spalten darstellen kann. Dies würde eine normale Eingabe der Spalteninhalte ermöglichen und man braucht nur die nötigen Spalten per nextpage abzutrennen.

Diese Herangehensweise kommt dem normalen Blog Nutzer entgegen, der sich mit Themes, PHP und CSS nicht auseinander setzen will. Auch sind Herausgeber eines Blogs dann in der Lage, Seiten im Spaltenlayout zu entwerfen, ohne in das Theme eingreifen zu müssen.

prozentuale Angaben für die Breite von div Containern

Die Browser verstehen ja alle prozentuale Angaben für Breiten und auch Ränder. Somit sollte es ja einfach sein, die Breite der zu erzeugenden Spalten prozentual von 100 % her ausrechnen zu lassen unter Berücksichtung von y Rändern zu je x % zwischen den Spalten. So wurde auch das ursprüngliche Konzept erstellt und umgesetzt.

Als Ergebnis dessen zeigte sich, das alle Browser bis auf den IE in der Lage waren, die links umfließenden Spalten nebeneinander zu bekommen. Der IE patzt bei der letzten Spalte je nach “Mondstand” und bricht diese unter die existieren Spalten um. Was also macht der IE da ?

Testarena von 4 Browsern

Um dem Ganzen auf den Grund zu gehen, hab ich in der Entwicklerversion des Plugins die Breiten der entsprechenden Spalten mit anzeigen lassen und die 4 Browser mit dem auf Breite fixierten Standard-Theme übereinander verglichen. Hier das Ergebnis:

Wie man dem Test entnehmen kann (bitte anklicken zum vergrößern), haben einige Browser eine merkwürdige Vorstellung von Prozentrechnung.

Obwohl alle Browser durch die Bank weg mit 31.33 % Breite der Container erzeugt wurden, sind die realen Pixel basierten Breiten sehr unterschiedlich.
Firefox und erstaunlicherweise auch IE errechnen dafür 141px reale Breite. Opera aber meint, das dieser Prozentwert nur 139px entspricht und der Safari hat Mut zur Lücke und kommt auf 140px.
Das ergibt nun schon mal 3 verschiedene Summen:

1. Firefox und IE: 141px * 3 = 423px
2. Safari: 140px * 3 = 420px
3. Opera: 139px * 3 = 417px

Das sind schon 6px Differenz zwischen größter und kleinster Kalkulation, die man deutlich sehen kann. Aber dem eigentlichen IE Problem kommt man über die Spaltenbreite nicht auf die Schliche, denn diese stimmt mit der von Firefox überein. Übrigens hat Firefox keine Fehler in all den Tests gemacht und dient als Referenz für alle anderen Browser bei mir.

Wurzel des IE Übels - prozentuale Ränder (margin)

Der IE beherrscht es überhaupt nicht gut, mit margin Angaben auf prozentualer Ebene umzugehen. Selbst wenn alle errechneten Werte aller Spaltenprozente und Abstandsprozente exakt 100% in Summe sind, bricht der IE unter Umständen die letzte Spalte um. Selbst wenn man künstlich dafür sorgt, dass man unter 100% bleibt und niemals 100% erreicht, hilft das überhaupt nicht. Denn die margin Werte in % Angaben rechnet der IE irgendwie falsch, jedoch ist nicht erkennbar nach welchem Muster.

Daher hab ich mich entschieden, für IE alle margin Werte mit einem serverseitigen Korrekturfaktor anzupassen. Sagen wir mal 3% ist der eigentliche margin Wert. Dann werden alle Spaltenbreiten unter Berücksichtigung von 3% Abständen berechnet, was auch stimmt, nur werden die margin Werte selbst dann nicht mit 3% sondern mit 3% * 0.66 = 1.98% eingetragen. Dieser Korrekturwert ist bei Tests mit fluid Themes entstanden, die auch 1600px Breite ausnutzten.

Der Pferdefuß daran ist, wenn die verfügbare Gesamtbreite niedriger wird, müßte dieser Fehlerkorrekturwert umgekehrt proportional (evtl. logarithmisch) ansteigen. Im Standard-Theme bräuchte man so in etwa den Korrekturwert 0.75 was zu 2.25% führen würde. Diese margin Korrektur ist im Screenshot auch zu erkennen, aber für den IE nicht anders lösbar. Wenn jemand einen besseren Vorschlag hat, ich bin gespannt.

Fazit der bisherigen Tests

Als einziger Browser kann Firefox die verfügbare Gesamtbreite gleichmäßig aufteilen, hat eine hervorragende Fehlerkorrekturrechnung und nutzt exakt die 100% Summe aller Spaltenbreiten und Abstände, um auf die geforderten 100% total zu kommen.

Der IE kann zwar erstaunlicher Weise die Spaltenbreiten korrekt berechnen, hat aber erhebliche Probleme, die Abstände in den Griff zu bekommen. Eine 100% Summe führt je nach verfügbarer Gesamtbreite zum Umbruch der letzten Spalte, hier muß man in die Angabe der Abstände eingreifen, um Schlimmeres zu verhindern!

Opera und Safari haben in den Tests zwar nie umgebrochen, jedoch nutzen sie die 100% Gesamtbreite nicht aus. Je nach verfügbarer Gesamtbreite variiert der verbleibende Leerraum nach der letzten Spalte. Während das beim Safari nur eine geringe Toleranz zu sein scheint, macht Opera zum Teil wilde Sprünge von mehr als 10px, wenn man kontinuierlich die Gesamtbreite erhöht.

Wenn man also prozentual arbeiten möchte (oder muß), sollte einem klar sein, das es Leerraum am Ende geben kann und das man den IE eine spezielle Behandlung zukommen lassen muß.