Problem?

Dass der IE6 manchmal ein übler Troll sein kann und sein Nachfolger IE7 ihm in dieser Hinsicht in nichts nachsteht, brauch ich euch ja wohl kaum erzählen (ich habs jetzt natürlich trotzdem gemacht, einfach um ein cooles Intro zu haben ). Jedenfalls bin ich neulich erst auf einen richtig schönen Fix für ein bekanntes Problem bezüglich der Darstellung von Buttons im IE gestoßen.

Kennt ihr das: Ihr habt einen Button oder ein Submit-Input und gebt dem etwas Padding und schon zerschießt es euch im IE das halbe Formular, weil dieser Browser denkt, er müsse den Dicken markieren, indem er den Padding-Wert verdoppelt?

Na dann seit ihr hier goldrichtig!

Das Problem

Wir haben also einen button oder ein input mit dem type="submit" (der Bug betrifft beides gleichermaßen) auf unserer Seite, was der tut ist uns an dieser Stelle reichlich egal.

HTML

1

<button>Button</button>

Normalerweise rate ich immer dazu die Buttons so zu lassen, wie sie sind und so wenig wie möglich am Styling zu ändern. Natürlich kommt es jedoch vor, dass sie dadurch nicht richtig ins “Corporate Design” einer Firma “fitten”. Und da Kunde==König immer wahr ist, muss man hier und da etwas nachhelfen, dass die Buttons auch zum Rest passen. Sehr häufig muss dazu beispielsweise links und rechts das Padding erhöht werden, damit das alles nicht so zusammengeklatscht aussieht.

CSS

1
2
3

button {
	padding:3px 10px;
}

Alles gut denkt man, aber beim X-Browser-Test macht man schnell große Augen: Im IE6 und IE7 sind es nicht nur 10 Pixel links und rechts sondern mindestens doppelt so viele. Hier ein Vergleich:

Die türkisen Linien sind nachträglich eingezeichnet worden..

Die Lösung

In solchen Momenten möchte man am liebsten in die Tastatur beißen oder die Maus durch die Gegend werfen (@Wireless-Maus-User: tut es nicht!). Aber das ist gar nicht nötig, denn die Lösung ist ganz einfach, nahezu trivial.

Alles, was wir tun müssen, ist eine Zeile CSS mehr zu schreiben:

CSS

1
2
3
4

button {
	overflow:visible;
	padding:3px 10px;
}

Durch overflow:visible hört der IE auf, mehr Padding zu vergeben als eigentlich gewollt. Das Schöne daran ist, dass er 100% valide ist und keinerlei Nachteile hat. Der Tag ist damit gerettet und alle können quietschvergnügt nach Hause gehen!

Frontend-Developer 1:0 Internet Explorer

IE rafft es nicht!

Heute habe ich mal wieder über etwas gestaunt, das der Internet Explorer nicht kann. Folgendes Szenario: Ihr habt ein Bild auf dem unter anderem ein Schriftzug steht, z. B. “Jetzt hier Registrieren!”. Weil die Schrift mit tollen Effekten und dergleichen ausgestattet ist, bindet ihr sie direkt ins Bild ein. Im Frontend wird das Bild über ein img-Tag ausgegeben und soll jetzt verlinkt werden. “Ok..”, dachte ich mir, “..leg ich halt einen transparenten Link darüber!” – Denkste!

Hier erst einmal ein Beispiel, damit ihr auch versteht, was ich meine. Wie nehmen ein Bild und einen Link und packen einen Wrapper darum. Der Wrapper bekommt position:relative, damit wir den Link per position:absolute über das Bild schieben können. Der Link soll natürlich transparent sein, wir wollen ja nicht irgendwie das Bild “übermalen” sondern nur einen anklickbaren Bereich schaffen, also wird der Text versteckt.

Problembeispiel (alle IE-Versionen)

HTML

1
2
3
4

<div class="wrapper">
	<img src="http://www.getfirebug.com/img/firebug-logo.png" alt="Bild"/>
	<a href="http://www.getfirebug.com">Link</a>
</div>

CSS

1
2
3
4
5
6
7
8
9
10
11
12

.wrapper {
	position:relative;
	width:293px;
}
a {
	height:70px;
	position:absolute;
	right:0;
	text-indent:-9999px;
	width:185px;
	top:0;
}

Ergebnis

Link

Ich habe die wichtigen Bereiche nochmal hervorgehoben, der blaue Rahmen umrandet den Wrapper, der rote den Link.

