Invalides HTML in den Lang-Attributen fixen

In WordPress 4.3 wurde bei einigen optionalen Sprachpaketen die formelle Form eingeführt. Beispielsweise bei der Sprachauswahl unter den Einstellungen mit „Deutsch (Sie)“.

Leider wurde bei dem Setzen der Sprachattribute in der Funktion language_attributes() etwas unvorsichtig agiert: Durch die in Themes übliche Zeile

wird nach Wahl des Sprachpakets „Deutsch (Sie)“ folgendes erzeugt:

Dies macht den Code für den HTML-Validator invalid. Im Trac ist das Problem schon notiert worden: https://core.trac.wordpress.org/ticket/33511

Meine Lösung ist nicht elegant, aber sie reicht:

Ich lösche hier also einfach das „-formal“. Man könnte stattdessen auch das fehlende „-x“ einfügen. Das ist die auskommentierte Zeile.

Eine für WordPress-Entwickler elegantere Lösung würde wahrscheinlich eher die get_locale() Funktion nutzen. Dort könnte man dann im Array der verfügbaren Sprachcodes was machen.

Egal, es tut.

Da die Ursache ein Bug ist, der sicher eh irgendwann behoben wird, möchte ich auch nicht zu viel Zeit investieren.

Flattr this!

Was Print-Designer für die Umsetzung eines Webdesigns liefern müssen

(Vorbemerkung: Dieser Artikel hat noch kein Endzustand erreicht und wird noch nach und nach durch das eingehende Feedback korrigiert und erweitert.)

Das Webseiten keine Gemälde sind und die Gestaltung für das Web anderen Regeln gehorcht als bei der Print- oder Screengestaltung wurde bereits in vielen Artikeln von Experten ausführlich und in nahezu epischer Breite beschrieben.
Stellvertretend für viele Artikel verweise ich auf den aktuellen Artikel von Marc Hinse, ein professioneller Webdesigner und Webentwickler, der in klaren und offensichtlichen Beispielen die wichtigsten Dinge aufzeigt: Web ≠ Print

Ein Rant zum Einstieg

Trotz der großen Zahl an Artikeln, Büchern und Studien (insbesondere solche die die Themen Usability und der Barrierefreiheit behandeln) gibt es immer noch sehr viele Agenturen und Screen/Print-Designer, die glauben mit der Erstellung einer Photoshop-Vorlage sei alles getan um ein Webdesign fertig zu stellen; Und nun müsse nur noch ein „Programmierer“ es einfach umsetzen.
Noch schlimmer: Es gibt sogar Studiengänge oder Kurse die damit werben, daß man in diesen die Erstellung von Webdesigns erlernt; bei denen allerdings nur Grundlagen von HTML 4.0 (!) gestreift werden, der Schwerpunkt aber nur daraus besteht, (zugegebenermaßen) schöne Grafiken mit Photoshop zu erstellen.

Doch genug geschimpft, kommen wir zur Sache.

Was braucht ein Webdesigner von einem Print-Designer?

Es gibt Situationen bei denen man nicht umhin kommt, doch die Vorlage eines Print-Designer umzusetzen.
Die Ausgangslage ist die folgende: Kunde hat sich von einer Print-Agentur beschwatzen lassen, ein Design von der Agentur zu nehmen. Ein Webdesigner soll dieses Design danach umsetzen. Was braucht er dazu?

Die Photoshop-Vorlage für die Startseite eines größeren Webangebotes ist allenfalls der allererste und einfachste Schritt. Marc Hinse beschreibt in seinem Artikel ausführlich woran es Print-Designs mangelt. Dies kann als Orientierung genutzt werden, was ein Screen-Designer zusätzlich liefern muss.
Die folgende Auflistung soll versuchen, dies zusammenzufassen.

Grundlegendes

Vor der Umsetzung sollte eine Prüfung der Vorlage stattfinden auf visuelle und logische Fehler, sowie anderer offensichtlicher Mängel in Bezug auf Usability und Barrierefreiheit.

  • Farbkontraste: Wenn unterschiedliche Farben verwendet werden für Texte und Hintergründe, ist zu prüfen ob die Kontraste ausreichend sind. Als Anhaltspunkt können hier die gängigen Formeln aus der barrierefreien Gestaltung von Webauftritten herangezogen werden.
  • Navigation und aktuelle Position auf der Website: Wie wird bei einzelnen Unterseiten die aktuelle Position innerhalb des Webauftritts dargestellt? Ist eine entsprechende Navigation enthalten? Gibt es eine Vorlage für eine Inhaltsübersicht in Baumform und einer in alphabetischer Ansicht?
  • Optische Bedienelemente: Gibt es rein optische Bedienelemente, die verlangen, daß Surfer sie auch optisch genauso wahrnehmen und nutzen können, wie der Design?
  • Scrolling: Welches Scrollverhalten für Inhaltsbereiche ist vorgesehen? Kann es etwa passieren, daß Texte aus dem Sichtbereich verschwinden, nur weil der Surfer eine größere Schriftart verwendet?
    Welches optische Verhalten ist für Überschriften oder Slogans im Kopf der Seite vorgesehen, sollten diese auf zwei oder mehr Zeilen umbrechen?
  • Formulare: Haben alle Formulare erkennbare Absendebuttons?

