Oskar Welzl: Weblog zur Homepage

Web



Jabber Instant Messaging

Jabber Instant MessagingIch bin wieder mit Instant Messages erreichbar: Gestern habe ich mir einen Jabber-Account gegönnt. Nicht, weil mir Instant Messaging so sehr abgegangen wäre. Es hatte schon einen Grund, warum ich noch zu Windows-Zeiten ICQ wieder gelöscht habe…

In erster Linie möchte ich mit Jabber bzw. dem XMPP-Protokoll einfach nur rumprobieren. Immerhin ist es, soviel ich weiß, der einzige offene Standard auf dem Gebiet. Und wenn irgendwo „offener Standard“ draufsteht, muß ich es haben. Egal, ob ichs nun brauchen kann oder nicht.

Jedenfalls ist meine Jabber-ID ossi1967@amessage.at. Bin ja gespannt, ob das Ding auch wirklich funktioniert.


Statistiken: Mac OS X und Firefox legen zu

Meine Freude an statistischen Auswertungen fördert zutage: Die meisten Leser dieses Weblogs kommen aus Deutschland. Der häufigste Suchbegriff, der von Suchmaschinen hierher führte, war „robbie williams nackt video“. Internet Explorer verliert, Mac OS X findet immer mehr Freunde und ich hatte tatsächlich einen Leser aus Chile hier, ohne daß ich es bemerkt hätte.

Im Detail sehen die Ergebnisse der Browser-Statistik folgendermaßen aus:

BrowserAnteil in Prozent
Internet Explorer54%
Firefox, Mozilla und Netscape43%
Opera3%

Noch im letzten Monat lag der Internet Explorer bei 58%. Nach wie vor nicht berücksichtigt ist der Safari; laut Support-Mail von blogcounter handelt es sich hier um einen bekannten Fehler, der ausgebessert werden soll. Wenn jeder Zugriff, der in den Detailauswertungen unter „unbekannt“ läuft, mit einem Safari erfolgte, kommt dieser Browser grob geschätzt auf ca. 2%.

Bei den Betriebssystemen hat Mac OS X mächtig aufgeholt, nämlich von 6% auf 9%, in absoluten Zahlen nur knapp hinter Windows 2000 auf dem dritten Platz:

BetriebssystemAnteil in Prozent
Windows XP70%
Windows 20009%
Mac OS X9%
GNU/Linux5%
Windows ME3%
Windows 982%
Andere2%

Insgesamt ist die durchschnittliche Zahl der Besucher pro Tag von 9 im Oktober auf 15 im Dezember angestiegen (bei 31 Seitenaufrufen/Tag). Ich könnte mich stundenlang mit diesen Zahlenspielen beschäftigen… Ach ja: Die wahrscheinlich sinnloseste Suchanfrage, mit der jemand via Google bei mir gelandet ist, war „alles-und“.


AGBs gegen Hacker und Banküberfälle

Auf Der Gipfel der Unverschämtheit beschreibt Dirk Heringhaus (leider etwas zu ausführlich, aber lesenswert), wie er binnen kürzester Zeit in der österreichischen Ausschreibungs-Datenbank auftrag.at Administratorenrechte erlangen und sämtliche Benutzerdaten einsehen konnte. (Er hat dazu einfach die in der Adreßzeile des Browsers sichtbare Benutzer-ID geändert.)

Das alleine wäre noch nicht so berichtenswert: Sicherheitslücken gehören zur EDV wie das Schwarze zu den Fingernägeln. Man macht es weg, es kommt wieder. Der Kreislauf des Lebens eben… Wo war ich stehen geblieben? Ja, auftrag.at und die Administratorenrechte. Wie gesagt, so etwas passiert nun mal.

