Microsoft Internet Explorer doesn't support 8-bit alpha transparency in PNG images until version 7.0.

Fortunately, Angus Turnbull created an excellent fix that adds full PNG alpha transparency to Internet Explorer. It uses an HTC that replaces every PNG image by an DXImageTransform.Microsoft.AlphaImageLoader filter, which is able to display the PNG with its alpha channel.

But this fix has some limitations. For example it cannot handle the CSS properties background-repeat and background-position properly. The latter is especially problematic if you want to use CSS Sprites to reduce the number of HTTP requests to your server. They just don't work without background-position support.

As the image filter doesn't support background-position you have to fake it. That's possible by removing the background image completely from the element, creating a new child element that holds the (filtered) background image, positioning it absolutely inside the parent element and setting overflow: hidden on the parent to hide the rest of the background.

As a proof of concept I refactored the original IEPNGFix and added this feature to the code. I also added a minified version.

I haven't tested this code thoroughly, but feel free to download it or try it out. It's licensed under the LGPL. It contains the original fix, a cleaned up version and the refactored and enhanced version. The positions right, bottom and center don't work, yet. Additionally, some features might not work anymore due to my refactorings, but the included test page still works as expected.

Aaron Gustafson beschreibt in seinem Artikel Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8 eine Möglichkeit, die weitgehend sicherstellen soll, dass heute entwickelte Websites auch in den Browsern von morgen noch korrekt dargestellt werden.

Das ist nicht selbstverständlich. Denn jede Browserversion behebt Fehler oder bringt neue mit sich. Viele Websites werden in neuen Browsern nicht mehr richtig dargestellt.

Das Version-Targeting soll das mit einem einfachen Prinzip verhindern: Man definiert in einem HTTP-Header oder einem äquivalenten meta-Tag die Browser-Versionen, mit denen man die Seite getestet hat. Z.B.:

<meta http-equiv="X-UA-Compatible" content="IE=7;FF=2;Opera=9;Safari=3" />

Wird die Seite nun mit einem neueren Browser (z.B. IE 8) angezeigt, so soll er in einen Kompatibilitätsmodus wechseln — sich also wie ein IE 7 verhalten. Es ist also sichergestellt, dass die Seite korrekt dargestellt wird, obwohl der neue Browser sie andernfalls möglicherweise falsch darstellen würde.

In der Praxis wird es wohl darauf hinauslaufen, dass nur der IE 8 (und aufwärts) dieses Feature unterstützt — andere Browserhersteller kümmern sich ohnehin nicht allzusehr um die Bugs in alten IE-Versionen (obwohl sie den Doctype-Switch alle implementieren). Man wird diesen Header also nur brauchen, wenn man explizit die Rendering-Engine des IE 8 nutzen will. Dann reicht folgende Zeile:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

Diese "Rückwärtsorientierung" empfindet Eric Meyer in seiner Antwort auf Gustafsons Artikel zunächst als sehr negativ. Sie verführt dazu, browserspezifisch zu programmieren, anstatt sich auf Standards zu stützen, die hoffentlich auch in den Browsern von morgen funktionieren.

Allerdings stellt er auch fest, dass das Version-Targeting viele Vorteile mit sich bringt: Die Wartung von Websites wird wesentlich vereinfacht. Nur weil ein neuer Browser rauskommt, muss man nicht die gesamte Website prüfen und evtl. überarbeiten. Außerdem werden die Browser-Hersteller ermutigt, ihre Bugs zu beheben. Viele Bugs wurden im IE lange Zeit nicht behoben, weil sich die Darstellung vorhandener Websites sonst stark verändern würde.

Schlussfolgernd kann man also sagen, dass diese Technik durchaus erstrebenswert ist. Vermutlich wird sie zunächst im IE 8 implementiert, da sie durch eine Nachfrage des IE-8-Teams entwickelt wurde.

Will man von anderen Rechnern aus auf seine Musik zugreifen, so kann man sie entweder auf einen (möglicherweise sehr großen) MP3-Player kopieren und mitschleppen oder sie bei bestimmten Diensten (privat) hochladen.

Eine weitere Möglichkeit ist der Einsatz von GNUMP3d, das die Musik über einen Stream anbietet, der über eine Webseite gesteuert wird.