Vorlagen für unterschiedliche Seitentypen

Ein Webauftritt besteht aus unterschiedlichen Typen von Seiten. Für alle diese Typen muss eine Vorlage geliefert werden, wenn diese Typen vorhanden sind:

  • Startseite
    Die Eingangsseite der Webpräsenz.
  • Doorway-Page
    Hinweis: Doorway-Pages sollten nur in Ausnahmefällen verwendet werden. Für normale Webauftritte, derren Schwerpuntk auf der Informationsverbreitung liegt, sollten Doorway-Pages nicht mehr zum Einsatz kommen. Am Besten verzichtet man auf dieses Relikt des letzten Jahrtausends!

  • Inhaltsübersichten / Inhaltsindex
    Bei komplexen Seiten reicht eine Navigation meist nicht aus, es muss auch eine Inhaltsübersicht und/oder ein alphabetischer Seitenindex geliefert werden. Dabei handelt es sich dann auch meist um eine umfangreiche Liste, derren optische Darstellung definiert sein sollte.
  • Fehlerseiten
    Falls ungültige Adressen auf der Webseite aufgerufen werden, der Zugriff fehl schlug oder es zu einer anderen Art von Fehler kam.
  • Ausgabeseiten für Suchergebnisse
    Falls der Webauftritt eine Suchmaske anbietet, muss definiert werden, wie das Ergebnis der Suche aussieht.
  • Seiten mit Formularen
    Sind Eingabeformulare auf dem Webauftritt vorhanden, müssen diese vollumfänglich dargestellt werden. Dabei müssen alle üblichen Eingabemasken und Bedienmöglichkeiten definiert sein: Eingabemasken für Texte (sowohl mit aktiven Cursor als auch ohne), Auswahllisten, Checkboxen, Radioboxen und Absendebuttons.
    Bei textuellen Eingabemasken, sowie bei Auswahllisten ist anzugeben, ob es ein Default-Element gibt, welches sichtbar ist, wenn die Eingabemaske oder Auswahlliste nicht aktiv ist.
  • Seiten mit viel Text, Seiten mit ganz wenig Text
    In der klassischen Vorlage eines Print-Designers ist Mustertext immer schön passend lang, damit die Seite optisch gut aussieht.
    In der Praxis allerdings gibt es unterschiedlich lange Texte. Die Länge des Textbereiches hat Einfluß auf das Scrollverhalten der Seite. Daher sind für beide Varianten Vorlagen zu liefern. Bei der Variante mit viel Text, muss dieser so lang sein, daß der gesamte Text nicht auf einer Bildschirmseite darstellbar ist. Nur so kann der Webdesigner erkennen, wie die Seite mit Scrollbalken auszusehen hat.
  • Seiten mit kleiner Schriftgröße, Seiten mit großer Schriftgröße
    Damit klar ist, wie sich das Webdesign verhält, wenn Surfer mit unterschiedlich eingestellten Schriftgrößen die Seite besuchen, sind mindestens 4 Beispielvorlagen für folgende Varianten zu liefern:

    1. Startseite mit Schriftvergrößerung auf 150%
    2. Startseite mit Schriftverkleinerung auf 75%
    3. Inhaltsseite mit Schriftvergrößerung auf 150%
    4. Inhaltsseite mit Schriftverkleinerung auf 75%
  • Seiten mit Bildern in den Textbereichen
    Verwendete Bilder in Textbereichen können in Größe und Position variieren. Zudem ist ihre Darstellung auch abhängig davon ob sie von Text umflossen werden sollen oder nicht. Daher muss eine Vorlage vorhanden sein, die zeigt, wie sowohl kleine Bilder (bis zu einer Größe von 300px in Höhe und Breite), als auch wie große Bilder (bis zu einer Größe von 1024px Breite und 800px in der Höhe) dargestellt werden sollen.
    (Diese Vorlage können ggf. mit der Vorlage der Seiten mit viel Text kombiniert werden.)

  • Sonstige spezielle Inhaltsobjekte und „Web 2.0“-Elemente
    Wenn die Seite verschiedene eingebettete Objekte enthält, wie beispielsweise YouTube-Videos, Werbebanner und Werbetextbereiche, diverse Web 2.0-Bookmarklets, Feeds aus Blogs oder anderen Medien, dann muss auch hier die Position und die Art der Darstellung definiert sein.

    Ausserdem gibt es oft einige textuelle Informationen, die ebenfalls gesondert dargestellt werden sollten. Beispielsweise die „Personen-Visitenkarten“ bei einer Wir über uns-Seite oder die Kontaktdaten in einem Impressum.

Vorlagen für verschiedene Ausgabeformate

Neben der Vorlage für die Darstellung mit Webbrowsern müssen ebenso Vorlagen geliefert werden für die Darstellung derselben Seite mit folgenden Medien:

  • Print
  • Handheld
  • Screenreader

