Webdesign - Zapps Blog

Ich finde es schon spannend, dass Safari offensichtlich seine eigenen Schriften mitbringt, die von ihm unabhängig von den Systemschriften verwendet werden.

Safari 3.1/Win stellt momentan das Blog auch auf Windows-Rechnern mit der Lucida Grande dar, während die anderen Browser mit dieser Schriftartangabe nichts anfangen können und auf Arial zurückfallen.

Leider sieht die Microsoft-Alternative Lucida Sans Unicode, die auch die anderen Browser auf meinem System kennen, vergleichsweise hässlich aus und wird daher nicht zum Einsatz kommen.

Mehr zur Lucida und ihrem Problem mit Kursiven bei Gerrit, dem ich nicht zuletzt wegen seiner wirklich guten Artikel viel Glück beim Befreiphone-Gewinnen wünsche: Gute Lucida, schlechte Lucida.

Auf den meisten Windows-Systemen dürfte der erste Block in Arial dargestellt werden, erst mit Safari sieht man den Unterschied. Ist Safari installiert, findet man die Lucida Grande im Ordner Safari.resources im Installationsverzeichnis und kann sie natürlich auch den Systemschriften hinzufügen.

Ich habe momentan ein leichtes Déjà-vu-Erlebnis, das mich ein paar Jahre zurückwirft.

Als ich damals begann mich für HTML und CSS zu interessieren, fand ich die Möglichkeiten beider Sprachen faszinierend und das Konzept der Trennung von Inhalt und Layout einleuchtend. Der erste Tatendrang wurde zeitweise nur durch eine Software aus dem fernen Redmond gebremst: den Internet Explorer.

Version sechs verhielt sich oft anders, als man das angesichts des Codes erwarten sollte. Schnell war klar, dass das nicht nur am anfängerhaften Code sondern auch und vor allem am veralteten Browser lag und mit der Zeit und einigen Internetrecherchen lernte ich manche Eigenheiten des IE kennen. Begriffe wie „Star-HTML-Hack“ und „hasLayout“ verloren ihre Schrecken und so wurden Layouts möglich, die auch im im IE 6 und seinem grossen Bruder IE 7 akzeptabel aussehen.

Nun stehe ich mit JavaScript wieder am Anfang einer neuen Websprache und was soll ich sagen: Die Probleme sind ähnlich. Es gibt recht klare und einleuchtende Konzepte, die in der Praxis am IE scheitern.

So gibt es etwa die setAttribute-Methode, die einem Knoten ein Attribut zuweisen kann. Einem Link kann beispielsweise mit linkknoten.setAttribute("class","externer"); die Klasse „externer“ zugeteilt werden, die man mit der komplementären getAttribute-Methode auch wieder auslesen kann. Mit der gleichen Syntax könnte der Link auch noch href- und title-Attribute bekommen, bevor er schliesslich in den Dokumentenbaum eingehängt wird. setAttribute ist universell einsetzbar und hat eine leicht zu merkende Syntax, warum sollte man sich für das Setzen und Auslesen von Klassen noch mit dem Wissen um die vergleichsweise spezielle className-Eigenschaft eines Knotens belasten müssen?

Ganz einfach: Weil der Internet Explorer in seinen beiden am weitesten verbreiteten Inkarnationen nicht zuverlässig damit klar kommt.

Durch setAttribute gesetzte Klassen, die der IE-DOM-Inspektor auch sieht, werden dann auf einmal vom CSS nicht beachtet oder Klassennamen werden nicht korrekt ausgelesen, weshalb das betreffende Script dann natürlich nicht im IE funktioniert.

Genau das gleiche Problem existiert im IE bei der Behandlung des onclick-Attribut, auf das man verzichten und stattdessen knotenname.onclick = function(){}; einsetzen sollte.

Dummerweise stand das nicht in meinem ansonsten wirklich genialen Lehrbuch, was mir einige Stunden Gefluche mit meinem Lieblingsbrowser eingebracht hat. Bei einem so diffusen Problembild war meine Webrecherche erfolglos, und auf die Idee, bei SELFHTML ausgerechnet bei setAttribute nachzuschlagen um dort eine eindringliche Warnung inklusive Erklärung des Phänomens zu finden, bin ich leider nicht gekommen. So brachte erst ein beiläufiger Hinweis in einem JavaScript-Cheatsheet die Erleuchtung.

Und damit Google in Zukunft eine Stelle mehr im Web findet, die von Anfängerproblemen mit JavaScript, Klassen, Event-Handlern und dem Internet Explorer berichtet, habe ich diesen kleinen Beitrag verfasst.

