Standortdaten im Browser auf stationären Computern

12 02 2011

Jaja, irgendwann ist alles mobil und wireless und in der Cloud, aber bis dahin benutzen wir noch ab und an bis immer stationäre Computer, die an Kabeln hängen. Die meisten modernen Desktopbrowser (auch der IE ab Version 9) unterstützen die Abfrage von Standortinformationen durch Websites, etwa um bequem die nächste Filiale von Laden X zu finden oder sich bei Foursquare einzuchecken. Das ist schön und mit Notebooks funktioniert wohl das dank WLAN-Erkennung auch ohne GPS überraschend gut. Auf Computern ohne WLAN wird aber lediglich die IP-Adresse zur Erkennung des Ortes herangezogen, was die Genauigkeit auf irgendwo zwischen Stadtmitte der aktuellen Stadt und Langen in Hessen drückt, mithin also zum einen reichlich nutzlos ist, zum anderen aber auch Serverseitig anhand der IP-Adresse gemacht werden kann, ganz ohne Mitwirkung des Besuchers.

Da sich Geräte ohne WLAN in der Regel nur an einem Ort aufhalten, wäre es nun konsequent, wenn man im Browser einmal seine Position festlegt und fortan eine richtige Positionsangabe hat. Doch weit gefehlt. Weder Opera 11, noch Firefox 3.6 oder Chrome 9 bieten eine Möglichkeit, seinen aktuellen Ort manuell einzustellen, es wird einfach alternativlos der auf der IP-Adresse basierende Dienst von Google benutzt. Für den Firefox gibt es immerhin ein Add-On namens Geolocater für genau diesen Zweck, aber sowas gehört direkt in den Browser. Ich frage mich ernsthaft, wieso kein Browserhersteller es für nötig hält, dass ein Nutzer seine gemeldete Position manuell festlegen kann. Hat da jemand eine Antwort?


HTML5-Elemente auch im IE ohne JavaScript und trotzdem valide

20 12 2010

Ha, na sowas. Da kommt jemand mit einer relativ eleganten Möglichkeit um die Ecke, dem IE die neuen HTML5-Elemente auch ohne JavaScript bekannt zu machen. Er benutzt dafür einen XML-Namespace und benutzt dann so Sachen wie html5:section statt section. Das ist geradezu genial und funktioniert angeblich sogar zuverlässig, validiert aber in erster Linie nicht, wenn man sich nicht mit XHTML5 ganz anderen Ärger ins Haus holen will. Daneben ist es auch komisch, wenn der Autor so ein HTML schreiben muss, nur um auf den IE Rücksicht zu nehmen. Wie ließe sich das also noch verbessern?

Mir kam sofort die naheliegende Idee, das mit einem serverseitigen Ausgabefilter nur an die IEs auszuliefern. Die Voraussetzung wird nicht jedes CMS einfach so mitmachen, aber falls doch, ermöglicht einem das, die HTML5-Elemente jetzt zu benutzen. Wie genau soll das funktionieren? Wenn man einen serverseitigen DOM/HTML-Parser benutzt, ist es relativ leicht, aber das sollte in der CMS-Landschaft die große Ausnahme sein. Also braucht man ein paar simple RegExes:

  • <html muss im HTML-Output durch <html xmlns="http://www.w3.org/1999/xhtml" xmlns:html5="http://www.w3.org/1999/xhtml" ersetzt werden. Wenn man gründlich arbeitet, prüft man vorher, ob das HTML-Element nicht schon die passenden Namespaces trägt.
  • <(/?)(abbr|article|aside|audio|canvas|details|figcaption|figure|footer|header|hgroup|mark|meter|nav|output|progress|section|summary|time|video) muss im HTML-Code durch <$1html5:$2 ersetzt werden, das sind die öffnenden und schließenden Tags.
  • (abbr|article|aside|audio|canvas|details|figcaption|figure|footer|header|hgroup|mark|meter|nav|output|progress|section|summary|time|video) muss im CSS durch html5\:$1 ersetzt werden.

Das schöne an dieser Lösung ist, dass man Serverseitig recht einfach einen IE erkennen kann und ihm die gefilterten Quellen anbietet. Dass der Code für den IE nicht validiert, halte ich für verschmerzbar. Falls man versehentlich einen Browser erwischt, der sich nur als IE ausgibt, klappt zudem trotzdem alles. Und das wichtigste in meinen Augen ist, dass man die CSS Spezifität nicht verändert und sich auf diesem Weg keine Seiteneffekte ins Boot holt. Gut so.

Der einzige Nachteil, den ich momentan sehe, ist die Voraussetzung eines finalen Output-Filters. Viele CMSe buffern den HTML-Output sowieso und bieten einen Hook an, an den man sich einfach dranhängt, in dem Fall hat man natürlich leichtes Spiel. Etwas schwieriger ist das bei CMSen, die sowas nicht haben und vor allem bei statischen CSS-Dateien, in dem Fall muss man irgendwie einen Filter in den Workflow frickeln, was stark von der eingesetzen Serverumgebung abhängt und nicht einfach generalisiert lösbar sein wird. Wenn man aber sowieso schon ein CSS-Framework wie Turbine einsetzt, lässt sich das prima dort lösen, vielleicht gar mit einem HTML5-Enabler Plugin. Ansonsten wäre das mal ein guter Anlass, so ein Framework einzusetzen.

Damit löst man aber noch immer nicht das Cache-Problem: Man muss externe Proxy-Caches aushebeln und benötigt zudem plötzlich zwei lokale Caches, die von der Cache-Logik unterschieden werden müssen. Da wird es dann diffizil und man verzichtet vielleicht lieber auf eine Browser-Unterscheidung, macht den Output-Filter immer an und scheißt auf den Validator. Ist ja auch eine Lösung und man muss weiterhin nicht selbst mit den Namespaces hantieren.


Was für ein feiner Rootkit-MBR-Supertrojaner

13 12 2010

Kürzlich wurde ich gerufen, um einen Rechner mit Windows 7 von einem Trojaner zu befreien, der eine lustige TAN-Abfrage in das Online-Banking der Postbank injiziert ("Geben Sie 20 TANs ein" direkt nach der Eingabe von Kotonummer und PIN). Schnell war klar, dass ich es mit einem ordentlichen Stück Software zu tun hatte, weil alleine die organische Einbindung der injizierten Abfrage mittels jQuery UI wirklich sauber ausgeführt wurde. So gehört sich das. Der Virenscanner hat zwar etwas gefunden, aber das verriet lediglich den Weg der Infektion über ein veraltetes Java-Plugin (Update 17, aktuell ist Update 23). Ein Autostart war auch schnell auffindbar, aber ebenfalls eine Sackgasse: Die Exe hatte 0 Byte und war zusammen mit dem Autostart-Eintrag nach jedem Löschen plus Neustart wieder da. Klingt ziemlich nach Rootkit, also Rechner mitnehmen und genauer ansehen.

