In HTML-Seiten kann man kleine Programme einbetten, die in Javascript (von
Netscape eingeführt) bzw. dem dazu halbwegs kompatiblen JScript (Microsoft)
geschrieben sind. Eine weitere Alternative ist das allerdings nur von
Microsoft-Browsern unterstützte VBScript, das an Visual Basic angelehnt ist.
Man kann solche Programme so in HTML einbetten, dass der Browser (der Client)
das eingebettete Programm interpretiert und beispielsweise dynamisch neue
Fenster öffnet oder Eingaben überprüft. Alternativ kann auch der Web-Server
selbst Programmstücke in HTML-Seiten interpretieren. Bei Microsoft nennt man
solche Seiten ASP (Active Server Pages). Ferner wird auf Web-Servern oft die
Script-Sprache Perl eingesetzt, beispielsweise zur Verarbeitung von
Formular-Eingaben oder, wie bei ASP oder PHP, zur Generierung dynamischer
Seiteninhalte. Server-Side Includes (SSI) sind eine weitere einfache
Möglichkeit zur dynamischen Seitengestaltung.
Javascript ist die derzeit am häufigsten eingesetzte client-seitige
Programmiersprache. Das folgende Beispiel ist in dieser Sprache geschrieben und
erzeugt beim Anklicken von diesem Link
einfach ein kleines Fenster mit dem Text "Hallo Welt!".
Der übliche Beginn einer HTML-Datei: <html><head><title>Test</title>
</head><body>
Eine kleine Javascipt-Funktion, die eine Message-Box mit OK-Knopf öffnet: <script type="text/JavaScript"><!--
function fenster()
{ alert("Hallo Welt!"); }
// --><script>
Dieser Text wird angezeigt, wenn der Benutzer Javascript deaktiviert hat: <noscript><p>
Sie haben Javascipt ausgeschaltet!
</p></noscript>
Ein Text als Link, der die Fenster-Funktion aufruft: <p><a href="javascript:fenster()">
Bitte hier klicken!</a><p>
Das übliche HTML-Ende: </body></html>
Das kleine Javascript-Programm ist für Browser, die noch keine
Script-Sprachen verstehen, in Kommentar-Anweisungen zwischen <!-- und -->
eingebaut, so dass sie keinen Unsinn anzeigen. Da sie auch die Anweisung <noscript>
nicht verstehen, wird von Ihnen der zwischen <noscript> und </noscript>
stehende Text angezeigt. Dasselbe passiert, wenn man in einem modernen Browser
Javascript abschaltet.
Die zwei Schrägstriche (//) am Beginn der ersten Zeile nach dem
Javascript-Code sorgen dafür, dass diese Zeile vom Script-Interpreter als
Javascript-Kommentar aufgefasst wird, so dass er nicht auf die Idee kommt, das
darauffolgende HTML-Tag "-->", das den HTML-Kommentar beendet, zu
interpretieren, was zu einer Fehlermeldung führen würde.
Der Code wird in der HTML-Datei genau an der Stelle ausgeführt, an der er
steht, und natürlich auch zu dem Zeitpunkt, zu dem der entsprechende Teil der
HTML-Datei geladen wird. Deshalb muss ein Javascript-Programm, das auf weiter
hinten stehende HTML-Elemente der Seite bezug nimmt, etwa auf Anker (lokale
Link-Ziele innerhalb der Datei) oder Formular-Felder, entweder am Ende der
Datei stehen oder als Funktion mit <body onload="funktion( )"> im
body-Tag der HTML-Seite erst dann aufgerufen werden, wenn die Seite vollständig
geladen ist.
Es kann beliebig viele Javascript-Abschnitte in einer HTML-Datei geben. Man
kann auch mitten in der Seite einen per Javascript generierten Text einfügen,
z.B. so:
Eine nützliche Anwendung von Javascript ist auch das automatische Nachladen
von Frames, wenn ein Benutzer z.B. von einer
Suchmaschine kommend nur eine einzelne Datei des Framesets aufruft und ihm
dadurch die im Frameset vorhandenen Navigations-Möglichkeiten zunächst fehlen.
In jeder Teildatei braucht dazu nur folgendes enthalten zu sein, wobei
frame.htm in diesem Beispiel die Frameset-Definition enthält:
<script type="text/JavaScript"><!--
if (parent.frames.length<1) location.replace("frame.htm");
// --></script>
Der Javascript-Code braucht nicht unbedingt in der HTML-Datei selbst
enthalten zu sein. Es ist auch möglich, ihn in einer getrennten Datei
zu speichern, typischerweise mit der Endung .js, und in den HTML-Code folgende
Zeile einzubauen (file1.js ist hier natürlich nur ein Beispielname): <script type="text/JavaScript" src="file1.js" type="text/javascript"></script>
Javascript-Programme sind case-sensitiv, d.h. die Befehle
müssen exakt mit Klein- und Großbuchstaben geschrieben werden (z.B. indexOf,
charAt und so weiter). Javascript ist eine objektorientierte Sprache;
Objekte wie Fenster oder Frames haben "Eigenschaften", die bestimmte
Eigenschaften des Objekts beschreiben oder verändern können, und es gibt
"Methoden", die irgend etwas mit den Objekten tun. So kann man etwa mit der
Anweisung window.location.href="www.telekom.de/"; den Browser veranlassen, die Eigenschaft href (die Adresse) des
Objekts location auf die Telekom-Homepage zu setzen und somit zu ihr
zu springen. location ist seinerseits ein Objekt, das in der
Hierarchie unterhalb des window-Objekts liegt, also zum jeweils
offenen Browser-Fenster gehört.
Javascript benutzt Variant-Variablen, das bedeutet, eine
Variable hat keinen bestimmten Typ, sondern kann entweder eine Zahl oder eine
Zeichenfolge aufnehmen. Variablen brauchen vor der Verwendung nicht deklariert
werden, wenngleich das mit der Anweisung var durchaus möglich ist und der
Übersichtlichkeit dient. Anweisungen müssen, wenn in derselben Zeile weitere
folgen, mit einem Semicolon enden; man kann sich das aber auch
zur generellen Gewohnheit machen.
Wie auch zu HTML gibt es im Web und in Buchform eine ganze Reihe von
Abhandlungen zu Javascript bzw. JScript, nicht zuletzt natürlich von Netscape
und Microsoft, so dass an dieser Stelle auf eine ausführliche Sprach-Referenz
verzichtet wird.
Java hat trotz des ähnlichen Namens wenig mit Javascript
gemein. Diese Sprache, die in Applets (Code, der im Browser ausgeführt wird)
und Servlets benutzt wird (Code, der auf dem Server ausgeführt wird), wird
nicht wie Javascript zur Laufzeit als Quelltext interpretiert, sondern während
der Entwicklung in in einen effizienten Zwischencode (Byte-Code) vorcompiliert,
der wesentlich schneller ausgeführt werden kann. Dafür benötigt man allerdings
eine eigene Entwicklungsumgebung, weshalb Java trotz seiner Bedeutung an dieser
Stelle nur am Rande erwähnt wird.
Durch Verbinden von Javascript und Java - Netscape
nennt das Liveconnect - kann man Dinge tun, die von manchen
gutgläubigen Menschen für unmöglich gehalten werden, so etwa das Ermitteln der
E-Mail-Adresse. Ein Beispiel, das so allerdings nur mit Netscape-Browsern
funktioniert:
Wenn man diesen Code als HTML-Datei speichert, sie in den Netscape-Browser
lädt und auf den enthaltenen Link "Test" klickt, wird nach einer
(abschaltbaren) Sicherheitsabfrage die E-Mail-Adresse des Benutzers in einem
Message-Fenster angezeigt.
Das Programm funktioniert nur als lokale Datei. Versucht man, es mit einer
http-Adresse von einem Web-Server auszuführen, bricht der Browser die
Ausführung sofort ab. Es gibt allerdings bei einigen Browser-Versionen
Methoden, die diese Sperre aushebeln.
VBScript
VBScript ist eine von Visual Basic abgeleitete Programmiersprache, die früher
vom Microsoft Internet Explorer interpretiert wurde (seit Version 11 nicht
mehr; Microsoft empfiehlt den Umstieg auf Javascript). Das Einbetten von
VBScript-Programmen in HTML funktioniert grundsätzlich genauso wie bei
Javascript:
<script type="text/VBScript"><!--
sub vbfenster()
msgbox "Hallo Welt!"
end sub
' --></script>
Und so lässt sich die Funktion im HTML-Code durch einen Button aufrufen:
Ein Unterprogramm ohne Rückgabewert wird in VBScript mit sub
eingeleitet und mit end sub beendet. Statt alert heißt die
Anweisung zum Anzeigen eines Meldungsfensters hier msgbox. Die Zeile
unter end sub beginnt mit einem Apostroph, da dies in Visual Basic das
Zeichen für einen Kommentar darstellt und der Rest der Zeile so vom Interpreter
ignoriert wird.
Perl und CGI
Die Programmiersprache Perl (Practical Extraction and Report
Language) wird im Gegensatz zu Javascript, JScript und VBScript ausschließlich
auf dem Web-Server ausgeführt. Die Ausgabe eines Perl-Programms erfolgt
entsprechend dem CGI-Standard (Common Gateway Interface) über
die Standard-Ausgabe (STDOUT) des jeweiligen Betriebssystems. Sie wird vom
Web-Server zum Browser z.B. als HTML-Seite durchgereicht.
Umgekehrt kann ein Perl-Programm Eingaben von einem
Formular auf einer Web-Seite mit <form action="get"> über die
Environment-Variable QUERY_STRING oder mit <form action="post"> über
die Standard-Eingabe (STDIN) übernehmen. Damit das Programm bei STDIN weiß, wo
die Daten zu Ende sind, wird die Datenlänge zusätzlich in der
Environment-Variablen CONTENT_LENGTH übergeben. Der vom Perl-Programm dadurch
erhaltene Übergabe-String enthält jeweils durch "&" getrennt die Namen und
Werte der im Formular enthaltenen Elemente, hier "Textfeld" und "Button";
Leerzeichen in übergebenen Strings werden durch "+" ersetzt, Umlaute durch %XX
als Hex-Code.
Wenn der Client-Browser ein Perl-Programm auf dem Web-Server aufruft, muss
das Perl-Programm eine vollständige HTML-Seite inklusive eines Mindest-HTTP-Headers
als Antwort zurückliefern. Der HTTP-Header gibt den Informationstyp an (meist
text/html), danach folgen zwei Zeilenumbrüche als
Header-Endekennzeichen (\n\n), und schließlich der HTML-Text der Ergebnisseite.
Jedes Perl-Programm beginnt mit einer Zeile wie dieser: #!/usr/bin/perl Sie nennt dem Web-Server das Verzeichnis (hier /usr/bin/perl), wo er
einen geeigneten Interpreter für die Perl-Datei finden kann. Im sonstigen
Script-Text dient die Raute # zur Kennzeichnung von Kommentaren.
Ohne auf Details einzugehen, sei hier als Beispiel ein Perl-Programm
vorgestellt, das dem Besucher der Seite sagt, welcher Typ von Web-Server hier
läuft, über welchen Internet-Provider die Verbindung aufgebaut wurde, welchen
Browser-Typ der Client benutzt und ein paar interessante Dinge mehr. Die letzte
Anweisung "exit(0)" sagt dem Web-Server, dass das Programm erfolgreich beendet
wurde.
Perl-Programme werden auf dem Web-Server meist in einem Unterverzeichnis
/cgi-bin gespeichert. (Alle Dateiangaben und Seiten-Referenzen
im Script müssen entweder relativ zu diesem Verzeichnis oder absolut mit
vorangestelltem Schrägstrich erfolgen!) Nach dem Übertragen des Programms,
nennen wir es environ.pl, muss man bei einem unter Unix oder Linux laufenden
Web-Server meist noch dafür sorgen, dass die Datei das Attribut "ausführbar"
enthält. Dies erreicht man durch folgende Unix-Anweisung:
chmod +x environ.pl
Falls Ihr FTP-Programm numerische Werte für die Dateiattribute zulässt,
geht es gewöhnlich so: chmod 755 environ.pl In FTP-Programmen mit ankreuzbaren Datei-Attributen muss die Einstellung
so lauten:
chmod
Owner
Group
Other
Read
x
x
x
Write
x
Execute
x
x
x
Eine mögliche Falle ist noch, dass die Perl-Datei auf Unix-Rechnern
nur Line Feeds als Zeilentrennung enthalten darf. Wenn Sie das
Perl-Programm auf einem Windows-Rechner erstellt haben, der CR+LF zwischen den
Zeilen benutzt, achten Sie darauf, beim FTP-Programm
den ASCII-Modus zu benutzen, der die CR-Steuerzeichen
entfernt.
Perl-Programme müssen nicht notwendigerweise Textausgaben zurückliefern. Das
folgende Beispiel-Script, nennen wir es showgif.pl, liefert beim Aufruf aus
einer HTML-Seite mit <img src="cgi-bin/showgif.pl"> die Bilddatei
bild.gif zurück:
#!/usr/bin/perl
print "Content-Type: image/gif\n\n"; # HTTP-Header+Leerzeile
open IN, "/pic/bild.gif" || die; # Pfad relativ zu /cgi-bin!
while( <IN> ) { print; } # Gibt den Inhalt der Bilddatei aus
close IN; exit (0);
Während die obigen Beispielprogramme noch halbwegs verständlich sind, sei
nicht verschwiegen, dass man zahlreichen Perl-Konstrukten kaum ansieht, was sie
eigentlich tun, und das Programmieren in Perl ist sicher eine der
anspruchsvolleren Aufgaben für einen Web-Designer.
Server-Side Includes (SSI)
Eine ganz einfache Methode, auf dem Web-Server Informationen dynamisch in
eine HTML-Seite einzufügen, sind Server-Side Includes. Solche HTML-Dateien
müssen bestimmte Datei-Endungen haben (typisch .shtml oder
.sht), damit der Server weiß, dass er bestimmte Schlüsselworte
darin als Anweisungen interpretieren darf. Diese sind im Text als
HTML-Kommentare eingebunden, so dass sie nur vom Server beachtet und vom
Browser ignoriert werden. Ein paar Beispiele:
<!--#config errmsg="Syntaxfehler"--> SSI-Fehlermeldung festlegen <!--#config timefmt="%d.%m.%Y %H:%M"--> Zeitausgabeformat festlegen <!--#config sizefmt="bytes"--> Dateilängen in Bytes azeigen <!--#config sizefmt="abbrev"--> Dateilängen in KByte anzeigen <!--#fsize file="test.zip"--> Anzeige der Länge einer Datei <!--#echo var="DATE_LOCAL"--> Ausgabe der lokalen Zeit <!--#echo var="DATE_GMT"--> Ausgabe der Weltzeit (GMT) <!--#echo var="LAST_MODIFIED"--> Änderungsdatum der akt. Datei <!--#flastmod file="index.htm"--> Änderungsdatum einer and.Datei <!--#include virtual="teil2.htm"--> Fügt den Inhalt einer Datei ein <!--#exec cmd="bin/search.exe *.htm"--> Startet eine ausführbare Datei <!--#exec cgi="/cgi-bin/environ.pl"--> Führt ein CGI-Programm aus <!--#printenv --> Environment-Variablen anzeigen <!--#set var="x" value="abc" --> Setzt einen Variablen-Wert
Zusätzlich gibt es auch noch die Möglichkeit von Bedingungen nach dem Schema
if, elif (else-if) und else:
<!--#if x="wert1" --> Bedingung 1 ist erfüllt <!--#elif x="wert2" --> Bedingung 2 ist erfüllt <!--#else --> Keine der obigen Bedingungen trifft zu <!--#endif --> Ende der bedingten Anweisungen
Die Ausgabe des vom SSI-Element erzeugten Textes erfolgt genau an der Stelle
der HTML-Datei, an der das Element steht. Allerdings sind Server-Side Includes
aus Sicherheitsgründen nicht auf allen Web-Servern freigeschaltet. Darüber
hinaus unterscheiden sich die zur Verfügung stehenden SSI-Anweisungen je nach
Server-Software erheblich. Die obige Liste gilt deshalb ausschließlich für
Apache-Server ab Version 1.2. Andere Server benutzen zum Teil
eine andere Syntax.
PHP
Ähnlich wie Perl wird die Script-Sprache PHP auf dem
Web-Server ausgeführt, und ähnlich wie bei SSI wird der
PHP-Code in HTML eingebettet. Der Server erkennt PHP-Seiten an ihrer
Dateiendung (je nach Version z.B. .php3 oder .php4). Im HTML-Code beginnen
PHP-Anweisungen mit <? oder <?php und enden mit ?>. Der Server sendet die
PHP-Abschnitte nicht an den Browser des Benutzers, sondern interpretiert sie.
Beispiel für einen Abschnitt einer Web-Seite, die die Browser-Version des
Benutzers anzeigt:
Ihr Browser: <?php echo $HTTP_USER_AGENT; ?>
Die folgende Sequenz gibt einen passenden Text aus, wenn der Benutzer einen
Internet Explorer von Microsoft verwendet:
<?php
if (strstr($HTTP_USER_AGENT,"MSIE"))
{ echo "Sie benutzen den Internet Explorer.<br>"; }
?>
Da PHP einen wesentlich größeren Befehlsumfang als SSI besitzt, ist seine
Leistungsfähigkeit mit Perl vergleichbar, besitzt aber den Vorteil, dass es wie
SSI direkt in HTML-Seiten integriert werden kann. Eine besondere Stärke ist
auch die Möglichkeit von Datenbank-Zugriffen (SQL).
Cookies
Was haben Cookies mit Script-Sprachen zu tun? Nun, man benutzt gewöhnlich
Scripts, um Cookies zu schreiben oder zu lesen, deshalb werden sie im Abschnitt
über Script-Sprachen erwähnt.
Was ist ein Cookie? Eine Textzeile einer Datei im Browser-Verzeichnis Ihres
Computers, die HTTP- oder script-gesteuert erzeugt und gelesen werden kann und
einer bestimmten Web-Adresse zugeordnet ist. Darin kann sich ein Web-Server
irgendwelche Dinge merken, bis man ihn irgendwann erneut besucht. Zum Beispiel
kann der Server Ihre auf einer Mitteilungs-Seite einmal eingegebene
Mail-Adresse in einem Cookie auf Ihrem PC speichern, damit das entsprechende
Feld beim nächsten Besuch derselben Seite automatisch passend ausgefüllt wird.
Manche Web-Server benutzen Cookies auch, um die Zahl unterschiedlicher
Besucher festzustellen. Dazu wird beim ersten Besuch der Seite einfach ein
Cookie gespeichert, sein Name ist meist WEBTRENDS_ID. Ein neuer Besucher ist
dann einfach einer, bei dem dieses Cookie noch fehlt. Dadurch kann man die
"echte" Besucherzahl besser von der Zahl der Seitenabrufe unterscheiden. (Da
viele Anwender Cookies im Browser allerdings deaktiviert haben, ist der
Mechanismus etwas fragwürdig.)
Cookies sind im Prinzip ungefährlich, in der Größe auf 4 KByte begrenzt und
können keinen ausführbaren Code, sondern nur einfache Wert-Zuweisungen
enthalten, zum Beispiel "Vorname=Albert" oder "Mail=abc@example.com". Es ist
einem Web-Server normalerweise nicht möglich, Cookies auszulesen, die von einem
Server mit einem anderen Domain-Namen erzeugt wurden. Bedenken sollte man
allerdings, dass viele Server Werbe-Grafiken von einer anderen Domain laden,
die dann ebenfalls Cookies speichern kann, wenn die Grafik mit einem
CGI-Script realisiert wird.
Wenn ein Web-Server den Browser veranlassen will, ein Cookie zu speichern,
liefert er im HTTP-Header zusätzlich eine Zeile
"Set Cookie": Set-Cookie: Name=Wert; path=/; expires=Mon, 09-Dec-2002 13:46:00 GMT
"Name" steht dabei für den Namen des Cookies, "Wert" für einen numerischen
oder alphanumerischen Wert, "path" gibt an, welche Seiten (hier alle derselben
Domain) später auf das Cookie zugreifen dürfen, und "expires" sagt dem Browser,
wann er das Cookie wieder löschen darf. Wenn expires=... fehlt, wird das Cookie
nur bis zum Beenden des Browsers gespeichert.
Wenn der Browser später den Inhalt eines Cookies zum Server schickt, sendet
er ebenfalls einen HTTP-Header, in dem ebenfalls zusätzlich der Cookie-Name und
sein Wert stehen: Cookie: Name=Wert
In Perl kann man Cookies ganz leicht erzeugen, da ein
Perl-CGI-Programm auf dem Server den HTTP-Header selbst generiert; somit kann
man auch "Set-Cookie: ..." hineinschreiben. Das Lesen von Cookies erfolgt in
Perl über die Environment-Variable $ENV{'HTTP_COOKIE'}, sie liefert das
Ergebnis wieder in der Form Name=Wert.
In Javascript oder VBScript
kann ein Cookie ganz einfach mit Hilfe von document.cookie gelesen
oder geschrieben werden. Die Anweisung zum Schreiben kann zum Beispiel so
aussehen: document.cookie="Name=Wert; path=/; expires=Mon, 01-Jan-2001 00:00:00 GMT"
Ob ein Cookie zur eigenen Domain bzw. Seite existiert, kann man einfach mit
if (document.cookie) abfragen. Das Lesen erfolgt wieder durch Auslesen
des Werts von document.cookie, wobei man eine Zeichenfolge der Form
Name=Wert erhält. Wenn Cookies im Browser deaktiviert sind, führen diese
Anweisungen nicht zu einer Fehlermeldung, sondern werden einfach ignoriert.
Falls dieselbe Domain mehrere Cookies erzeugt hat, werden sie in der Form Name1=Wert1; Name2=Wert2; Name3=Wert3
gemeinsam zurückgeliefert, zum Beispiel: Vorname=Albert; Nachname=Einstein; Mail=albert@example.com
Um ein Cookie scriptgesteuert zu löschen, kann man entweder seinen Wert auf
einen Leerstring setzen oder das Verfalldatum auf einen Wert in der
Vergangenheit ändern. Um dagegen alle Cookies des Browsers manuell zu löschen,
muss man bei Netscape die Datei Cookies.txt löschen und beim Microsoft
Internet Explorer alle Dateien im Windows-Unterverzeichnis Cookies
entfernen, nachdem man den Browser beendet hat.
Mobiles Webdesign
Rückblick: WAP, WML, XHTML
Mobile
Geräte, insbesondere GSM-Handys, benutzten früher meist ein spezielles
Verfahren zum Internet-Zugang, das an ihre begrenzten Speicher- und
Prozessor-Möglichkeiten angepasst ist, das "Wireless Application Protocol"
(WAP). Für die an das sehr kleine Display der sog. Feature-Phones angepassten
Internet-Seiten wurde ursprünglich die "Wireless Markup Language" (WML)
erfunden: In den Gateway-Rechnern der GSM-Netzbetreiber wurden WML-Seiten aus
dem Internet vor dem Senden ans Endgerät komprimiert; dabei wurden die WML-Tags
wie etwa <p> jeweils in einen 1-Byte-Code übersetzt, um Übertragungszeit zu
sparen. WAP 1.0/1.1/1.2 und das dazugehörige WML haben sich allerdings trotz
anfänglicher Erfolge nicht auf breiter Front durchsetzen können.
Später wurde mit WAP 2.0 ein neuer, dem herkömmlichen HTML (oder genauer:
XHTML) wesentlich ähnlicherer Standard entworfen. XHTML ist eine in eine
XML-Struktur eingebettete HTML-Variante. Wesentliche Eigenschaften sind:
Bei XHTML müssen Elemente, für die es kein getrenntes Abschluss-Tag wie
etwa </p> gibt, implizit abgeschlossen werden, z.B. <br />.
In XHTML müssen alle Tags klein geschrieben werden - also z.B. <p> statt
<P>.
Es ist eine XML- und eine Dokumenttyp-Deklaration nötig.
Der Webserver sollte als Content-Type application/xml+xhtml statt text/html
ausgeben (das wird allerdings bisher nicht konsequent eingehalten, da der
Microsoft Internet Explorer - auch dessen PDA-Version - dann leider ein
Download-Fenster öffnet, statt die Seite anzuzeigen).
WAP-2.0-Seiten sollten ferner grundsätzlich UTF-8 als Codierung verwenden;
beispielsweise werden deutsche Umlaute dabei in einem 2-Byte-Code dargestellt.
In Perl ist die Umwandlung von ISO-8859-1 in UTF-8 ein
kompakter Einzeiler: $text=~s/([\x80-\xFF])/chr(0xC0|ord($1)>>6).chr(0x80|ord($1)&0x3F)/eg;
Hier ist als kleines Beispiel das Gerüst einer typischen WAP-2.0-XHTML-Datei:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN"
"http://www.wapforum.org/DTD/xhtml-mobile10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta name="description" content="Aktuelle Informationen />
<title>News (PDA)</title></head><body>
<h1>News</h1><p>Test<br />Dies ist Blindtext ohne Bedeutung.</p>
</body></html>
Stand
der Technik: Mobiles HTML
Heute gelten WAP, WML und das mobile XHTML als veraltet. Moderne
Mobil-Browser in Smartphones und Tablet-PCs verstehen ganz normales HTML.
Generell gelten aber für Inhalte, die auf mobilen Endgeräten gut und schnell
darstellbar sein sollen, folgende Empfehlungen:
Frames sollten überhaupt nicht und Tabellen nur im Notfall verwendet
werden.
Tabellen sollten nicht breiter sein als die minimale Pixelbreite von
Endgeräten (typisch 320 Pixel).
Bilder sollten relativ klein sein; in jedem Fall muss das <img..>-Tag
Angaben zu Breite und Höhe enthalten.
Ansonsten sollten Pixelbreiten-Angaben etwa in Tabellenspalten oder
DIV-Abschnitten vermieden werden.
Flash-Inhalte scheiden generell aus - Adobe bietet Flash für Android nicht
(mehr) an.
Popup-Fenster sind strikt verboten; mobile Browser können keine
zusätzlichen Fenster darstellen.
Dynamische Seiten (PHP, ASP, Perl usw.) sollten HTTP-Caching-Infos liefern
und auswerten, z.B. Expires, Last-Modified usw.
Auf mobilen Geräten ist die Texteingabe oft sehr zeitraubend; sie sollte
nur im wirklichen Bedarfsfall nötig sein.
Die einzelnen HTML-Seiten sollten nicht größer sein als wenige KByte und
nicht allzu viele JS- oder CSS-Dateien nachladen.
Links, die zu herkömmlichen, nicht für mobile Geräte optimierten Seiten
führen, sollten entsprechend gekennzeichnet sein.
Beim Apache-Server kann man mit Hilfe einer Datei .htaccess dafür sorgen, dass mobile
Geräte eine andere Seite als Desktop-PCs oder Laptops angezeigt bekommen. Dabei
wird ein mobiler Browser mit einem User-Agent-String, der eines der Worte
"Android" oder "Phone" beinhaltet (z.B. iPhone, Windows Phone) beim Arufruf der
Domain ohne Dateiname dahinter automatisch zu einer Seite "pda.htm" umgeleitet.
Der Zusatz [NC] sorgt dafür, dass Groß- oder Kleinschreibung ignoriert wird:
# Root-Aufruf mobiler Geräte zu spezieller Seite umlenken
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} (Android|Phone) [NC]
RewriteRule ^$ %{DOCUMENT_ROOT}/pda.htm
Das ist allerdings stets nur eine Notlösung! Im Idealfall ist dieselbe
HTML-Seite durch ein entsprechend flexibles Layout (responsive design) auf
großen wie auf kleinen Bildschirmen gleichermaßen gut lesbar. Dafür darf es
allerdings keine allzu großen Elemente mit fester Breite geben, und größere
Bilder sollte man mit einer Stil-Angabe wie etwa style="max-width:100%; height:auto"
automatisch auf die verfügbare Bildschirmbreite skalieren - das hat auch den
Vorteil, dass eine u.U. höhere physikalische Auflösung mancher Geräte
entsprechend dem Pixelverhältnis (siehe unten) genutzt wird..
Beim Seiten-Design sollte man daran denken, dass mobile Geräte sehr
unterschiedliche Auflösungen haben können, und deshalb ein Layout mit festen
Pixel-Breiten vermeiden. Als allgemein akzeptables Mindestformat gilt bei
hochkant gehaltenen Smartphones eine Breite von 320 Pixeln (z.B. Sony X8, Apple
iPhone 3GS+4, LG Optimus One).
Dabei ist die physikalisch vorhandene Pixelzahl bei neueren Geräten oft um
den Faktor 1.325, 1.5 oder 2.0 höher (sog. Pixelverhältnis, device pixel
ratio). Wenn man beispielsweise erzwingen möchte, dass bei einem Gerät wie dem
Google Nexus 7 (2013) die Seite in gut lesbarer Schriftgröße mit der durch das
Pixelverhältnis vorgegebenen Skalisierung von 2 mit 600 x 960 Pixeln
dargestellt wird und nicht mit der nativen Display-Auflösung von 1200 x 1920
Pixeln, muss man im HTML-Header folgende Zeile ergänzen: <meta name="viewport" content="width=device-width">
Wenn diese Zeile fehlt, wird das Gerät einen deutlich größeren virtuellen
Bildschirm emulieren, auf dem die Schrift entweder zu klein ist, um lesbar zu
sein, oder man muss den Inhalt dauernd hin- und herschieben, um alles lesen zu
können. Die Viewport-Angabe macht aber nur dann Sinn, wenn der Rest der Seite
wirklich (auch) für Mobilgeräte optimiert ist.
Mobile
Geräte, insbesondere GSM-Handys, benutzten früher meist ein spezielles
Verfahren zum Internet-Zugang, das an ihre begrenzten Speicher- und
Prozessor-Möglichkeiten angepasst ist, das "Wireless Application Protocol"
(WAP). Für die an das sehr kleine Display der sog. Feature-Phones angepassten
Internet-Seiten wurde ursprünglich die "Wireless Markup Language" (WML)
erfunden: In den Gateway-Rechnern der GSM-Netzbetreiber wurden WML-Seiten aus
dem Internet vor dem Senden ans Endgerät komprimiert; dabei wurden die WML-Tags
wie etwa <p> jeweils in einen 1-Byte-Code übersetzt, um Übertragungszeit zu
sparen. WAP 1.0/1.1/1.2 und das dazugehörige WML haben sich allerdings trotz
anfänglicher Erfolge nicht auf breiter Front durchsetzen können.
Stand
der Technik: Mobiles HTML