• kann nicht mehr per

  html/*\*/>/*/*/body {} head/*\*/+/*/*/body {} html/*/*/>/*/*/body {} head/*/*/+/*/*/body {} html>/**/body {}

  von CSS ausgeschlossen werden.

  Zwischen Beta 1 und Beta 2 hat es hier wohl massive Änderungen in Richtung Standardkonformität gegeben, bei einer zugegebenermassen ziemlich kurzen Suche habe ich noch keinen funktionierenden Hack gefunden.

• versteht nun auch

  @import url(style.css) all;

• interpretiert manche CSS-Angaben aber immer noch so saudumm wie seine Vorgänger.

  Die Unterstützung von @font-face kann man nicht unbedingt erwarten, aber warum produziert das Ding bei

  @font-face { font-family: GraublauWeb; src: url(../fonts/GraublauWeb.otf) format(truetype); /* www.fonts.info */ }

  eine Anfrage nach

  GraublauWebBold.otf)format(truetype

  und damit unweigerlich einen 404?

Grumpf!

Eine der von Microsoft gross beworbenen Neuerungen des Internet Explorer 8 wird die Unterstützung von Webslices sein.

Webslices ähneln einem RSS-Feed darin, dass sie dem IE-Benutzer erlauben, Inhalte aus einer Internetseite herauszulösen und sie bequem über die Lesezeichenliste zugänglich zu machen. Das entsprechende „Bookmark” erscheint ausserdem fett gedruckt, wenn sich der Inhalt des Webslice geändert hat.

Konzeptionell ist das nichts besonders neues, der Grundgedanke ähnelt RSS-Feeds und die Umsetzung entspricht letztlich einem von Microsoft definierten Microformat mit den drei Bezeichnungen hslice, entry-title und entry-content.

<div class="hslice"> <h2 class="entry-title">Aktuelle Meldungen</h2> <ul class="entry-content"> <li></li> <li></li> </ul> </div>

Beispiel 1: Der Inhalt der gesamten Liste kann in einem Webslice mit dem Titel „Aktuelle Meldungen” dargestellt werden.

<div class="hslice"> <h2 class="entry-title">Aktuelle Meldungen</h2> <h3 class="entry-content"></h3> <p><p> <h3 class="entry-content"></h3> <p></p> </div>

Beispiel 2: Hier werden nur die Artikelüberschriften, nicht jedoch die Artikeltexte im Webslice auftauchen.

Allerdings ist die Integration der Inhalte im IE 8 deutlich hübscher lösbar, als mit der rudimentären RSS-Unterstützung, die etwa Live-Bookmarks bieten. Somit könnten sich neue Anwendungsgebiete eröffnen, von Microsoft wird gerne die Verfolgung von Auktionen bei eBay als Beispiel angegeben.

Das klingt alles ganz einfach, hat aber einen kleinen Nachteil: Erstellt man Webslices mit dieser simplen Methode, gestaltet sich ihr Layout einigermassen schwierig. Im Vorschaufenster wird um die entry-content-Elemente einfach ein <body></body> gelegt, auf den die gleichen CSS-Selektoren zutreffen, wie auf den eigentlichen Body der Ursprungswebsite. Ist dort beispielsweise eine Hintergrundfarbe angeben, die der Farbe der h3-Ãœberschriften im Webslice-Container entspricht, hat man das klassische Problem des schwarzen Adlers auf schwarzem Grund.

Aber Microsoft wäre nicht Microsoft, wenn sie dafür nicht eine typische Lösung parat hätten: Man möge seinem „richtigen” Body doch bitte eine ID oder Klasse zuweisen und ihn dann darüber ansprechen â€¦

Das halte ich aus semantischen Gründen nur für begrenzt sinnvoll und so habe ich mich bei meinen Experimenten mit einem Selektor, der die ID eines übergeordneten ausserhalb des Webslice liegenden Containers enthält, beholfen. So ist nun die Rubrik „Aktuelles” aus der Navigationsspalte auch als Webslice zu haben.

Wer sich das Ganze mal anschauen mag, braucht aber nicht unbedingt den IE 8 zu installieren, die Webchunks-Erweiterung rüstet eine Websliceunterstützung für den Firefox nach. Die Erweiterung ist noch nicht ganz ausgreift, inkompatibel zur All-in-One-Sidebar-Erweiterung und legt die Slice-Links in einer separaten Toolbar statt zu den Lesezeichen ab, aber für einen ersten Eindruck der Möglichkeiten reicht’s.

Mit einem selbst zu schreibenden Greasemonkey-Script ist es ausserdem möglich, von jeder beliebige Seite Webslices für den Firefox zu erstellen.

Update (02.09.2008):

Webchunks scheint mit der Angabe einer spezifischen Vorschauseite nicht klarzukommen. Daher benutzt Webchunks hier im Blog die wie oben beschrieben eingebetteten Webslice-Informationen, während der IE 8 im Vorschaufenster richtigerweise die per

eingebundene Alternativseite zeigt.

Durch die Angabe einer Alternativseite eröffnet sich die komplette Palette an CSS-Gestaltungsmöglichkeiten für die Webslice-Vorschau, worauf Firefox-Benutzer momentan wohl leider verzichten müssen.

Und noch ein Benutzerstylesheet, das das neue heise-Layout durch die Mangel dreht:

Das Originallayout wird kräftig entschlackt und flexibel an die Grösse des Browserfensters angepasst.

Mit Hilfe eines Benutzer-JavaScripts können ausserdem die Topnews in die Sidebar verlegt werden. Dann sollte man auch auf kleineren Monitoren nicht mehr scrollen müssen, um die neusten Nachrichten auf heise.de zu finden.

Stylesheet und Greasemonkey-JavaScript sind nicht kompatibel zu den älteren Versionen.

Update (29.08.2008):

Die neue Variante des User-JavaScripts ist gegenüber Veränderungen bei heise-Online etwas toleranter und funktioniert auch ohne ein Benutzerstylesheet mit dem Heise-Originallayout. Da im neuen JavaScript auch einige wenige Layout-Informationen stecken, habe ich mein Benutzerstylesheet entsprechend angepasst.

Heute habe ich mein erstes Layout mit display:table-cell gebastelt, allerdings mit tatkräftiger Unterstützung der Jungs und Mädels von heise online:

Mit dem richtigen Stylesheet ist das viel kritisierte neue Layout von heise gar nicht mal so übel.

Zumindest erlaubt die neue technische Basis der Seite, die auf XHTML und CSS setzt, nun das einfache Entwickeln von Userstylesheets ohne dass man sich dabei durch Tabellen kämpfen muss. Über einige recht unsemantische Bezeichnungen, etwa #mitte_rechts oder .col100weiss, sollte man dabei allerdings auch mal hinwegsehen können.

CSS und Script werden nicht weiterentwickelt. Ich empfehle die neue Kombination von Stylesheet und JavaScript aus diesem Beitrag: Jedem sein eigenes heise.

Wer mit Safari im Web unterwegs ist, wird bemerkt haben, dass sich das Erscheinungsbild des Blogs etwas geändert hat. Die eingesetzte Schriftart ist nun die Graublau Sans Web von fonts.info.

Safari ist momentan der einzige Browser, der das Einbinden von Schriftarten in Internetseiten mit CSS unterstützt. Die dazu notwendige @font-face-Regel wird von allen anderen Browsern ignoriert, die weiterhin Verdana als Standardschriftart des Blogs verwenden.

Ich finde die Möglichkeiten, die sich durch die Einbettung beliebiger Schriftarten ergeben, ziemlich spannend, auch wenn sich damit eventuell wieder ein weites Feld für Abmahnungen eröffnet, wenn Schriftarten unter Verletzung ihrer Lizenzbedingungen eingesetzt werden.

Normalerweise produzieren mies erstellte Webseiten lediglich frustrierte Ex-Besucher, die Website der SEB-Bank stellte hingegen für die Kunden dieser Bank ein handfestes finanzielles Risiko dar: Online Banking fatal (heise security).

Dass die Bank auch noch mit einem Siegel „Sehr gute Website” wirbt, setzt dem Ganzen dann die schwedische Krone auf (1). Erinnert mich irgendwie an eine katastrophale Kommunen-Website, die mit ihrer Barrierefreiheit warb.

Es sind also leider nicht nur deutsche Kommunen, sondern auch Privatunternehmen mit extrem hohen Sicherheitsbedürfnissen absolut ahnungslos, was Internettechniken angeht. Und zwar so ahnungslos, dass sie nicht mal auf die Idee kommen, externen und unabhängigen Sachverstand zur Überprüfung ihrer Seiten einzukaufen.

1) Wobei anzumerken wäre dass dieses „Qualitätssiegel” von einem Markforschungsinstitut aufgrund einer Befragung der Besucher der Site vergeben wurde. Von einer so fachkundigen und repräsentativen Jury (Sehbehinderte werden wohl kaum darunter gewesen sein, mein Alt-Text-Favorit ist „teaser_bjoern_3”) kann man natürlich keine ernsthafte Bewertung erwarten.