Also habe ich als nächstes die Desinfec't DVD von der c't 02/2010 gebootet und einige Stunden Bitdefender, Kaspersky und Avira mit aktuellen Signaturen laufen lassen. Für sowas braucht man viel Zeit, weil alleine die Akualisierung der Scanner sich bei mir im Stundenbereich bewegt hat. Verwunderliches Ergebnis: Nichts, keine einzige verdächtige Datei, die Avira nicht schon aus dem laufenden System heraus in Quarantäne verschoben hatte. Nanu? Irgendwo her muss der Scheiß doch kommen und so neu oder unbekannt wird so ein Virus auch nicht sein. Bleibt also als letzte Möglichkeit der MBR. Also schnell mal mit fixmbr.exe hantiert und von einer Boot-CD aus den Autostart und die immer wieder neu angelegte 0-Byte-Exe gelöscht, und zack, das war es. Keine TAN-Abfrage mehr beim Banking. Die hatte übrigens den Firefox und den Internet Explorer betroffen, nicht aber einen testweise heruntergeladenen Protable Chrome. Scheinbar injiziert sich das Ding als geheime DLL in ihm bekannte Browser, um sein Unwesen zu treiben.

So muss das. Diese Scriptkiddie-Virusbaukasten-Kinderkacke langweilt doch nur. Ich warte schon lange auf solche Schadsoftware, die mal ein echter Gegner ist; die auch mal von Leuten lanciert wird, die nicht mit ihren scheiß Botnetzen und adoleszent geprägten Allmachtsfantasien irgendwelche Seiten DDoSen, weil man dort ihren Account wegen Missbrauchs geblockt hat. Von sowas hat mir gerade gestern noch jemand erzählt, der eine Matchmaker/Liga-Seite für ein beliebtes Computerspiel betreibt. Stattdessen gibt es ordentlich gestaltete Software, die ihren Zweck erfüllt und mal wieder zeigt, wie angreifbar Online-Banking mit TAN-Liste doch ist. Mit Browser-basiertem Banking hat man da besonders als Angreifer leichtes Spiel, aber wenn jemand so weit ist, dass er sich mit einem MBR-Rootkit tarnen und unauffällig den ganzen Browser manipulieren kann, sollte auch ein Angriff auf StarMoney oder andere Banksoftware kein prinzipielles Problem sein.

Dass man hier sehr auffällig direkt 20 iTANs haben will, ist wohl dem Umstand geschuldet, dass man diese nur verkauft und eben nicht direkt selber nutzt. Sollte sich jemand finden, der bereit ist, das zu tun, ist es natürlich viel erfolgsversprechender, eine legitime TAN-Abfrage abzuwarten und nur die Überweisungsdaten zu manipulieren. Dagegen helfen einige neuere TAN-Verfahren, die neben der TAN auch immer Ziel und Betrag der Überweisung anzeigen. Wenn man dem überhaupt Beachtung schenkt. mTAN oder die neueren TAN-Generatoren tun da gute Dienste, weil sie die TAN-Generierung an die angezeigten Überweisungsdaten binden. Nutzt sowas, wenn ihr das noch nicht macht. Oder eben HBCI-Chipkarten-Banking mit (teurem) Kartenleser mit Display und eigenem Pinpad, aber das ist wirklich sehr unkomfortabel, vor allem wenn man mehr als eine Bank hat.

Insgesamt muss man sagen: Haltet um Gottes Willen Eure Software aktuell! Ein Java Update 17 ist einfach mal sechs Versionen alt und enthält etliche Sicherheitslücken, die sich ohne Zutun des Anwenders bequem im Browser ausnutzen lassen. Was aus sowas werden kann, hat dieser Fall mal wieder eindrucksvoll bewiesen. Auf dem betroffenen Rechner habe ich jetzt Java einfach deinstalliert, denn bezeichnend an der Sache ist, dass der Besitzer von Java eben noch nie etwas gehört hatte; kein Wunder also, dass er dessen Update-Anfragen offensichtlich ignoriert hat. Weg damit. Überhaupt: Alle Browser-Plugins sind tickende Zeitbomben, das gilt genau so für Flash und den Adobe Reader (oder Shockwave oder Quicktime oder Windows Media). Die Browser sind heutzutage echt ziemlich sicher geworden, vor allem Google Chrome mit seinen ungefragten Hintergrund-Updates geht da den richtigen Weg. Aber wenn man sich diese Sicherheit mit Sandboxen und allem durch veraltete Plugins direkt wieder kaputt macht, ist das ein Fehler im Prinzip. Also: Plugins vermeiden oder zumindest nicht ungefragt ausführbar machen, ein Flashblocker ist heutzutage sicherheitstechnisch wirklich Gold wert, NoScript kann das sogar mit allen Plugins. Ansonsten muss Java eben ganz gehen, aber das hatten wir ja schon neulich.


Java muss gehen

03 11 2010

Ich mochte die Java-Runtime noch nie, in letzter Zeit aber hat das Java-Plugin im Browser die Führung übernommen (von Flash und dem Adobe Reader), was die Ausnutzung von Sicherheitslücken angeht. Also ist eines klar: Java muss endlich mal aus meinen Browsern verschwinden, vorzugsweise gleich vom ganzen System. In Opera benutze ich sowieso schon den PlugIn-Blocker, den man in opera:config aktivieren kann und der alle PlugIns erst nach einem Aktivierungsklick auf einen Platzhalter startet. Das betrifft dann auch das Adobe Reader PlugIn, Flash und Silverlight. Bequem, aber irgendwie habe ich das Gefühl, dass einige PlugIns trotzdem einfach so starten (möglicherweise, wenn sie in einem iframe geladen werden). Im Firefox kann man PlugIns einfach deaktivieren, aber nach einem Update von Java war selbiges im Firefox wieder aktiv. Also auch hier nur eine halbe Lösung. Java muss also vom System verschwinden, die Browser sollen keine PlugIns sehen.

Leider stehen der systemweiten Deinstallation von Java einige Hürden entgegen, allen voran ein paar unersetzliche Java-Programme wie Netbeans und der JDownloader. OpenOffice meckert ohne Java auch herum, läuft dann aber trotzdem. Ich habe das alles lösen können, als Notiz eine kurze Beschreibung, worauf es ankommt:

1. JavaPortable

Dankenswerterweise gibt es bei portableapps.com eine portable Version von Java, die aktuell gehalten wird und sich bequem und fix installieren lässt. Ich habe ein Sammelverzeichnis für portable Programme, dort landet gleich auch Java. Soweit kein Problem, Java findet sich jetzt unter D:\ProtableApps\Java (das sind Backslashes, keine Pipes, liegt am Font).