Dirk Heringhaus ist nun ein guter Hacker und bittet (als deutscher Staatsbürger) sofort das BSI, mit den zuständigen österreichischen Stellen Kontakt aufzunehmen. Eine Rückfrage von auftrag.at, deren Administratoren den Braten gerochen haben, beantwortet er ebenfalls sofort, obwohl der Ton der Rückfrage schon etwas daneben lag. Es wurde nämlich sofort das Einleiten rechtlicher Schritte angekündigt und darauf hingewiesen, daß die auftrag.at Ausschreibungsservice GmbH & Co KG […] eine Tochterfirma der Wiener Zeitung GmbH ist, welchselbige als offizielles Amtsblatt der Republik Österreich im Eigentum des Bundeskanzleramtes steht. Als ob das irgend eine Rolle spielen würde.

Was das nun mit AGBs und Banküberfällen zu tun hat? Ganz einfach: auftrag.at relativiert in einer weiteren an Dirk Heringhaus gerichteten Mail die gefundene Sicherheitslücke mit einem Verweis auf die AGBs, die da angeblich lauten:

Der Kunde ist nicht berechtigt, Mechanismen, Software oder sonstige Routinen bei der Nutzung von auftrag.at zu verwenden, die den Betrieb von auftrag.at beeinträchtigen können. Die Nutzung von auftrag.at darf nur im Rahmen des normalen Geschäftsbetriebes und im vereinbarten Umfang erfolgen.

„Angeblich“ deswegen, weil diese AGBs für mich auf auftrag.at nicht auffindbar waren und ich mich daher auf die von Dirk Heringhaus zitierte Version verlassen muß. (Wobei ich es, ganz nebenbei bemerkt, schon seltsam finde, daß ich auf so einer Seite keine AGBs finden kann.)

Weiters wird Herr Heringhaus „aufgefordert“, eine Dokumentation seiner „Eingriffe“ zu übermitteln. Richtigerweise kommentiert Dirk Heringhaus diese Mail mit:

Wozu Sicherheitsvorkehrungen in einer Bank? Es ist doch verboten eine Bank zu überfallen, oder fremdes Geld an sich zu nehmen. […] Alles ganz einfach: Wir brauchen nur AGBs…

[…]„ich möchte sie daher auffordern“ - Jetzt aber mal wirklich: Ich bekomme für meine Hilfe ja schon kein Geld – weder fordere ich es, noch wird es mir in irgendeiner Form angeboten - aber ein „Bitte“ oder „Danke“ in irgendeiner Form tut dann und wann gut. Aufgrund von „Was“ fordern Sie etwas von mir? In dieser Form lasse ich mich bestimmt nicht fordern.

Wie gesagt: Sicherheitslücken gehören zur EDV wie das Schwarze zu den Fingernägeln. Man macht es weg, es kommt wieder. Es kommt also darauf an, wie man damit umgeht. Ein Verweis auf die AGB reicht sicherlich nicht aus. Vor allem aber sollte es mittlerweile zum guten Ton gehören, gerade jenen Hackern, die einen diskret auf solche Schwachstellen aufmerksam machen, zu danken und ihre Arbeit zu honorieren. Bei uns wird stattdessen immer noch Befehlston angeschlagen, werden Rechtsabteilungen eingeschaltet und wird darauf verwiesen, daß das ja sowieso alles nicht sein kann, weil es den Geschäftsbedingungen widerspricht. Da liegt noch ein weiter, weiter Weg vor uns.

auftrag.at dürfte die Lücke mittlerweile geschlossen haben, zumindest läßt sich aus den News auf der Startseite schließen, daß neue Zugangsdaten zu verwenden sind. Zuvor hat Dirk Heringhaus alle Kunden, deren Accounts er einsehen konnte, angemailt und sie über diese Tatsache in Kenntnis gesetzt. Technisch scheint’s also beendet. Ich hoffe, daß auf Sicherheitsnotizen demnächst auch etwas über einen kulturellen Fortschritt bei auftrag.at zu lesen sein wird. Der Jahreszeit entsprechend wäre ein Weihnachtsgeschenk an Herrn Heringhaus angebracht.


Statistik: Browser, Betriebssysteme, Seitenaufrufe

