Sascha Postner macht Jagd auf Kommunikation, Webstandards und Public Relations

 

Archiv für die Kategorie „Browserbugs“

Browserkrieg 2.0? Google steigt ein in die Webbrowser-Entwicklung.

Dienstag, 2. September 2008

Da habe ich gerade noch gestern zusammen mit David Maciejewski und Daniel Jagszent die neue Beta 2 des Internet Explorer 8 mal etwas näher unter die Lupe genommen habe und wir durchaus angenehm überrascht und zufrieden mit der Entwicklung des Microsoft Browsers waren, vermeldet heute Google, dass sie einen eigenen Browser Namens Chrome herausbringen werden.

Da zeichnet sich IMHO ein neuer Browserkrieg ab, in dem dann vor allem vier “Big Player” versuchen werden den Kuchen aufzuteilen. Wie schwer es allerdings für Google werden dürfte den eigenen Browser unter das Volk zu bringen zeigen ja die Zahlen des Firefox-Browsers, der immerhin den Markt wieder etwas in Schwung gebracht hat. Wie schnell Safari von Apple hier zum Achtungserfolg des Mozilla-Projekts aufgeschlossen hat (immerhin derzeit bereits runde 6.4% Marktanteil) und die relative Stagnation des Feuerfuchses zeigen, dass ein eigenes OS als gute Vermarktungskanal durchaus wichtig ist.

Da einige neue Funktionen des Platzhirsches “Internet Explorer” durchaus der Google-Politik “Daten sammeln was das Zeug hält” entgegenwirken, wie z.B. InPrivate Browsing und vor allem InPrivateBlocking (höre den Podcast für mehr Infos), erscheint diese Kampfansage heute wie eine Verteidigung des Werbe-Geschäftsmodells und der Siteübergreifenden Datensammlung ala Google-Analytics und WebSense.

Wie auch immer diese Grabenkämpfe weitergehen, die Hinwendung von Microsoft zu Webstandards und die guten Entwicklungen des Internet Explorers zeigen wohin die Reise derzeit geht. Webstandards, Individualisierung, Sicherheit und Usability. Wenn sich da alle Hersteller dran halten, kann ein solcher Browserkrieg 2.0 letztlich vor allem dem Anwender nützen. Schade wäre es nur, wenn im Kugelhagel zwischen Google, Microsoft und Apple vielversprechende Projekte wie der Firefox- oder Opera-Browser auf der Strecke blieben!

Popularity: 35% [?]

Flackern/Springen bei Link:hover im IE7

Mittwoch, 28. Februar 2007

Trotz aller Unkenrufe entwickele ich auch derzeit fleißig an barrierefreien Webseiten. Und bei der Arbeit zu einem aktuellen Projekt bin ich auch mal wieder über einen Internet Explorer Bug gestoßen. Diesmal aber mit einer kleinen Besonderheit zu allem was mir vorher widerfahren ist: Dieser Bug scheint nur im IE7, nicht jedoch im IE6 aufzutreten.

Ich gebe zu, dass ich mir nicht die Mühe gemacht habe alles bis ins letzte Detail auszutesten, so kann es also sein, dass der DOCTYPE eine Rolle spielt oder, dass der Bug doch im Internet Explorer 6 existiert, aber mit bestimmten Einstellungen auf meinen Testrechnern unterdrückt wird. Wie auch immer hier isser.

Der Bug im IE7

Es sollte sich von selbst verstehen, aber natürlich kann man das Verhalten live nur im IE7 nachvollziehen ;) . Was passiert?

Beim bewegen der Mouse über den Link springt er plötzlich nach links. Das liegt jedoch nicht an einer Auszeichnung in der Pseudoklasse :hover und ist einfach nicht gewollt. Ein Reload der Seite bringt den Link wieder an die richtige Position.

Schauen wir uns einmal an wie der HTML und der CSS Code aussieht:

CSS

a:hover { background-color: red;}
#center-content {
position: relative;
border:1px solid red; }

.lbContent {
border: 1px solid #CCC;
margin-left: 100px;
float:left; }

HTML

