Browser-Bugs
Freitag14. August 2009

Es folgt mal wieder eine Bug-Beschreibung. Firefox hat aktuell ein ausgesprochen hässliches Problem in Verbindung mit CSS Tabellen und JavaScript. Die Kombination der beiden führt in einigen Fällen zu groben Renderingfehlern wobei einzelne Zellen einer Tabellenzeile scheinbar willkürlich in eine neue Zeile umgebrochen werden.

Das Rendering der CSS-Tabellen funktioniert prinzipiell, es ist also kein einfacher CSS-Bug. Ich verwende diese Technik in YAML zur Erstellung gleichhoher Container per CSS. Das eigentlich perverse an diesem Bug - er ist extrem schwer nachvollziehbar. Ich habe die CSS-Tabellen mittlerweile in mehreren Real-Live-Situationen ausprobiert und dabei bereits im Winter erstmals Bekanntschaft mit diesem Bug gemacht. Allerdings war die Fehldarstellung meist nach einem Reload oder auch nur dem Versuch eines Elementchecks mit Firebug verschwunden. Die Ursachenfindung hat das extrem erschwert. Erst vor einigen Wochen hat dann im YAML-Forum ein User einen weiteren Tipp beigesteuert, der letztlich einen Testcase ermöglichte.

Gestern Abend habe ich mich nochmals hingesetzt und endlich einen - zumindest bei mir - funktionierenden Testcase erstellt, sowie den Bug bei Bugzilla gemeldet (Bug 510350) . Die Einzelheiten zum Wie und Warum sind übrigens im Testcase ausführlich beschrieben.

Im Testcase wird der Bug durch eine fast leere Script-Node getriggert, wobei diese hier direkt im HTML-Code der Tabelle steht. Es ist die einzige halbwegs verlässliche Möglichkeit, den Bug zu erzwingen, die ich kenne. In meinen Real-Life-Layouts reichte meist schon die pure Anwesenheit von JavaScript in Form von jQuery oder sonstigem.

Und abschließend: Dieser Bug ist derart fies, dass sein Auftreten auf wundersame Weise sogar vom Dateinamen des Testcases beeinflusst wird. Auf meinem lokalen Rechner tritt der Bug - genau wie in der Netzversion - sporadisch auf. Wenn ich den Testcase jedoch in “index.html” umbenenne, wird er plötzlich permanent getriggert. Das verstehe wer will. Ich hoffe daher, die Mozilla-Jungs finden und eleminieren die Ursache möglichst schnell.


Freitag08. August 2008

Wer gelegentlich unter Windows mit dem Safari surft oder aber mit Safari/Firefox auf dem Mac im Internet unterwegs ist, wird das Problem wahrscheinlich kennen. Die Kantenglättung führt bei hohen Kontrastverhältnissen zwischen Vorder- und Hintergrund zu einem ungewöhnlich “fetten” Schriftbild. Verursacher ist wohl die CoreText-Technologie, welche Apple zur Kantenglättung in OSX einsetzt und welche auch beim Windows-Safari zum Einsatz kommt. Folgender Beitrag erklärt die Unterschiede zwischen der den Kantenglättungsverfahren von Apple und Mircosoft (Danke an Herrn Caspers für den Link).

Der linke Teil des Screenshots zeigt, was gemeint ist. Kleine und mittlere Schriftgrößen wirken so, als ob sie generell im Fettdruck gesetzt wurden. Richtig auffällig wird das beispielsweise unter Windows Vista, wenn man die Darstellung im IE7, Firefox oder Opera zum direkten Vergleich heranziehen kann.

Bekannte Bugfixes

Einige schlaue Leute haben zwei mögliche Bugfixes gefunden, die das Problem zuverlässig beseitigen. Auf Jonnotie werden beide Ansätze vorgestellt. Das Ergebnis zeigt der rechte Teil des oben gezeigten Screenshots, der mit dem Safari/Win entstand.

Text-Shadow-Methode