2. JDownloader und andere Java-Programme, die als .jar kommen

Der JDownloader ist ein klassisches Java-Programm, das direkt als .jar kommt und mit einem einfachen Aufruf gestartet werden kann. Man legt in so einem Falle einfach irgendwo eine neue Verknüpfung an und trägt ins Zielfeld D:\PortableApps\Java\bin\javaw.exe -jar D:\PortableApps\Jdownloader\JDownloader.jar ein, in das Feld "Ausführen in:" kommt D:\PortableApps\Jdownloader. Die Pfade müssen natürlich der Situation angepasst werden und ggf. jeweils in Anführungszeichen gepackt werden, wenn Leerzeichen darin vorkommen. Dann wählt man der Optik halber das Symbol der JDownloader.exe aus und speichert die Verknüfpung ab. Das wars schon, JDownloader läuft jetzt ganz entspannt und hat sogar den Vorteil, dass man die Verknüpfung an die Taskleiste von Windows 7 anheften kann, was mit der JDownloader.exe daran scheitert, dass man nur den Starter anheften kann und für das laufende Programm ein zweiter Eintrag in der Taskleiste erscheint. Heftet man das laufende Programm an, hat es nur ein fieses Platzhalter-Symbol, wenn es nicht läuft.

3. OpenOffice/LibreOffice

OpenOffice bzw. LibreOffice meckert beim ersten Start, wenn keine Java-Runtime am Start ist, lässt sich aber unter Extras->Optionen->OpenOffice.org->Java ohne weiteres mit der portablen Runtime bekannt machen. Ich bin mir aber gar nicht sicher, ob das überhaupt notwendig ist, denn auch ohne Java scheint OpenOffice/LibreOffice ganz normal zu funktionieren.

4. NetBeans

Netbeans benötigt normalerweise ein ganzes JDK, da kommt man um eine systemweite Installation nicht herum. Will man es nur für die PHP-Enwicklung (oder andere Java-freie Sprachen) benutzen, reicht aber auch eine portable JRE. Nur scheitert die Installation ohne systemweites Java. Hilfsweise kann man ein bereits installiertes NetBeans umstellen oder die plattformunabhängige Version hernehmen, der Trick ist der gleiche: Im etc-Ordner der Installation gibt es eine netbeans.conf, die eine Zeile für den Pfad der JRE enthält. Den schnell umgestellt (Pfad natürlich wieder anpassen), und NetBeans startet wieder:

netbeans_jdkhome="D:\PortableApps\Java"

Bei meinen ersten Versuchen bin ich daran gescheitert, dass hier das Java-Hauptverzeichnis angegeben werden muss und nicht das Unterverzeichnis bin mit dem Java-Binary.

Fazit

So, meine Browser sind nun zuverlässig befreit vom Java-PlugIn und ich kann wieder ruhig schlafen; meine wichtigen Java-Programme laufen nach kurzem manuellem Eingriff trotzdem wie zuvor. Alles wird gut. Schlimm genug, dass Browser Sicherheitslücken haben, aber sowieso nie benutze PlugIns wie Java werden immer wieder vergessen, erfahren keine oder zu späte Updates und sind alle paar Wochen erneut ein spannender Zoo von Zero-Day-Exploits. Die Antwort kann nur lauten: Weg damit. Und Java im Browser werde ich nicht vermissen.

P.S. Bei der Gelegenheit habe ich übrigens auch gleich den Adobe Reader entsorgt und durch SumatraPDF ersetzt, ein simples Frontend für Ghostscript, das zur einfachen Anzeige völlig reicht und zudem super schlankt ist. Nachteil ist, dass das Markieren von Text damit nicht wirklich komfortabel klappt (Strg gedrückt halten und einen Rahmen aufziehen, der darunter liegende Text wird dann irgendwie unvorhersehbar markiert). Das kann ich aber zumeist verschmerzen. Flash wird bei mir sowieso in allen Browsern grundsätzlich geblockt (Opera blockt alle PlugIns bis auf Widerruf, FlashBlock erledigt das in Firefox und Chrome dank einer einfachen Whitelist sogar noch viel eleganter).

Nachtrag 19.11.2010: Wenn man JDownloader auf die angegebene Weise mit einem portablen Java verheiratet, kann man .dlc-Dateien leider nicht mehr per Doppelklick im JDownloader öffnen. Man muss dazu die Dateizuordnungen manuell ändern, was wiederum in Windows 7 nicht mehr mit den klassischen Bordmitteln geht. Die alte Oberfläche zur genaueren Dateizuordnung gibt es sein Vista nicht mehr, man muss also in der Registry hacken oder das tolle Tool ExtMan benutzen, das in etwas die alte von XP gewohnte Oberfläche wieder bringt. Tolles Tool und ein prima Ziel für PayPal-Spenden. Für den JDownloader muss man den Eintrag für .dlc-Dateien editieren und folgende "Anwendung für diesen Vorgang" zuordnen (wie immer: Pfade anpassen): D:\PortableApps\Java\bin\javaw.exe -jar D:\PortableApps\Jdownloader\JDownloader.jar "%1". Dann klappt auch der Start per Doppelklick wieder. Für die visuellen Typen habe ich dazu mal zwei Screenshots gemacht:

.dlc-Dateien mittels ExtMan mit JDownloader verknüpfen Schritt 1.dlc-Dateien mittels ExtMan mit JDownloader verknüpfen Schritt 2


Warum der Pornomodus von Opera momentan nichts taugt

03 03 2010

Opera 10.50 wurde gestern veröffentlicht und bringt neben einem echten Geschwindigkeitsschub und endlich einer Windows 7 angemessenen modernen Optik auch den von mir schon lange vermissten Pornomodus mit. Nur leider ist der derart blöd eingebunden, dass er quasi wertlos ist.

Es fängt damit an, dass man den Modus dank fehlenden Tastenkürzels umständlich aus der zweiten Menüebene oder dem Kontextmenü der Tableiste hervorkramen muss. Was zur Hölle soll das? Nun gut, sicher kann man den Privatmodus an bestimmte Bookmarks binden… Kram, such, kann man nicht. Dreck. Dann hat Opera ja auch die super geniale Funktion der Seitenspezifischen Einstellungen, da kann man sicher den Privatmodus für einzelne Seiten aktivieren… Nope, auch hier nichts vom Privatmodus zu sehen. Nun gut, dann mache ich eben so einen privaten Tab auf und rufe dann die entsprechenden Bookmarks auf. Hab ich gedacht, ganz bauernschlau. Doch weit gefehlt: Das Aufrufen von Bookmarks öffnet einen neuen Tab im Standardmodus. Nicht mal das Kontextmenü von Lesezeichen im Panel bietet das Öffnen im Privatmodus an.