<div id="center-content">
<div class="lbContent"><a href="http://blog.postner.de/#">Hover this link</a></div>
<br style="clear: both" /></div>

Das Problem

Scheinbar verliert der DIV-Container mit der CSS-Klasse lbContent im Moment des Hovers den Margin-left von 100px.
Ich konnte den Bug relativ weit eingrenzen, denn es IST wichtig, dass der umrandende Container relative positioniert ist (was natürlich gelegentlich vorkommt, da man ja so darin enthaltene Objekte an ihm orientiert absolute positionieren kann) UND es scheint auch wichtig zu sein, dass der Container, der in diesem Beispiel hüpft floated.

Die Lösung

Wenn man alle Ratschläge der Gurus befolgt wird man vermutlich gar nicht auf diesen Fehler stoßen, denn er resultiert letztlich aus dem Link, dem beim hover eine andere background-color zugewiesen wird.
Wie schon erwähnt, ich habe nicht endlos getestet ob es auch mit anderen styles, anderen Verschachtelungen oder anderne Testumgebungen funktioniert, aber bei mir wurde das Problem in der Tat durch die Hintergrunfarbe des Links hervorgerufen.

Eine einfache Zuordnung einer Hintergrunfarbe auch für den “normalen” Link hat das Problem behoben (wie immer zu einfach um es für wahrscheinlich zu halten!).

a:link, a:visited, a:active { background-color: #fff;}

Das war es schon! ;) Easy! Und da die Empfehlung eh heißt, wenn du eine Schriftfarbe bestimmst, bestimm auch eine Hintergrundfarbe sollte es für die meisten Leute keine Probleme geben.(Bitte beachtet, dass ich in den funktionierenden Beispielen auf dieser Seite einiges anders gebaut habe als ich es in den Codeschnipseln zeige, um es hier gut darstellen zu können, der Quelltext dieser Seite ist also unterirdisch und hier flackert sonst auch viel auf der Seite! ;))

Ich hoffe das hilft dem einen oder anderen. Vielleicht hat ja jemand Lust das ganze auch in Englisch zu übersetzten (und mir entweder den Text oder einen Link auf die Englische Erklärung zu senden). Oder ihr zeigt mir wo der Bug bereits seit Monaten beschrieben wird ;)
Sollte es noch andere Nebeneffekte oder ähnliche Auswirkungen mit anderen Konfigurationen geben sagt mir Bescheid.

Sorry noch einmal für diese knappe Aufbereitung, mir fehlt die Zeit. Ich finde es einfach wichtig solche Dinge zu berichten, damit auch andere davon profitieren können.

Denkt dran: http://www.technikwuerze.de/ ;)

Popularity: 19% [?]

Safari jetzt auch auf Windows

Freitag, 4. August 2006

Jedem ernsthaften Webseiten Betreiber und Designer ist das Problem bekannt. Unterschiedliche Browser zeigen den gleichen Quelltext auf dem Bildschirm der Besucher unterschiedlich an. Dadurch wird es notwendig die eigenen Webseiten unter vielen verschiedenen Bedingungen zu testen, um eine möglichst optimale Darstellung bei möglichst vielen Menschen zu ermöglichen.

tortendiagramm.png

Dabei werden einem so einige Steine in den Weg gelegt. So kann man auf “normalem” Weg zum Beispiel nur eine Version des Internet Explorers auf seinem Rechner installieren. Ein weiteres Problem betrifft die Betriebssystemkompatibilität. So war es bisher nur möglich Webseiten auf einem Mac-System mit dem Browser Safari zu testen. Aber wer, der nicht sowieso auf einem Mac arbeitet, hat zuvällig noch ein teures Testsystem zur Verfügung um darauf die Seite für alle Safari-Surfer zu optimieren?
Auch Dienste wie BrowserCam bieten nur sehr eingeschränkte Hilfe, da man so zwar einen Screenshot zum Vergleichen erhält, aber Funktionen und “Feeling” nicht wirklich testen kann.