Natürlich ist diese Denkweise nicht verkehrt, sie hat nur einen Haken: In allen von mir getesteten Versionen des Internet Explorers (IE6-9) hat das nicht funktioniert! Im IE kann man den Link einfach nicht anklicken, alle anderen Browser haben damit absolut kein Problem.

Ich dachte erst es liegt daran, dass das Bild den Link im IE irgendwie überdeckt, weil ich kein z-index benutze. Dann habe ich versucht den Text über padding-top und overflow-hidden zu verstecken und dachte der IE eventuell damit besser zurecht. Nichts hat geholfen.. wenn ich den Text nicht versteckte, konnte man nur den Text anklicken, nicht aber den Rest der klickbaren Fläche. Erst als ich das Bild aus dem Quellcode entfernt hatte, konnte man ganz plötzliche die komplette transparente Fläche anklicken.

Natürlich war ich schon wieder kurz vorm Platzen.

Lösung

Ein ähnliches Problem mit nicht anklickbaren Links hatte ich zwar schon mal im IE6 aber ich hätte nie gedacht, dass IE8 und 9 hier immer noch solche Probleme haben. Aber was soll’s, eine Lösung musste her und es gibt zwei Wege, wie man das Problem umgehen kann..

1. das Bild nicht als img-Tag einbinden, sondern dem Wrapper/Link als background-image zuweisen
2. dem Link ein transparentes Hintergrundbild verpassen

In meinem Fall war letztere Variante günstiger, ich würde aber prinzipiell eher zu Variante eins raten, da sie sauberer ist. Und ja, sobald der Link eine Hintergrundfarbe oder ein Hintergrundbild bekommt, kann man ihn auch im IE anklicken, verrückte Welt oder?

Beispiel mit Lösungsvariante 1

HTML

1
2
3

<div class="wrapper">
	<a href="http://www.getfirebug.com">Link</a>
</div>

CSS

1
2
3
4
5
6
7
8
9
10
11
12
13
14

.wrapper {
	background:transparent url(http://www.getfirebug.com/img/firebug-logo.png) repeat 0 0;
	height:89px;
	position:relative;
	width:293px;
}
a {
	height:70px;
	position:absolute;
	right:0;
	text-indent:-9999px;
	width:185px;
	top:0;
}

Ergebnis

So klappts auch im IE!

PS: Firebug 1.6 wurde heute veröffentlicht, schnell runterladen oder updaten und die Beispiele damit untersuchen!

WP e-Commerce UTF-8 Bug

Wenn man einen Shop in seine WordPress-Installation integrieren will, führt wohl kaum ein Weg an WP e-Commerce vorbei. Trotz zahlreicher Schwächen ist es im Vergleich zu den anderen Plugins in den schier unendlichen Weiten des Plugin Directories das kleinere Übel.

Ein Bug, der mich einiges an Zeit kostete, war die falsche Ausgabe von Adressen mit Umlauten oder “ß” im Namen, was in Deutschland recht häufig der Fall ist (“Straße”). Die Adressen wurden richtig kodiert in die Datenbank gespeichert (darauf achten, dass sie auf UTF-8 gestellt ist) aber es wurden immer komische Zeichen wie ü, ö oder � ausgegeben.

Das Problem des Russen, betrifft alle Zeichen die außerhalb des Ami-Alphabets sind..

Nach einigen Rumgooglen (tolles Wort oder?) fand ich schließlich in einem russischen Forum die Lösung. Großer Dank geht dabei an die Übersetzungkunst von Google .

Der Threadersteller hatte genau das gleiche Kodierungsproblem – die Adressen wurden von WP e-Commerce nicht in UTF-8 ausgegeben. Die dargestellte Lösung behebt das Problem, alles was man tun muss ist eine Zeile im Plugin zu verändern.

In der Datei plugins/wp-e-commerce/wpsc-includes/checkout.class.php die Zeile 348:

1

$saved_form_data = htmlentities(stripslashes($_SESSION['wpsc_checkout_saved_values'][$this->checkout_item->id]), ENT_QUOTES);

mit folgendem Code ersetzen:

1

$saved_form_data = htmlentities(stripslashes($_SESSION['wpsc_checkout_saved_values'][$this->checkout_item->id]), ENT_QUOTES, 'UTF-8');

Und siehe da, die Adressen, Namen und Städte werden ordentlich, d.h. in UTF-8 kodiert, ausgegeben. Hoffe, das hilft einigen weiter.