Zusammenfassend muss ich leider sagen, dass der Privatmodus wirklich denkbar schlecht implementiert wurde: Es ist unter keinen simplen Umständen möglich, Bookmarks im Privatmodus auszurufen und wenn der Privatmodus in der zweiten Menüebene ohne Tastenkürzel dahinschimmelt, wird ihn auch niemand regelmäßig aktivieren. Als einzige Möglichkeit bleibt, ein zweites Opera-Fenster im Privatmodus zu öffnen, in dem man dann auch Bookmarks aufrufen kann. Das geht sogar mit einem Tastenkürzel, immerhin.

Warum nur, Opera? Es ist ja nicht so, als hätten nicht alle anderen Browser bessere Implementierungen dieser Idee parat. Seid ihr zu stolz, von anderen abzugucken? Warum so halbherzig? Schaut euch mal den Firefox an, dessen Privatsphäreeinstellungen sind bestechend simpel, sogar rückwirkend kann man hier gezielt einzelne Seiten oder Zeiträume aus der History kicken. Eure Seitenspezifischen Einstellungen sind so ein großartiger und von mir oft genutzter Ansatz, warum taucht der Pornomodus hier nicht auf?

Randbemerkung: Es ist für mich kein Widerspruch, Bookmarks und Privatmodus gleichzeitig nutzen zu wollen. Ob eine detaillierte Porno-History angelegt wird, die zudem auch noch andere Seiten aus der Autovervollständigung verdrängt und vor allem auch dort auftaucht, wenn einem Leute über die Schulter sehen, oder ob man nur ein Bookmark in den Lesezeichen liegen hat, ist für mich ein zentraler Unterschied. Vor mir selber habe ich nichts zu verbergen, der Pornomodus ist also für mich lediglich eine Komfortfunktion zur History- und Cookie-Hygiene. Ich würde also erwarten, dass bei den Seitenspezifischen Einstellungen (oder im Bookmark) der Pornomodus wählbar ist, dieser in den Tabs klar gekennzeichnet ist und sich vor allem auch auf die darin verlinkten Seiten auswirkt.

Und wo wir gerade beim Thema Opera und Lästigkeiten sind:

  • Warum kann ich die Mausgeste für einen neuen Tab nicht mehr benutzen, wenn alle Tabs minimiert sind und ich den grauen Hintergrund sehe? Bisher ging das immer, jetzt muss ich hier einen Doppelklick machen. Kleine Umgewöhnung, halb so wild, aber überflüssig und inkonsistent. Ein Doppelklick in einen bestehenden öffnet ja auch keinen neuen Tab, dafür gibt es ja die Geste.
  • Lästiger ist, dass man noch immer nicht die Reihenfolge der Symbolleisten ändern kann: Ich habe die Tableiste und die Persönliche Leiste oben positioniert; das sorgt leider dafür, dass der coole neue O-Button nicht im Fensterrand hängt, sondern links von den Tabs. Ich hätte also gerne die Persönliche Leiste (Bookmarks) unter den Tabs oder wenigstens den coolen O-Button trotzdem im Fensterrand. Warum geht das nicht?
  • Warum gibt es beim neuen und an sich sehr gelungenen Standard-Skin allerlei unfassbare Farben als Farbschema, aber keine neutrale dunkle Farbe? Das System-Farbschema ist schon OK, aber grau und ein weißer Hintergrund im Schnellstarter sind keine wirklich erfreulichen Gesellen.
  • Warum gibt es keinen Feeds-Button für die Symbolleiste? Einen Lesezeichen-Button gibt es ja auch und ohne Menüleiste braucht man irgendwie einen direkten Zugang zu den Feeds. Klar, man kann sich im Netz benutzerdefinierte Buttons besorgen, so einen habe ich ja auch, aber der ist kleiner als der Lesezeichen-Button und fällt total aus dem Rahmen.
  • Der eingebaute Torrent-Client schnappt sich bei ein paar aktiven Torrents gerne mal die gesamte zur Verfügung stehende Bandbreite, so dass man parallel nicht mal mehr normale Websites aufrufen kann. Das muss man bei 50/10MBit VDSL erst mal schaffen.

So, genug gemeckert. Opera ist nämlich für mich immer noch der beste Browser von allen. Chrome gefällt mir auch sehr gut und in Zukunft will Google auch auf die eindeutige ID verzichten, wie ich gehört habe. Mit der neu hinzugekommenen Extension-Schnittstelle und seiner Smoothness ist er ein heißer Kandidat für den besten Browser. Firefox ist nachwievor (unter Windows und Linux) großartig und ich benutze ihn ebenfalls intensiv, wenn ich auch aus Gründen der Smoothness und aus Gewohnheit für das alltägliche Surfen seit nunmehr etwa 11 Jahren ununterbrochen Opera nutze. Safari ist inzwischen auch ein prima Browser, aber unter Windows eher überflüssig und vor allem gibt es ihn nicht als portable Version, was für mich als Webentwickler ziemlich bitter ist.

Nachtrag 09.03.2010: Wenn man in der Adresszeile opera:config eingibt, kommt man in einen erweiterten Config-Dialog, ähnlich wie bei Thunderbird und Firefox. Dort kann man so einige Nervigkeiten von Opera loswerden, etwa den Bandbreitenhunger für Torrents oder die Tab-Integration in der Windows 7 Taskleiste. Immerhin.


Toolbar Wut

20 08 2009

Ich bin genervt, weil immer mehr Programme einem irgendwelche Toolbars oder andere Browser Extensions aufdrängen. Aktueller Höhepunkt: Das zur Zeit verteilte Java Update (JRE 6 Update 15) bringt voreingestellt die Yahoo! Toolbar für den Firefox mit. Ich sitze ständig an fremden Rechnern und werfe den Mist überall wieder runter, das nervt total. Auch Skype macht mich krank, weil es bei jedem verfickten Update seine unfassbar bremsende Firefox Extension wieder installiert, sogar ohne Nachfrage. Eine Kundin rief mich mal völlig genervt an, dass ihr Internet seit ein paar Tagen so unglaublich träge geworden wäre. Was war los? Ich wäre schon fast hin gefahren (50km), habe aber vorher noch mal per Fernwartung auf ihren Rechner geguckt. Und siehe da, die Skype Extension hat für das Suchen von Telefonnummern auf Websites so unglaublich lange gebraucht, dass es sich merklich langsamer surfte. Schnell deaktiviert und schon fluffte es wieder.