Ein bisschen war ich ja schon überrascht, als Google bereits zwei Stunden nach der Veröffentlichung meines Gammelfleisch-Artikels damit anfing, mir fleissig Besucher zu vermitteln. Allerdings scheint Google generell einen Zahn zugelegt zu haben, was die Indizierung angeht, sodass bei Rivva sogar schon fast die Technorati-Dämmerung heranziehen gesehen wurde.

Der Leserzustrom zu meinem Blog erklärte sich durch den guten 7. Platz, den der Artikel bei Google mit der Suchphrase „k3 fleisch” errungen hatte. Leider verlinkte die Suchmaschine aber die Hauptseite des Blogs und nicht den Artikel. In einigen Tagen würde der Beitrag so also nicht mehr zu finden sein.

Daher habe ich mit dem Wordpress-Plugin Google Sitemaps eine neue Sitemap erzeugt, in der die Hauptseite schwächer gewichtet wird als die Artikelseite (Priority 0.8 gegenüber 1). Nach der Einreichung der neuen Sitemap über die Webmaster-Tools reagierte die Suchmaschine prompt und als angenehmer Nebeneffekt errang der Blogeintrag nun Position 1 unter den Suchergebnissen. Hierbei wird wohl das Vorkommen der Suchphrase im Titel der Seite eine Rolle gespielt haben.

