Google hat einen netten Browser herausgebracht. Nur für Windows zunächst und auch noch in einer verbuggten Beta, aber ok. Was sind die Highlights? Da sind spontan die neue JavaScript Engine und die Sache mit den Tabs in eigenen Threads. Letzteres ist jetzt keine sooo neue Idee und der Effekt mit dem geringen Speicherverbrauch – ich weiß nicht, wie es bei Euch ist, aber selbst als Redakteur komm ich auf maximal 7 Tabs (für ein paar Minuten) und da stößt keiner meiner Rechner auch nur annähernd an seine Leistungsgrenzen (es sei denn, ich besuche createordie.de, die hier passender Weise ein Stimmungsbild eingefangen haben;-)

JavaScript, dass schneller verarbeitet wird? Ok, ich gebe zu, da kann man neidisch werden. Wenn auch nur ein wenig. Ich selbst lebe ganz gut mit WebKits‘s Nightly Build, der seit SquirrelFish ja nun auch keine so schlechte Figur mehr macht.

Muss ich dafür einen weiteren Browser haben? Ich glaube nicht. Andererseits will Google ja auch nicht das Rad neu erfinden – sondern nur etwas Chrome auftragen…

Laut Alexey Proskuryakov, WebKit Reviewer, liegt es wohl in der Handhabung der Accept Header:

This happens because WebKit no longer sends “text/xml” in Accept header. The ChangeLog for <http://trac.webkit.org/projects/webkit/changeset/35167> states that we match Firefox 3, but this is not quite true – only the list of accepted types is the same, but their priorities are quite different.

In Safari 3, the Accept header matched Firefox 2 exactly.

Kurz gesagt, die Art und die Reihenfolge der Accept Header ist noch nicht ganz so, wie es sein sollte.

Davon einmal abgesehen noch schnell ein Lob an alle Beteiligten. Innerhalb von nur zwei Stunden hatte Alexey den Bug aufgenommen und selbst Dustin Whittle (Symfony-Core-Developer) hat kaum eine Stunde nach bekanntwerden des Problems einen Blick auf seine Server-Konfiguration werfen können. Das das so schnell geht, hätte ich dann doch nicht gedacht.

Mal schauen, ab wann der Fehler auch wirklich beseitigt ist;-)

Ich selbst mag es ja lieber, wenn Links sich in einem neuen Tab öffnen. Dann kann ich weiterführende Infos schon einmal laden lassen, währed ich noch durch den eigentlichen Text lese. Neues Fenster ginge wohl auch, aber ich hab es gerne unter einer Oberfläche.

Andererseits … angeblich mögen auch viele dieses target=”blank” nicht. Der Surfer soll selbst entscheiden, was durch seine Klicks ausgelöst wird. Und außerdem gibt es ja auch Back-Buttons. In Zeiten von AJAX und nicht immer funktionierenden Back-Buttons sehe ich sowas aber kritisch. Nee, für mich muss es ein neuer Tab sein.

Natürlich hab ich mir das Tastenkürzel für das Öffnen von Hyperlinks in neuen Fenstern schon angewöhnt, aber wie angenehm wäre es, wenn alle von sich aus target=”blank” (oder von mir aus auch target=”_blank”) einsetzen würden …

Um es genau zu wissen, gibt es unten links einen passenden Quickvote dazu.

P.S.: Ich spreche sogar tatsächlich davon, alle Links in einem neuen Tab zu öffnen. Wobei ich, ganz selten und unter bestimmten Voraussetzungen, einen internen Link zulassen könnte. Vor allem in Menüelementen wie der Siedebar, hier gleich rechts. Oder da ganz oben, in der Hauptnavigation.

Exemplarisch weiterführende Meinungen zum Thema, das so alt ist, wie target selbst:

Er mag es nicht: Warum target=”_blank” nervt und verboten gehört

Er mag es: target=”_blank”

Ein Mann und eine Frau. Und zwischen ihnen der Link.