Um mir meine Wut mal von der Seele zu schreiben, hier mal eine unvollständige Liste der von mir eingesetzten lästigen Programme:

  • Java Runtime Environment 6 Update 15: Vor einigen Versionen hat einem das Java Update einen Link zum Download von OpenOffice.org auf den Desktop gelegt. Das ist nervig, aber ohne echte Folgen. Die aktuelle Version bringt aber voreingestellt die Yahoo! Toolbar für Firefox mit. Das geht gar nicht: Wenn kostenlose Software wie IrfanView sich ein paar Euro mit Toolbars dazu verdient, ist ist das eine Sache. Wenn aber eine Runtime sowas mitbringt, ist das eine schlichte Unverschämtheit. Als ob Sun kein Interesse daran hätte, ihre Java Runtime auf möglichst vielen Systemen in aktueller Version installiert zu haben.
  • Skype installiert bei jedem Update (das sowieso praktisch eine Neuinstallation ist) eine Firefox Extension, die den Browser total ausbremst. Unfassbar. Dabei geht es nicht um Werbung, sondern um Absatzsteigertung: Die Extension macht Telefonnummern auf Websites anklickbar, so dass man diese direkt über Skype anrufen kann, was natürlich kostenpflichtig (und nicht mal wirklich billig) ist. Auch hier: Lästig und unverschämt, zumal die Installation ungefragt geschieht und sehr störende Nebeneffekte (angezogene Firefox Handbremse) mit sich bringt.
  • Die Daemon Tools binden CD-Images bequem als virtuelles Laufwerk ins System ein und tun das sehr zuverlässig seit vielen Jahren. Früher war der Hauptzweck, den Kopierschutz von Spielen zu emulieren, heute muss man (ich zumindest) alle Nase lang auf CD Images zugreifen, vor allem auf Netbooks. Die aktuelle Version bringt eine unfassbare Konfigurationsorgie mit, damit man weder Suchseiten noch Toolbars mitinstalliert. Das kann man alles abstellen, aber es ist extrem nervig. So nervig, dass ich seit vielen zufriedenen Jahren nun auf der Suche nach einem Open-Source Image-Mounter bin. Zudem sind die Daemon Tools nur noch für die private Nutzung kostenlos und kosten sonst richtig Geld. Warum kann eigentlich nicht mal Windows 7 ISO-Images mounten? Immerhin kann Windows 7 ISO-Images schon mal brennen.
  • Der Adobe Reader haut bei jedem (dringend nötigen!) Update immer wieder ungefragt sein Symbol auf den Desktop. Das wäre nur halb so bescheuert, wenn dieses Icon irgendeinen nennenswerten praktischen Nutzen hätte. Hat es aber nicht, oder kennt ihr jemanden, der einfach so den nackten Adobe Reader startet? Wozu auch? Seine einzige Funktion ist das Anzeigen von PDF-Dateien und die öffnet man mit einem Doppelklick. Wir sind ja nicht auf dem Mac, wo man alles per drag and drop öffnet und die Voschau des Systems PDF-Dateien anzeigt.
  • IrfanView ist ein großartiges Programm, aber leider seit einiger Zeit eine stete Quelle des bei der Installation vorausgewählten Google Desktops. Bei der Installation lässt dieser sich zwar leicht abschalten und ich habe hier vollstes Verständnis für das Ansinnen, ein paar zusätzliche Einnahmen zu generieren. Aber der Google Desktop ist aus Datenschutzsicht ein sehr spezieller Fall und deswegen sehr fragwürdig.
  • Winamp bringt, wenn man nicht aufpasst, auch eine Menge Zeugs mit. Das ist einer der Gründe, wieso ich Winamp seit einigen Jahren nicht mehr benutze.
  • Apple ist der König unter den nervigen Mitbringselschnürern. Installiert man notgedrungen iTunes, weil man dem iPhone oder einem iPod anheim gefallen ist, landet automatisch das verhasste Quicktime samt unglaublich überflüssigem Tray-Icon auf dem Rechner. Will man Quicktime alleine installieren, muss man gut aufpassen, um nicht iTunes gleich mitinstalliert zu bekommen. Das alleine wäre schon lästig, aber wenn man nicht aufpasst, hat man bald auch noch Safari auf dem Rechner, denn bei den regelmäßigen Updates von iTunes und Quicktime ist Safari immer wieder aufs neue vorausgewählt. Das geht wirklich gar nicht! Apple ist derart dreist, was das angeht, dass man echt nur den Kopf schütteln muss: Apple ist das neue Microsoft, nur viel schlimmer.
  • HP hat es sich bei mir ebenfalls verscherzt: Die den Multifunktionsgeräten beiliegende Softwareunverschämtheit belegt nicht nur einige hundert Megabyte Platz auf dem Rechner, indem sie ein ganzes Bündel an zusätzlicher und überflüssiger Software mitbringt. Das wäre alleine schon zum kotzen. Dass der Mist dann leider häufig nicht funktioniert und ich das Zeug über ein Jahr verteilt sage und schreibe 10 mal auf Anweisung des (durchaus guten) Hotline-Chats jeweils eine geschlagene Stunde lang neu installiert habe, weil wieder irgendetwas nicht mehr lief, war für mich Grund genug, auf absehbare kein HP Gerät mehr zu kaufen oder zu empfehlen.

Diese Liste ist alles andere als vollständig und spiegelt nur die Software wieder, die ich selber benutze oder bei Kunden sehe. Teenager-Rechner kann man übrigens gar nicht betreten vor lauter ICQ-, MSN- und Skype-Messengern, die beim Start online gehen und alle ihre eigenen Toolbars und was auch sonst immer mitbringen.


Mal wieder: Wie sollte man mit den IE6-Nutzern umgehen?

15 07 2009

So viel wurde schon zum IE6 geschrieben, so viel Hass wurde ausgeschüttet und so viele Erklärungsansätze für den noch immer beschämend hohen Marktanteil dieses Fossils wurden gebracht. Nun muss ich noch mal etwas dazu loswerden. Warum gerade jetzt? Zu einen habe ich zuletzt mehrere Tage unbezahlt mit IE6-Debugging verbracht, zum anderen hat YouTube angekündigt, den Support für den IE6 ab sofort auslaufen zu lassen. Das ist eine großartige Entscheidung, denn bisher hat sich kaum ein reichweitenstarkes Webangebot zu diesem Schritt durchringen können. Die Begründung halte ich für sehr stichhalting: YouTube sagt, dass sie der Support des IE6 glasklar messbar und nicht zu knapp Geld kostet und dass einige neue und praktische Funktionen mit vollem IE6-Support nicht machbar sind. Genau das ist der Punkt. Danke an Google für diesen mutigen Schritt. Denn nur durch Leidensdruck seiner Nutzer wird der IE6 aus den Statistiken verschwinden. Solange die Inhaltelieferanten die teilweise massiven Mehrausgaben bei der Entwicklung für den IE6 tätigen, wird sich an der Situation nichts ändern.