Gleichzeitig hat Google aber auch einen Link zum Kommentarfeed aufgelistet. Als erste Gegenmassnahme bekamen alle Links zu Kommentarfeeds ein rel="nofollow" verpasst. Leider brachte diese Massnahme überhaupt nichts, die Feeds wurden weiterhin indiziert. Daher bestand nun der nächste Schritt darin, Suchmaschinen per robots.txt von den Kommentarfeeds fernzuhalten. Aufgrund der Struktur meiner Permalinks lautet der entsprechende Eintrag für mein Blog: User-agent: * Disallow: /*/*/*/*/feed/ Hierauf reagierte schliesslich auch der grosse Bruder aus Mountain View und ersetzte den Feed in den Suchergebnissen durch einen Verweis auf die Hauptseite des Blogs.

Linktechnisch war ich nun zufrieden, aber irgendwie störten mich noch die nichtssagenden Beschreibungen, die von Google zur Erläuterung der Treffer verwendet wurden. Abhilfe schafft hoffentlich das Plugin wpSEO, welches für jeden Wordpress-Artikel dynamisch eine eigene Description-Metaangabe generieren kann. Da der Gammelfleisch-Artikel durch den Googlebot noch nicht wieder eingelesen wurde, hat sich diese Änderung aber noch nicht auf die Suchergebnisse durchgeschlagen.

Als Ergebnis meiner Spielereien mit Google hier die Einstiegstipps zur Suchmaschinenoptimierung:

1. Eine Sitemap erstellen, bei der die Artikel stärker gewichtet werden als die Hauptseite. (Google-Sitemaps-Plugin)
2. Die Kommentarfeeds per robots.txt von der Indizierung ausschliessen. (SelfHTML)
3. Gegebenenfalls dynamisch passende Description-Metatags erstellen lassen. (wpSEO-Plugin)

Mittlerweile hat übrigens eine schnöde Agenturmeldung bei einigen Google-Datacentern meinen Blogeintrag bereits wieder vom Spitzenplatz verdrängt. Sic transit gloria mundi.

Undersökningen kan också avliva en del myter om den svenska bloggvärlden.

Syftet är att sprida kunskap och nyfikenhet om bloggvärlden till folk som vanligtvis inte läser bloggar.

Das bekomme ich momentan zu lesen, wenn ein Server seine Besucher anhand der IP-Adresse erkennt und automatisch auf eine Seite in der vermeintlich passenden Sprache umleitet. Nur scheint es für ihn nicht so einfach zu sein, zwischen Schweden und Schweiz zu unterscheiden.

Dieses Phänomen kann ich leider immer wieder mal beobachten, mein DSL-Provider scheint eine Vorliebe für „schwedische” IP-Adressen zu haben. Wenn die serverseitige Weiterleitung – wie in diesem Fall – auch noch auf eine Seite führt, die keine Auswahl der Sprache zulässt, steht man ganz schon im Regen.

Sowas könnte ich echt hassen â€¦

Smørrebrød ist übrigens Dänisch und nicht Schwedisch, aber es passte so schön und auf eine falsche Sprache mehr oder weniger kommt es bei dem Thema auch nicht mehr an. Römpömpömpöm.