Bei den unterschiedlichen Ausgabemedien sollte zudem bedacht werden, daß Bereiche der Webseite bei diesen gegebenfalls obsolet sind oder aber ob welche zusätzlich definiert werden müssen, die in der Monitordarstellung jedoch fehlen:

  • Bei der Print-Darstellung ist die optische Darstellung von Links und Menüs zu hinterfragen. Einige Links machen bei der Print-Ausgabe keinen Sinn mehr und sollten daher dann unsichtbar sein.
  • Bei der Print-Darstellung könnte möglicherweise eine für Print-Publikationen andere Corporate Design-Vorgabe für den Kopfteil der Seite gelten.
  • Bei der Handheld- und Screenreader-Darstellung sind etwaige vorher unsichtbare Skiplinks sichtbar zu machen.

Unterstützung verschiedener Fensterauflösungen

Wenn ein Print-Designer anhand der obigen Anforderungen noch nicht verzweifelte und laut über diese unangemessenen Nachfragen des unwürdigen Code-Sklavens geflucht haben, wird er gleich möglicherweise völlig aus der Haut fahren. Denn nun wird sich heraus stellen, ob das ganze Design überhaupt was wert ist: Wie soll das Design denn bei verschiedenen Fensterauflösungen reagieren?

Folgende Vorlagen sind zu liefern:

  • Startseite mit Auflösungen von
    1. 1600×900 Pixel (neuer 16:9 Bildschirm)
    2. 1024×800 Pixel
    3. 950×500 Pixel
    4. 600×320 Pixel und 320x600Pixel (für diverse ältere Handhelds)
  • Textseite, die auch Bilder enthält mit Auflösungen von
    1. 1600×900 Pixel (neuer 16:9 Bildschirm)
    2. 1024×800 Pixel
    3. 950×500 Pixel
    4. 600×320 Pixel und 320×600 Pixel (für diverse ältere Handhelds)

Ein Anhaltspunkt und Hintergrundinformationen liefert u.a. die Seite Browser Size von Google.

Verwendete Bilder

Alle für die Vorlage verwendeten Bilder (insbesondere bei Hintergründen zu Bereichen der Webseite) müssen einzelnt geliefert werden. Die Bilddateien sollten dabei möglichst im Orginal und in einem der gängigen Bildformate JPG, GIF, PNG, TIFF geliefert werden. Keinesfalls sollten Bilder vom Print-Designer selbst verkleinert werden. Bilder, welche in einem Word- oder PDF-Dokument embedded werden, sind nicht nutzbar.
Ausserdem müssen alle verwendeten Logos, die auf der Webseite dargestellt werden sollen, geliefert werden.
Für den Fall, daß Hintergrundbilder in einer oder zwei Dimensionen wiederholbar sein sollen, muss die Vorlage des Bildes entsprechende Ränder haben, die einen fließenden Übergang erlauben.

Verwendete Schriften

Wenn die Webseite verschiedene Schriften verwendet, sind diese anzugeben. Zusätzlich müssen zu jeder Schrift mindestens 2 weitere Alternativschriften genannt werden, die dann verwendet werden, wenn die favorisierte Schrift nicht verfügbar ist.
Weiterhin muss für den Fall, daß keine der drei Schriften verfügbar ist, angegeben werden, ob es sich um eine Serifenschrift handelt oder nicht.

Schriftgrößen

Für alle Bereiche der Homepage in der Texte dargestelt werden, sind die exakten Schriftgrößen anzugeben. Allerdings sollte nur der Haupttextbereich (=Inhaltsbereich) in der Größenangabe Pixel oder Point fest definiert werden. Die Schriftgrößen aller anderen Textbereiche werden dagegen proportional zu der Größe des Haupttextbereiches definiert werden.

Schriftgrafiken

Werden Schriftgrafiken verwendet, sind die dafür verwendete Schriftarten und Schriftgrößen ebenso wie bei den normalen Textbereichen anzugeben. Handelt es sich bei den Schriftgrafiken um Grafiken, bei der es zu keinen besonderen grafischen Modifikationen kam, werden diese vorzugsweise vom Webdesigner verworfen und über normale Texte dargestellt, derren Optik mit Hilfe von CSS an die Vorlage angepasst wird.

Reaktion bei Maus- und Tastaturbedienung, sowie Hovereffekte

Der aktuelle Fokus des Cursors (sowohl bei Maus- oder Tastaturbedienung) von Links ist sichtbar zu machen. Dies gilt für:

  • Links in der Navigation
  • Links in Textbereichen
  • Links auf Grafiken
  • mit der Tastatur angesteuerte aktive Skiplinks
  • weitere mit Maus oder Tastatur angesteuerte reaktive Bereiche, die zu einer Aktion führen (Buttons, Ajax-Schaltflächen, usw.)

Zusätzlich muss definiert werden, wie ein selektierte Objekte (Texte und Bilder) in den jeweiligen Bereichen der Homepage aussieht.

Farben