Ein viel gehörtes Argument ist ja, dass viele Nutzer an Firmen-PCs nur den Internet-Explorer 6 benutzen können/dürfen und so ja jetzt ausgeschlossen sind. Das stimmt. Na und? Eine reichweitenstarke Seite wie YouTube verliert dadurch vielleicht ein paar Prozent seiner Nutzer. Noch mal: Na und? YouTube ist wichtig genug, dass diese Leute im Zweifel schon einen Weg finden werden, sprich einen anderen Browser installieren. Oder sie lassen YouTube eben bleiben. Man darf nicht vergessen, dass da jemand mit einem Programm unterwegs ist, zu dessen Erscheinungszeitraum Videodienste wie YouTube noch unfassbare Zukunftsmusik waren. Woher kommt die Erwartungshaltung, dass das ohne Einschränkungen klappen muss? Ich denke, man muss sich einfach der Realität stellen. Es gibt genug Alternativen und keine davon kostet etwas.

Aber das CRM-System in unserer Firma (oder Intranet-Anwendung-XY) läuft nur mit dem Internet Explorer! Auch das höre ich immer wieder und ich habe zwei Antworten darauf: Erstens würde ich mich fragen, ob meine Intranet-Anwendung eine gute Anwendung ist, wenn sie die vorletzte Version eines so wichtigen Programmes als Zugangsvoraussetzung hat, aber da rede ich Firmen ungerne rein. Zum anderen aber spricht meiner Meinung nach nichts gegen den Paralleleinsatz von IE6 als Zugangsprogramm fürs veraltete Intranet und einem modernen Browser für das Internet. Selbst wenn es unbedingt der Internet Explorer 8 sein muss, gibt es Mittel und Wege, parallel einen IE6 zu betreiben. Zu viel Administrationsaufwand? Nun, so ist die Welt. Man denke im Firmeneinsatz übrigens auch an die haarsträubenden Sicherheitslücken des IE6, die nicht mehr behoben werden.

Aber was ist mit der Barrierefreiheit? Nutzer auszuschließen widerspricht dem Barrierefreiheitsgedanken, klar. Aber ist das hier wirklich so? Dafür muss ich eine Analogie bemühen: Man stelle sich vor, es gäbe ein Gesetz, das die Beschaffenheit von Rollstuhlrampen regelt. Alle Hersteller von Rollstühlen halten sich an diese Vorhaben und fahren prima damit. Nur der klare Marktführer hat bei früheren Modellen einmal diese Regeln anders ausgelegt und die Räder als Vielecke statt als Kreise ausgelegt. Das ist anfangs vielleicht Stand der Technik gewesen, technisch sinnvoll war es aber nie. Auf standardkonformen Rollstuhlrampen ist die Fahrt für Nutzer solcher Rollstühle dadurch etwas unbequem, weswegen alle Gebäudebetreiber ihre Rollstuhlrampen bisher sehr teuer in mechanisch sehr aufwändigen und vor allem technisch unsinnigen Varianten gebaut haben. Für die Nutzer standardkonformer Rollstühle gäbe es längst Entwicklungen, die die Nutzung von Rollstuhlrampen wesentlich bequemer und einfacher gestalten würden, aber diese sind mit den Vieleckrädern nicht oder nicht sinnvoll in Einklang zu bringen. Der Marktführer würde daher schon lange ein kostenloses Austauschprogramm für seine alten Modelle anbieten. Macht es hier Sinn, von einer Barriere zu sprechen, wenn man bei neuen Gebäuden die sich bietenden Vorteile nutzt und die Nutzer der veralteten Rollstühle zwingen würde, das kostenlose Austauschprogramm des Herstellers zu benutzen? Ich habe da meine Schwierigkeiten mit. Es geht ja nicht darum, dass der alte Rollstuhl die Rampe gar nicht mehr benutzen kann, es würde für etwas holpriger werden.

So sehe ich das auch beim IE6: Wer der Meinung ist, mit einem Browser aus dem Jahr 2001 im Jahr 2009 alle Funktionen moderner Websites genießen zu können, leidet unter massivem Realitätsverlust. Eine Website sieht komisch aus? Nun gut, da könnte man denken, der Seitenbetreiber wäre ein Idiot. Wenn aber immer mehr Websites komisch und kaputt aussehen und mir einhellig sagen, dass sie meinen veralteten Browser nicht mehr unterstützen, kann ich die alle doof finden oder mich der Realität stellen und ein Update machen. Genau deswegen braucht es Seiten wie YouTube, die die Eier haben, dieses doof gefunden werden einstecken zu können und im Zweifel ein paar Nutzer zu verlieren.

Hier kommt wieder der Geldaspekt ins Spiel. Mal angenommen, die Implementierung einer modernen Funktion ist im IE6 nicht möglich. Dann wird YouTube durchrechnen, was für einen finanziellen Wert die neue Funktion hätte. Dann wird YouTube gegenrechnen, was der Ausfall von einer angenommenen Zahl an IE6-Nutzern, die nicht umsteigen, sondern YouTube den Rücken kehren, kosten würde. Dann wird YouTube einrechnen, wieviel es wert ist, wenn x Prozent der ehemaligen IE6-Nutzer auf den Google-Browser Chrome umsteigt. Dann wird YouTube einen großen Strich unter die Rechnung machen und den IE6-Support sofort einstellen. Die Dimension, dass auch andere Google-Dienste vom Tod des IE6 profitieren, habe ich hier noch gar nicht einbezogen. Eine ähnliche Rechnung tut sich auf, wenn man die Entwicklungskosten für IE6-Zurechtbiegen gegen den Imageverlust durch etwas komisch aussehende Websites gegenrechnet.

Bei einem eigenen Projekt würde ich keinesfalls Geld in die Kompatibilität mit dem IE6 stecken und auf tolle neue Funktionen für alle anderen verzichten. Wer das Geld weiterhin ausgeben möchte, kann das ja weiterhin tun.

P.S. Ich muss dazu sagen, dass ich bei meinem letzten Auftrag einen Pauschalpreis veranschlagt und dabei u.a. die für das IE6/IE7 Debugging nötige Zeit völlig falsch eingeschätzt habe. Insgesamt habe ich nun mehrere Tage komplett unbezahlt (das entspricht meinen Fixkosten für einen ganzen Monat) da rein stecken müssen, was mich ernsthaft ärgert. Merke: Keine Pauschalpreise für so einen Mist und wenn doch, dann nicht so knapp kalkuliert.


jQuery Stolperstein: hover() und slideUp()/slideDown()/animate()

21 06 2009

Gelegentlich möchte ein CSS Dowpdown-Menü um eine kleine Animation erweitert werden, die bei der Gelegenheit auch den Suckerfish für den IE6 übernimmt. Natürlich macht man sowas mit jQuery, wenn man das sowieso eingebunden hat, in etwa so (natürlich alles innerhalb von $(document).ready()):

$('#mainMenu>li').hover(
  function(){
    $(this).find('>ul').slideDown(150);
  },
  function(){
    $(this).find('>ul').slideUp(50);
  }
);