Seit ca. einem Monat läuft ein Zähler bei blogcounter für dieses Blog mit. In dieser Zeit hatte ich im Schnitt 11 Besucher pro Tag. (Seitenaufrufe: 24/Tag) Ich weiß jetzt, daß ich Leser aus Brasilien und Japan habe und fühle mich geehrt.

Besonders interessant finde ich die Aufstellung über die von den Besuchern verwendeten Browser und Betriebssysteme. Bei den Browsern bin ich besonders stolz auf mein verehrtes Publikum - der Internet Explorer liegt bei weitem unter den sonst üblichen Werten:

Browser Anteil in Prozent
Internet Explorer 58,14%
Firefox, Mozilla und Netscape 38,37%
Opera 3,49%

Weniger überraschend die Situation bei den Betriebssystemen, obwohl auch hier Mac OS X und GNU/Linux gemeinsam mit deutlich über 10% besser als erwartet im Rennen liegen:

Betriebssystem Anteil in Prozent
Windows XP 68,47%
Windows 2000 12,61%
Mac OS X 6,01%
GNU/Linux 5,41%
Windows ME 2,70%
Windows 98 2,40%
Andere 2,40%

Der Zähler ignoriert übrigens meine eigenen Seitenaufrufe. Die Tatsache, daß ich selbst beim Schreiben von Einträgen mit GNU/Linux und Firefox zugreife und natürlich einer der regelmäßigsten Besucher hier bin, hat die Statistik also nicht verfälscht.


Steve Jobs ist Darth Vader

Steve Jobs als Darth VaderHalloween kann mir ja an sich gestohlen bleiben. Andererseits: Ohne Halloween würde das Wirtschaftsmagazin Forbes nicht jährlich bekannten Managern bunte, lustige Masken per Fotomontage auf’s Gesicht klatschen. Heuer hat es - neben Alan Greenspan, Oprah Winfrey und anderen - gleich als ersten Steve Jobs erwischt. Ihm wurde die Ehre zuteil, mit Darth Vader verglichen zu werden:

… as time passed, his hunger for power took over, leading him to sue hapless bloggers and embrace dark arts, like digital-rights management.

Der Originalartikel enthält den Link auf die Maske zum Ausdrucken und Ausschneiden.

Typographie

Es war die kurze Übersicht „Die häufigsten Typografie-Fehler“, die mir diese Flausen ins Ohr gesetzt hat. Ich kann diesmal wirklich nichts dafür!

Jedenfalls wußte ich nach kurzem Überfliegen dieses Artikels und nach eingehender Beschäftigung mit „Satzzeichen“ auf Wikipedia: Ich kann nicht weiter [Shift]+[2] auf der Tastatur drücken, um Anführungszeichen zu schreiben. Ich kann nicht weiterhin drei mal auf die Taste [.] klopfen, um Auslassungen zu kennzeichnen („Verschwinde von hier, du …loch!“). Nein! So weit als möglich sollten ab nun die typographisch korrekten Zeichen wie „, “, …, ’ etc. hier verwendet werden. Nur: Wie stell ich’s an? Gemeinerweise sind diese Zeichen auf keiner Tastatur zu finden.

Die Lösung war mehrstufig: Echte Zitate werden im HTML-Quelltext mit dem <q>-Tag ausgezeichnet. Über das Stylesheet wird der Browser dann angewiesen, mit <q>…</q> eingeschlossene Zitate mit den korrekten Anführungszeichen zu versehen. Das funktioniert (fast) überall. (Einzige Ausnahme, wie so oft: der Internet Explorer von Microsoft. Aber damit kann ich leben.)

Für alle anderen Anwendungsfälle bleibt weiterhin nur die Eingabe über die Tastatur. Für Windows kenne ich hier nur den uralten Trick mit niedergedrückter [Alt]-Taste und Eingabe eines 4stelligen Zahlencodes auf dem Ziffernblock.