Texte, Links, Hintergründe, Ränder und Bereiche haben unterschiedliche Farben. All diese müssen in RGB-Werten angegeben werden.
Zusätzlich sollte man bei Farbübergängen von Flächen die Start- und die Endfarbe angeben.

Verwendete Mustertexte

Wie oben bereits beschrieben, sollten die Vorlagen sowohl kurze, wie auch lange Texte beinhalten. Häufig wird dabei zurückgegriffen auf das bekannte Lorem Ipsum.
Leider fehlt es dem Lorem Ipsum-Text, wie auch meisten anderen Mustertexten, an unterschiedlichen Textarten. Beispielsweise Tabellen oder Zitate. Wenn der Webdesigner ein CSS entwerfen soll, muss dieser jedoch auch wissen, wie auszusehen haben.
Ein idealer Mustertext sollte daher folgende Elemente enthalten:

  • Tabellen (mit mindestens 3 Zeilen und Überschriftenzeile, sowie mindestens 3 Spalten und Bezeichnungsspalte)
  • Zitate (sowohl innerhalb eines Absatzes als auch in Form eigener Absatzzitate)
  • Akronyme und Abkürzungen
  • Listen (ungeordnete Listen, geordnete Listen; dabei auch Listen in Listen).
  • Zitate oder Absätze in anderen Sprachen

Postionen und Ausrichtung von Bereichen

Falls in der Vorlage verschiedene Bereiche definiert wurden (zum Beispiel zwei nebeneinander stehende Textblöcke), ist zu definieren, wie diese zueinander positioniert sind und welche Textausrichtung genutzt werden soll.
Über die oben genannte Vorlage für kleinere Bildschirmauflösungen soll dabei auch gezeigt werden, wie die Textbereiche dargestellt werden, wenn der zur Verfügung stehende Platz nicht ausreicht, diese nebeneinander zu positionieren.

Rechtliche Aspekte

Viele Print-Designer greifen zurück auf ein großes Archiv von Bildern verschiedener Quellen. Diese werden z.B. für Hintergründe, als Schmuckgrafiken oder zur emotionellen Ansprache benutzt.
Beispielsweise finden sich auch Fotos von Menschen dabei, die in der eine oder anderen Situation aufgenommen wurden und sich damit eignen eine werbende Botschaft zu überbringen.
Hier ist zu hinterfragen, ob die Bilder überhaupt für die Nutzung im Internet frei gegeben sind, ob diese entsprechende Lizenzen haben. Dies gilt ganz besonderes auch dann, wenn nur einzelne oder wenige Personen abgebildet sind.
Die Vorlage einer Nutzungslizenz für eine begrenzte Auflage von Print-Publikationen reicht nämlich keinesfalls aus um das Recht zu erlangen, selbige Bilder weltweit abrufbar im Internet zu verbreiten.

Alles da? Dann los

Erst nachdem all das obige geliefert wurde, kann ein Webdesigner daran gehen, das Design für einen Webauftritt umzusetzen.
Sollte etwas fehlen, wird es zwangsläufig zu Rückfragen kommen. Dies kann auch sehr schnell sehr teuer werden. Beispielsweise dann, wenn Teile bereits umgesetzt wurden, sich dann aber herausstellt, dass aufgrund von mangelhaften Vorlagen (z.B. das Verhalten der Seite beim Einsatz von großen Bildern im Inhaltsbereich) die grundlegende Gestaltung nochmals neu gemacht werden muss.

Fazit

Das der Aufwand, den ein Print-Designer leisten müsste um all die oben definierten Informationen zu liefern sehr hoch ist, dürfte offensichtlich sein.
Der Aufwand dürfte eher selten wirklich geleistet werden. Trotzdem hab ich bislang keine andere ausreichende Checkliste gefunden, die alles auflistet, was ein Webdesigner im Idealfall bekommen sollte. Daher sehe ich diese Auflistung als idealtypischen Orientierungsrahmen an.
In der täglichen Praxis erwarte ich jedoch nicht, daß dieses Ideal erfüllt wird. So schön es auch wäre. Denn wenn alls richtig laufen würde, dann bräuchte man sowas garnicht:

Denn besser und kostengünstiger ist es immer noch, ein Webdesign gleich von einem richtigen Webdesigner entwerfen zu lassen, der dann das Print-Design zusammen mit dem Handheld- und Screenreader-Design erstellt.

Wenn ich meine Wohnung streichen lassen will, werde ich auch zum Maler gehen. Und nicht zum Lackierer.

Eine ebenfalls gute Variante wäre noch, wenn Webdesigner und Print-Designer noch während der ersten Erstellungsphase einer Vorlage schon zusammen und Hand-in-Hand arbeiten.

Weitere Links zum Thema

Flattr this!

GoogleMap vs. OpenStreetMap

Nachdem ich heute wieder (und schon einige Male davor) von einer GoogleMap genervt wurde, hab ich mich der Sache mal genauer angenommen. Mit dem Ergebnis: GoogleMap raus, OpenStreetMap rein.

Die GoogleMap verwendete den ganz normalen Google Code wie er auch dokumentiert wurde. Zusätzlich wurden Marker mit Hilfe einer XML-Datei gesetzt.
Diese Dateien sahen dann wie folgt aus:

Eigentlich ist die Syntax nicht so schwer begreiflich. Aber die Tücke liegt im Detail. Die Datei wurde von mehreren Kolegen bearbeitet, die überdies nicht in einer homogenen Arbeitsumgebung sind. Einer griff via vi aus der Unixshell drauf zu, der andere via Notepad von Windows und wiederum jemand anders über ein ganz anderes Tool.
Das Problem war: Das JavaScript erwartet eine valide XML-Datei. Sobald jedoch Sonderzeichen nicht mit UTF8, sondern mit einem anderen Charset gespeichert wurden oder jemand anders -in Kenntnis des Problems, dass sein Editor unter Windows nicht in UTF8 zu speicherte- Entities verwendete, wurde die Datei nicht interpretiert und die gesamte Karte wurde nicht gezeichnet.

Die Karte wurde also nur dann erstellt, wenn keine entweder keine Sonderzeichen vorhanden waren, oder diese ganz streng nur in UTF8 geschrieben waren.
Jemand, der nur auf einem Betriebssystem wird nun die Schultern zucken und sagen: „So what?!“.
Aber wer wie ich in einem heterogenen Umfeld arbeitet wird wohl mitfühlen können. Einige Editoren haben nicht einmal eine Konfigurationsmöglichkeit bei der man angeben kann, in welchem Charset gespeichert wird! Die übernehmen dann im Bestfall dass vom Betriebssystem (was auch nicht unbedingt optimal sein muss. Windows-Charset, you know?).
Andere Editoren (Dreamweaver CS3) haben zwar die Konfigurationsmöglichkeit, in UTF8 zu speichern, tun dies aber nur für neue Dateien. Wenn ich damit eine Datei öffne, die bereits im Windows-Murkschar gespeichert ist, läßt es das so wie es ist undich hab trotzdem keine Portierungsmöglichkeit.

Nun ja, lange genug gejammert.

Ich bin schlicht auf OpenStreetMap umgesteigen.
Mit den OpenLayer POI wird das Problem einfach dadurch umschifft, indem man als Quelle für Marker eine Textdatei nimmt.
Mit der Methode OpenLayers.Layer.Text wird diese Datei eingelesen und interpretiert.

Eine Textdatei, bei der man lediglich darauf achten muß, Tabstops richtig zu setzen, stellt für normale User auf alle Fälle eine Erleichterung dar gegenüber einer XML-Datei.

Hier das Ergebnis:
Plan der Umgebung zum Webkongress Erlangen 2010

Die Textdatei sieht wie folgt aus: wke2010-orte.txt

Frecherweise hab ich mich bei den Icons dann aber doch bei der Google Map Icon Library bedient.

Flattr this!

Webseiten auslesen und importieren

Wer mehrere Webauftritte auf unterschiedlichen Plattformen betreibt, hat mitunter das Problem, das selbe Texte auf verschiedenen Auftritten stehen sollen. Diese möchte man aber natürlich nicht dauernd kopieren oder mehrfach pflegen.

Auf Basis der Perl-Module HTML::TreeBuilder und LWP::UserAgent hab ich daher ein Skript geschrieben, welches definierte Webseiten einließt und über ein SSI-Befehl dann in der jeweiligen Seite anzeigt: import-url.pl.

Das Skript besteht aus drei Teilen: Zuerst wird die Liste der auszulesenden URLs aus einer CSV-Datei eingelesen. Welche dieser URL eingebunden wird, liefert die ID, welche im Aufrufparameter des Skriptes liegt. Eine direkte Angabe der URL wäre zu gefährlich, da ansonsten Dritte beliebige URLs importieren könnten, bzw. die Webseite für ungewollte Webpipes ausnutzen könnten.
Im zweiten Teil wird über LWP die URL ausgelesen:

Der Inhalt wird dann mit HTML::TreeBuilder analysiert.
Die Webseiten, die ich betreibe haben eine klar definierte Semantik, in der der eigentlich Inhalt von einem <div id=“content“> … </div> umschlossen wird. Danach suche ich um alle Teile der Webseite wegzulassen, die bspw. Menu oder Metainformationen enthalten:

Die Variable $out enthält somit den Inhalt der Seite.
Wenn die Seite keine Bilder oder Links enthielte, wäre ich damit fertig. Diese muss ich aber noch anpassen.
Dazu suche ich in einer while()-Schleife und ein paar Regular Expressions einfach nach den Vorkommen von src=““ und href=““ innerhalb der HTML-Tags.
Das sieht dann im wesentlichen so aus (Beispiel nur für die Suche nach Links):

$content ist der HTML-Text, $content ist dabei das Ergebnis. Ausgehend von der ursprünglichen URL verfüge ich ausserdem über die beiden Variable $base und $uripath, welche die Adresse der Website und die URI der Seite enthalten.

Das Skript ließe sich nun noch leicht erweitern. Zum Beispiel über spezifische RegExp pro einzulesender URL oder auch um eine noch genauere Filterung des Inhaltes nach anderen Bereichen.

Flattr this!

Webtechniken im Überblick

Index

  1. HTML
  2. XML
  3. CGI
  4. SSI
  5. PHP
  6. Java
  7. JavaScript
  8. ASP
  9. Sonstiges
  10. Akzeptanz und Nutzung der Webtechniken
  11. Anmerkung zum Artikel

1. HTML

HTML ist die Abkürzung für „Hypertext Markup Language“. Sie beschreibt, wie der darzustellende Text strukturiert und formatiert wird, und wie unterschiedliche Medientypen (wie Bilder, Grafiken, Töne usw.) in die Seite eingebunden werden können. Die Grundsyntax von HTML wird in der HTML-Norm festgelegt, welche vom World Wide Web Consortium definiert wird. Eine gewöhnliche HTML-Datei besteht grundsätzlich aus folgenden zwei Teilen:

  • Header (Kopf – enthält Angaben zu Titel u.ä.)
  • Body (Körper – enthält den eigentlichen Text mit Überschriften, Verweisen, Grafikreferenzen usw.)

Neben dem eigentlichen Text enthalten HTML-Dateien HTML-spezifische Befehle. Alle HTML-Befehle stehen in sog. Tags. Die Tags werden durch spitze Klammern markiert. Fast alle Befehle von HTML bestehen aus einem einleitenden und einem abschließenden Tag. Der Text dazwischen ist der „Gültigkeitsbereich“ für die betreffenden Tags.

Beispiel:

Quellcode 1. HTML

Der gesamte Inhalt einer HTML-Datei, wie in Quellcode 1 angegeben, wird in die Tags <html> bzw. </html> eingeschlossen. Hinter dem einleitenden HTML-Tag folgt der einleitende Tag für den Kopf <head>. Zwischen diesem Tag und seinem Gegenstück </head> werden allgemeine Angaben, meist META-Daten, zur HTML-Datei notiert. Die wichtigste dieser Angaben ist der Titel der Webseite, die durch die Tags <title> bzw. </title> markiert wird. Unterhalb davon folgt der Textkörper, kenntlich gemacht durch die Tags <body> bzw. </body>. Im Textkörper wird der eigentliche Inhalt der Seite notiert, also das, was im Anzeigefenster des Webbrowsers angezeigt werden soll. Eine umfangreiche deutschsprachige Dokumentation von HTML wurde von Stefan Münz erstellt und ist Online abrufbar.

2. XML

XML steht für Extensible Markup Language. Mit Hilfe von XML lassen sich Kontext und Inhalt einer Seite fest definieren und maschinell auswertbar machen. Genauer: „Dadurch, daß alle Dokumente den gleichen Regeln folgen, ist es möglich, Anwendungen zu schaffen, welche die Informationen aus den Dokumenten auslesen und automatisch verarbeiten.“ [Zitat: http://www.w3.org/TR/REC-xml] XML entstand aus SGML („Standard Generalized Markup Language“). Im Vergleich zu HTML bietet XML die Möglichkeit eigene HTML-Tags zu definieren und ist somit anpaßbar an die Bedürfnisse der Benutzer, bzw. an die Umgebungsdaten.
Ebenso wie HTML ist XML ein Standard, welcher vom W3C-Konsortium verwaltet wird. Das folgende Beispiel zeigt eine typische XML-Struktur.

Quellcode 2. XML-Beispiel 1

In der ersten Zeile des Beispiels wird die Nummer für die verwendete XML-Version angegeben. Darauf folgt in der nächsten Zeile die Angabe welcher Dokumententyp zu verwenden ist. Dieser kann entweder –wie im Beispiel– direkt angegeben sein, oder aber in einer gesonderten Dokumententyp-Definition-Datei (DTD-Datei) ausgelagert sein.
Im der DTD wird angegeben, wie ein Tag zu interpretieren ist. In diesem Fall werden die beiden neuen Tags <gruss> und <inhalt> mittels der Angabe <!ELEMENT * #PCDATA> als Textfelder definiert.
Die XML-Spezifikation enthält weit mehr Element-Typen. So lassen sich alle HTML-Tags durch XML-Definitionen festlegen: XML ist somit eine Oberklasse von HTML. Aufgrund der Erweiterbarkeit und Plattformunabhängigkeit von XML bietet es sich als universelles Speicherformat für Datensätze an. So zeigt das folgende Beispiel, wie ein Benutzerdatensatz aussehen könnte:

Quellcode 3. XML-Beispiel 2

Ein weiterer Vorteil von XML ist der, daß die neuste Generation der Webbrowser (Internet Explorer 5.0, Netscape 6.0 ) in der Lage sind, XML-Dateien zu lesen und entsprechend der DTD anzuzeigen.

3. CGI

CGI steht für Common Gateway Interface und definiert einen standardisierten Weg, Daten aus einem HTML-Formular an einen Webserver zu übertragen, welcher wiederum mit diesen Daten als Argument einen neuen Prozeß (CGI-Programm) startet.
CGI Mechanismus Die Abbildung zeigt dieses Schema. Aus einer HTML-Seite werden die Daten eines Formulars zuerst an den Webserver geschickt. Dieser ruft als nächstes ein CGI-Programm auf und übergibt diesem die eingegebenen Daten.
Das CGI-Programm verarbeitet diese Daten und übergibt dem Webserver als Antwort entweder Statusinformationen oder, im häufigsten Fall, den Content-Type und den Inhalt einer neuen Seite. Mit Hilfe von CGI-Programmen lassen sich komplexe Funktionen auf einer Website realisieren, angefangen bei dem einfachen ausfüllen und speichern eines Formulars, bis zu CGI-Programmsystemen mit denen Server konfiguriert und gesteuert werden können. Da bei CGI nur die Art der Datenübergabe geregelt ist, ist die Programmiersprache, die für das CGI-Programm verwendet wird, nicht festgelegt. Das CGI ist somit weitgehend plattformunabhängig. Da ein CGI-Programm auf dem Server ausgeführt wird, auf dem das aufgerufene CGI-Programm liegt, ist es unabhängig davon, welchen Browser oder welches Betriebssystem der Benutzer, also die Person, die es ausführt, verwendet. Ein einführendes Tutorial zu CGI befindet sich im CGI-Teil dieser Website.

4. SSI

Mit Hilfe von SSI, d.h. „Server-Site Includes“ lassen sich Befehle innerhalb einer HTML-Seite einbauen, die vom Webserver ausgeführt werden. Im Normalfall handelt es sich bei diesen Befehlen um dynamische Ausgaben, wie z.B. die Systemzeit oder die Kennung des verwendeten Browsers. Es lassen sich jedoch auch Programme starten und deren Ausgabe in die Datei einbetten. Da SSI-Befehle vom Webserver ausgeführt werden, „sieht“ der Benutzer diese in der Regel nicht: Der Webserver verarbeitet diese Befehle zuerst und zeigt dann die Ergebnisse innerhalb der vom Benutzer angeforderten Webseite an.
SSI ist technisch als Ergänzung zu HTML zu verstehen, um den Zugriff auf CGI-Programmen zu vereinfachen. Ebenso wie bei CGI ist SSI unabhängig davon, welcher Browser oder welches Betriebssystem vom Benutzer genutzt wird.
Eine Übersicht zu SSI findet sich im CGI-Teil dieser Website.

5. PHP

Ähnlich wie SSI arbeitet PHP. PHP steht für „Hypertext Preprocessor“ und ist eine serverseitig interpretierte Skriptsprache, welche in den HTML-Quellcode eingebunden werden kann. PHP hat eine ähnliche Syntax wie C, Java und Perl, hat jedoch zusätzlich einige Features wie z.B. Kommandos zum Zugriff auf Datenbanken.
PHP kann sowohl über ein Modul in die Seite integriert werden als auch als CGI aufgerufen werden. Der folgende Quellcode zeigt ein Beispiel, wie ein PHP-Aufruf in HTML eingebunden wird:

Quellcode 4. PHP-Beispiel

Bei der Anforderung der obigen Datei durch einen Benutzer wird der Webserver diese zuerst lesen, den PHP-Teil (im Beispiel blau markiert) interpretieren, d.h. den PHP-Teil durch dessen Ausgabe ersetzen und die Seite mit dem interpretierten Inhalt an den Benutzer weiterleiten. Ein Tutorial, sowie weitere Informationen zu PHP finden sich auf der Webseite vom PHP-Center.

6. Java

Java wurde seit 1990 von SUN entwickelt und 1995 der Öffentlichkeit vorgestellt. Es handelt sich dabei um eine objektorientierte Programmiersprache mit deren Hilfe es möglich ist, interaktive Programme in Form eines „Applets“ in einem Browser ablaufen zu lassen. Ein Applet ist ein Programm, welches innerhalb der HTML-Seite eingebunden wird [Zitat: „Contentmanagement für das Intranet des Klinikums der Universität Erlangen-Nürnberg“, Stephan Raabe, Studienarbeit, Lehrstuhl Betriebssysteme].
Java ist plattformunabhängig: Das eigentliche Programm wird auf dem Quellrechner vorkompiliert und die Referenz darauf im HTML-Quellcode eingebunden. Bei einem Aufruf wird das Javaprogramm mittels der auf dem Ziel-Rechner befindlichen „Java Virtual Machine“ (JVM) lauffähig gemacht und gestartet. Die JVM ist auf jedem Betriebssystem installierbar und verarbeitet den vorkompilierten Bytecode des Quellrechners, um daraus einen Maschinencode zu machen, der vom Zielrechner ausgeführt werden kann [Zitat: „Web Professional“, Rainer Kolbeck, Interest Verlag, 1998, ISBN 3-8245-0402-2].

7. JavaScript

JavaScript ist eine Entwicklung der Firmen SUN und Netscape. Im Gegensatz zu den anderen hier aufgeführten Techniken, wird JavaScript vollständig Browserseitig ausge-führt. Das bedeutet, daß JavaScript nicht durch den Webserver, auf dem die Seite liegt, ausgeführt wird, sondern durch den Browser auf dem Rechner des Benutzers.
JavaScript lehnt sich in der Syntax an Java an, wird allerdings nicht vorkompiliert und ist eine Skriptsprache. Der JavaSkript-Quellcode wird dabei direkt in die HTML-Seite eingebunden.

Quellcode 5. JavaScript-Beispiel

Das Beispiel aus Quellcode 5 zeigt das Vorgehen. Im Beispiel wird als Ergebnis der String „Welt!“ mit Hilfe von JavaScript ausgegeben, so daß letztlich im Browser der Text „Hallo Welt!“ zu sehen ist [Aus: „JavaScript – 7-Tage-Crashkurs“, Arman Danesh, Markt&Technik, 1996, ISBN 3-8272-5176-1].
Damit JavaScript ausgeführt werden kann, muß der Browser des Benutzers dieses verstehen bzw. die JavaScript-Funktion eingeschaltet haben. Da JavaScript jedoch schon weit verbreitet ist und von über 90% aller Browser verstanden wird, hat sich diese Technik weitgehend etabliert.

8. ASP

ASP heißt „Active Server Pages“. Es ist eine Technik vergleichbar mit CGI und PHP, wobei es jedoch eine Eigenentwick-lung von Microsoft ist. ASP läßt sich derzeit fehlerfrei nur auf den Webserver Microsoft-IIS ausführen, hat dafür aber auch Zugriff auf Funktionen, die mittels der Skriptsprache ActiveX® implementiert sind [Siehe auch: ASP-Forum, http://www.asp-forum.de]. Aufgrund von Sicherheitsproblemen, insbesonders bei der Nutzung von ActiveX®, sowie der Beschränkung auf den Webserver, geht die Nutzung von ASP derzeit stark zurück.
Ähnlich wie PHP, kann es in Webseiten durch eine umrandende Markierung eingebunden werden. Man verwendet hier die Kennzeichnung durch <% … %>.

9. Sonstiges

Weitere Techniken, die benutzt werden können, sind DHTML („Dynamic HTML“), CSS („Cascading Style Sheets“), Shockwave, ActiveX® und VRML („Virtual Reality Modelling Language“). Diese spielen jedoch bei der Implementierung von interaktiven Webseiten eine geringe Rolle. Besonders CSS und DHTML werden zwar häufig angewendet, jedoch liegt ihre Bedeutung mehr darin, das Design einer Seite zu bestimmen und nicht aktiv einen Mechanismus zu steuern.
Ein Vergleich der meisten der oben genannten Techniken mit einer Trennung auf serverseitige und clientseitige Techniken findet sich im Artikel Interaktive Mechanismen für Webseiten.

10. Akzeptanz und Nutzung der Webtechniken

Da ein nicht unerheblicher Zeitaufwand bei der Implementierung von interaktiven Webseiten für die Unterstützung der oben angesprochenen Techniken benötigt wird, stellt sich die Frage, inwieweit diese überhaupt genutzt werden.
Derzeit gibt es jedoch in dieser Richtung nur wenige Forschungsberichte, bzw. bewerten diese nicht direkt die benutzten Techniken, sondern nur das Surfverhalten der Benutzer [Siehe hierzu auch: „Studie. Websites vergraulen Surfer“, c’t Bericht zur Studie des Forschungsschwerpunkts Kommunikation an der FH Düsseldorf, Juli 2000].
Abschätzungen über die Nutzung von JavaScript oder CSS auf publikumsstarken Websites sprechen zwar von einer Nutzung von über 80%, jedoch muß dies nicht für alle Seite gelten. Man hat hier das Problem, daß Websites, die von größeren Unternehmen oder Online-Dienstleistern angeboten werden, eine hohe Änderungs- und Verbesserungsrate haben, während einfache Homepages oder Seiten bei denen nur wenige Benutzer auftreten kaum mit neueren Techniken versehen werden. Auch in diesem Punkt spielen Image-Überlegungen der Unternehmen eine große Rolle und wieviel Geld diese für eine akkurate Pflege der Website ausgeben.

Auswertung der Umfrage In Form einer Online-Umfrage wurde versucht eine Abschätzung darüber zu erhalten, welche der angegebenen Techniken am häufigsten von Webdesignern und Programmierern eingesetzt wird. Die Umfrage fand vom 22.5.2000 bis zum 5.6.2000 auf xwolf.com statt und erfaßte die Meinungen von 405 Personen zu der Frage: „Welches ist Ihre bevorzugte Programmiersprache zur Gestaltung dynamischer Webseiten?“.
Aus den Ergebnissen nach (siehe Abbildung) erkennt man, daß CGI, JavaScript und PHP am häufigsten genutzt werden, während ASP und sonstige Techniken keine große Rolle mehr spielen.

Anmerkung:

Dieser Artikel ist ein Auszug aus meiner Diplomarbeit „Konzeption und Realisierung eines Web-Content-Management-Systems am Beispiel des Rechenzentrums Erlangen-Nürnberg“, welche über die Diplomarbeitenbörse Diplom.de käuflich erwerbbar ist.

Flattr this!