Nun kommt es dabei immer wieder zu den selben Problemen:

Fährt man mit der Maus schnell mehrmals über einen Punkt, werden alle nötigen Animationen in eine Warteschlange gepackt und nach und nach gemütlich abgearbeitet. Das lässt sich noch leicht und logisch beheben, indem man jeweils mit einem stop() vor slideDown() und SlideUp() die Animation erst einmal stoppt, bevor man das Gegenstück ausführt. Das gleiche passiert auch bei animate() und vergleichbaren Sachen und lässt sich da auf die gleiche Weise beheben. Soweit kein Problem und nach ein paar Sekunden Google-Recherche gefunden.

Ein weiteres Problem ist das Handling der Animation bei der ersten Berührung mit der Maus: Scheinbar wird das jQuery hover Event erst bei der zweiten Berührung genutzt, bei der ersten klappt das Menü ganz normal mit der im CSS definierten Methode aus. Auch hier hilft eine Google-Recherche schnell weiter und bringt die Lösung frisch auf den Tisch: Vor der ersten Berührung (also zweckmäßiger Weise in $(document).ready()) müssen die UL-Elemente der Untermenüs mit einem beherzten Aufruf von hide() versteckt werden, auch wenn sie durch das CSS eigentlich schon versteckt sind. OK, das muss man wissen und kommt nicht von alleine drauf.

Perfide ist das dritte Problem bei Animationen mit den Ausmaßen der Untermenüs, also slideDown()/slideUp() und animate() in Kombination mit height() oder width(): Nutzt man diese innerhalb der hover() Funktion und verlässt das Element noch während die Animation läuft, speichert jQuery den zu diesem Zeitpunkt aktuellen Wert der animierten Abmessungen zwischen und animiert fortan nur noch bis zu diesem Maximalwert. Verlässt man den Menüpunkt also sofort wieder, wird das Menü bis zum Seitenreload nie wieder erscheinen, denn es ist ja nur noch etwa einen Pixel hoch und wird entsprechend auch nur bis zu einem Pixel animiert. Hier habe ich keine Lösung bei Google gefunden, weil ich nicht wusste, wonach ich suchen sollte. Also habe ich mich mit dem Firebug auf die Lauer gelegt und das Problem in der beschriebenen Form analysieren können. Ich weiß nicht, ob das ein Bug ist oder volle Absicht, aber ich kann mir nicht wirklich eine Situation vorstellen, wo dieses Verhalten gewünscht wäre. Die Lösung dafür liegt aber auf der Hand: Ein unscheinbares height('auto') vor der ausklappenden Animation behebt das Problem sehr zuverlässig.

So sieht nun also das komplette Menüscript aus, das sich endlich so verhält, wie man es auch erwartet:

$('#mainMenu>li>ul').hide(); // needed to prevent CSS-only behaviour on first contact
$('#mainMenu>li').hover(
  function() {
    $(this).find('>ul').stop().height('auto').slideDown(150); // the height('auto') prevents the menu from memorizing an incorrect height-value forever when leaving the menu while the animation is running
  },
  function() {
    $(this).find('>ul').stop().slideUp(50);
  }
);

An anderer Stelle half mir height('auto') aber nicht weiter, was also tun? Die Lösung lag zunächst auch hier auf der Hand: Beim Laden der Seite müssen die initialen Werte des Elements in einer Variablen gespeichert werden, zu denen die Animation dann jeweils zurückkehren kann. Das schien mir immens unelegant, weil ich nicht den globalen Scope mit solcherlei Variablen vollmüllen wollte. Mein Bruder brachte dann den entscheidenden Tipp: Man kann die Werte prima als Attribute des Elements im DOM ablegen. Beliebige Attribute sind in HTML zwar nicht erlaubt, aber wenn das Dokument erst mal ins DOM eingelesen wurde, sind die Limitierungen von HTML völlig gleichgültig. Kurz gesagt: Ist das Ding im DOM, ist es kein HTML mehr. Die Denke muss man sich erst mal klar machen. Gut, also schreibe ich die Werte in $(document).ready() fix als Attribute ins DOM und alles wird gut. Doch da hatte ich nicht mit der strengen, aber korrekten Auslegung des ready()-Events in Opera gerechnet: Dort stehen zu diesem Zeitpunkt die gewünschten Werte nicht zur Verfügung, weil es sofort gefeuert wird, sobald das DOM fertig eingelesen wurde, aber eben noch bevor die Engine irgendetwas rendern konnte. Abmessungen sind also nicht bekannt. Die Lösung lautet hier $(window).load(). Dieses Event wird gefeuert, sobald die Seite gerendert wurde, mithin also auch alle Abmessungen bereit stehen. So sind die Events spezifiziert, aber Opera scheint der einzige Browser zu sein, der sie auch so handhabt. Die komplette Lösung für dieses Problem lautet also in etwa so:

$(window).load(function(){
  $("#elementId").attr('origHeight', $("#elementId").height());
});

Ausgelesen wird auf die gleiche Weise, also $("#elementId").attr('origHeight').

Nachtrag 05.07.2010: Wo ich den alten Beitrag gerade noch mal lese, fällt mir auf, dass Doku lesen oft hilft. Der letzte Punkt wird natürlich viel eleganter gelöst, wenn man einfach die data()-Methode von jQuery benutzt. Also wie immer: Augen auf und Hirn an.

Nachtrag 19.07.2011: In den Kommentaren wurde ich darauf hingewiesen, dass ein .stop(true, true) die genannten Probleme löst. Fantastisch. Ist das neu dazu gekommen oder bin ich nur zu blöd, Dokumentationen zu lösen?

Nachtrag 04.11.2011: jQuery 1.7 nimmt sich zumindest bei toggling animations des Problems an, dass ein Abbruch auf halber Höhe weitere Klappvorgänge nur noch bis dort hin durchführt. Ich zitiere aus dem Release-Post zu jQuery 1.7:

In previous versions of jQuery, toggling animations such as .slideToggle() or .fadeToggle() would not work properly when animations were stacked on each other and a previous animation was terminated with .stop(). This has been fixed in 1.7 so that the animation system remembers the elements’ initial values and resets them in the case where a toggled animation is terminated prematurely.

Ich habe das noch nicht ausprobiert und wenn das nur bei Toggle funktioniert, braucht es eine der oben genannten Methoden in anderen Fällen weiterhin, aber trotzdem eine gute Nachricht.


Warum ich XHTML schreibe und HTML meine

29 04 2009