* { text-shadow: #000000 0 0 0px; }

Diese Methode funktioniert im Firefox und im Safari 3.

Opacity-Methode

* { opacity: 0.9999999; }

Diese Methode funktioniert laut Jonnotie auch in der Entwicklerfassung des Safari 4 und wird daher zur Anwendung empfohlen.

Vorsicht bei der Anwendung

Ich habe beide Bugfixes nochmals getestet und kann die Funktion bestätigen. Dennoch rate ich vom Einsatz in der hier gezeigten Form grundsätzlich ab. Der Grund dafür ist die Wahl des Stern-Selektors, wodurch der Bugfix pauschal auf alle Elemente des Layouts angewendet wird. Sowohl im Firefox als auch im Safari führt dieses Vorgehen zu eklatanten Performance-Einbrüchen im Rendering beider Browser. Spürbar wird das besonders, wenn man die Größe des Browserfensters ändert. Beide Browser beginnen bei Seiten mit viel Text massiv an zu ruckeln, selbst auf schnellen Dual-Core-Prozessoren. Speziell auf Notebooks mit schwachen Grafikkarten sind verstärkt Ruckler zu befürchten.

Wer also mit der Textdarstellung unzufrieden ist, und diese unbedingt korrigieren will, sollte dies mit Bedacht tun. Entscheidend für die Performance ist dabei die Größe (Höhe * Breite) der betroffenen Elemente. Ähnlich wie bei der Alpha-Transparenz von PNG-Grafiken wirken sich kleine Elemente kaum auf die Performace aus. Wird der Fix aber großflächig auf z.B. den Inhalt dieses Weblogs angewendet, wird der Performance-Einbruch sehr schnell spürbar und kann auf langsamen Rechnern/leistungsschwachen Grafikkarten (man denke an Notebooks) störend wirken.

Da es in der Regel aber nur Sinn macht, alle Elemente zu korrigieren, rate ich vom Einsatz dieses Fixes eher ab. Wer mit den betreffenden Browsern surft, dürfte sich mit dem Schriftbild arrangiert haben und die zu befüchtenden Performance-Einbrüche auf einigen Rechnern dürften bei den Besuchern eher einen schlechten Gesamteindruck der Seite hinterlassen als dass Sie die schönere Kantenglättung zu schätzen wissen.

 


Mittwoch18. Juni 2008

Eineinhalb Jahre hat die Entwicklung der Version 3 des Mozilla-Vorzeigebrowsers gedauert. Seit gestern Abend ist er zum Download verfügbar und mittlerweile konnte ich ihn einige Stunden kennenleren. Leider hinterlässt der Browser mich mit sehr gemischten Eindruck, den ich hier auch begründen möchte.

Standard-Theme

Das neue Standard-Theme "Strata" ist in der Community bereits seit einiger Zeit in der Diskussion. Alle Welt wundert sich über den quietschbunten Look der Oberfläche, der dadurch auch nicht gerade von Übersichtlichkeit geprägt ist. Aktuell bin ich unter XP auf das Theme "Phoenity Aura 0.3" ausgewichen. Ebenfalls zu empfehlen - doch leider momentan scheinbar nicht verfügbar - sind die Themes der CrystalFox Serie, die eine leicht KDE-angehauchten Touch verleihen. Auch warte ich noch auf eine finale Version des FF2-Themes für den Firefox 3, an dessen Anblick ich mittlerweile gewöhnt bin.

Den gesamten Beitrag lesen


Donnerstag27. März 2008

Das Entwicklerteam des Opera-Browsers ist ausgesprochen aktiv und immer um die Weiterentwicklung ihres Browsers bemüht. Erst gestern meldete das Opera Desktop Team 100 von 100 möglichen Punkten im ACID 3 Test des Webstandards Projects (im Wettrennen mit Safaris Webkit-Engine) und darf sich nun feiern und auf die Schulter klopfen lassen.

Sehr schön, wirklich. Allerdings kontrolliert der ACID3-Test offensichtlich nicht Ergebnisse grundlegender Rechenoperationen, die jeder Browser beherrschen sollte (sowas wird allgemein nach der Grundschule vorausgesetzt). Und so passiert es, dass der Opera seit Jahren nicht dazu fähig ist, Prozentangaben als reelle Zahlen zu verarbeiten. Stattdessen schneidet er beständig auch in der neuesten Beta-Version Nachkommastellen einfach weg und behandelt Breiten- und Höhenangaben in Prozent als Integerwerte.

Das W3C legt in der CSS2 Spezifikation in Abschnitt 4.3.3 fest:

The format of a percentage value (denoted by <percentage> in this specification) is an optional sign character (’+’ or ‘-’, with ‘+’ being the default) immediately followed by a <number> immediately followed by ‘%’.

Die Definition für <number> findet sich in Abschnitt 4.3.1, die wichtigen Passagen sind markiert:

Some value types may have integer values (denoted by <integer> ) or real number values (denoted by <number>). Real numbers and integers are specified in decimal notation only. An <integer> consists of one or more digits “0” to “9”. A <number> can either be an <integer>, or it can be zero or more digits followed by a dot (.) followed by one or more digits. Both integers and real numbers may be preceded by a “-” or “+” to indicate the sign.

Die Auswirkungen dieses Bugs bekommt man bei der Positionierung von Containern mit flexiblen Spaltenbreiten oder -höhen, sowie bei der Skalierung von Schriftgrößen (man denke an krumme Werte infolge Vererbung) zu spüren, denn wo selbst der IE5 (FF und Safari natürlich ebenso) bei der Rechnung 66.666% + 33.333% = 99.999% (bei Layoutbreiten unter 100.000 Pixeln also effektiv 100 Prozent) errechnen, landet Opera bei 99 Prozent denn er macht daraus 66%+33%. Aus dieser Eigenart ergeben sich dann plötzlich Abstände und Zwischenräume im Layout wo keine sein dürften. Für Webdesigner entstehen hingegen Fragezeichen über dem Kopf und unnötiger Anpassungsaufwand, denn patchen lässt sich dieser Bug leider nicht.

Also liebe Opera-Entwickler: Wenn Ihr mit dem Feiern fertig seid wäre es wirklich ein Segen, wenn ihr Euch dieses Problems endlich mal annehmen könntet. Ich war auch diesmal so freundlich, einen Testcase zu bauen, extra für Euch.

Auf der anderen Seite zeigt sich für mich mal wieder, dass auch die ACID-Tests (mittlerweile in der 3. Generation) für den Alltag nicht die Praxisnähe haben, die man sich eigentlich wünschen würde, um die Rendering-Qualität von Browsern korrekt einschätzen und vergleichen zu können.

Update 16.6.2012: Vor wenigen Tagen ist Opera 12 erschienen. Und mit dieser Version ist dieser “ewige” Bug nun endlich beseitigt. Vielen Dank.

 


Samstag20. Oktober 2007

Aufgrund der späten Stunde hier nur die wichigsten Fakten. Das neueste Firefox Update auf Version 2.0.0.8 bringt einen äußerst hässlichen Bug mit. Auslöser sind floatende Boxen mit negativem seitlichen Außenabständen (Margins). Diese Boxen werden weder in einem ebenfalls floatenden Elterncontainer eingeschlossen (containing floats), noch funktioniert das normale Beenden der Fließumgebung (clearing floats) über ein nachfolgendes Element mit der Eigenschaft clear:both. Ein Versuch mit overflow:hidden (sollte floatende Container ebenfalls einschließen) schlägt übrigens auch fehl. In diesem Fall werden die sonst überstehenden Bereiche einfach abgeschnitten.

Ein entsprechender Testcase steht bereit und ein Ticket bei Bugzilla ist geschrieben. Ich hoffe, die Entwickler sorgen schnellstmöglich für eine Korrektur, denn diese Technik ist bei aktuellen CSS-Layouts sehr verbreitet.

Ach ja, einen Workaround gibt es: Das Clearing mit der Clearfix-Methode funktioniert, ist aber mit Sicherheit keine Dauerlösung.

UPDATE: Es sieht danach aus, als könnte sich das Problem innerhalb der nächsten Woche wieder erledigt haben. Offensichtlich gab es noch weitere “Kollateralschäden”, sodass vermutlich Ende nächster Woche bereits der Firefox 2.0.0.9 das Licht der Welt erblicken wird. Und der Float-Clearing-Bug wird in diesem Update gefixt sein.

UPDATE 2 (31.10.07): Habe eben den RC des Firefox 2.0.0.9 installiert und getestet. Der Bug ist definitiv gefixt und - was YAML betrifft - scheint es auch keine neuen Probleme zu geben.


Seite 1 von 2 Seiten

 1 2 >