Seit Kurzem gibt es aber dankenswerterweise eine Lösung. Unter dem Namen Swift wurde ein Windows Browser erschaffen (derzeit Alpha-Status), der die gleiche Renderingengine nutzt, wie Safari auf MacOS. Eine erste Testinstallation verlief bei mir prima. Beachten sollte man aber, dass auf dem Rechner auch das .NET 2.0 Framework installiert sein muss. Sonst quittiert die Installationsroutine den Dienst mit dem Hinweis auf die fehlende “WebKit.dll”.

A web browser for Windows based on the Apple WebKit rendering engine.
GetWebKit

Dieser Browser erleichtert die Arbeit für Webdesigner erheblich und auch Webseitenbetreiber können so leichter überprüfen ob die von den Agenturen versprochenen Kompabibilitäten wirklich gegeben sind. Allerdings wird sich erst noch heraus stellen, ob die Engine auf Windows wirklich alles genau so anzeigt wie auf MacOS.
Aus Anlass der Veröffentlichung dieser Software, möchte ich auch noch kurz darauf Hinweisen, welche Browser ich zum testen so nutze. Zugegebener Weise achte ich dabei vor allem auch auf die Verbreitung der Browser.

Zum Testen nutze ich neben InternetExplorer (sowohl IE6 als auch IE5 und IE5.5), Firefox, Netscape, Opera und dann jetzt auch noch häufiger Safari (eigenständig lauffähige Versionen gibt es zum Beispiel im Broser Archiv von evolt.org).

Selbstverständlich kann man je nach Projekt auch noch auf andere Browser wert legen, so hatte ich zum Beispiel auch eine Kundin, die dringend auf IE5.1 für Mac optimierte Seiten benötigte. Bein anderen Seiten kann man vielleicht bestimmte Browser ausschließen.

Wer aber von Anfang an zugängliche Seiten geschraubt hat wird hier nur sehr wenig Überraschungen erleben und braucht wenig optimieren. ;)

Würde mich freuen wenn Ihr Tipps oder Hinweise für Crossbrowsertesting habt. Gibt es wichtige Browserversionen (ausserhalb der IE Reihe) die man beachten sollte, wo man vielleicht mehrere Versionen nebeneinander benötigt?

Ganz nebenbei geht auch noch ein kleiner Dank an Paul Boag von boagworld.com, unser großes Vorbild was das Podcasten angeht ;) . Er hat mir erlaubt das Mikrofon in dem neuen Batch oben rechts von seiner Site zu kopieren…

Popularity: 14% [?]

The IE inline-wrap bug

Donnerstag, 20. April 2006

Deutsche Version

(There is also an English version of this article)

Der Internetexplorer stellt ja bekanntlich nicht alles so dar wie es standardkonform logisch wäre. Ein Fehler, der mich schon seit Jahren aufregt, möchte ich inline-wrap bug nennen. Das Problem tritt auf, wenn man ein inline element (z.B. span oder a) umbricht, d.h. über zwei Zeilen laufen läßt. Weißt man einem solchen Element bestimmte CSS Regeln zu, so werden diese nicht so angezeigt wie der logische Menschenverstand einem dies suggerieren würde bzw. die Standards definieren.

Am auffälligsten ist dieser Fehler bei Hintergrundbildern. Auf dieser Seite nutze ich beispielweise ein Wordpress Plugin um Links ein kleines Icon anzufügen und so externe Links, die in einem neuen Fenster geöffnet werden, zu markieren (das ganze setze ich auch oft ohne Wordpress ein). Sobald ein solcher Link am Ende einer Zeile umbricht wird das Hintergrundbild nicht richtig angezeigt (linker Pfeil im folgenden Bild). Wie es eigentlich aussehen sollte zeigt der erste Link im Bild (rechter Pfeil).

problem_2.gif
Abb.1: der inline-bug im IE6

Wenn man genau hinsieht erkennt man beim ersten Wort des zweiten Links (“Brian”) unten am “n” noch ein paar blaue Pixel, die von dem eigentlich in der nächsten Zeile zu erwartenden Hintergrundbild übriggeblieben sind.