Aktuell gibt es im Zuge der HTML5-Spezifikations-Diskussion eine in meinen Augen völlig überflüssige Unterdiskussion: Soll man HTML oder XHTML schreiben? Der von mir geschätzte Eric Eggert argumentiert pro HTML und hat gute Argumente im Gepäck, die ich jetzt nicht noch mal wiedergeben mag. Ich selber schreibe seit Jahren strikt nach XHTML-Syntax mit dem DOCTYPE XHTML 1.0 Strict, liefere aber als text/html aus, was schon immer widersprüchlich war und sich mit HTML5, dessen DOCTYPE ich seit einiger Zeit nur noch verwende, ja sowieso erledigt hat. Deswegen und weil in meinen Augen korrekter Code sowohl in HTML als auch in XHTML gültig ist (bzw. funktioniert), halte ich die Diskussion für überflüssig. Echtes XHTML scheidet in der Praxis wegen des IEs und weil ein wohlgeformtes XML-Dokument faktisch nicht dauerhaft und zu jedem Zeitpunkt sicherzustellen ist, sowieso aus. Auch ich selber übersehe gelegentlich solche Fehler und dann würde das rendern der ganzen Seite abbrechen. In Atom-Feeds sieht man ja, wie lästig das ist: Ein Tippfehler oder auch nur eine benannte HTML-Entity im Dokument (hallo an die WYSIWYGs dieser Welt) und der Feedreader verarbeitet den ganzen Feed nicht mehr, na vielen Dank.

Für wichtig halte ich aber die Frage, ob man die SGML-Freiheiten von HTML nutzt oder sich Mühe gibt, sauberen und wohlgeformten XML-Code zu schreiben. Und da sehe ich den großen Schwachpunkt von HTML: Hier sind syntaktische Konstrukte erlaubt, die mir den kalten Schweiß auf die Stirn treiben und die wirklich niemand benutzen sollte. Aber auch schon so Dinge wie ungequotete oder fehlende Attributwerte kann ich nicht ertragen. All das ist in HTML erlaubt und was erlaubt ist, wird von irgendwelchen Leuten und vor allem WYSIWYG-Editoren auch genutzt. Das war der Grund, wieso ich meine Dokumente stets als XHTML 1.0 strict deklariert habe: Solche schlechten Angewohnheiten müssen zumindest vom Validator bemängelt werden. Dass die Browser so fehlertolerant sind ist in der Praxis ja schön, aber es verleitet eben auch zu krudem und unverständlichen und fehleranfälligem Code. XML-Syntax ist letztlich wegen der strikteren Regeln deutlich einfacher zu erlernen und zu nutzen: Klare Regeln sind hier immens von Vorteil für alle, das merkt man spätestens, wenn man Menschen an HTML und allgemein Auszeichnungssprachen heranführt.

Also mein simples Fazit: Aktuell und in Zukunft deklariere ich als HTML5, schreibe aber in strikter XML-Syntax. Das ist in HTML5 gültig, für jeden verständlich und eindeutig und es geht mit gutem Beispiel voran. Wünschenswert wäre ein Modus in HTML5, dessen Syntax XML statt SGML nutzt (was sich im Validator ausdrückt), ohne gleichzeitig die Strenge von XML beim Parsen im User-Agent zu erzwingen. Warum basiert HTML5 überhaupt auf SGML? Wer hat was davon? Wer nutzt überhaupt die Freiheiten von SGML? Was spricht gegen eine HTML5 Spezifikation, die XML-artige Syntax vorschreibt, aber den Browsern Fehlertoleranz erlaubt?


IE6 erledigt sich von alleine

11 03 2009

Momentan liest man viel zur IE6-Problematik. Die einen radikalisieren sich, andere finden das wiederum unprofessionell, es werden gute Argumente ausgetauscht für den richtigen Umgang mit der Sache. Ein wirklich gutes Argument habe ich zuletzt bei Dirk Jesse gesehen: Es gibt seit Jahren für die meisten IE6-Probleme gut dokumentierte Lösungswege und wer die nicht kennt und nutzt, handelt wenig professionell. Ein gutes Argument, keine Frage. Ich selber stehe aber trotzdem auf der mehr oder weniger radikalen Seite und nehme sogar absichtlich IE6-Nutzern Styles und Funktionen weg. Ich bestrafe die IE6-User also wo ich kann mit einer gewissen Hässlichkeit, ohne die Inhalte unzugänglich zu machen. Ich halte das für einen durchaus gangbaren Kompromiss für Seiten, die nichts an IE6-Nutzer verkaufen müssen. Alle anderen sollten unbedingt Frameworks nutzen. Aber vor allem halte ich es für politisch wichtig, dass es einen gewissen Anteil von Websites gibt, die IE6-Nutzern die Beschissenheit des von ihnen genutzten Webzugangsprogramms vor Augen führt. Ich denke, dass nur durch solchen Druck der IE6-Anteil nennenswert sinken wird.

Ich sage damit nicht, dass das eine allgemeingültige Lösung sein soll und wer keine Lust hat, seine IE6-Nutzer zu nerven, soll das auch bleiben lassen. Aber wenn genug Websites sich die Hände schmutzig machen und ihre IE6-Nutzer etwas nerven, werden diese irgendwann die Schnauze voll haben und den Browser doch wechseln oder ihre Admins nerven. Autos ohne Kat zahlen auch mehr Steuern, wieder so ein aufgeschnapptes Argument.

Gestern in der Bahn fiel mir aber eine ganz subtile Lösung ein, die das IE6-Problem demnächst von ganz alleine lösen wird: Die verdammt miese JavaScript Performance sorgt ganz besonders auf Seiten, wo Sachen wie die JavaScript-Canvas-Emulation am Werk sind, für eine merkliche Langsamkeit des Browsers. Dass der IE6 dazu auch noch zumeist auf älteren Rechnern am Start ist, verschärft das nur noch weiter. Die Bedienung moderner Websites wird also trotz voller Funktionsfähigkeit zunehmend träger und quälender mit dem IE6. Und ich denke so ziemlich jeder IE6-Nutzer wird die gefühlte Geschwindigkeit mit modernen Browsern früher oder später bei anderen sehen oder davon berichtet bekommen. Und zack, ist es seine Idee, den Browser zu wechseln und kein von allen Seiten angeratener Akt mehr. Also liebe Webmenschen, macht kräftig Gebrauch von Sachen wie Canvas und dessen IE6-Emulation. Alles, worauf Ihr achten müsst, ist die Zugänglichkeit der Inhalte auch ohne JavaScript zu gewährleisten und bei guten Browsern nicht zu viel Performance zu fressen. typeface.js für Überschriften bietet sich da zum Beispiel an, da es nur mit aktiviertem JavaScript ins Spiel kommt und dann Schriften mit Canvas rendert, recht träge im IE6 natürlich. Ihr findet schon einen Weg, das gemeinsame Ziel ist klar: Der IE6 muss weg und der IE7 am besten gleich mit. Microsoft muss echten Druck spüren, die kommenden IEs auf die Höhe der Zeit zu bringen.