Beim Mac scheint ein einfacheres Verfahren zu existieren (Mac OS: Wahltaste + 2 für “), Details konnte ich aber auf den Übersichtsseiten nicht auftreiben.

Unter GNU/Linux könnte ich (zumindest im GNOME-Desktop), ähnlich wie unter Windows, [Shift]+[Strg]+Unicode des Zeichens Tippen, also z.B. [Shift]+[Strg]+201E für „.

Da ich nun meistens unter GNU/Linux arbeite, habe ich mir einfach meine Tastatur umdefiniert. Zusammen mit [AltGr] zaubern [Y] und [X] ein « bzw. ein », [V] und [B] stehen für „ und “, [AltGr]+[.] ergibt … und so weiter.

Ach ja: Natürlich könnte ich auch die HTML-Entities verwenden. &bdquo; zum Beispiel (für „) oder &hellip; für … ‐ aber so dumm das jetzt auch klingt: Das ist mir zu mühsam. Außerdem sollte man sich gar nicht erst daran gewöhnen: In XML-Umgebungen außerhalb von (X)HTML werden diese named entities in der Regel nicht verstanden.

PS: Wirklich gemein ist, daß die hier verwendete Schrift Verdana, noch dazu in dieser Größe, kaum einen Unterschied erkennen läßt. Eine andere Schriftart zeigt besser, was gemeint ist.

„Verwend’ korrekte Satzzeichen, sonst …“

"Verwend' keine falschen Satzzeichen, sonst ..."


Podcasts: Heiße Luft?

Es gibt Begriffe, die nur deshalb exisitieren, weil sie die Herzen der Ich bin so hip, ich mach' der Million anderer Starbucks Venti Latte Trinker alles nach-Szene erreichen. Podcasting ist einer davon - zumindest technisch gesehen.
Für viele beschreibt Podcasting einfach die Idee von "Radio über Internet", vielleicht noch verbunden mit dem Gefühl des amateurhaft Sebstgestricken. Falsch. Internet-Radio existiert seit 1993 mit mehr oder weniger hörenswerten Inhalten und mit den verschiedensten technischen Grundlagen, und zwar je nach Bedarf entweder als Live-Stream oder als Playlist. Trotzdem wurde der Begriff "Podcasting" erst im Februar 2004 in einem Artikel des Guardian erstmals erwähnt (und mit hoher Wahrscheinlichkeit gleichzeitig erfunden). Was also unterscheidet die Podcasts von heute technisch gesehen von den Playlists, mit denen man vor vier Jahren sein selbstgebasteltes Radio in die Welt übertragen hat?
Grundsätzlich handelt es sich bei Podcasts (meist) um RSS-Files. Das ist, vereinfacht gesagt, der einzige Unterschied zu früher und gleichzeitig der kleinste gemeinsame Nenner aller Podcasts. RSS steht, je nach Version und Lesart, für "Rich Site Summary", "RDF Site Summary" oder "Really Simple Syndication". RSS-Dateien werden geschrieben, um auf andere Inhalte zu verweisen, diese zu beschreiben und in eine chronologische Abfolge zu bringen. Gleichzeitig enthalten sie die Information darüber, wie oft diese Inhalte sich wahrscheinlich ändern werden.
Podcasts nützen nun genau diese Eigenschaft: Ein Podcast-File beschreibt
  • eine Liste von Audio-Dateien (die irgendwo abgespeichert sind)
  • mit ihrer jeweiligen Entstehungszeit, aus der sich die Abspiel-Reihenfolge ergibt,
  • und dem Zeitpunkt, zu dem voraussichtlich die nächste Änderung stattfinden wird (=ein neues Stück hinzukommt).