Die CSS Regel die dies bedingt sieht wie folgt aus (mehr Details könnt Ihr auch noch in dem Artikel “Besondere Links ohne Aufwand markieren” nachlesen)


a.liexternal {
padding-right: 12px;
background: url("/images/icons/link-icon_external.gif") no-repeat right;
}

Dieses Problem kommt dadurch zu Stande, dass der Internet Explorer das inline Element (in diesem Fall der a tag) von den Dimensionen her so abgrenzt, dass der rechte Rand des Elements am rechten Rand des Absatzes ist. Richtet man nun ein Hintergrundbild rechts aus, so wird es am rechten Rand des Absatzes angezeigt. Besser ist dieses Phänomen zu sehen wenn man den CSS Code so modifiziert, dass das Icon rechts und oben positioniert wird.


a.liexternal {
padding-right: 12px;
background: url("/images/icons/link-icon_external.gif") no-repeat right top;
}

Dies führt zu folgendem Ergebnis:

problem2.gif
Abb.2: der inline-bug im IE6 mit Background top

Selbst Wikipedia (schaut euch einen Artikel an der externe Links am Ende der Seite hat und verkleinert das Fenster so weit, dass der Link umbricht) hat dieses Problem und scheint machtlos zu sein. Leider habe ich bisher keine Lösungsansätze im Internet gefunden. Es blieb daher nur die Möglichkeit darauf zu achten, dass es keinen Umbruch in den Links gibt.

Die CSS-Lösung

Die erste Idee war, dem ganzen Link die CSS-Regel “white-space: nowrap” hinzuzufügen um einfach den Umbruch zu verhindern. Leider führt selbst dies nicht dazu, dass der IE die Abgrenzungen des Elements korrekt rendert. Umgehen kann man dies, indem man ein “display: inline-block” benutzt. Dieser Wert für “display” ist Teil der CSS 2.1 Specification des W3C, wird aber leider nicht von Gecko basierenden Browsern unterstützt (Ein miracle! Sonst ist das ja tendenziell eher andersrum).
So wird der Link im InternetExplorer immer als ganzer “Block” angezeigt und das Hintergrundbild ist an der richtigen Stelle.
Damit wäre eigentlich schon alles OK, ich finde es aber nicht so nett, dass im Firefox dann der Link umgebrochen wird, auch wenn er dort dann korrekt aussieht.

loesung1_1.gif
Abb.3: Anzeige mit “display: inline-block” im IE6
korrekt.gif
Abb.4: Korrekte Anzeige im Firefox

Dies läßt sich angleichen indem man nun noch die Regel “white-space: nowrap” hinzufügt. Dann wird sowohl im IE als auch im Firefox die Anzeige wie in Abb.3 aussehen.

Der entgültige CSS-Code sieht dann so aus:

a.liexternal {
padding-right: 12px;
background: url("/images/icons/link-icon_external.gif") no-repeat right top;
display: inline-block;
white-space: nowrap;
}

Leider validiert nun das CSS-File nicht mehr, zumindest solange man die Standardeinstellungen des W3C Validators nutzt. Ruft man diesen jedoch über seine Adresse jigsaw.w3.org auf so kann man als Option auch CSS2.1 auswählen, womit auch dieser Code validieren kann. Schließlich ist der Wert ja bereits in den CSS 2.1 Spezifikationen enthalten.

Ein weiteres Problem wird durch Opera generiert. Michael Wöhrer hat in seinem Blog darauf hingwiesen, dass display: inline-block in diesem Browser dazu führt, dass das Element ein paar Pixel nach oben verschoben wird. Deshalb ist es sinnvoll diese CSS Regel in eine extra Datei zu packen die nur vom InternetExplorer aufgerufen wird (hier können dann auch alle anderen IE Hacks rein). Dazu kann man am besten Contitional Comments nutzen. So wird die Regel überhaupt nicht mehr in anderen Browsern ausser dem IE5+ interpretiert.
Das ganze sieht dann zum Beispiel so aus:

<!--[if gte IE 5]>
<style type="text/css" media="screen">
@import url( styles/style_ie.css );
</style>
< ![endif]-->

Diesen Code in den Head des Dokuments packen und die oben erwähnte CSS-Regel in die Datei styles/style_ie.css.

Anregungen und Codeverbesserungen sind jederzeit willkommen und gerne gesehen!

English Version

(es gibt auch eine deutsche Version des Artikels)

In this article I would like to talk about a very special internet bug, which could be called inline-wrap bug. This problem occurs if an inline element (i.e. span or a) wraps over two lines in the Internet Explorer. If those elements have some “special” CSS rules, they are not redered as anybody would expect or as the W3C Guidelines/Standards define it.

A good example are background-image for link tags. On this and many other sites I use a tiny little Skript to mark external links, which will open in a new window, with an icon behind it (I use a Wordpress Plugin here, on other sites I use a Javascript).
If such a link wraps at the end of a line, the background-image is not displayes (corretly). See the left arrow in the next picture for the problem and the right arrow for an example of the correct marking.

problem_2.gif
Img.1: the inline-bug in IE6

If you have a closer look at the first word of the second link (“Brian”), you might see a some blue Pixel at the botom right of the “n”, which are left from the expected background-image.
The CSS rule which does that can look like that:


a.liexternal {
padding-right: 12px;
background: url("/images/icons/link-icon_external.gif") no-repeat right;
}

This problem is occuring because the Internet Explorer is giving the inline elements (in this case an a-tag) wrong dimensions, if the element is wraps. IE calculates the right border of the element at the right border of the paragraph. If now a background-image is positioned at the right border of the tag, it is automaticaly positioned at the right border of the paragraph.
You can get a better understanding of the problem if you position the image right and top of the link.


a.liexternal {
padding-right: 12px;
background: url("/images/icons/link-icon_external.gif") no-repeat right top;
}

This displays like that:

problem2.gif
Img.2: the inline-bug in IE6 with background top

The problem even occurs on Wikipedia (check an article with external links at the end and resize the browserwindow so that they wrap) and I have not found a solution on the web yet.

The CSS solution

My first idea was to simply give the link a “white-space: nowrap”, which would prevent any line wrapping. As you can imagine IE will not display the background-image in the right spot although the link is in the second line and in one piece.
The solution is to use “display: inline-block”. This value is part of the CSS 2.1 Specification of the W3C but is not supported in Gecko based browsers yet (a miracle!).
Styling the link this way the InternetExplorer renders it as a block and the background-image is at its correct position.

This is OK (even with the disadvantage that now no link can wrap), but i.e. Firefox is still wrapping the link. If you are not angry about sites which look different in two browsers you are fine.

loesung1_1.gif
Img.3: output with “display: inline-block” in IE6
korrekt.gif
Img.4: correct output in Firefox

We can prevent this issue bei just adding “white-space: nowrap” to your CSS rule. This does the trick! Now IE and Firefox should output the text like you can see in Image 3.

Final CSS code:

a.liexternal {
padding-right: 12px;
background: url("/images/icons/link-icon_external.gif") no-repeat right top;
display: inline-block;
white-space: nowrap;
}

Unfortunately now the CSS file is not validating anymore… as long as you use the standard options of the Validator. But if you use the jigsaws direkt adress, you can choose the specifications you want to use (i.e. CSS2.1). So even this code can be validated.

Another problem is coming up in Opera. In this Browser the Element which has display: inline-block in his rules, is moved some pixels up. Michael Wöhrer mentioned this in his Blog. That’s why it is urgent to use Contitional Comments to let this rule only appear for the IE5+. Just put our CSS Code into a file called i.e. styles/style_ie.css and include it in the following way into the head of your documents:

<!--[if gte IE 5]>
<style type="text/css" media="screen">
@import url( styles/style_ie.css );
</style>
< ![endif]-->

Corrections and hints for better code and/or other solutions are appritiated.

Popularity: 43% [?]

Diese Seite hat Beta Status!
Mein XING-Profil. Mein Linkedin-Profil. Mein PGP-Schlüssel. Meine Amazon Wunschliste. Mein Twitter Account.
Volltextsuche Im Blog nach