Wer lieber die eigene Playersoftware anstatt der (nicht besonders tollen) Weboberfläche von GNUMP3d benutzen will, kann einen eigenen Stream-Server installieren und ihn mit der Musik des eigenen Rechners versorgen. Auf dem eigenen Rechner kann man jeden beliebigen Player nutzen, den man per VNC fernsteuern kann.

Dieser Weg wird im Folgenden beschrieben.

Icecast-Server installieren

Mit einem Icecast-Server kann man sozusagen einen eigenen Internetradiosender erstellen.

Dazu Icecast von icecast.org herunterladen und installieren. Danach muss man die Konfigurationsdatei icecast.xml anpassen. Sie liegt im Programmverzeichnis (üblicherweise: C:\Programme\Icecast2). Eine funktionierende Minimalkonfiguration kann wie folgt aussehen:

<icecast>
	<authentication>
		<source-password>hackme</source-password>
		<relay-password>hackme</relay-password>
		<admin-user>admin</admin-user>
		<admin-password>hackme</admin-password>
	</authentication>
	<listen-socket>
		<port>8000</port>
	</listen-socket>
</icecast>

Wichtig: Die Passwörter anpassen! Evtl. will man auch den Port anpassen, auf dem der Server lauscht.

Oddcast zum füttern des Streams

Der Icecast-Server sollte nun funktionieren. Er braucht allerdings eine Quelle, die ihn mit Musik versorgt. Das kann man sehr schön mit Oddcast machen. Dieses Tool kann den Ton abgreifen, der normalerweise über die Soundkarte ausgegeben wird, und leitet ihn an den Icecast-Server weiter. Das hat den Vorteil, dass man somit praktisch jeden Player nutzen kann und nicht auf bestimmte Player wie Winamp angewiesen ist, wo man dann noch Plugins installieren müsste.

Nachdem Oddcast installiert und gestartet wurde, muss man diesem Tool den Icecast-Server bekannt machen. Dazu unten in der Liste auf Add Encoder ⇒ Rechte Maustaste auf den Eintrag ⇒ Configure. Dort muss an praktisch nur das Passwort anpassen. Der Rest kann erstmal so bleiben.

Um den Icecast-Server nun zu füttern, muss man in Oddcast lediglich die richtige Soundkarte und den richtigen Kanal wählen, unten den richtigen Listeneintrag wählen und auf Connect klicken.

Den Stream anhören

Der Stream ist nun unter http://dein-rechner:8000/stream.ogg erreichbar und mit jedem modernen Player abspielbar. Um sich nicht immer die IP-Adresse des eigenen Rechners merken zu müssen, kann man einen Dienst wie DynDNS nutzen.

Durch die Musiksammlung navigieren

Wirklich reizvoll wird das alles natürlich erst, wenn man auch Lieder überspringen/auswählen kann. Eine einfache Möglichkeit ist es, einen VNC-Server einzurichten. Es gibt viele, leicht zu bedienende Implementierungen — ich nutze UltraVNC. Auch hier wieder wichtig: Ein sicheres Passwort wählen!

Firewall

Um von außen auf den Stream und auf den VNC-Server zuzugreifen, muss an diese Dienste natürlich in der Firewall auf dem Rechner freischalten. Wer einen Router einsetzt, muss zusätzlich die relevanten Ports (Icecast: 8000, VNC: 5900) im Router auf den eigenen Rechner weiterleiten.

1. Einloggen
2. Unten im Fuß auf Datenschutz klicken
3. Auf Datenschutz-Erklärung klicken
4. Gaaanz unten auf Einstellungen zur Verwendung meiner Daten klicken
5. Alle Häkchen deaktivieren und speichern

Es wird kein Zufall sein, dass das so gut versteckt ist. Die Kuh war teuer und muss gemolken werden. Insbesondere wenn die Gefahr besteht, dass sie von der Konkurrenz bald zu Steak verarbeitet wird.

Übrigens: Es scheint ein echter Trend zu sein, die Profile und vor allem auch die Namen im StudiVZ zu ändern. In etwa jeder vierte meiner Kontakte hat schon einen abgewandelten oder gekürzten Namen angegeben. Wenn sich der Trend ausweitet, könnte das den Vernetzungscharakter langfristig kippen — denn man findet seine Freunde einfach nicht mehr, wenn sie ihren Namen nicht (richtig) angeben.

Hier ein paar Beispiele: