Üblicherweise muss das Layout für den Ausdruck in folgenden Bereichen angepasst werden:

• Schriftgrösse: Wenn für die Ausgabe am Bildschirm nicht die logische Masseinheit em verwendet wird, sollte die Schriftgrösse für den Ausdruck auf em geändert werden, da in px deklarierte Schriftgrössen meist zu klein wirken.
• Unnötige Elemente: Manche Elemente wie Menüs, Werbung oder Formulare sind am Ausdruck sinnlos, daher können sie für den Druck versteckt werden.
• Farben: Manche Farben, insbesondere Schriftfarben wirken am Ausdruck schlecht und sollten daher angepasst werden.
• Ränder: Für den Bildschirm deklarierte Element-Ränder können manchmal nicht zum Druck-Layout passen und müssen gegebenenfalls angepasst werden.

Was genau am Layout für den Druck geändert werden muss hängt von der Website ab.

Eine Möglichkeit ist, für den Ausdruck eine eigene HTML-Seite zu genierieren. Dies kann jedoch - abhängig von der verwendeten Technik - relativ aufwändig und wartungsintensiv sein. Eine einfache und schnelle Möglichkeit das Layout für den Druck anzupassen ist die Verwendung von medien-spezifischen Stylesheets.

Um ein gelinktes Stylesheet ausschliesslich für ein bestimmtes Ausgabegerät zu verwenden, steht beim link-tag das Attribut media zur Vefügung (media-attribut referenz auf w3.org). Einer der vordefinierten Augabe-Typen ist print. Die Datei - in unserem Fall ein Stylesheet wird also nur verwendet, wenn es sich um eine Ausgabe auf einen Drucker handelt. Auch auf WEBKONTEXT.net ist das so gelöst:

<link rel="stylesheet" href="fileadmin/templates/css/webkontext_print.css" type="text/css" media="print" />

Dieses Styles-File beinhaltet aussschliesslich Klassen-Deklarationen, die sich von der am Bildschirm verwendeten Deklaration unterscheiden und überschreiben die allgemein gültigen Klassendeklarationen, welche im CSS-File webkontext.css deklariert sind:

<link rel="stylesheet" href="fileadmin/templates/css/webkontext.css" type="text/css" />
<link rel="stylesheet" href="fileadmin/templates/css/webkontext_print.css" type="text/css" media="print" />

Das CSS-File für den Ausdruck kommt zusätzlich zum normalen Stylesheet zur Anwendung, beinhaltet also ausschliesslich Deklarationen die sich von der Bildschirmausgabe unterscheiden

Bei der Anzeige am Bildschirm kommt also nur das CSS-File webkontext.css zur Anwendung, beim Ausdruck zusätzlich das File webkontext_print.css. Da das File webkontext_print.css nach dem allgemein gültigem Stylesheet gelinkt wird, haben die darin enthaltenen Deklarationen höhere Priorität als die Deklarationen des allgemeinen Stylesheets, überschreiben sie also.

Im Fall von WEBKONTEXT.net sind die div-Elemente #menubar, #ldboard, #leftcol und #rightcol am Ausdruck sinnlos und sollen versteckt werden. Da wird mit display: none; erreicht.  Ausserdem  wird die Schriftfarbe für Links  für das Druck-Layout  verändert, da auf  SW-Druckern Orange nur mehr ein blasses Grau ist.

Damit sieht das Stylsheet für Drucker hier so aus:

body, 
h1, h2, h3, h4, h5, h6,
a, a:link, a:hover, a:visited, a:active
{
	color: #000000;
}

#mainbody
{
	/*
	Fuer die Bildschirmanzeige wurde rundherum ein Rahmen definiert
	Den brauchen  wir beim Ausdruck nicht
	*/
	margin: 0px;
	padding: 0px;
	border: none;
}

#titlebar
{
	/* Keine Einrueckung des Logos am Ausdruck */
	margin-left: 0px; 
	padding-left: 0px;
}

#titlebar a img
{
	/* Keine Einrueckung des Logos am Ausdruck */
	margin-left: 0px; 
	padding-left: 0px;
}

#ldboard
{
	display: none;
}

#menubar
{
	display: none;
}

#leftcol
{
	display: none;
}

#rightcol
{
	display: none;
}

#content {
	/* 
	es gibt keine linken und rechten spalten mehr 
	fuer die platz reserviert werden muss 
	*/
	margin-left: 0px;  
	margin-right: 0px;
}

.tx-veguestbook-pi1 form
{
	display: none;
}

p.codeblock, pre.codeblock
{
	font-size: 80%;
}

Das Stylesheet, welches das Layout für den Druck bestimmt beinhaltet also nur wenige Deklarationen.

Die Schriftfarbe für Links und Überschriften wird auf Schwarz geändert.

Dann werden die Ränder der Elemente mainbody, titlebar und titlebar a img angepasst.

Der am Ausdruck verwendete Seitenrand kann nicht browser-unabhängig vom CSS beinflusst werden. Der Seitenrand ist also browser- bzw. Benutzerabhängig. Daher sollten bei en eigentlichen Content-Elementen Ränder vermieden werde um Platz zu sparen.

Dies geschieht hier indem beim alles-umgebenden Element #mainbody die Ränder und Rahmen auf Null gesetzt werden.

Weiters wird das Layout beeinflusst, indem beim Ausdruck unnötige Elemente mit display: none; versteckt werden.

Das Element #content wird weiter verwendet, allerdings werden die margins, welche am Bildschirm Platz für die linke und rechte Spalte reservieren angpeasst (die gibts ja am Ausdruck nicht).

Typo3 speichert intern jede Änderung mit. Das heisst, auch alte Versionen eines Datensatzes (Seite, News-Record, ...) bleiben erhalten und gehen beim Änderun und Speichern nicht verloren.

In Typo3 werden alle Änderungen eines Datensatzes in der Record-History, also der Änderungs-Geschichte gespeichert. Die Record-History ist eine Art Logbuch in der alle Änderungen eines Datensatzes ersichtlich sind.

Rücksetzen auf die vorherige Version

Die einfachste Möglichkeit auf die vorherige Version eines Datensatzes zuzugreifen bietet der Button  Zurücksetzen-Button im Record. Dazu muss der Datensatz, der zurückgesetzt werden soll geöffnet. Bewegt man den Mouse-Cursor über den Zurücksetzen-Button erscheint ein Hint wie alt die letzte Version ist welche bei Betätigung des Buttons wieder herangezogen wird. Durch mehrfaches Betätigen des Buttons kann schrittweise zurückgegangen werden. Typo3 bietet also eine Undo-Funktion auch ohne manueller Versionierung.

Die Änderungs-Geschichte

Auf die Record-History lässt sich auch direkt zugreifen. Dafür ist es notendig in die Listenansicht Web>Liste zu wechseln.  Im Baum wird dann das übergeordnete Element ausgewählt. In der Listenansicht rechts erscheint dann die Liste aller enthaltenen Elemente. Für jede Art von Datensatz wird eine History geführt. Es ist also möglich auch die Änderungen eines einzelnen Content-Elements einer Seite zu betrachten und gegebenenfalls auf eine frühere Version zurückzugreifen.

Wird in der List-View der Button Änderungsverlauf anzeigen angeklickt, erscheint die Liste der Änderungen des Datensatzes.

Die Liste beinhaltet auch die Details der Änderungen. Hinzugefügte Passagen werden in grün dargestellt, gelöschte in Rot. Bei jeder Version in der Record-History erscheint ein Button der den Datensatz auf die jeweilige Version zurücksetzt.

Wenn es weltweit einen Usability-Guru gibt, dann ist das Jakob Nielsen. Tausende von Lesern in aller Welt erwarten jeweils mit Spannung seine auf http://www.useit.com erscheinenden Kolumnen. Seit dem 22. Februar 2002, seit über 5 Jahren, wird Jakob Nielsens "Alertbox" vom Institut für Software-Ergonomie und Usability in Zürich ins Deutsche übersetzt - ein kostenfreier, sehr rege genutzter Service, der Nielsens wertvolle Tipps und Anregungen den Lesern im deutschsprachigen Raum leichter zugänglich macht. http://www.usability.ch/Alertbox/main.htm

Um 25% schneller Navigieren

So erlaubt die richtige und fixe Positionierung von Elementen für geübte Surfer ein um 25% schnelleres Navigieren. Auch das Leseverhalten ist unterschiedlich zwischen Papier und Monitor: Immerhin mehr als Dreiviertel der Internetuser liest die Texte auf Websites nicht, sondern "scannt" sie nur.

Neben Gestaltung der Website ist die Sprache von entscheidender Bedeutung. "Sprechen Sie die Sprache der Benutzer" ist seit �ber 20 Jahren eine der wichtigsten Usability-Richtlinien. Das gilt besonders bei der Optimierung für Suchmaschinen: Der beste Weg zu einem guten Ranking ist, jene Schlüsselwörter zu schreiben, die auch den Suchanfragen der Benutzer entsprechen.

Mit zwei Zeilen im TSConfig des Benutzers lassen sich sich die Funktionen Seiten-Cache löschen und FE-Cache löschen auch für normale Benutzer freigeben:

User TSConfig:
options.clearCache.pages = 1
options.clearCache.all = 1

Die Funktionen erscheinen aber nicht links im Hauptmenü des Typo3-Backends, sondern rechts oben im Menü der jeweiligen Seite.

Diese Einstellung bietet normalen Benutzern die Möglichkeit den Cache zu löschen, wirklich benutzerfreundlich ist das aber noch nicht, da die Löschung des Caches noch immer manuell vorgnommen werden muss.

Cache seitenabhängig automatisch löschen

Eine elegantere Möglichkeit Caches zu löschen bieten einige Optionen im Page-TSConfig. Diese Einstellungen ermöglichen es bei Änderungen in einer Seite oder eines Folders automatisch den Cache anderer Seiten zu löschen. Die Option bietet die Möglichkeit zur Angabe von einzelnen PIDs (PIDs sind die ID-Nummern der Seiten. Die PIDs erscheinen wenn man im Page-Tree mit der Maus über die Seiten-Symbole fährt), all für alle Caches und pages für Seiten-Caches.