So weit, so einfallslos. Das ist einfach RSS, wie es seit Jahren existiert. Keine aufregende neue "Podcasting-Technologie". RSS 1.0 konnte das von Anfang an, ohne daß es den Entwicklern der Spezifikation überhaupt aufgefallen wäre. RSS 2.0, die fast gleichzeitig entstandene "Konkurrenz-Spezifikation", ist etwas unflexibler und benötigt zur Beschreibung von Multimedia-Inhalten sogenannte "enclosures", die 2001 zur Spezifikation hinzugefügt wurden. (Im Grunde schafft das auch jede *.m3u-Playlist, wenn man ein zusätzliches Feld für den Zeitpunkt der nächsten Änderung spezifiziert.)
Weil nun Podcasts einfach nur RSS sind, können sie natürlich auch alles, was RSS (bzw. die gerade verwendete RSS-Version) ebenfalls kann: Bilder, beschreibende Texte und Verweise auf andere Dokumente können in die Struktur eingebaut werden. (http://www.kommunismus.net/podcast/index.xml nutzt diese Möglichkeit sogar für den Verweis auf begleitende PDF-Files.)
Erst seit Juni 2005 erhält der Begriff Podcasting erstmals auch eine technische Dimension: Apple hat eine Erweiterung zu RSS 2.0 veröffentlicht (und in iTunes 4.9 eingebaut), die RSS 2.0-Files mit iTunes kompatibel machen soll. Dabei geht es vor allem um die Art der Bezeichnung und Kategorisierung von Dateien. Hier hätten wir es also erstmals mit einer Spezifikation zu tun, die gezielt auf den Begriff "Podcasting" zugeschnitten ist. Allerdings wird der Wert dieser Spezifikation mehr als nur bezweifelt: Die mildeste Reaktion war Edd Dumbills Apple clearly don't have enough people who really understand XML. Eine ausführliche Aufzählung der Probleme findet sich im Artikel Finger in the Dike, Thumb in the Damned, in dem die düstere Vermutung geäußert wird, daß diese "Erweiterung" das Ende des ohnehin schon problematischen RSS-Formats sein könnte:

iTunes is to podcasting as Internet Explorer is to HTML. RSS interoperability, at least as far as podcasting goes, now means “works with iTunes.” Thousands of people and companies will begin making podcasts that “work with iTunes,” but unintentionally rely on iTunes quirks [...]. This in turn will affect every developer who wants to consume RSS feeds, and who will be required to emulate all the quirks of iTunes to remain competitive.

Apple has effectively redefined the entire structure of an RSS feed, added multiple core RSS elements, made all RSS elements case-insensitive, made XML namespaces case-insensitive, created a new date format, made several previously required attributes optional, and created a morass of undocumented and poorly-documented extensions… to what was already a pretty messy format to begin with.

Was bleibt also unterm Strich? Podcasts spielen Audio-Dateien in einer fix vorgegebenen Reihenfolge ab. Das konnte schon vorher jedes beliebige Playlist-Format. Sie nutzen (oder mißbrauchen) dazu RSS, seit den 90ern in verschiedenen Versionen existiert. Im Grunde ist es ein schönes Buzzword für etwas, das es bereits seit Ewigkeiten gibt. Was weiter nicht schlimm wäre (das nächste Buzzword kommt bestimmt), wenn nicht die Gefahr bestünde, daß durch die mißlungenen RSS-Erweiterungen von Apple der gesamte Standard gekippt wird.
Wie gesagt, das alles bezieht sich auf die technische Seite. Inhaltlich möchte ich, wie zu Beginn, http://hitherto.net zitieren: Just because you have a face for radio does not mean that you have a voice for radio.

Trackbacks

Versuchsweise habe ich heute die Trackback-Funktion in meinem Blog aktiviert. Damit können auf anderen Trackback-fähigen Websites "externe Kommentare" zu meinen Blog-Einträgen verfaßt werden.
Funktionieren tut das so:
Ich schreibe einen Eintrag darüber, wie sehr ich Leberknödelsuppe liebe. Irgendwo sitzt Karin, die meinen Eintrag liest und dabei auf die Idee kommt, ihr Rezept für Leberknödelsuppe zu veröffentlichen. Allerdings will sie das nicht als Kommentar in meinem Weblog hinterlassen, sondern einen eigenen Artikel dazu in ihrem Blog "Essen und Trinken" verfassen. Der Bezug zu meinem Artikel soll aber erhalten bleiben; vor allem soll man auf meiner Seite einen Link zu ihrem Rezept finden.
Um das zu erreichen, holt Karin sich die sogenannte Trackback-URL, die ab sofort unter jedem meiner Einträge aufgeführt ist, und fügt sie ihrem Artikel hinzu. Im Hintergrund nehmen nun die beiden Webserver Kontakt miteinander auf: Karins Server schickt eine Nachricht an den meinen, und ohne mein Zutun erscheint ein Link zu Karins Werk unter meinem Leberknödel-Eintrag.
Unnötig zu erwähnen, daß sich diese Technik auch hervorragend dazu eignet, fremde Weblogs mit völlig unpassendem Werbemüll zuzuspammen, falls der Server keinen Spamschutz bietet. Mal sehen, wie das hier auf twoday.net realisiert ist...

XHTML 2.0: Ersatz für @hreflang?

XHTML 2 sieht zwar weiterhin ein Attribut "hreflang" vor (so wie HTML 4.01 und XHTML), allerdings in einer völlig veränderten Bedeutung, die es eigentlich überflüssig macht. Die ursprüngliche Bedeutung wird sich über das META-Element wieder ausdrücken lassen. Ein vollwertiger Ersatz wird dies jedoch höchstwahrscheinlich nicht.

Schon 2003 ist mir im damals aktuellen Public Working Draft des W3C für XHTML 2 aufgefallen, daß das aus HTML 4.01 und XHTML 1.0 bekannte hreflang-Attribut fehlte. Obwohl selten benutzt, hatte es doch einigen Charme: Man konnte als Autor von HTML-Dokumenten auf ein externes Dokument verweisen und dem Leser gleichzeitig die Information mitgeben, in welcher Sprache dieses externe Dokument verfaßt war.

Beispiel: Auf einer deutschsprachigen Homepage verweise ich auf eine türkische Seite. Mit dem Zusatz hreflang="tr" kann ich diesen Link als türkischsprachig markieren. Sofern diese Meta-Information dem Leser vom Browser (oder durch ein Stylesheet, Script ...) in irgendeiner Weise angezeigt wird, spart er sich den Klick und die Wartezeit, sofern er nicht türkisch spricht. Nicht lebensnotwendig, aber praktisch.

In XHTML 2 war dieses Attribut zunächst nicht mehr vorgesehen, rutschte dann aber - vielleicht auch aufgrund der relativ umfangreichen Diskussion nach meiner Anfrage in der Mailing-List - wieder hinein. Leider mit einer völlig veränderten Bedeutung, die mit der ursprünglichen Intention als Meta-Information gar nichts mehr zu tun hat. Ein Auszug aus dem aktuellen Public Working Draft:
The user agent must use this list as the field value of the accept-language request header when requesting the resource using HTTP.
Im Klartext: Das Attribut ist keine Meta-Information mehr. Es beeinflußt nun, welches von mehreren verfügbaren Zieldokumenten der Browser anfordern soll.

Beispiel: http://members.aon.at/neumair steht in 2 Sprachversionen zur Verfügung. Wenn der Leser die Seite mit einem auf Deutsch eingestellten Browser aufruft, erhält er das deutsche Dokument, ansonsten das englische. (In Wahrheit stehen dahinter 2 Seiten, .../neumair/index_de.htm und .../neumair/index_en.htm - der Webserver entscheidet, welche der beiden Seiten ausgeliefert wird.) Wenn ich nun in Zukunft mit XHTML 2.0 von meiner Website auf http://members.aon.at/neumair/ verlinke, kann ich die Browser meiner Leser durch die Angabe von hreflang="en" zwingen, die englische Version zu holen - auch dann, wenn der Leser seinen Browser auf "Deutsch" eingestellt hat. Das mag insofern brauchbar erscheinen, als man damit gezielt auf die einzelnen Versionen verlinken kann. In Wahrheit ist es selbstverständlich überflüssig:

Die Angabe
href="http://members.aon.at/neumair/" hreflang="en"
ist absolut gleichbedeutend mit
href="http://members.aon.at/neumair/index_en.htm"

Kurz gefaßt: Das Attribut hreflang hat seine ursprüngliche Bedeutung als Meta-Info verloren, der Sinn seiner neuen Bedeutung erschließt sich mir zumindest auf den ersten Blick nicht.

Nun scheint es aber so, als ob die alte Bedeutung von hreflang in XHTML 2 zumindest auf Umwegen wieder Einzug gehalten hätte:

Die Meta-Informationen sind der Schlüssel. Was in HTML 4.01 und XHTML 1.0 noch sehr einfach mit

<a href="http://members.aon.at/neumair/index_de.htm" hreflang="de">... </a>

auszudrücken war, ist nach dem aktuellen Entwurf in XHTML 2 zwar komplizierter, aber möglich:

<meta about="http://members.aon.at/neumair/index_de.htm" property="dc:language" content="de"/ >
<a href="http://members.aon.at/neumair/index_de.htm">... </a>


Die Art der Notation ist umständlich und im Vergleich zur jetzigen Handhabung wenig elegant, die Bedeutung jedoch die gleiche. Gleichwertig sind die beiden Varianten dennoch nicht: Mit HTML 4.01 bzw. XHTML 1 ist es einfach, CSS-Formatierungen an den Inhalt eines hreflang-Attributes zu knüpfen und so zB vor/nach jedem Link den Sprachencode oder ein Flaggensymbol einzufügen. Dieser Mechanismus läßt sich mit dem Meta-Element aus XHTML 2.0 nicht umsetzen. Die Information bleibt also im Dokument erhalten, wird aber de facto nicht mehr darstellbar.

Verzerrte Bilder II

Wie in diesem Eintrag beschrieben, gab es Probleme mit einer verzerrten Darstellung von Bildern im Internet Explorer und, wie sich später herausstellte, in Safari/Konqueror.
Während es sich bei der Safari/Konqueror-Familie um einen ziemlich einfachen und nachvollziehbaren Bug bei der Behandlung des CSS-Attributs "auto" für die Höhe eines Bildes handelt, war und ist das Verhalten des Internet Explorers rätselhaft: Ob es nämlich zur falschen Darstellung kam oder nicht, hing ein bißchen von der Anzahl der Bilder auf der Seite ab und war nach jedem Reload ein bißchen anders, also nicht vorhersehbar.
Meine Vermutung: Der Internet Explorer versucht die richtige Höhe für das Bild zu einem Zeitpunkt festzulegen, zu dem das Bild noch nicht fertig geladen ist. Er kann daher das Original-Seitenverhältnis (das ja beibehalten werden soll) noch nicht kennen und macht Fehler. Beim Laden der gleichen Seite (inkl. aller Bilder) von der lokalen Festplatte tritt das Problem nicht auf. Hier ist offenbar jede Dateiinformation schnell genug vollständig verfügbar.
Mein Lösungsansatz (nicht sehr elegant, aber erscheint zu funktionieren): Die von meinem Kamera-Handy gesendeten Bilder haben immer ein fixes Seitenverhältnis. Ich habe also die Angabe für die Höhe eines Bildes im Stylesheet von 'auto' auf '90px' geändert. Das funktioniert so lange, solange ich nicht a) ein Foto mit der Handy-Einstellung "Porträt" verwende (anderes Seitenverhältnis) oder b) das Handymodell wechsle.
Ganz glücklich macht mich die Sache nicht. Vor allem finde ich in höchstem Ausmaß irritierend, daß ich im Web noch keinen Hinweis auf diesen bug gefunden habe. Kann ja nicht sein, daß nur ich "auto" als Höhenangabe verwende...?