Auch bei dieser Konfiguration muss options.clearCache.all = 1, wie im vorherigen Kapitel beschrieben gesetzt werden, da sonst auch die automatische Cache-Löschung inaktiv ist. (Siehe http://bugs.typo3.org/view.php?id=4543)

Wird im TSConfig der root-Seite

Page-TSConfig:# Caches aller Seiten bei Änderungen automatisch verwerfen
TCEMAIN.clearCacheCmd = all

in das Page-TSConfig eingetragen bewirkt das, dass immer alle Caches gelöscht werden, sobald auf einer Seite eine Änderung vorgenommen wird. Der Griff zu FE-Cache löschen wird damit unnötig.

Diese Einstellung hat aber nach wie vor den Nachteil, dass alle Caches gelöscht werden, und dadurch bei grossen Sites die Performance sinken kann.

Typo3 bietet auch die Möglichkeit zu löschende Caches genauer zu spezifizieren. Bei der Verwendung beispielsweise von tt_news kann es z.B. sinnvoll sein beim Erstellen einer neuen News nur die Caches jener Seiten zu löschen, die auf die News referenzieren, also z.B. die News-Übersicht.

Für diesen Zweck bietet Typo3 mit der Option TCEMAIN.clearCacheCmd die Möglichkeit zur Anführung einer PID-Liste.

Beispiel:

Die tt_news-Records befinden sich im Sysfolder "News", eine News-Übersicht auf der Home-Seite mit der PID 1 und auf einer Unterseite mit der PID 23. Mit folgendem Eintrag in der Page-TSConfig des Sysfolders "News" wird der Cache der abhängigen Seiten bei Änderung oder Erstellung eines News-Records automatisch gelöscht:

Page-TSConfig der Seite mit den News-Records:# Caches von Seite 1 und 23 bei Eingabe von News automatisch löschen
TCEMAIN.clearCacheCmd = 1,23

Weitere Optionen

Typo3 bietet im Page-TSConfog noch weitere für das Löschen des Caches.

TCEMAIN.clearCache_pageSiblingChildren = 1 bietet die Möglichkeit die Unterseiten aller "Geschwisterseiten" (also die Caches aller Seiten auf gleicher Ebene sowie deren Unterseiten) automatisch löschen zu lassen. Standardmässig, also wenn TCEMAIN.clearCache_pageSiblingChildren = 0 ist, werden nur die Caches der Geschwisterseiten automatisch gelöscht.

TCEMAIN.clearCache_pageGrandParent = 1 löscht den Cache der "Grosseltern-Seite", also der über der übergeordneten Seite bei Änderungen der Seite automatisch.

Wenn TCEMAIN.clearCache_disable = 1 im Page-TSConfig eingetragen ist werden bei Änderungen in dieser Seite oder deren Unterseiten keine Caches automatisch gelöscht. Wird diese Option verwendet muss der Redakteur also immer manuell den Cache löschen

Fazit

Das manuelle Cache löschen wird schnell zur Gewohnheit, ist allerdings nicht sehr benutzerfreundlich, insbesondere da die Funktion bei normalen Usern recht gut versteckt ist. TCEMAIN.clearCacheCmd = all in der Page-TSConfig der obersten Seite ist die einfachste Alternative, insbesondere wenn die Typo3-Site nicht allzu gross ist und nicht allzuviele Änderungen vorgenommen werden. Bei grossen Sites und Sites mit sehr vielen Besuchern kann das dauernde Löschen aller Caches - selbst wenn nur bei der kleinsten Änderung vorgenommen wurde - auch Performance-Probleme hervorrufen. Da empfiehlt es sich dann mit TCEMAIN.clearCacheCmd unter Angabe von abhängigen Seiten-IDs die Einstellung etwas feiner vorzunehmen um nur jene Caches automatisch zu löschen, die wirklich nicht mehr gültig sein sollen.

Ich habe hier eine (sicher nicht vollständige Liste) von Webkatalogen zusammengestellt.

Zumeist sind es komplett freie Webkataloge, die für eine Standard-Eintragung weder Geld noch Backlinks verlangen.

Kataloge leben auch von den Backlinks zurück auf den Webkatalog. Das ist nur fair, und Webmaster sollten meiner Ansicht nach - insbesondere wenn sie schon eine Links bzw. Parner-Page führen einen Link auf die Kataloge setzen in welchen sie gelistet sind. Aber die Forderung mancher Kataloge den Backlink auf der Startseite zu etzen ist dumme SEO-Abzocke. Daher sind Kataloge die solche Forderungen stellen nicht in dieser Liste.

Wer noch andere gute Webkataloge kennt, bitte einfach ein Kommentar posten. Aber bitte ausschliesslich Webkataloge, die keinen Backlink auf der Startseite bzw. unterseite mit mindest-PR verlangen.

Anfangs war Suchmaschinenoptimierung (engl. SEO, Search Engine Optmization)  - bzw. in diesem Zusammenhang eher Suchmaschinenspam genannt - relativ einfach: Der Website-Betreiber der Website konnte die Seite mit irgendwelchen Schlüsselwörtern füllen (um so häufiger um so besser), dazu vielleicht noch irgendwelche nicht passenden Schlüsselwörter um ja möglichst viele Leute herzu locken, und fertig war die Suchmaschine

Diese Zeiten sind Gott sei dank vorbei. Suchmaschinen-Spam führt nicht mehr zum gewünschten Erfolg. Suchmaschinen reihen mit Keywords überfüllte Seiten mittlerweile schlechter bzw. schliessen sie aus der Suchmaschine aus.

Anleitung zum SEO-Misserfolg

Um einen möglichst garantieren Misserfolg zu landen, müssen eigentlich nur ein paar Punkte eingehalten werden:

• Versuchen Sie die Seite so inhaltslos wie möglich zu machen, um sicherzustellen, dass niemand die Seite freiwillig verlinkt.
• Vermeiden Sie die Verwendung von Schlüsselworten im Text der Seite nach welchen jemand suchen könnte.
• Überfüllen Sie die Seite mit Schlüsselworten und verstecken sie diese mit irgendwelchen obskuren HTML-Tricks.
• Kopieren sie Texte von anderen Seiten, damit Suchmaschinen die Seite möglichst schnell als Duplikat erkennen.
• Beifüllen sie die den keyword-meta-tag im header mit möglichst vielen Keywords die möglicherweise nicht mal im Text vorkommen.
• Gaukeln sie der Suchmaschine andere Inhalte vor als dem Benutzer. Mit etwas Glück erkennt die Suchmaschine das und kickt die Seite aus dem Index.
• Verwenden sie Flash damit Suchmaschinen keinen Inhalt finden.

Bei Einhaltung dieser Regeln ist ein Misserfolg ziemlich sicher.

Erfolgversprechendere Optimierung

Vorweg genommen: Niemand kann eine Platzierung zu allen möglichen Suchbegriffen unter den Top 10 garantieren. Schon gar nicht dauerhaft und bei heiss umkämpften Begriffen.

Zusammengefasst stellt sich erfolgversprechende Suchmaschinenoptimierung folgendermassen dar:

• Achten Sie darauf, dass die Seite guten, eigenen Content bietet, also umfangreichen guten Text die keine Duplikate von anderen Websites sind.
• Achten sie im Text auf gute Schlüsselwort-Auswahl. Die relevanten Suchbegriffe müssen im Text ein paar mal vorkommen, allerdings nicht zu häufig.
• Vermeiden Sie Frames, Flash und JavaScript soweit wie möglich, da derartige Layouts suchmaschinenfeindlich sind.
• Textelemente sollten nie als Bild dargestellt werden, da Suchmaschinen dies nicht als Text interpretieren. Soweit Bilder eingebunden werden sollten diese mittels Alt-Tag mit einer Beschreibung versehen werden.
• Schauen sie, dass sie gute Links auf ihre Seite bekommen.
• Achten sie auf Formulierungen im Text

Manch Web-Designer bekommt bei derartigen Einschränkungen möglicherweise Kopfschmerzen. Allerdings sollte dabei nicht vergessen werden, dass suchmaschinen-freundliches Webdesign meistens automatisch die Barriere-Freiheit erhöht. Text-To-Speech-Reader und Computer-Braille-Zeilen für Sehbehinderte können mit Grafiken, Flash und dergleichen genauso wenig anfangen wie Suchmaschinen. Wer bei Websites Text-Orientiert gestaltet und entsprechende Auszeichnungs-Tags verwendet erhöht also auch den direkten Nutzen für Menschen.

Schlüsselworte

Ein wesentlicher Aspekt ist die Wahl der relevanten Schlüsselworte. Es ist dabei häufig sinnlos, sich auf nur ein bestimmtes Einzel-Schlüsselwort zu konzentrieren, insbesondere wenn es heiss umkämpft ist. Die Suche nach dem Schlüsselwort Restaurant oder Hotel liefert hundert-tausende Einträge. Sich hier auf in die Top-10 Schaukämpfen ist nahezu unmöglich, und meistens auch nicht sinnvoll, da der Benutzer mit grösster Wahrscheinlichkeit ein Restaurant in einer bestimmten Stadt sucht.

Angenommen Sie betreiben ein Restaurant in der Stadt Baden (bei Wien). Eine Suche nach

Restaurant Baden

schränkt die die Ergebnisse bereits auf etwas mehr als eine Million Einträge ein. Gute Ergebnisse zu erzielen bei einer Million Einträge ist schon etwas leichter als bei einer 300 Millionen, wenn auch noch immer sehr schwer und unter Umständen nicht notwendig. Auch dem Suchenden werden 1 Million Einträge etwas zu viel sein, und er wird daher weiter einschränken.

Im Falle de Beispiels ist das möglich, da einige Städte Baden heissen. Es gibt Baden bei Wien, Baden-Baden und noch einige mehr.

Der Suchende könnte also auf die Suchbegriffe

Restaurant Baden bei Wien

ausweichen, was das Suchergebnis weiter einschränkt. Möglicherweise sucht er aber auch nach der übergeordneten Region, in diesem Fall Niederösterreich:

Beispielsweise

Restaurant Baden Niederösterreich

was das Suchergebnis (derzeit) auf rund 200000 Seiten einschränkt.

Sucht er nach einem China-Restaurant könnt der vom Suchenden benutzte Suchbegriff

China-Restaurant Baden

sein, was "nur" rund 100000 Einträge liefert.

Diese Beispiele zeigen, dass es wichtig ist, auf mehr als einen Suchbegriff zu optimieren. Im Fall des fiktiven China-Restaurants wäre das

• China-Restaurant
• Baden bei Wien (anstatt nur Baden)
• Niederösterreich
• und der Name des Restaurants, beispielsweise HappyChinese

Diese Schlüsselworte sollten einige male im Text vorkommen, aber nicht zu oft. Eine dreimalige Verwendung bei einer Schlüsselwort-Dichte von 5 % kann schon gute Ergebnisse liefern.

Dabei sollte aber auf jeden Fall eine zu häufige Verwendung vermieden werden. Schlüsselwort-Dichten von über 10 % können schnell von den Suchmaschinen als Spamming interpretiert werden und können im schlimmsten Fall zum Ausschluss der Seite aus den Suchmaschinen führen.

Layout

Grafisch nett gestaltete Websites mögen vielleicht für den einen oder anderen Benutzer besonders interessant sein, für Suchmaschinen sind sie es nicht. Ein Wort, das durch eine Grafik dargestellt wird, wird von Suchmaschinen einfach nicht erkannt. In Flash oder JavaScript implementierte Seiten liefern für Suchmaschinen keinen relevanten Inhalt. Daher sollten Websites eher text-orientiert gestaltet werden und auf den umfangreichen, aussagekräftigen Content genauso viel - wenn nicht mehr - Wert gelegt werden als auf die grafische Gestaltung.

Ein absoluter Suchmaschinen-Killer sind Frames. Seiten die die Frames deklarieren beinhalten normalerweise keinen eigenen Content sondern binden nur weitere Seiten in einen Rahmenbereich ein. Da die eigentliche Content-Seite untergeordnet ist, wird sie auch von Suchmaschinen als weniger Relevant betrachtet. Weiters führt es zu dem Problem, dass die eigentlichen untergeordneten Seiten schlecht verlinkbar sind.

Domain- und Dateinamen

Worte in Domains und Dateinamen werden von manchen Suchmaschinen ebenfalls als relevant betrachtet. Es ist also durchaus sinnvoll, den Dateinamen entsprechend zu benennen. Also besser speisekarte.html als 213.html. Gleiches gilt für Domainnamen. "restaurant-happychinese.at" kann wenn es um Suchmaschinenoptimierung geht besser sein als nur happychinese.at. Allerdings gehen solche Domain-Namen auf kosten der Merkbarkeit. Daher ist es immer noch besser, den Domainnamen kurz und prägnant zu halten. Wenn allerdings der ursprünglich gewünschte Domain-Name nicht mehr verfügbar ist, macht die Integration eines zusätzlichen Schlüsselwortes im Domain-Namen in Hinsicht auf die Suchmaschinenoptimierung Sinn.

Meta-Tags im Header

Meta-Tags im Header haben eine wechselhafte Geschichte hinter sich. Anfangs wurden sie schnell durch sogenannte SEO-Spezialisten dazu missbraucht um alle möglichen Schlüsselworte in das Keywords-Meta-Tag des den Headers zu stopfen. Das hat dazu geführt, dass Suchmaschinen irrelevanten Seiten vorne listeten. Dies hat dann dazu geführt, dass Suchmaschinen diese Meta-Tags eine Zeit lang ignorierten. Mittlerweile sind Suchmaschinen etwas intelligenter geworden und trennen relevante Keywords im Header von Suchmaschinen-Spam. Dies wird unter Anderen dadurch erreicht indem überprüft wird, ob ein in der Keywords-Liste vorkommendes Schlüsselwort auch im Text vorkommt.

Lange Listen von Schlüsselworten sollten auf jeden Fall vermieden werden.

<META name="keywords" content="HappyChinese, China-Restaurant, Baden bei Wien, Niederösterreich, chinesische Küche">

ist auf jeden Fall erfolgversprechender als

<META name="keywords" content="HappyChinese, China-Restaurant, Baden bei Wien, Niederösterreich, chinesische Küche, Essen, Trinken, Fortgehen, Unterhaltung, China, Chop Suey, Bambussprossen, Peking-Ente, Suki-Jaki, Schweinefleisch süss-sauer, chinesische Suppe, süss-sauer">

Nicht nur, dass eine lang Liste von Keywords die Wertung des einzelnen Schlüsselwortes verringert besteht bei Überfüllung von Keywords auch das Risiko, dass Suchmaschinen die Seite als Spam werten und dann schlechter reihen oder ganz ausschliessen.

Ein weiteres von Suchmaschinen teilweise gut bewertetes Meta-Tag im HTML-Header ist das Description-Element.

Auch hier gilt, dass die Beschreibung nicht allzulang sein sollte (weniger als 120 Zeichen). Und wie der Name des Tags schon aussagt sollte es eine Beschreibung sein, keine Schlüsselwort-Auflistung.

Im Falle des beispielhaften Restaurants könnte das sein

<META name="description" content="Website des China-Restaurants HappyChinese in Baden bei Wien. Informationen über die Speisekarte, Anfahrtsweg und Öffnungszeiten">

Die Verwendung des Description-Tag bietet noch einen weiteren Vorteil: Einige Webkataloge übernehmen den Inhalt des Description-Tag als Beschreibung für die Seite, was einiges an manueller Tipparbeit ersparen kann. Das bedeutet aber auch, dass die Beschreibung menschenfreundlich sein soll - also keine sinnbefreite Liste von Keywords.

Hervorhebung mit Tags

Viele Suchmaschinen interpretieren in spezielle Tags eingeschlossene Schlüsselworte als wichtig. Dazu zählen beispielsweise das Header-Tag <h1>, oder die logische Auszeichnung mit <em> für emphasize, also "betonen" und <strong> für stark betonen. Auch die tags <b> für Fettschrift und <i> können einen ähnlichen Effekt haben.

Suchmaschinenoptimierung (italic) wird also möglicherweise wichtiger gewertet als nur Suchmaschinenoptimierung (normalschrift). Es kann also durchaus nützlich sein, wichtige Elemente mit Tags sowohl für den Besucher der Website als auch für die Suchmaschinen hervorzuheben.

Aber auch hier gilt: Nicht übertreiben. Es ist sinnlos alle in Fett zu stellen oder den gesamten Text als Überschrift zu markieren. Das hebt weder die Benutzerfreundlichkeit noch die Akzeptanz durch die Suchmaschinen und hebt die relevanz der der einzelnen Wörter gegenseitung aus. Hervorhebungen durch Fettschrift oder Italic sollte also nur für einzelne Wörter oder Absätze durchgeführtwerden, wenn diese auch für den Menschen wichtig sind.

Grafiken

Grafiken sind für Suchmaschinen im Prinzip wertlos. Grafiken sollten also sparsam verwendet werden. Falls Text-Elemente besonders gestalten werden sollen, ist es wesentlich besser dieses mittels CSS zu tun, als durch das Einbinden einer Grafik.

Offsite-Optimierung

Neben der Onsite-Optimierung stellt die Offsite-Optimierung einen wesentlichen Teil dar. Offsite-Optimierung ist Optimierung, die – wie die Bezeichnung schon sagt - nicht auf der Website selbst geschieht. Sie ist dadurch etwas schwerer zu bewerkstelligen.

Suchmaschinen vertreten die Ansicht, dass gut häufig verlinkte Seiten wichtiger sind als selten verlinkte Seiten. Das ist darauf zurückzuführen, dass wichtige Seiten oft gerne freiwillig verlinkt sind. Das freie Nachschlagewerk Wikipedia ist von der Internet-Community sehr oft verlinkt (mehrere Millionen Links zeigen auf sie), und wird daher auch von den Suchmaschinen als sehr wichtig interpretiert. Dies führt dazu, dass ein Themeneintrag in der Wikipedia oft in den Top 30 erscheint, egal wie viele Seiten es zu dem Thema im Internet gibt.

Gute Websites werden häufig freiwillig verlinkt. Dass man jemals so viele Links bekommt wie die Wikipedia ist freilich unwahrscheinlich. Trotzdem kann man auch selbst einiges tun um Links auf die eigene Seite zu bekommen:

Eine Möglichkeit stellt die Eintragung in Webkataloge dar. Yahoo und dmoz.org sind die Urväter der Webkataloge. Im Gegensatz zu Yahoo ist die Eintragung in dmoz.de jedoch kostenlos. Mittlerweile gibt es einige andere Webkataloge, wie beispielsweise www.retort.de, PSeek.net und Andere.

Besonders sinnvoll kann natürlich die Eintragung in regionale bzw. Themenkataloge sein. Ähnliches gilt für regionale Portale. Für das im obigen Beispiel angeführte China-Restaurant wäre beispielsweise eine Eintragung im Portal www.baden.at sinnvoll.

Es gibt Dienstleister die einen kostenlosen Eintrag in tausende Webkataloge und Suchmaschinen versprechen. Diese sind mit grösster Vorsicht zu geniessen. Erstens gibt es nicht so viele relevante Kataloge, zweitens unterscheidet sich die Struktur guter Kataloge was automatisierten Eintrag verhindert und drittens kann es passieren dass man auf so genannten Linklisten landet. Solche Linklisten wurden nicht für Menschen sondern nur zur Suchmaschinenoptimierung online gestellt. Das birgt die Gefahr, dass Suchmaschinen Links die sich auf solchen Linklisten befinden aus dem Index werfen, da offensichtlich versucht wurde den Suchmaschinen-Algorithmus zu betrügen.

Es ist also auf jeden Fall besser sich in einzelne gute Webkataloge manuell einzutragen, also auf sogenannte kostenlose Eintragungsdienste zu vertrauen. Es kann bei in Anspruchsnahme solcher Eintragungs-Dienste dazu führen, dass man nachher zwar mit SPAM zugemüllt wird, aber trotzdem nicht besser gelistet wird (im schlimmsten Fall kann es sogar zu einem Rauswurf führen).

Wichtig ist auch die der für den Link verwendete Text. Der Text im Link wird als Keyword der Zielseite gewertet, und trägt damit zur Schlüsselwort-Gewichtung bei.

So wurde George W. Bush's website von politischen Aktivisten sehr oft mit dem Anker-Text miserable failure verlinkt, was dazu führte, dass Bush's Website bei einer Suche nach miserable failure auf Platz 1 bei Google aufscheinte, obwohl diese Worte auf der Seite nicht vorkamen.

Diese Vorgangsweise wird Google-Bombing genannt. Google hat bald erkannt, dass der gezielte Einsatz von Links dazu verwendet werden um einer Seite Schlüsselworte zuzuweisen die nicht relevant sind (obwohl sich gerade in Bushs Fall ja genau darüber trefflich streiten liesse).

Der gezielte Einsatz von Anker-Texten ist nach wie vor sinnvoll, aber es solle vermieden werden immer nur mit dem haargenau dem gleichen Text zu verlinken, da Suchmaschinen dies als Spam werten könnten.

Der Google PageRank

Wie bereits im Abschnitt Offsite-Optimierung erwähnt, führen Links auf die Seite zu besseren Ergebnissen. Der Google-PageRank ist sozusagen ein Gradmesser dafür: Wenn eine gut verlinkte Seite (also eine Seite mit gutem Pagerank) auf  eine andere Seite zeigt, bekommt die Zielseite einiges des PageRank ab, da der  Link als wichtig gewertet wird.

In der Theorie sollte man also danach streben, links von Seiten mit hohem PR zu bekommen, da diese die eigene Seite aufwerten. Soviel zur Theorie. In der Praxis hat der in der Google Toolbar angezeigte Wert recht wenig Einfluss auf das tatsächliche Suchergebnis.  Die in der Toolbar angezeigten Werte werden nur von Zeit zu Zeit aktualisiert und spiegeln nicht den aktuellen Wert wieder.

Auch Seiten mit niedrigem PageRank werden oft gut gefunden. Der in der Google Toolbar angezeigte PR ist meistens nicht am letzten Stand und der PageRank an sich macht nur einen kleinen Teil der Bewertung aus. Es ist also ziemlich sinnlos verzweifelt Links von Seiten mit hohem PageRank nachzulaufen.

Menüs und Navigation

Auch für die Navigation innerhalb der Seite gilt das gleiche wie von aussen: Gut verlinkte Unterseiten werden höher bewertet - aber eben nur bei echten Links. Links über JavaScript werden von Suchmaschinen in der Regel nicht verfolgt und sind daher für die erfolgreiche Listung in Suchmaschinen schlecht.

Die Navigation innerhalb der Seite sollte also über Textlinks erfolgen. Menüs lassen sich mit unsortierten Listen (<ul>) gut strukturieren und per CSS benutzerfreundlich gestalten. Diese Strukturierung hilft auch, dass Hilfsprogramme für Sehbehinderte mit der Seite gut zurecht kommen.

Vermeiden Sie Dirty Tricks

Eine Zeit lang haben Webschaffende versucht Seiten mit Keywords voll zu stopfen und diese dazu noch vom Benutzer zu verbergen, beispielsweise indem für die Schrift die gleiche Farbe wie für den Hintergrund verwendet wurde. Das hat auch funktioniert. Aber die Betonung liegt auf hat. Suchmaschinen haben solche Seiten mit der Zeit bestraft und schlechter gelistet oder aus dem Index gekickt.

Einige Zeit hat Google Elemente die mit dem CSS-Attribut display: none bzw.  visibility: hidden versehen waren nicht im Index aufgenommen. Mittlerweile werden scheinbar jene Teile wieder indiziert, nur wie es in Zukunft aussieht ist nicht sicher. Suchmaschinen können schnell wieder auf die Idee kommen derartig versteckte Elemente entweder zu ignorieren oder zumindest geringer zu bewerten.

Auch "legitime" Verwendung von Techniken die die Inhalte verbergen können heikel sein. Es ist für Suchmaschinen schwer zu unterscheiden was zur Suchmaschinenoptimierung und was zur Gestaltung verwendet wurde. Es besteht also auch das Risiko, dass zu verspieltes Design "bestraft" wird.

Verspielte Layouts mit hidden Elementen die dann dynmaisch eingeblendet werden (beispielsweise in einer FAQ in der dann die Antwort dynamisch ausklappt indem die Antworten per Javascript wieder auf Visible gesetzt werden) bergen also das Risiko, dass sie in von Suchmaschinen (in diesem Fall irrtümlicherweise) als Suchmaschinenspam erkannt werden.

Suchmaschinen werden mit der Zeit intelligenter. Natürlich gibt es immer wieder Tricks die noch funktionieren. Kurzfristig können diese auch Erfolg haben. Langfristig bergen sie allerdings das Risiko eines Rauswurfs.

So hat BMW bis 2006 eine mit Keywords gespickte Doorway-Page betrieben, die der Suchmaschine Schlüsselworte vorgaukelte. 2006 wurde dann BMW aus dem Google-Index geschmissen und erst wieder aufgenommen als die Seite bereinigt war. Und es ist durchaus davon auszugehen, dass es kleinere Websites nach einem Rausschmiss schwerer haben wieder in den Index zu kommen als der Konzern BMW. Vorsicht ist also durchaus angesagt.

Fazit

Suchmaschinenoptimierung ist nicht Suchmaschinen-Spamming, sondern die Vermeidung von Gestaltungen und Strukturen, die Suchmaschinen bei ihrer Arbeit behindern. Suchmaschinen-Optimierung ist auch die gezielte Formulierung von Texten, sodass sie relevante Schlüsselworte beinhalten - es ist aber nicht das Vollstopfen mit unwichtigen Schlüsselworten.

IE7: Internet Optionen/Allgemein/Browser-Verlauf/Einstellungen

IE6: Internetoptionen/Allgemein/Temporäre Internet-Dateien/Einstellungen

Folgende Einstellungen müssen vorgenommen werden, damit IE mit dem htmlArea zurechtkommt:

Neuere Versionen der gespeicherten Seiten suchen: Automatisch

Zu verwendendernder Speicherplatz: mindstens 32 MB

Das XML eines RSS-Feeds beinhaltet keinerlei Informationen wie der Feed dargestellt werden soll, sondern nur strukturierte Daten.

Dementsprechend verwirrend kann es für einen Benutzer sein, wenn er sich irrtümlich auf einen RSS-Feed „verirrt“ keine Plugins zur Aufbereitung der Feeds installiert hat und auch sonst nicht mit RSS vertraut ist.

Ein unformatierter RSS2-Feed sieht im Browser ungefähr so aus:

Der Screenshot wurde auf Basis dieses Beispiel-Feeds erstellt. Wer keine Software für das Handling des Feeds installiert hat wird ein ähnliches Ergebnis bekommen wie im Screenshot. Für einen User also nicht gerade einladend. Natürlich kann man dem entgegenhalten, dass RSS-Feeds an sich dafür gedacht sind von Software gelesen und formatiert zu werden, nicht von Menschen. Aber nicht jeder User hat entsprechende Software installiert oder ist mit RSS vertraut.

Unformatierte RSS Feeds haben also folgende Nachteile:

• Nur schwer lesbar

• Keine Möglichkeit einen Link zu einem Artikel per Mouse-Klick zu öffnen

• Corporate Design wird unterbrochen und die Website sieht für einen nicht mit RSS vertrauten Besucher „fehlerhaft“ aus.

RSS-Feeds müssen aber nicht so aussehen. Ein Beispiel für einen formatierten und aufbereiteten Feed ist der RSS2-Feed von Typo3.org. Dies wird mit XSL Transformations (XSLT) erreicht. XSLT ist eine Programmiersprache zur Transformation von XML-Dokumenten. Es baut auf der logischen Sturktur eines XML-Dokumentes auf und erlaubt die Definition von Umwandlungs-Regeln.

Grundsätzlich hat ein RSS2-Feed folgende Struktur:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="beispiel-rss-2-html.xsl" media="screen" ?>
<rss version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Feed-Titel</title>
    <link>www.meine-seite.net</link>
    <description>Beschreibung des Feeds</description>
    <language>de</language>
    <image>
      <title>Feed-Titel</title>
      <url>http://www.meine-seite.net/mein-feed-icon.gif</url>
      <link>www.meine-seite.net</link>
      <width>254</width>
      <height>39</height>
      <description>Beschreibung des Feeds</description>
    </image>
    <lastBuildDate>Zeitpunkt des letzten Updates</lastBuildDate>
    <item>
      <title>Titel des Artikels</title>
      <link>Link zum Artikel</link>
      <description>Artikel-Teaser (Zusammenfassung)</description>
      <content:encoded>Artikel-Text</content:encoded>
      <category>Artikel-Keyword</category>
      <category>Artikel-Keyword</category>
      <author>Autor</author>
      <pubDate>Erstellungsdatum des Artikels</pubDate>
    </item>
  </channel>
</rss>

Eine Beschreibung der Elemente von RSS2-Feeds ist hier zu finden: http://www.rssboard.org/rss-specification.

Diese Struktur gilt es per XSLT so zu transformieren, dass aus dem XML leicht lesbares, formatiertes HTML wird.

Aus XML wird HTML

Mit XSLT ist es möglich Regeln zu definieren, die den XML-basierenden RSS-Feed mit HTML-Tags aufbereiten. Die meisten modernen Browser verfügen über einen integrierten XSLT-Prozessor. Die Beispiele in dem Artikel beziehen sich auf RSS2, können aber nach geringfügiger Anpassung für andere Feed-Strukturen verwendet werden.

Grundsätzlich passiert bei der Transformation folgendes:

1. Der Browser bekommt vom Server den RSS-Feed
2. Anhand der im Feed angeführten XSL-Datei wird der Feed transformiert (in diesem Fall mit HTML-Tags formatiert)
3. Der formatierte Feed wird im Browser lesbar dargestellt.

XSL-File in den RSS-Feed einbinden

Damit der Browser weiss, welche Transformations-Regeln er anwenden muss, muss das XSL-File in den RSS2-Feed eingebunden werden. Die zweite Zeile verweist auf die Datei mit den Transformations-Regeln:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="beispiel-rss-2-html.xsl" media="screen" ?>

Um dies in Typo3 zu erreichen ist es am einfachsten das tt_news template für die RSS-Feeds entsprechend anzupassen.

Mehr ist am RSS-Feed selbst nicht zu ändern. Alle Regeln für die Aufbereitung und Formatierung des Feeds stehen im XSL-File, das in diesem Beispiel beispiel-rss-2-html.xsl heisst.

Transformationsregeln im XSL-File

Mit XSLT sieht der Beispiel-RSS-Feed schon aufgeräumter auf:

Die Formatierung des Feeds wurde mit folgender Transformation erreicht (Erklärung weiter unten):

<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
>
	<xsl:template match="rss">
		<html>
			<!-- ===Template des HTML-Head-Parts=== -->
			<head>
				<title>
					<xsl:value-of select="/rss/channel/title"/>
				</title>
				<!-- ===Stylesheet einbinden. Gegebenenfalls muss absoluter Pfad verwendet werden === -->
				<link rel="stylesheet" href="rss-xsl-styles.css"/>
			</head>
			<!-- ===Template des HTML-body-Parts=== -->
			<body>
				<div class="full-feed">
					<!-- Hier werden die anderen Templates hinein genierert. Siehe weiter unten -->
					<xsl:apply-templates/>
				</div>
			</body>
		</html>
	</xsl:template>
	
	<!-- ===TEMPLATE FUER DAS CHANNEL-ELEMENT -->
	
	<xsl:template match="channel">
	<div id="header">
		<h1>
		<xsl:element name="a">
			<xsl:attribute name="href">
				<xsl:value-of select="link" />
			</xsl:attribute>
			<xsl:element name="img">
				<xsl:attribute name="src">
					<xsl:value-of select="image/url"/>
				</xsl:attribute>
				<xsl:attribute name="alt">
					<xsl:value-of select="title"/>
				</xsl:attribute>
			</xsl:element>
		</xsl:element>
		</h1>
		<p><strong>Dies ist ein per XSL in HTML transformierter Beispiel-RSS2-Feed. Die Beschreibung wie das geht finden sie <a href="http://www.webkontext.net/">hier</a>. Weitere Artikel von <a href="http://www.webkontext.net/">WEBKONTEXT.net hier</a></strong></p>
		<xsl:value-of select="description"/><br />
		Letzte &#196;nderung: <xsl:value-of select="substring(pubDate,5,18)"/><br />
	</div>
	
	<!-- ===TEMPLATE FUER DIE ITEM-ELEMENTE -->

	<xsl:apply-templates select="item"/>
	</xsl:template>
	<xsl:template match="item">
		<div class="feed-item">
			<h2>
			<xsl:element name="a">
				<xsl:attribute name="href">
					<xsl:value-of select="link" />

				</xsl:attribute>
				<xsl:value-of select="title" />
			</xsl:element>
			</h2>
			<p>
			<xsl:value-of select="description"/>
			<span class="morelink">
				&#160;
				<xsl:element name="a">
					<xsl:attribute name="href">
						<xsl:value-of select="link" />
					</xsl:attribute>[mehr...]
				</xsl:element>
			</span>
			</p>
			<xsl:if test="pubDate">
				<span class="itempubDate">Datum: <xsl:value-of select="substring(pubDate,5,18)"/></span>
			</xsl:if>

		</div>
	</xsl:template>
</xsl:stylesheet>

Das für die Formatierung des RSS-Feeds verwendete XSLT sieht auf den ersten Blick etwas kompliziert aus, allerdings brauchen wir für die Transformation des RSS-Feeds nur einige wenige Regeln. Eine vollständige Beschreibung von XSLT findet sich hier. Auch die Wikipedia bietet einen kurzen Überblick über die XSLT.

Im Wesentlichen brauchen wir für die Transformation von RSS nach HTML nur eine Hand voll Regeln im XSLT:

xsl:template: Das Template wird immer angewendet, wenn der Name eines Elements dem angegebenen entspricht: <xsl:template match="channel"> im XSLT bedeutet also, dass das eingeschlossene Element auf Elemente namens „Channel“ angewendet wird.

xsl:apply-templates: Wendet an dieser Stelle die Templates an. Das Attribut select spezifiziert, welche Elemente verarbeitet werden sollen: <xsl:apply-templates select="item"> bedeutet also, dass an dieser Stelle Item-Elemente eingefügt werden sollen.

xsl:value-of: Fügt an dieser Stelle den Wert des per Attribut select spezifizierten Elements ein. Beispielsweise fügt <xsl:value-of select="/rss/channel/title"/>.den Wert des Elements Title des Elements Channel ein. Da XML als Baum strukturiert ist, kann im select-Attribut der komplette Pfad zu einem Element angegeben werden.

xsl:element und xsl:attribute: Diese setzen bei der Transformation Tags zusammen. Vollständige Tags können auch direkt im XSLT angeführt werden, sobald jedoch Attribute des Tags anhand von Werten im XML gesetzt werden müssen, kommen diese Regeln zur Anwendung.

Diese Zeilen markieren das XML-File als XSLT:

<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
>

Da ein RSS2-Feed mit einem Element Namens RSS umschlossen ist, wird als erstes ein Template für dieses Element deklariert. Dies geschieht mit

	<xsl:template match="rss">
		<html>
			<!-- ===Template des HTML-Head-Parts=== -->
			<head>
				<title>
					<xsl:value-of select="/rss/channel/title"/>
				</title>
				<!-- ===Stylesheet einbinden. Gegebenenfalls muss absoluter Pfad verwendet werden === -->
				<link rel="stylesheet" href="rss-xsl-styles.css"/>
			</head>
			<!-- ===Template des HTML-body-Parts=== -->
			<body>
				<div class="full-feed">
					<!-- Hier werden die anderen Templates hinein genierert. Siehe weiter unten -->
					<xsl:apply-templates/>
				</div>
			</body>
		</html>
	</xsl:template>

Die innerhalb des Templates angeführten Elemente werden 1:1 ins generierte HTML übertragen, in diesem Fall also das Head und Body.

Das XSLT-Element <xsl:value-of select="/rss/channel/title"/> zwischen den HTML-Title-Tags übernimmt den Wert des RSS-Titels und fügt ihn als HTML-Title ein. Als nächstes wird das externe CSS-File eingebunden.

Im HTML-Body-Element wird ein div, also ein Container, mit der Klasse full-feed generiert. Das <xsl:apply-templates/> innerhalb des body-tags weist den XSLT-Prozessor an dort die Templates für den header und die Items des RSS-Feeds anzuwenden.

	<xsl:template match="channel">
	<div id="header">
		<h1>
		<xsl:element name="a">
			<xsl:attribute name="href">
				<xsl:value-of select="link" />
			</xsl:attribute>
			<xsl:element name="img">
				<xsl:attribute name="src">
					<xsl:value-of select="image/url"/>
				</xsl:attribute>
				<xsl:attribute name="alt">
					<xsl:value-of select="title"/>
				</xsl:attribute>
			</xsl:element>
		</xsl:element>
		</h1>
		<p><strong>Dies ist ein per XSL in HTML transformierter Beispiel-RSS2-Feed. Die Beschreibung wie das geht finden sie <a href="http://www.webkontext.net/">hier</a>. Weitere Artikel von <a href="http://www.webkontext.net/">WEBKONTEXT.net hier</a></strong></p>
		<xsl:value-of select="description"/><br />
		Letzte &#196;nderung: <xsl:value-of select="substring(pubDate,5,18)"/><br />
	</div>

Dieses Template transformiert den Header, (also Titel, Beschreibung, Logo usw.) des RSS-Feeds. Der Header wird mit einem div mit der Klasse header umschlossen. Der Kopfbereich wird so formatiert, dass in der Überschrift das Logo des Feeds erscheint. Wer dem RSS-Feed kein Icon zugewiesen hat, kann das Element zur Generierung der img-Tags einfach löschen und durch ein <xsl:value-of select="title"/> ersetzen.

Zum Schluss werden noch die einzelnen Artikel-Einträge formatiert. Diese befinden sich im RSS-Feed in Tags mit dem Namen <Item> eingeschlossen. Dafür ist folgender Bereich im XSL-File zuständig:

	<!-- ===TEMPLATE FUER DIE ITEM-ELEMENTE -->

	<xsl:apply-templates select="item"/>
	</xsl:template>
	<xsl:template match="item">
		<div class="feed-item">
			<h2>
			<xsl:element name="a">
				<xsl:attribute name="href">
					<xsl:value-of select="link" />

				</xsl:attribute>
				<xsl:value-of select="title" />
			</xsl:element>
			</h2>
			<p>
			<xsl:value-of select="description"/>
			<span class="morelink">
				&#160;
				<xsl:element name="a">
					<xsl:attribute name="href">
						<xsl:value-of select="link" />
					</xsl:attribute>[mehr...]
				</xsl:element>
			</span>
			</p>
			<xsl:if test="pubDate">
				<span class="itempubDate">Datum: <xsl:value-of select="substring(pubDate,5,18)"/></span>
			</xsl:if>

		</div>
	</xsl:template>

Jeder Artikel-Eintrag wird für die Ausgabe so formatiert, dass er von einem div mit der Klasse feed-Item umschlossen ist. Darin wird der Titel des Artikels als h2-Überschrift formatiert. Weiters wird der Teaser-Text (also die description des Artikel-Items ausgegeben und mit einem Link zum eigentlichen Artikel versehen. Das ist auch einer der wesentlichen Vorteile einer per XSLT-transformierten und HTML-Formatierten Ausgabe eines RSS-Feeds: Die URLs der Artikel werden als Link dargestellt und sind damit auch ohne RSS-Reader leicht öffenbar.

Weg mit class="bodytext"

Standardmässig weist Typo3 allen Absätzen die CSS-Klasse bodytext zu.  Das kann mit einer Zeile im Template-Setup leicht unterdrückt werden:

Template-Setup:# Ein P bleibt ein P und wird nicht zum P class="bodytext"
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.addAttributes.P.class >


Diese Zeile verhindert, dass bei Paragraph-Tags automatisch ein class=bodytext angehängt wird.

Im Editor angegebene Klasse bei Tabellen beibehalten

Standardmässig weist Typo3 einer Tabelle die Klasse contenttable zu, auch wenn im RTE der Tabelle eine andere Klasse zugewiesen wurde.

Mit folgenden Zeilen im Template-Setup lässt sich das verhindern:

Template-Setup:#
# Wenn einer Table im Editor eine Klasse zugewiesen wurde diese beibehalten
#

lib.parseFunc_RTE.externalBlocks.table.stdWrap.HTMLparser.tags.table.fixAttrib.class.list >


Keine P's in Tabellenzellen generieren

Per default generiert Typo3 p-Tags um den Inhalt von im RTE eingegebenen Tabellen-Zellen. Mit   lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default > im Template-Setup lässt sich verhindern, dass Typo3 Table-Zellen durch den Parser schickt und aufgrund der fehlenden Umschliessung mit P-Tags diese hinein generiert.

Da wirft allerdings das Problem auf, dass dann beispielsweie in einer Zelle eingegebene Links nicht mehr umgesetzt werden.

Dieses Problem lässt sich umgehen, indem man Typo3 anweist die Einstellungen von lib.ParseFunc zu übernehmen. Dadurch werden die Tags in Tabellen-Zellen geparst, ohne dass zuätzliche P-Tags generiert werden.

Template-Setup:# keine P in TD generieren aber trotzdem Inhalt parsen

lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default >
lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default.stdWrap.parseFunc =< lib.parseFunc 


Wie der französiche XiTi-Monitor berichtet, kommt der Firefox in Europa mittlerweile  (März 2007) auf einen Marktanteil von nahezu 24.1 %.

Einzelne Länder können jedoch einen wesentlich grösseren Anteil von Firefox-Usern aufweisen. Am häufigsten wird der Firefox in Slowenien und Finnland (mit jeweils über 40 % Anteil) benutzt.

Obwohl der Firefox im deutschsprachigen Raum (Deutschland, Österreich, Schweiz) nicht an die Spitzenwerte in Finnland herankommt zeigt die Studie doch, dass auch bei uns der Firefox äusserst beliebt ist:

Auf den Internet Explorer hin zu optimieren kann mittlerweile also fast ein Drittel der Besucher kosten.

In der Praxis überschneiden sich beide: Auch die meisten Tags zur logischen Textauszeichnung haben bestimmte Darstellungen zur Folge.

Ursprünglich war an die physikalische Textauszeichnung bei der Entwicklung von HTML kaum gedacht worden. Zum Zeitpunkt der Entwicklung waren Workstations noch hauptsächlich ASCII-Terminals die keine grafische Darstellung beherrschten. Daher war die physikalische Textauszeichnung mit Funktionen zur Wahl der Schrift, Farbe und dergleichen nebensächlich. Der Browser sollte anhand der Information um was es sich handelt selbst entscheiden wie er den Textteil darstellt. Das war für die damals hauptsächlich wissenschaftlichen Texte auch ausreichend.

Mit der Kommerzialisierung des Webs gewann aber die Gestaltung einer Website mehr und mehr Bedeutung über dessen Inhalt, und die wenigen zur Verfügung stehenden Tags wurden missbraucht um Seiten zu gestalten.

Ein Beispiel dafür ist das Tag <blockquote>, das laut HTML-Spezifikation ein Zitat markiert. Da aber die meisten Browser „Zitate“ eingerückt darstellten, wurde <blockquote> von Webdesignern bald missbraucht um Text einzurücken, auch wenn es sich nicht um ein Zitat handelte.

Seit der Einführung von CSS sind derartige Missbräuchliche Verwendungen von Tags nicht mehr notwendig, da sich die Gestaltung über Klassen bis ins Detail regeln lässt.

Trotzdem, oder gerade deswegen kommt der logischen Auszeichnung von Texten wieder mehr Bedeutung zu, insbesondere auch in Hinblick auf XHTML, welches die Gestaltung nur mehr über CSS erlaubt. Gute logische Auszeichnung bietet mehrere Vorteile:

• Sinnvolle Darstellung auf allen Ausgabegeräten, auch reinen Text-Browsern.
• Bessere Interpretation durch Screenreader: Logische Auszeichnung erleichtert die Verwendung von Hilfsmitteln für Sehbehinderte. Textpassagen werden entsprechend der Markierung betont
• Logische Textauszeichnung erleichtert die Übergabe von HTML-Texten, beispielsweise in Blogs, da auf der Website die den Artikel übernimmt die eigenen CSS-Definitionen unter Umständen nicht vorhanden sind bzw. ausgefiltert werden.
• Erleichterter Umstieg auf XHTML

Tag in einem eigenen CSS definieren

Wie die logisch markierten Bereiche dargestellt werden hängt vom Browser ab. In der Regel unterscheidet sich die Darstellung nicht wesentlich. Wer sichergehen will, dass der logisch ausgezeichnete Bereich so dargestellt wird wie gewünscht, kann da die Tags in einem eignenen CSS definieren:

Mit <strong> markierte Elemente werden von den meisten Browsern fett dargestellt. Wer möchte, dass diese Elemente fett und zusätzlich in rot dargestellt werden, kann dies beispielsweise mit folgender CSS-Definition tun

strong {
font-weight: bold;
color: #FF0000;
}

strong - Stark hervorzuhebender

Das Tag <strong> markiert stark hervorzuhebende Textteile.

Die meisten Browser stellen mit <strong> markierten Text standardmässig in Fettschrift dar.

Beispiel:

<strong>Stark hervorzuhebender Text</strong>

Ausgabe:

Stark hervorzuhebender Text

em: Betonen

Das Tag <em> steht für Emphasize, also „betonen“. Mit diesem Tag werden zu betonende Textelemente markiert.

Die meisten Browser stellen betonten mit <em> markierte Textteile in Kursivschrift dar.

Beispiel:

Es ist <em>sehr</em> wichtig, Text auch logisch zu strukturieren

Ausgabe:

Es ist sehr wichtig, Text auch logisch zu strukturieren

cite: Kurzes Zitat oder Referenz zu anderen Quellen

<cite> markiert Zitat aus anderen Quellen beziehungsweise eine Referenz auf andere Quellen. Damit sind Zitate oder Referenzen gemeint die im Lauftext eingebunden sind.

Mit <cite>cite</cite> markierte Teile werden von den meisten Browsern standardmässig in Kursivschrift dargestellt

Beispiel:

Eines der bekanntesten Zitate ist sicher <cite>Hamlet: Sein oder Nichtsein, das ist hier die Frage (To be, or not to be: that is the question)</cite>.

Ausgabe:

Eines der bekanntesten Zitate ist sicher <cite>Hamlet: Sein oder Nichtsein, das ist hier die Frage (To be, or not to be: that is the question)</cite>

blockquote: Längeres Zitat

Im Gegensatz zu <cite> markiert <blockquote> ein längeres Zitat, das in einem eigenen Abatz dargestellt wird.

Bei <blockquote> handelt es sich um ein Block-Element. Der Textblock wird von den meisten Browsern standardmässig eingerückt dargestellt.

Beispiel:

<blockquote> Werde ich recht behalten, werden die Deutschen sagen, ich sei Deutscher, die Franzosen, ich sei Europäer und die Amerikaner, ich sei Weltbürger. Werde ich nicht recht behalten, werden die Amerikaner sagen, ich sei Europäer, die Franzosen, ich sei Deutscher und die Deutschen, ich sei ein Jude.<br><br>- Albert Einstein, befragt über die möglichen Auswirkungen seiner Relativitätstheorie</blockquote>

Ausgabe:

Werde ich recht behalten, werden die Deutschen sagen, ich sei Deutscher, die Franzosen, ich sei Europäer und die Amerikaner, ich sei Weltbürger. Werde ich nicht recht behalten, werden die Amerikaner sagen, ich sei Europäer, die Franzosen, ich sei Deutscher und die Deutschen, ich sei ein Jude.

- Albert Einstein, befragt über die möglichen Auswirkungen seiner Relativitätstheorie

dfn: Definition

Mit <dfn> kann ein definiertes wort markiert werden. Dies wird meistens bei der ersten Verwendung im Text gemacht:

Beispiel:

<dfn>HTML</dfn> steht für Hypertext Markup Language und <dfn>CSS</dfn>für Cascaded Style Sheets.

Ausgabe:

HTML steht für Hypertext Markup Language und CSS für Cascaded Style Sheets.

kbd: Tastatureingabe

Mit <kbd> können – beispielsweise in einem Benutzerhandbuch – vom User vorzunehmende Eingaben markiert werden.

Die meisten Browser stellen in kbd eingeschlossenen Texte in nicht-proportionaler Schrift dar

Beispiel:

Geben sie bitte <kbd>cd /</kbd> ein um ins Hauptverzeichnis zu wechseln.

Ausgabe:

Geben sie bitte <kbd>cd /</kbd> ein um ins Hauptverzeichnis zu wechseln.

samp: Beispiel

Das Tag <samp> markiert ein Beispiel. In Tutorials können damit Beispiele markiert werden, und hat damit eine ähnliche Funktion wie das Tag <code>.

Beispiel:

<samp><dfn>HTML</dfn> steht für Hypertext Markup Language und <dfn>CSS</dfn>für Cascaded Style Sheets.</samp>

Ausgabe:

<dfn>HTML</dfn> steht für Hypertext Markup Language und <dfn>CSS</dfn>für Cascaded Style Sheets.

code: Computer-Code

Das Tag <code> markiert Computer-Code, also Ausschnitte aus Programmen, HTML-Quelltext oder ähnliches.

Beispiel:

Ausgabe von „Hallo Welt“ in einer Schleife in Pascal: <code>for x := 1 to 10 do writeln ('Hallo Welt');</code>

Ausgabe:

Ausgabe von „Hallo Welt“ in einer Schleife in Pascal: for x := 1 to 10 do writeln ('Hallo Welt');

address: Adresse

Mit <address> kann eine Adresse markiert werden:

Beispiel:

<address>
Helicon Software Development<br>
Trimplinggasse 6<br>
A-2500 Baden
</address>

Ausgabe:

abbr: Abkürzung

Mit <abbr> önnen im Quelltext Abkürzungen markiert werden und unter Verwendung des title-Attributs eine Erklärung eingeblendet werden.

Beispiel:

In <abbr title="Hypertext Markup Language">HTML</abbr> kann das Tag <strong> verwendet werden um Textteile besonders hervorzuheben.

Ausgabe:

In HTML kann das Tag <strong> verwendet werden um Textteile besonders hervorzuheben.

Ins/Del: Gelöscht und hinzugefügt

Mit <del> lassen sich Textteile als gelöscht, und mit <ins> als hinzugefügt markieren. Damit können Änderungsvorgänge dargestellt werden.

Beim Tag <ins> kann optional durch Angabe des Attributs dattime noch zusätzlich der Zeitpunkt der Änderung angegeben werden. Dabei muss das Format yyyy-mm-dd verwendet werden. Ebenso optional ist die Verwendung des Attributs cite welches ermöglicht auf ein HTML-Dokument zu verweisen da nähere Angaben macht.

Die meisten Browser stellen gelöschte, also in <del> eingeschlossene Textteile durchgestrichen, mit <ins> hinzugefügte unterstrichen dar.

Beispiel:

Das Projekt ist im <del>Juni</del><ins datetime=“2007-03-17“>Juli</ins> abgeschlossen.

Ausgabe:

Das Projekt ist im JuniJuli abgeschlossen.

Der von manchen Webmastern gerne betriebene Gästebuch- und Foren-Spam stellt meist keine (positive) Mundpropaganda dar, sondern wird als lästig empfunden. Einträge wie "Super Artikel, schau doch mal www.meineseite.com an" diskreditiert die Zielseite eher, als sie ihr hilft.

Um in den Genuss von Mundpropaganda zu kommen, muss natürlich der Inhalt der Website stimmen. Nichtssagende Werbeseiten ohne nennenswerten Inhalt werden kaum freiwillig verlinkt werden. Aber selbst wenn die Seite gut ist, kann es am Anfang notwendig sein, klassische Internet-Werbung zu betreiben, insbesondere wenn es sich um ein heiss umkämpftes Themenfeld handelt und auch die Suchmaschinen nicht weiterhelfen um gefunden zu werden.

Kontext

User besuchen Websites um sich zu einem bestimmten Thema zu informieren bzw. die dortigen Angebote wahrzunehmen. Daher ist kontext-bezogene Werbung wesentlich sinnvoller, als Werbung, die in keinem Zusammenhang steht mit dem eigentlich erwünschten Thema.

Werbung für Gartenmöbel wird beispielsweise auf einer Website zum Thema Mathematik kaum den erwünschten Erfolg, selbst wenn die Website sehr gut besucht ist. Sie wird von den Benutzern eher als störend empfunden werden und bestenfalls keinen, schlimmstenfalls einen negativen Effekt erzeugen. Die gleiche Gartenmöbel-Werbung bei gleicher Positionierung auf einer Webpage über Gartengestaltung kann jedoch gut funktionieren, da sie unter Umständen vom Benutzer sogar als hilfreich empfunden wird.

Banner

Banner, Textlinks und Popups stellen dabei die bekanntesten Werbeformen dar. Allerdings beinhalten diese auch einige Fallstricke.

Banner-Werbung war anfangs sehr effektiv. Hauptgrund: Sie war neu, Banner waren unbekannt und die Leute klickten, weil sie wissen wollten was sich hinter dem Banner verbirgt. Der Erfolg der Banner hatte aber auch zur Folge, das immer mehr Seiten mit Banner übersäht waren.

Das führte zu der bereits 1998 in einer Studien beschriebenen Banner-Blindheit (http://www.internettg.org/newsletter/dec98/banner_blindness.html). Der Versuchsaufbau war denkbar simpel: Es wurde ein banner-artiges Gebilde gezeigt und ein Stück darunter ein kleiner im Text eingebetteten Text-Link. Die meisten Benutzer folgten nicht dem Banner, sondern dem wesentlich kleineren Link. Es ist nicht davon auszugehen, dass die Benutzer den Banner wirklich übersahen, sondern ihn eher ignorierten, weil er als Werbung empfunden wurde.

Wenn die Banner aber nicht gänzlich übersehen, sondern nur ignoriert und damit zumindest unbewusst aufgenommen werden, können Banner zumindest zur Bekanntheit einer Marke bzw. Angebots, beitragen auch wenn sie nicht unbedingt zu einem click-through führen.

Dabei ist aber auch wichtig zu beachten, dass Banner auf Seiten nicht störend platziert werden. Das Persuasive Technology Lab der Stanford University hat 2001 versucht in einer Studie  festzustellen, was eine Website vertrauenswürdig erscheinen lässt. Die Autoren kamen zu dem Schluss, dass aggressive Werbung auf Seiten zu Vertrauensverlust der Benutzer führen kann, gut gemachte Banner-Werbung aber auch das Vertrauen erhöhen kann.

Viele grosse Medien-Seiten sind auf Werbung angewiesen und finanzieren sich daraus. Allerdings sind die Seiten meistens so gestaltet, dass die Werbung für den Benutzer nicht extrem störend wirkt. Banner sind meistens dezent auf der Seite platziert und stören damit nicht den Lesefluss. Dadurch unterscheiden sie sich massgeblich von den blinkenden Banner-Seiten die vielfach zum Ärger der Benutzer über Banner beitragen. Eine Studie  von MOIRA BURKE (Carnegie Mellon University), ANTHONY HORNOF (University of Oregon), ERIK NILSEN (Lewis & Clark College) und NICHOLAS GORMAN (University of Southern California) hat gezeigt, dass schlechte Banner-Werbung die empfundene Arbeitslast und den Lesefluss stören kann, und letztendlich vergessen wird.

Aus dem Original-Banner (468 × 60 Pixel) haben sich mit der Zeit weitere Bannergrössen entwickelt, die unterschiedlich eingesetzt werden können und damit eine benutzerfreundliche Gestaltung der Website erleichtern:

Rectangles and Pop-Ups

Banners und Buttons

Skyscrapers

Skyscraper werden von Benutzern vielfach als angenehm empfunden, da sie nicht den vertikalen Lesefluss stören, und meist rechts oder links ausserhalb des Textes angebracht sind.

Insbesondere Werbung rechts am Rand neben der vertikalen Bildlaufleiste haben gute Klickraten. Ein möglicher Grund dafür ist, dass sich beim Lesen meistens der Cursor auf der Bildlaufleiste, und damit in der Nähe der Werbung befindet. Der Benutzer muss also beim Blick nach rechts um die Bildlaufleiste zu treffen, einen kurzen Blick auf die Werbung richten und hat auch schon den Mousecursor in der Nähe. Unabhängig davon wird vertikale Werbung als wenig störend empfunden, was zur Benutzerakzeptanz beiträgt.

Textlinks

Obwohl Textlinks relativ unauffällig sind, können sie bemerkenswert effektiv sein. Mit ein Grund dafür ist, dass sie vielfach nicht auf den ersten Blick als Werbung empfunden werden. Ein guter Titel, der im Bezug zum Thema steht, kann leicht dazu führen, dass der Besucher der Webpage gerne auf den gebotenen Link klickt.

Popups

Popups werden von Usern als noch wesentlich störender empfunden als Banner. Moderne Browser haben bereits Popup-Blocker integriert, was das unerwünschte Zeigen von eben diesen verhindert. Popups verdecken unter Umständen den gesamten erwünschten Inhalt. Das kann zu brauchbaren Klick-Raten führen, ob es letztendlich auch zum gewünschten Erfolg führt, ist dagegen fraglich, da Popups von 78% der Benutzer als sehr störend empfunden werden. Layer-Ads sind entsprechen in der grundlegenden Funktion den Popups und wurden eigentlich nur entwickelt um die von den Benutzern verwendeten Popup-Blocker auszuhebeln. Sie wurden Anfangs auch von den grossen Medien-Unternehmen gerne genutzt, kommen mittlerweile aber immer weniger zum Einsatz, da sie letztendlich beim Benutzer den gleichen Ärger auslösen wie Popups.

Paidmail

Neuere, meistens kostenlose Formen von Werbung sind Paidmail und Besuchertausch. Bei Paidmail wird der Benutzer sogar dafür bezahlt auf Werbung zu klicken.

Um Paidmail zu empfangen, muss man sich bei sogenannten Paid-Mailern anmelden. Ab dann bekommt man Werbung zum gewünschten Thema zugeschickt. Da der Benutzer aber in der Regel sich nur anmeldet um für das Ansehen der Seite bezahlt zu werden, kann davon ausgegangen werden, dass der Streuverlust relativ hoch ist, da Paidmail "erzwungener Traffic" ist: Der Benutzer muss auf einen Link klicken um das zu bekommen, was er eigentlich will, nämlich Punkte bzw. Geld. Hier gilt es abzuschätzen wie gross die Wahrscheinlichkeit ist, dass der Benutzer letztendlich wirklich auf der beworbenen Seite hängen bleibt und den Dienst nützt (z.B. eben einkauft). Da aber beim Paidmail – im Gegensatz zum Besuchertausch – tatsächlich ein Mensch die Seite besucht, sind die einen oder anderen Erfolge nicht ausgeschlossen.

Besuchertausch

Besucher-Tausch funktioniert nach der Methode: "Besuchst du meine Website, so besuche ich Deine". Klingt auf den ersten Blick vielversprechend, ist es aber nicht. Die meisten Besuchertausch-Systeme funktionieren automatisch, das heisst es wird eine Seite nach der Anderen eingeblendet. Es ist nichtmal eine Bestätigung durch den Benutzer des Besuchertausch-Systems erforderlich. Das führt dazu, dass der Besuchertausch auch laufen kann und Hits entstehen, ohne dass ein Mensch die Seite zu Gesicht bekommen hat. Ein Webshop-Betreiber wird von diesem System also genau nichts haben – eine Maschine kauft nun mal nicht selbst ein.

Fazit

Guter, von der Internet-Community freiwillig verlinkter Content sowie gute Auffindbarkeit in den Suchmaschien sind sicherlich die besten Wege zum Erfolg im Internet.

Damit wird die Web 2.0 Community immer mehr auch zum Wirtschaftsfaktor: In der Studie wurde festgestellt, dass 43% der britischen MySpace User Kaufbewertungen von unbekannten MySpace-Anwendern in Ihre Entscheidung miteinbeziehen. Das ermöglicht neue Wege der Meinungsbildung und Erzielung von Kaufentscheidungen - und damit auch Risiken, aber auch Chancen für Handel und Industrie.

Web 2.0 hat bereits heute die kritische Masse erreicht - und Lösungen wie MySpace oder YouTube sind dabei, trotz aller Diskussionen um Urheberschutz und Lizenzverletzungen, zum Motor des "neuen" Internets zu werden. Jene Anbieter, die sich dieser Aufgabe mit aller Kraft widmen und diese auch zu lösen im Stande sind, werden die Gewinner dieses Internet-Booms sein.

Das GMENU ist ein Unterobjekt von dem HMENU und generiert ein grafisches Menü, bei dem jeder Link eine separate GIF-Datei ist. TMENU objekte sind grundsätzlich text-orientiert, können aber wie in dem Beispiel mit Grafiken versehen werden.

Dieses Beispiel soll ein Top-Menü produzieren, bei welchem vor jedem Menüpunkt eine von der Seite abhängige Grafik dargestellt werden soll. Ist die Seite nicht die aktive, soll das Bild in S/W angezeigt werden, bewegt der Besucher den Maus-Cursor über den Menüpunkt oder ist die Seite aktiv wird das Bild in Farbe angezeigt.

Die Struktur des Menüs ist Grundsätzlich folgende:

<ul>

<li><a><img></a><div></a>Titel</a></div></li>

<li><a><img></a><div></a>Titel</a></div></li>

<li><a><img></a><div></a>Titel</a></div></li>

...

</ul>

TS-Template

field.mainMenu = HMENU
field.mainMenu.entryLevel = 0
field.mainMenu.maxItems = 5
field.mainMenu.1 = TMENU
field.mainMenu.1
{
#wrappe das ganze Menue in ul
wrap = <ul>|</ul>

#Die einzelnen menuepunkte wrappe in li
NO.allWrap = <li>|</li>

# Die Beschriftung des menuepunktes wrapppe in eine div mit klasse caption

NO.linkWrap = <div class="caption">|</div>

# Bild soll verlinkt werden
NO.beforeImgLink = 1

# Hole das Bild aus media-feld und bearbeite es
NO.beforeImg = GIFBUILDER
NO.beforeImg
{
format = jpg
#definiere groese des bildes im menue
XY = 105,70
10 = IMAGE
10.file
{
#bild aus media-feld holen
import = uploads/media/
import.field = media
import.listNum = 0
}
# bild wird grau dargestellt wenn punkt nicht angewaehlt
30 = EFFECT
30.value = gray
}

# Alternative Darstellung fuer Mouse-Over (RO). Bild ist in Farbe wenn sich maus
# ueber Menuepunkt bewegt.
NO.RO = 1
NO.beforeROImg < .NO.beforeImg
NO.beforeROImg
{
# Bild nicht in Grau konvertieren bei Roll-Over
30.value =
}
#
# Format wenn Aktiv. Div fuer Caption bekommt zusaetzlich Klasse caption-active
#
ACT < .NO
ACT = 1
ACT.linkWrap = <div class="caption caption-active">|</div>
ACT.beforeImg
{
# Nicht ausgrauen !
30.value =
}
#Current Menue-Punkte sind wie Active – Einfach uebernehmen
CUR < .ACT
CUR = 1
}

Das Script gestaltet sich relativ einfach. wrap = <ul>|</ul> umschliesst das gesamte Menü mit den Tags UL. Dadurch wird eine unsortierte Liste generiert. NO.allWrap = <li>|</li> ist dafür zuständig die einzelnen Menüpunkte mit List-Item-Tags zu versehen. Ich versehe die Beschriftung noch zusätzlich mit einem DIV: NO.linkWrap = <div class="caption">|</div>. Das ist nicht unbedingt notwendig und kann je nach Bedarf anders gewählt werden.

Template-TS (Auszug)

 NO.beforeImg = GIFBUILDER
NO.beforeImg
{
format = jpg
#definiere groese des bildes im menue
XY = 105,70
10 = IMAGE
10.file
{
#bild aus media-feld holen
import = uploads/media/
import.field = media
import.listNum = 0
}
# bild wird grau dargestellt wenn punkt nicht angewaehlt
30 = EFFECT
30.value = gray
}


Für die Darstellung der Grafik ist NO.beforeImg zuständig. Falls das Bild nach dem Text des Menüpunkts dargestellt werden soll kann auch NO.afterImg verwendet werden.

Dieses Beispiel zeigt, wie dafür ein Bild aus dem Medien-Feld der Seite genommen, und entsprechend konvertiert werden kann.

Dieses Menü geht davon aus, dass das Bild für die Seite als erstes Element im Medien-Feld steht (Achtung: Um Medien angeben zu können, muss der Seitentyp Advanced gewählt werden.

Dieser Abschnitt weist Typo3 an, die Grafik für das Menü aus dem Media-Feld zu nehmen und durch den GIFBUILDER zu jagen. Dabei wird in diesem Beispiel davon ausgegangen, dass die Grafik 105 x 70 Pixel gross ist. Durch die Angabe des Effekts „gray“wird das Bild in S/W konvertiert.

Natürlich können auch andere Grössen gewählt werden (einfach bei XY die anderen Werte angeben) und gegebenenfalls – falls nicht sicher gestellt ist, dass das Bild in der richtigen Grösse vorliegt – mit SCALE sklalieren. Mehr Infos dazu in der Doku des GIFBUILDER.

Bei Mouse-Over (in TMENUITEM ist dafür das Feld RO bzw. NO.beforeROImg zuständig) soll das Bild in Farbe, also ohne S/W-Konvertierung dargestellt werden. Für diesen Zweck wird die Deklaration von NO.beforeImg mit < in NO.beforeROImg kopiert und das für den Grau-Effekt zuständige Feld value mit einem Leerstring überschrieben. Es wird also auf die Grafik kein Effekt ausgeführt.

Template-TS (Auszug):

NO.RO = 1
NO.beforeROImg < .NO.beforeImg
NO.beforeROImg {
# Bild nicht in Grau konvertieren bei Roll-Over
30.value =
}

Die Menü-Stati ACT und CUR bekommen die Deklaration von NO zugewiesen wobei der Filter auch für beforeImg überschrieben wird, da das Bild der aktuellen Seite in Farbe dargestellt werden soll. Zusätzlich wird dem div um den Link-Text mit ACT.linkWrap = <div class="caption caption-active">|</div> noch eine weitere Klasse zugewiesen

Natürlich kann das CSS beliebig gestaltet werden. Für den Test wurde folgendes CSS verwendet:

Beispiel-CSS:

#top_menu ul
{
margin-left: 10px;
line-height: 1em;
list-style: none;
position: absolute;
left: 0px;
top: 77px;
line-height: 1.4em;
}
#top_menu ul li
{
text-align: center;
float: left;
width: 125px
}
#top_menu ul li .caption
{
display: table-cell;
vertical-align: middle;
width: 125px;
height: 38px;
}
#top_menu ul li .caption-active a,
#top_menu ul li .caption-active a:link,
#top_menu ul li .caption-active a:visited
{
color: #FFFFFF;
}

Ich gehe in dem Beispiel davon aus, dass sich das Menü in einem DIV mit der ID top_menu befindet. Dieses CSS bildet nebeneinander stehende Menüpunkte, jeweils mit jeweils einem mit Text unterschriebenen Bild.

Allerdings hat dieser Lösungsweg auch den Nachteil, dass es so sehr mühsam bis unm�glich wird HTML-Beispielcode in den Quelltext einzufügen, da dem RTE bekannte Tags nun als "echte" tags und nicht als Beispielcode interpretiert würde.

Um htmlArea dies abzugwöhnen und tags als Klartext zu erhalten sind nur zwei Zeilen in der Page-TSconfig notwendig:

Page-TSConfig:RTE.default.proc {
dontHSC_rte = 1
dontUndoHSC_db = 1
}

In Deutschland ist die Dominanz von Microsoft nicht ganz so stark, der Browser Firefox von der Mozilla-Foundation kann hier mit einem Marktanteil von über einem Viertel aller User Microsoft doch etwas Paroli bieten. Microsoft hält hier bei 69,47%, Firefox hat 25,66%, Opera 2,1%, Apples Safari 1,22% und weit abgeschlagen liegt Netscape mit 0,22$.

Quelle: Onestat, www.onestat.com

Grundsätzlich funktionieren die Hacks meistens nach einem bestimmten Schema: Man nützt eine Schwäche oder Bug des Internet Explorers aus, um eine andere Schwäche oder Bug zu umgehen. Klingt pervers, ist es auch

Grundätzlich sollte auf Hacks so weit wie möglich verzichtet werden,  da sie immer einen Missbrauch von HTML/CSS darstellen und nie sicher gestellt ist, dass der Hack noch in der nächsten Version von IE den gewünschten Effekt erzielt

Nur manchmal lassen sich Hacks nun mal nicht vermeiden. Besondere Kundenwünsche können Webdesigner dazu zwingen Deklarationen verwenden zu müssen, die im IE nun mal ohne Hack nicht richtig funktionieren.

Conditionals in HTML

Die verwendung von Conditionals in HTML stellt an sich eigentlich keine Hack dar und ist sicher die sauberste Variante um für den Internet Explorer zusätzliche oder andere CSS-Deklarationen zu verwenden.

Beispiel-HTML-Header:<link rel="stylesheet" type="text/css" href="allgemein.css" />

<!--[if IE]>
<link rel="stylesheet" type="text/css" href="nur-ie.css" />
<![endif]-->

Diese Art von Browserweiche nützt keinen IE-Bug aus und ist daher eine der Zukunftssicheren. Trotzdem ist anzumerken, dass sie nicht HTML-Standard sind.

Die Browserweiche ist relativ flexibel und bietet auch Operatoren und die Abfrage bestimmter Versionen des IE:

Bekannte Werte für den Vergleich sind

Javascript-Bugfixes für den IE

Im Internet finden sich mittlerweile einige interessante Javascript-Libraries die versuchen Probleme des IE zu umgehen.

Besonders bemerkenswert und umfangreich ist Dean Edwards Projekt IE7 {css2: auto}

Dieses Projekt hat nicht direkt etwas mit dem Internet Explorer 7 zu tun. Im Gegenteil. Das Projekt stammt aus dem Jahre 2004 und versuchte damals schon die gröbsten CSS-Probleme des Internet Explorers zu umgehen. Ein äusserst interessantes Projekt, aber leider noch in der Alpha-Version.

Der * html Hack

Mit dem * html Hack lassen sich bedingte Deklarationen für den Internet Explorer erzielen.

Verschachtelte CSS-Deklarationen werden immer von aussen nach innen interpretiert.  So besagt beispielsweise die Deklaration  a.mein-absatz  code {....},  dass die angegebene Formatierung für in code-tags eingeschlossene Bereiche nur dann verwendet werden soll, wenn sie sich innerhalb eines Absatzes mit der Klasse mein-absatz befindet.

Im Internet-Explorer 7 gibt es mit diesem Hack im strict-modus Probleme. Daher ist die Verwendung nicht unbedingt empfehlenswert.

* html bedeutet also, dass sich das html-element in "irgendwas" befinden muss. Nun ist es aber so, dass alle Browser ausser dem Internet-Explorer html als das Root-Element betrachten. Das ist logisch, weil <html> nicht in andere Tags eingeschlossen wird, und daher * html eigentlich unsinnig ist.

Typischer HTML-Code:

<html>
  <head>
    ....
  </head>
  <body>
    ....
  </body>
</html>

Ausserhalb von html ist nichts mehr. * html ist also eigentlich eine unsinnige, aber trotzdem syntaktisch valide Deklaration. Der Hack nützt aus, dass der Internet Explorer im Gegensatz zu allen anderen Browsern diese unsinnige Deklaration interpretiert.

Das Risiko ist also, dass IE auch

Daruch lassen sich allgemeine Deklarationen so überschreiben, dass sie nur vom IE interpretiert werden:

Test-HTML-Code:<html>
<head>

  <style type="text/css">

    /* Die allgemeine Deklaration */

    .mein-test {
      font-weight: bold;
    }

    /* und hier nur für den IE */


    * html .mein-test {
      font-weight: normal;
    }


  </style>

</head>
<body>
  <p>Ich teste hier wie <span class="mein-test">die Klasse mein-test</span> dargestellt wird.<p>
</body>
</html>

Auf allen Browsern ausser dem IE wird

Ich teste hier wie die Klasse mein-test dargestellt wird.

angezeigt wird. Nur beim IE erscheint

Ich teste hier wie die Klasse mein-test dargestellt wird.

Was für diesen Test genau der gewünschte Effekt ist.

Fazit

Auf Browswerweichen und Hacks kann derzeit leider nur selten verzichtet werden. Design-Ansprüche von Kunden zwingen Web-Designer dazu auch CSS zu verwenden, das vom Internet Explorer ohne Hack und Workaround nicht richtig dargestellt wird, was leider immer wieder zu Mehraufwand und Mehrkosten bei Web-Projekten führt. Hacks die ihrerseits wieder Bugs des IE ausnützen sollten dabei aber weitgehend vermieden werden, da nie auszuschliessen ist, dass Microsoft genau den ausgenützten Bug in zukünfigten Versionen beheben wird. Der Einsatz von Browserweichen auf basis von Conditionals in HTML stellt derzeit die sicherste Methode dar um spezielle Deklarationen für den IE zu verwenden.

Diese Links zeigen die Default-CSS-Deklartion des Firefox an:

resource:///res/html.css (Standard-Deklaration)

resource:///res/forms.css (Form-Elemente)

resource:///res/quirk.css (Abweichungen für den Quirk-Mode)

styles.content.links {
  allowTags := addToList(code)
}

===

styles.content.links {
  allowTags := addToList(code)
}

===

Damit kennt Typo3 mal das Code-Tag und es wird nicht mehr verworfen.

Achtung: addToList ist erst ab Typo3 Version 4 verf�gbar und h�ngt den in Klammer stehenden wert an den bestehenden Wert an. In älteren Versionen von Typo3 muss die gesamte Liste der erlaubten Tags angef�hrt werden.

Wer den RTE verwendet muss noch eine Deklaration im Page-TScript vornehmen, damit der Editor den Tag kennt und ihn nicht beim Speichern verwirft.

Dies geschicht durch folgende Zeilen in der Page-TScript der obersten Seite des Baumes:

Page-TScript:RTE.default {

    ## sicherstellen dass die angef�hrten Tags zulässig sind und nicht verworfen werden
    
    proc.allowTags := addToList(div, code)

    ## sicherstellen dass die angeführten Tags zulässig sind und nicht verworfen werden
    
    proc.allowTagsOutside := addToList(div, code)

    #
    # proc.entryHTMLparser_db: Umsetzung für Editor->DB konfigurieren
    #

        proc.entryHTMLparser_db {
                                allowTags < RTE.default.proc.allowTags
                                allowTagsOutside < RTE.default.proc.allowTagsOutside
    }
    
    #
    # proc.HTMLparser_rte: Umsetzung f�r DB->Editor konfigurieren
    #

    proc.HTMLparser_rte {
                                allowTags < RTE.default.proc.allowTags
                                allowTagsOutside < RTE.default.proc.allowTagsOutside
    }


}Um es den Benutzer einfacher zu machen Code-Blöcke schneller einzufügen kann es auch noch hilfreich sein, für diesen Zweck ein benutzerdefiniertes Element zu erstellen. Dies geschicht auch im Page-TScript:

Page-TScript:RTE.default {

    ## Zus�tzliche Buttons für den RTE - Zeigt Button "User-Elemente" im RTE an.

    showButtons := addToList(user)

    #
    # Userelement definieren
    #

    userElements.10.7 = SourceCode
    userElements.10.7 {
        description = F�gt einen Block Source Code ein. Verwendet dafür Code-Tags
        mode = wrap
        content = <p><b>Code:</b><code>|</code></p>
    }
}