edition W3C.de

HTML 4.01-Spezifikation

Deutsche Übersetzung

Diese Version:
http://www.edition-w3.de/TR/1999/REC-html401-19991224
Aktuelle Version:
http://www.edition-w3c.de/TR/html4
Übersetzer:
Christine Kühnel (Übersetzung, fachliche Kommentierung) <kuehnel@screenexa.net>
Stefan Mintert (Fachlektorat und fachliche Kommentierung) <www.mintert.com/stefan/mail/>
Stefan Schumacher (Übersetzung, fachliche Kommentierung) <sts@schumacher-netz.de>

Bei diesem Dokument handelt es sich um eine Übersetzung eines W3C-Textes. Dieser Text ist urheberrechtlich geschützt; bitte beachten Sie die nachfolgenden Hinweise des Originaldokuments. Die Rechte an der Übersetzung liegen bei den Übersetzern und dem Verlag Addison-Wesley. Die Übersetzung hat keine durch das W3C legitimierte, normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.

Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an die Übersetzer.

Kommentare der Übersetzer, die als solche gekennzeichnet sind, unterliegen dem Urheberrecht der Übersetzer. Sie sind nicht Bestandteil des Ursprungsdokuments.

Diese Veröffentlichung ist eine Vorveröffentlichung. Kein Teil dieses Textes darf kopiert werden. Alle Rechte vorbehalten. Nach Abschluss der Arbeit wird das endgültige Dokument unter der oben angegebenen Adresse veröffentlicht. Die jetzige Veröffentlichung während der laufenden Arbeit dient zur Information von Interessierten und zur Prüfung durch die Fachöffentlichkeit. Sollten Sie Fehler finden oder Verbesserungsvorschläge haben, schicken Sie diese bitte per Mail an die Übersetzer.
Folgende Teile liegen noch in Englisch vor und müssen noch in deutscher Fassung generiert werden: (a) Gesamtinhaltsverzeichnis (b) Index



Anhang B: Anmerkungen zur Performance, Implementierung und Gestaltung

Inhaltsverzeichnis

Die folgenden Anmerkungen sind informell, nicht normativ. Trotz auftauchender Wörter wie »muss« und »sollte«, erscheinen alle Anforderungen in diesem Abschnitt an anderer Stelle in der Spezifikation.

B.1 Anmerkungen zu ungültigen Dokumenten

Diese Spezifikation definiert nicht, wie konforme Benutzerprogramme allgemeine Fehlersituationen verarbeiten, einschließlich ihres Verhaltens, wenn sie Elemente, Attribute, Attributwerte oder Entities vorfinden, die nicht in diesem Dokument spezifiziert sind.

Um jedoch das Experimentieren und die Interoperabilität zwischen den Implementationen der verschiedenen HTML-Versionen zu vereinfachen, empfehlen wird das folgende Verhalten:

Zudem empfehlen wir, dass Benutzerprogramme eine Unterstützung dafür bieten sollten, den Benutzer über solche Fehler in Kenntnis zu setzen.

Anmerkung der Übersetzer:

Früher haben die bekannten Browser stillschweigend fast alles akzeptiert, was entfernt mit HTML zu tun hatte. Mittlerweile wird die Berücksichtigung von Standards langsam besser. Beim Mozilla wird das etwa dadurch erkennbar, dass er unter »Page Info« einen »Render Mode« anzeigt. Bei Dokumenten, die zum Beispiel gar keine DOCTYPE-Deklaration besitzen, steht dort: »Quirks Mode.« Bei ordentlichen Dokumenten: »Standards compliance mode.«

Page-Info im Mozilla

Auf den ersten Blick ist das keine große Sache – wer schaut schon die »Page Info« an? Interessant ist, dass der Mozilla sich auch unterschiedlich verhält: Einer der Übersetzer hatte auf seiner Site eine HTML-Seite, die schon lange »funktionierte«. Es befand sich jedoch ein kleiner Fehler darin, der dafür sorgte, dass die Seite nicht standardkonform war. Die Änderung war schnell erledigt, auch gleich der »Aufstieg« zu XHTML. Doch nach dem Neuladen im Browser waren alle Formatierungsanweisungen ausgeschaltet! Es dauerte eine Weile, bis der Grund klar wurde: Mozilla hat in den »Standards compliance mode« geschaltet. Doch leider wurde vom Server für die externe CSS-Datei der falsche MIME-Type »text/plain« im HTTP-Kopf geschickt. Die XHTML war völlig in Ordnung, die CSS-Datei auch, nicht aber die Server-Konfiguration. Mit »defektem« HTML-Code hat Mozilla diesen Fehler auch toleriert. Im »Standards compliance mode« lässt er sich offenkundig nicht alles bieten.

Weil Benutzerprogramme Fehlersituationen unterschiedlich behandeln können, dürfen sich Autoren und Benutzer nicht auf ein bestimmtes Fehlerbehebungsverhalten verlassen.

Die Spezifikation HTML 2.0 ([RFC1866]) beobachtet, dass viele HTML 2.0-Benutzerprogramme annehmen, dass sich ein Dokument ohne führende Dokumenttyp-Deklaration auf die Spezifikation HTML 2.0 bezieht. Wie die Erfahrung zeigt, ist das eine schwache These. Die aktuelle Spezifikation empfiehlt dieses Verhalten nicht.

Aus Gründen der Interoperabilität dürfen Autoren HTML nicht durch verfügbare SGML-Mechanismen »erweitern« (z.B. die DTD erweitern, einen neuen Satz von Entity-Definitionen hinzufügen und so weiter).

B.2 Besondere Zeichen in URI-Attributwerten

B.2.1 Nicht-ASCII-Zeichen in URI-Attributwerten

Auch wenn URIs keine Nicht-ASCII-Werte enthalten (siehe [URI], Abschnitt 2.1), geben Autoren sie manchmal in Attributwerten an, die URIs erwarten (d.h., in der %URI; definiert sind mit DTD). Zum Beispiel ist der folgende href-Wert ungültig:

<A href="http://foo.org/Håkon">...</A>

Wir empfehlen, dass Benutzerprogramme in solchen Fällen die folgenden Konventionen zur Verarbeitung von Nicht-ASCII-Zeichen übernehmen:

  1. Jedes Zeichen in UTF-8 (siehe [RFC2279]) als ein oder mehrere Bytes darstellen.
  2. Diese Bytes mit dem URI-Ersatzmechanismus ersetzen (d.h., durch Konvertierung jedes Bytes in %HH, wobei HH eine hexadizimale Schreibweise des Byte-Werts ist).

Dieser Vorgang führt zu einem syntaktisch gültigen URI (wie in [RFC1738], Abschnitt 2.2 oder [RFC2141], Abschnitt 2 definiert), der unabhängig von der Zeichenkodierung ist, in die das HTML-Dokument, das diesen URI enthält, umkodiert worden sein kann.

Anmerkung: Einige ältere Benutzerprogramme verarbeiten URIs in HTML, indem sie die Bytes der Zeichenkodierung verwenden, in der das Dokument empfangen wurde. Einige ältere HTML-Dokumente sind abhängig von dieser Praxis und funktionieren nicht, wenn sie umkodiert werden. Benutzerprogramme, die diese älteren Dokumente verarbeiten möchten, sollten, wenn sie einen URI empfangen, der Zeichen außerhalb der gültigen Menge enthält, zuerst die Konvertierung nach UTF-8 verwenden. Nur wenn der resultierende URI nicht aufgelöst werden kann, sollten sie versuchen, einen URI auf Grundlage der Bytes der Zeichenkodierung zu erzeugen, in der das Dokument empfangen wurde.

Anmerkung: Die gleiche Konvertierung auf Grundlage von UTF-8 sollte auch auf Werte des Attributs name des Elements A angewandt werden.

B.2.2 Und-Zeichen in URI-Attributwerten

Der URI, der erzeugt wird, wenn ein Formular übertragen wird, könnte als ein Ankerlink (z.B. Attribut href des Elements A) verwendet werden. Leider beißt sich die Verwendung des Zeichens »&« zur Trennung von Formularfeldern mit seiner Verwendung in SGML-Attributwerten zur Begrenzung von Entity-Zeichenreferenzen. Um zum Beispiel den URI »http://host/?x=1&y=2« als einen Link-URI zu verwenden, muss er <A href="http://host/?x=1&#38;y=2"> oder <A href="http://host/?x=1&amp;y=2"> geschrieben werden.

Wir empfehlen, dass Entwickler von HTTP-Servern, und insbesondere CGI-Entwickler die Verwendung von »;« anstatt von »&« unterstützen, um Autoren den Ärger zu ersparen, »&«-Zeichen auf diese Weise zu ersetzen.

B.3 Anmerkungen zur SGML-Implementierung

B.3.1 Zeilenumbrüche

SGML (siehe [ISO8879], Abschnitt 7.6.1) gibt an, dass ein Zeilenumbruch, der direkt auf einen Start-Tag folgt, ignoriert werden muss, genau wie ein Zeilenumbruch direkt vor einem End-Tag. Dies gilt ohne Ausnahme für alle HTML-Elemente.

Die beiden folgenden HTML-Beispiele müssen identisch dargestellt werden:

<P>Thomas schaut TV.</P>
<P>
Thomas schaut TV.
</P>

Ebenso die beiden folgenden Beispiele:

<A>Meine Lieblings-Web-Site</A>
<A>
Meine Lieblings-Web-Site
</A>

B.3.2 Nicht-HTML-Daten angeben

Skript- und Formatierungsdaten können als Elementinhalt oder als Attributwerte erscheinen. Die folgenden Abschnitte beschreiben die Grenzen zwischen HTML-Quelltext und Fremddaten.

Anmerkung: Die DTD definiert, dass Skript- und Formatierungsdaten sowohl für Elementinhalt als auch für Attributwerte CDATA sein müssen. SGML-Regeln gestatten keine Zeichenreferenzen in CDATA-Elementinhalt, erlauben sie jedoch in CDATA-Attributwerten. Autoren sollten besonders aufmerksam sein, wenn Skript- und Formatierungsdaten zwischen Elementinhalt und Attributwerten ausgetauscht (ausgeschnitten und eingefügt) werden.

Diese Asymetrie bedeutet auch, dass das Programm zur Umkodierung, wenn es von einer reichhaltigeren zu einer weniger Zeichen enthaltenden Zeichenkodierung transformiert, nicht einfach Zeichen in Skript- oder Styledaten, die es nicht umformen kann, mit der entsprechenden numerischen Zeichenreferenz ersetzen kann; es muss das HTML-Dokument parsen und jede Syntax einer Skript- und Formatierungssprache kennen, um die Daten richtig zu verarbeiten.

Elementinhalt 

Wenn der Inhalt eines Elements aus Skript- oder Formatdaten (SCRIPT und STYLE) besteht, beginnen die Daten direkt nach dem Start-Tag des Elements und enden vor dem ersten ETAGO-Begrenzer (»</«), gefolgt von einem Namensbeginn-Zeichen ([a-zA-Z]); beachten Sie, dass dies eventuell nicht der End-Tag des Elements ist. Autoren sollten »</« deshalb im Inhalt ersetzen. Ersetzungsmechanismen sind für jede Skript- oder Stylesheet-Sprache spezifisch.

UNGÜLTIGES BEISPIEL:
Das folgende Skript enthält die ungültige Zeichenkette "</" (als Teil von "</EM>") vor dem End-Tag von SCRIPT:

    <SCRIPT type="text/javascript">
      document.write ("<EM>This won't work</EM>")
    </SCRIPT>

In JavaScript könnte dieser Code durch Verstecken des ETAGO-Begrenzers vor einem SGML-eigenen Namensbeginn-Zeichen gültig formuliert werden:

    <SCRIPT type="text/javascript">
      document.write ("<EM>Dies wird funktionieren<\/EM>")
    </SCRIPT>

In Tcl könnte dies wie folgt erreicht werden:

    <SCRIPT type="text/tcl">
      document write "<EM>Dies wird funktionieren<\/EM>"
    </SCRIPT>

In VBScript könnte das Problem mit der Funktion Chr() vermieden werden:

    "<EM>Dies wird funktionieren<" & Chr(47) & "EM>"

Attributwerte 

Sind Skript- oder Formatierungsdaten Wert eines Attributs (entweder style oder Attribute eingebetteter Ereignisse), sollten Autoren das Vorkommen des zur Begrenzung des Attributwerts benutzen einfachen oder doppelten Anführungszeichens innerhalb des Wertes entsprechend den Konventionen der Skript- oder Stylesheet-Sprache schützen (escape). Autoren sollten auch das »&« schützen, wenn es nicht als Beginn einer Zeichenreferenz gedacht ist.

Deshalb kann man zum Beispiel schreiben:

 <INPUT name="num" value="0"
 onchange="if (compare(this.value, &quot;help&quot;)) {gethelp()}">

B.3.3 SGML-Eigenschaften mit begrenzter Unterstützung

Von SGML-Systemen, die konform zu [ISO8879] sind, wird erwartet, dass sie viele Eigenschaften erkennen, die von HTML-Benutzerprogrammen nur spärlich unterstützt werden. Wir empfehlen Autoren, die Verwendung all dieser Eigenschaften zu vermeiden.

Anmerkung der Übersetzer:

In SGML – und damit eigentlich auch in HTML – lässt sich ein Dokument auf bequeme Weise in mehrere Dateien teilen, die dann aus einer »Hauptdatei« inkludiert werden. Zum Beispiel:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd" [
 <!ENTITY kopf SYSTEM "head.html">
 <!ENTITY kap1 SYSTEM "einleitung/kap1.sgml">
 <!ENTITY kap2 SYSTEM "grundlagen/kap2.sgml">
 <!ENTITY kap3 SYSTEM "grundlagen/kap3.sgml">
]>
<html>
   &kopf;
   <body>
        <h1>XHTML, CSS & Co</h1>
        &kap1;
        &kap2;
        &kap3;
   </body>
</html>

Dies ist eine korrekte HTML-Datei. Voraussetzung ist, dass durch »Einfügen« der Inhalte der externen Dateien an den Stellen, an denen die jeweiligen Entity-Referenzen auftauchen, die Korrektheit erreicht wird. Beispielsweise muss die Datei head.html ein title-Element enthalten. Ein solches Aufteilen einer HTML-Seite auf mehrere Dateien kann Vorteile bringen. Es könnten nun etwa mehrere Autoren gleichzeitig an einem Dokument arbeiten. Doch leider funktioniert dies im Sonderfall HTML nicht ohne Weiteres. Nur falls der Server in echter SGML-Manier das Dokument parsen und die Entities einfügen würde, würde es funktionieren. Im (Normal-)Fall schickt der Server die Daten zum Browser und dieser kann damit gar nichts anfangen. – Abschließend sei bemerkt, dass das gezeigte Feature auch in XML vorhanden ist. Sie sollten sich aber auch bei so genannten »XML-fähigen« Browsern nicht auf die Unterstützung verlassen. Gleiches gilt für die unten genannten CDATA-Abschnitte.

B.3.4 Boolesche Attribute

Autoren sollten sich dessen bewusst sein, dass viele Benutzerprogramme nur die minimierte Form der Booleschen Attribute erkennen, nicht die vollständige Form.

Autoren möchten zum Beispiel angeben:

<OPTION selected>

An Stelle von:

<OPTION selected="selected">

B.3.5 Markierte Abschnitte (Marked Sections)

Markierte Abschnitte spielen eine ähnliche Rolle wie das #ifdef-Konstrukt, das von Präprozessoren der Programmiersprache C erkannt wird.

<![INCLUDE[
 <!-- dies wird eingeschlossen -->
]]>

<![IGNORE[
 <!-- dies wird ausgeschlossen -->
]]>

SGML definiert ebenso die Verwendung von markierten Abschnitten für CDATA-Inhalt, innerhalb dessen "<" nicht als Beginn eines Tags behandelt wird, z.B.:

<![CDATA[
 <Ein> Beispiel mit <sgml>-Markup, in dem <ohne Bedenken>
 ein < und solche Dinge geschrieben werden können.
]]>

Ein Anzeichen dafür, dass ein Benutzerprogramm einen markierten Abschnitt nicht erkennt, ist das Auftauchen der Zeichen »]]>«, die angezeigt werden, wenn das Benutzerprogramm irrtümlicherweise das erste »>«-Zeichen als Ende des Tags ansieht, der mit »<![« beginnt.

B.3.6 Verarbeitungsanweisungen (PI)

Verarbeitungsanweisungen sind ein Mechanismus, um plattformspezifische Ausdrücke zu erfassen. Eine Verarbeitungsanweisung beginnt mit einem <? und endet mit >

<?instruction >

Anmerkung der Übersetzer:

Vorsicht: In XML (und XHTML) sehen Verarbeitungsanweisungen wie folgt aus:

<?instruction ?>

Zum Beispiel:

<?>
<?style tt = font courier>
<?page break>
<?experiment> ... <?/experiment>

Autoren sollte bewusst sein, dass viele Benutzerprogramme Arbeitsanweisungen als Teil des Dokumenttextes darstellen.

B.3.7 Auszeichner abkürzen

Einige SHORTTAG-Konstrukte von SGML sparen Tipparbeit, fügen der SGML-Anwendung aber keine ausdrucksvolle Fähigkeit hinzu. Auch wenn diese Konstrukte technisch gesehen keine Zweideutigkeit einführen, reduzieren sie die Robustheit eines Dokuments, besonders wenn die Sprache erweitert wurde, um neue Elemente einzuschließen. Während SHORTTAG-Konstrukte in SGML, die sich auf Attribute beziehen, verbreitet verwendet werden und implementiert sind, sind es jene, die sich auf Elemente beziehen, nicht. Dokumente, die sie verwenden, sind konforme SGML-Dokumente, jedoch arbeiten sie wahrscheinlich nicht mit den meisten existierenden HTML-Werkzeugen zusammen.

Anmerkung der Übersetzer:

Nicht nur wegen obiger Begründung sollten Sie alle SHORTTAGs vergessen: In XML gibt es sie nicht mehr.

Die fraglichen Kurzauszeichner-Konstrukte sind die folgenden:

B.4 Anmerkungen zum Thema: Suchmaschinen helfen, die eigene Website zu indexieren

Dieser Abschnitt gibt einige einfache Ratschläge, um Ihre Dokumente zugänglicher für Suchmaschinen machen.

Definiere die Dokumentsprache
Im globalen Kontext des Webs ist es wichtig zu wissen, in welcher menschlichen Sprache eine Seite geschrieben wurde. Dies wird in Abschnitt 8.1, Spezifizierung der Sprache des Inhalts" besprochen.
Sprachvarianten des Dokuments angeben
Haben Sie Übersetzungen dieses Dokuments in anderen Sprachen angefertigt, sollten Sie das Element LINK verwenden, um auf diese zu verweisen. Dies gestattet es einem indexierenden Programm, Benutzern ein Suchergebnis in der vom Benutzer bevorzugten Sprache anzubieten, unabhängig davon, wie die Anfrage geschrieben war. Zum Beispiel bieten die folgenden Verweise französiche und deutsche Alternativen für Suchmaschinen:
<LINK rel="alternate" 
         type="text/html"
         href="mydoc-fr.html" hreflang="fr"
         lang="fr" title="La vie souterraine">
<LINK rel="alternate" 
         type="text/html"
         href="mydoc-de.html" hreflang="de"
         lang="de" title="Das Leben im Untergrund">
Schlüsselworte und Beschreibungen hinzufügen
Schlüsselworte und Beschreibungen hinzufügen
Einige indexierende Programme suchen nach META-Elementen, die eine durch Kommata getrennte Liste mit Schlüsselworten/Phrasen definieren oder eine kurze Beschreibung liefern. Suchmaschinen können diese Schlüsselworte als Ergebnis einer Suche präsentieren. Der Wert des Attributs name, der von einer Suchmaschine begehrt wird, ist nicht in dieser Spezifikation definiert. Betrachten Sie folgende Beispiele:
<META name="keywords" content="Urlaub,Griechenland,Sonnenschein">
<META name="description" content="Idyllische europäische Urlaubsreisen">
Zeige den Anfang einer (Dokument)sammlung an
Schriftsammlungen oder Präsentationen werden häufig in HTML-Dokumentsammlungen übertragen. Für Suchergebnisse ist es hilfreich, den Anfang einer Sammlung zusätzlich zur gefundenen Seite zu referenzieren. Sie könnten Suchmaschinen helfen, wenn sie das Element LINK in Verbindung mit rel="start" und dem Attribut title verwenden wie hier:
<LINK rel="start" 
         type="text/html"
         href="page1.html" 
         title="Allgemeine Relativitätstheorie">
Robots mit Indexieranweisungen füttern
Einge Leute mögen manchmal überrascht sein, dass ihre Seite durch einen Robot indexiert wurde, und dass dem Robot der Zugang zu einem sensitiven Teil der Seite nicht gestattet hätte sein dürfen. Viele Web-Robots bieten Administratoren von Websites und Autoren die Möglichkeit, diese Tätigkeiten des Robots einzuschränken. Dies wird durch zwei Mechanismen erreicht: durch eine Datei namens »robots.txt« und das META-Element im HTML-Dokument, wie unten beschrieben.

B.4.1 Such-Robots

Die Datei robots.txt 

Wenn ein Robot eine Web-Seite besucht, z.B. http://www.foobar.com/, überprüft sucht er zuerst die Datei http://www.foobar.com/robots.txt. Kann er dieses Dokument finden, wird er dessen Inhalt analysieren, um festzustellen, ob es gestattet ist, das Dokument zu empfangen. Sie können die Datei robots.txt anpassen, damit sie nur für bestimmte Robots gilt, und um den Zugang zu bestimmten Verzeichnissen oder Dateien zu verbieten.

Hier folgt ein Beispiel einer Datei robots.txt, die allen Robots untersagt, die gesamte Seite zu besuchen:

        User-agent: *    # gilt für alle Robots
        Disallow: /      # verbiete Indexierung aller Seiten

Die Robots werden nur nach einem »/robots.txt«-URI auf Ihrer Seite schauen, wenn der Webauftritt als ein HTTP-Server definiert ist, der auf einem bestimmten Host und einer bestimmten Port-Nummer läuft. Hier sind einige Beispielorte für robots.txt:

URI des WebauftrittsURI für robots.txt
http://www.w3.org/http://www.w3.org/robots.txt
http://www.w3.org:80/http://www.w3.org:80/robots.txt
http://www.w3.org:1234/http://www.w3.org:1234/robots.txt
http://w3.org/http://w3.org/robots.txt

Es kann nur eine »/robots.txt« für eine Site geben. Speziell sollten Sie »robots.txt«-Dateien nicht in Benutzerverzeichnissen ablegen, weil ein Robot niemals nach ihnen suchen wird. Möchten Sie, dass Ihre Benutzer in der Lage sind, ihre eigene »robots.txt« zu erzeugen, werden sie all diese in einer einzigen »/robots.txt« zusammenfügen müssen. Möchten Sie dies nicht tun, könnten Ihre Benutzer stattdessen vielleicht das META-Tag für Robots verwenden.

Einige Tipps: URIs unterscheiden zwischen Groß- und Kleinschreibung, »/robots.txt« muss vollkommen in Kleinbuchstaben vorliegen. Leere Zeilen sind innerhalb eines Einzeleintrags in der Datei »robots.txt« nicht gestattet.

Es muss genau ein Feld »User-agent« pro Eintrag geben. Die Robots sollten großzügig in der Interpretation dieses Feldes sein. Es wird empfohlen, einen Treffer als gültig anzusehen, wenn eine Teilzeichenfolge des Namens unabhängig von Groß- und Kleinschreibung und Versionsinformationen gefunden wird.

Ist der Wert »*«, beschreibt der Eintrag die Standard-Grundsätze für den Zugriff für alle Robots, die nicht einem der anderen Einträge entsprechen. Mehrere Einträge dieser Art sind in der Datei »robots.txt« nicht gestattet.

Das Feld »Disallow« gibt einen Teil-URI an, der nicht besucht werden darf. Dies kann ein vollständiger Pfad oder ein Teilpfad sein; jeder URI, der mit diesem Wert beginnt, wird nicht abgerufen. Zum Beispiel,

   Disallow: /help verbietet sowohl /help.html als auch /help/index.html,
   Disallow: /help/ dagegen würde /help/index.html verbieten, aber /help.html erlauben. 

Ein leerer Wert für »Disallow« zeigt an, dass alle URIs abgerufen werden können. Zumindest ein »Disallow«-Feld muss in der Datei »robots.txt« vorhanden sein.

Anmerkung der Übersetzer:

Hier noch einmal ein Beispiel, das die aktuelle Vorgehensweise von Robots verdeutlicht. Dazu eine vollständige robots.txt:

      User-Agent: *
      Disallow: /nur_meinrobot/
      Disallow: 
   
      User-Agent: meinrobot
      Disallow:

Im ersten Eintrag wird allen Robots (»*«) der Zugang zum Verzeichnis nur_meinrobot verwehrt, der Zugang zu allen anderen Verzeichnisse ist durch Angabe die von Disallow: ohne weiteren Parameter gestattet. Die folgende Leerzeile trennt den ersten Eintrag vom zweiten. Im zweiten Eintrag wird dem Robot meinrobot der Zugang zu allen Verzeichnissen gestattet. Die Angabe aus dem ersten Eintrag wird hiermit für diesen Robot außer Kraft gesetzt.

Robots und das META-Element 

Das Element META gestattet es HTML-Autoren, besuchenden Robots mitzuteilen, ob das Dokument indexiert oder verwendet werden soll, um mehr Links zu sammeln. Ein Eingreifen des Server-Administrators ist nicht erforderlich.

Im folgenden Beispiel soll ein Robot dieses Dokument weder indexieren noch auf Links hin analysieren.

<META name="ROBOTS" content="NOINDEX, NOFOLLOW">

Die Liste der Begriffe »content« ist ALL, INDEX, NOFOLLOW, NOINDEX.

Anmerkung: Anfang 1997 implementierten dies nur wenige Robots, aber es wird erwartet, dass sich das ändert, da der Kontrolle von indexierenden Robots mehr öffentliche Aufmerksamkeit geschenkt wird.

B.5 Anmerkungen zu Tabellen

B.5.1 Begründung des Tabellenentwurfs

Das HTML-Tabellenmodell hat sich aus Studien der existierenden SGML-Tabellenmodelle, der Behandlung von Tabellen in bekannten Textverarbeitungsprogrammen und einer Vielfalt tabellarischer Layout-Techniken in Magazinen, Büchern und anderen auf Papier basierenden Dokumenten entwickelt. Das Modell wurde ausgesucht, um einfache Tabellen einfach ausdrücken zu können, mit zusätzlich verfügbarer Komplexität, wenn notwendig. Dies macht die Erzeugung von Quellcode für HTML-Tabellen mit alltäglichen Texteditoren praktikabel und reduziert die Lernkurve, um die ersten Schritte zu vollziehen. Diese Eigenschaft ist sehr wichtig für den Erfolg gewesen, den HTML heute hat.

Benutzer erzeugen Tabellen zunehmend durch Konvertierung aus anderen Dokumentformaten oder dadurch, dass sie diese direkt in WYSIWYG-Editoren erzeugen. Es ist wichtig, dass sich das HTML-Tabellenmodell an diese Landschaft der Autorenwerkzeuge gut anpasst. Dies betrifft die Art der Darstellung von Zellen, die sich über mehrere Zeilen oder Spalten erstrecken, und die Verknüpfung von Ausrichtung und anderen Präsentationseigenschaften mit Zellgruppen.

Dynamisches Umformatieren 

Eine weitreichende Überlegung für das HTML-Tabellenmodell ist, dass der Autor nicht kontrolliert, in welcher Größe ein Benutzer eine Tabelle anzeigt, welche Schriftart er wählt und so weiter. Dies gestaltet es riskant, sich auf Spaltenbreiten zu verlassen, die in absoluten Pixeln angegeben sind. Stattdessen müssen Tabellen in der Lage sein, Größen dynamisch zu verändern, um sich der aktuelle Fenster und der Schrifgröße anzupassen. Autoren können Beratung anbieten die relative Breiten von Spalten betreffend, jedoch sollten Benutzerprogramme sicherstellen, dass Spalten breit genug sind, um die Breite des größten Elements im Inhalt der Zelle darzustellen. Muss die Angabe des Autors überschrieben werden, sollten relative Breiten individueller Spalten nicht drastisch verändert werden.

Inkrementelle Darstellung  

Inkrementelle Tabellendarstellung ist bei großen Tabellen oder langsamen Netzwerkverbindungen wichtig für die Benutzerzufriedenheit. Benutzerprogramme sollten in der Lage sein, eine Tabelle darzustellen, bevor alle Daten empfangen worden sind. Die voreingestellte Fensterbreite für die meisten Benutzerprogramme ist ungefähr 80 Zeichen und die Graphiken für HTML-Seiten werden mit diesen Werten im Hinterkopf erzeugt. Durch die Angabe der Anzahl der Spalten und durch Einbeziehung von Festlegungen zur Kontrolle der Tabellenbreite und der Breite verschiedener Spalten können Autoren den Benutzerprogrammen Hinweise geben, die eine inkrementelle Darstellung des Tabelleninhalts gestatten.

Zur inkrementellen Darstellung braucht der Browser die Anzahl der Spalten und ihre Breite. Die Standardreite ist die aktuelle Fensterbreite (width="100%"). Dies kann durch Angabe des Attributs width des Elements TABLE verändert werden. Standardmäßig haben alle Spalten die gleiche Breite, Sie können jedoch Spaltenbreiten über ein oder mehrere COL-Elemente angeben, bevor die Tabellendaten anfangen.

Die verbleibende Frage ist die nach der Anzahl der Spalten. Einige Leute haben vorgeschlagen zu warten, bis die erste Zeile der Tabelle empfangen wird, aber das könnte eine lange Zeit dauern, wenn die Zellen umfassenden Inhalts sind. Im Endeffekt macht es mehr Sinn, sofern inkrementelle Darstellung erwünscht ist, Autoren dazu zu bewegen, die Anzahl der Spalten im Element TABLE explizit anzugeben.

Autoren benötigen noch eine Möglichkeit, dem Benutzerprogramm mitzuteilen, ob inkremetelle Darstellung verwendet wird, oder ob die Tabelle automatisch angepasst werden soll, um den Zellinhalt aufzunehmen. Im Modus der automatischen Größenbestimmung mit zwei Durchläufen wird die Anzahl der Spalten im ersten Durchlauf bestimmt. Im inkrementellen Modus muss die Anzahl der Spalten zuerst festgelegt werden (mit den Elementen COL oder COLGROUP).

Struktur und Darstellung 

HTML unterscheidet strukturelle Auszeichnung, wie Absätze und Zitate, von darstellungsbezogenen Ausdrücken, wie Abstände, Schriftarten, Farben und so weiter. Wie beeinflusst diese Unterscheidung Tabellen? Vom Standpunkt des Puristen aus gesehen, ist die Ausrichtung von Text innerhalb der Tabellenzellen und der Trennlinien zwischen Zellen ein Darstellungsproblem, kein Strukturproblem. Auf der praktischen Seite ist es aber nützlich, diese mit den strukturellen Informationen zu gruppieren, weil diese Eigenschaften sehr einfach von einer Anwendung zur nächsten portiert werden können. Das HTML-Tabellenmodell überlässt die meisten Darstellungsinformationen verknüpften Stylesheets. Das Modell, das in dieser Spezifikation präsentiert wird, ist entworfen worden, um den Vorteil solcher Stylesheets zu nutzen, sie aber nicht zu erfordern.

Aktuelle Desktop-Publishing-Software erlaubt eine diffizile Kontrolle über die Darstellung von Tabellen, und es wäre nicht möglich, diese in HTML zu reproduzieren, ohne aus HTML ein sperriges Rich-Text-Format zu machen wie RTF oder MIF. Diese Spezifikation bietet Autoren jedoch die Möglichkeit, aus einer Menge verbreiteter Klassen von Rahmenformaten zu wählen. Das Attribut frame kontrolliert die Darstellung von Rahmen um eine Tabelle herum, während das Attribut rules die Wahl der Trennlinien innerhalb der Tabelle bestimmt. Eine feinere Kontrolle wird über Formatierungsanweisungen unterstützt. Das Attribut style kann zur Angabe von Formatierungsinformationen für individuelle Elemente verwendet werden. Weitere Formatierungsinformationen können über das Element STYLE im Dokumentkopf oder über verlinkte Stylesheets angegeben werden.

Während der Entwicklung dieser Spezifikation wurden einige Wege beschritten, die Linierungsmuster für Tabellen zu spezifizieren. Eine Frage betrifft die Art der Angaben, die gemacht werden können. Unterstützung für die Entfernung und den Zusatz von Eckzellen einzufügen, führt zu relativ komplexen Algorithmen. Zum Beispiel führte die Arbeit, allen Tabellenelementen die Unterstützung der Attribute frame und rules zu gestatten, zu einem Algorithmus, der 24 Schritte einschloss, um zu bestimmen, ob eine bestimmte Ecke einer Zelle mit Linien versehen werden sollte oder nicht. Selbst diese zusätzliche Komplexität bietet nicht genug Darstellungskontrolle, um den vollen Umfang der Erfordernisse von Tabellen zu befriedigen. Die aktuelle Spezifikation bezieht sich absichtlich auf ein einfaches intuitives Modell, das für die meisten Zwecke ausreicht. Weitere experimentelle Arbeit wird benötigt, bevor ein komplexerer Anlauf standardisiert wird.

Zeilen- und Spaltengruppen 

Diese Spezifikation gibt eine Obermenge des einfacheren Modells an, das in früheren Arbeiten zu HTML+ präsentiert wurde. Es wird angenommen, dass Tabellen aus einer optionalen Beschriftung, zusammen mit einer Sequenz aus Zeilen, welche ihrerseits aus einer Sequenz von Tabellenzellen bestehen, gebildet werden. Das Modell differenziert weiterhin zwischen Kopf- und Datenzellen und erlaubt Zellen, sich über mehrere Zeilen und Spalten zu erstrecken.

Dem CALS-Tabellenmodell (siehe [CALS]) folgend, gestattet es diese Spezifikation, Tabellenzeilen in Kopf-, Rumpf- und Fußabschnitte zu gruppieren. Dies vereinfacht die Repräsentation von Darstellungsinformationen und kann dazu verwendet werden, Tabellenköpfe und -füße zu wiederholen, wenn Tabellen über Seitengrenzen umbrechen, oder um feste Köpfe über scrollbaren Rumpfbereichen anzugeben. Im der Auszeichnung wird der Fuß vor den Rumpfabschnitten platziert. Dies ist eine Optimierung, die mit CALS geteilt wird, um mit sehr langen Tabellen zurechtzukommen. Damit ist die Darstellung des Fußes gestattet, ohne auf die Verarbeitung der gesamten Tabelle warten zu müssen.

Zugänglichkeit 

Für visuell Benachteiligte bietet HTML die Hoffnung, den Schaden wieder gutzumachen, den die Übernahme von Fenster-basierten graphischen Benutzerschnittstellen verursacht hat. Das HTML-Tabellenmodell schließt Attribute zur Beschriftung jeder Zelle ein, um eine hohe Qualität bei der Sprachumwandlung zu unterstützen. Die gleichen Attribute können auch dazu verwendet werden, um automatischen Import und Export von Tabellendaten in Datenbanken oder Arbeitsblätter zu unterstützen.

B.5.2 Empfohlende Layout-Algorithmen

Wenn die Elemente COL oder COLGROUP vorhanden sind, geben sie die Anzahl der Spalten an, und die Tabelle kann eventuell mit einem festen Layout dargestellt werden. Ansonsten sollte der automatische Layout-Algorithmus verwendet werden, der weiter unten beschrieben ist.

Ist das Attribut width nicht angegeben, sollten visuelle Benutzerprogramme einen voreingestellten Wert von 100% für die Formatierung annehmen.

Es wird empfohlen, dass Benutzerprogramme die Tabellenbreite über den mit width angegebenen Wert hinaus erhöhen, wenn der Zellinhalt sonst überlaufen würde. Benutzerprogramme, die die angegebene Breite überschreiben, sollten dies in einem vernünftigen Rahmen tun. Benutzerprogramme können sich entscheiden, Worte auf mehrere Zeilen aufzuteilen, um die Notwendigkeit übermäßiger horizontaler Scrollbewegungen zu vermeiden, oder wenn solch eine Scrollbewegung unmöglich oder nicht erwünscht ist.

Um des Layouts Willen sollten Benutzerprogramme bedenken, dass sich Tabellenüberschriften (angegeben durch das Element CAPTION) wie Zellen verhalten. Jede Überschrift ist eine Zelle, die sich über alle Spalten der Tabelle erstreckt, wenn sie sich oberhalb oder unterhalb der Tabelle befindet, und über alle Zeilen, wenn sie links oder rechts der Tabelle ist.

Algorithmus für festes Layout 

Für diesen Algorithmus wird angenommen, dass die Anzahl der Spalten bekannt ist. Die Spaltenbreite sollte per Voreinstellung gleich sein. Autoren können dies durch die Angabe relativer oder absoluter Spaltenbreiten überschreiben, und zwar mit den Elementen COLGROUP oder COL. Die Standardtabellenbreite ist der Raum zwischen dem aktuellen linken und rechten Rand, kann aber durch das Attribut width des Elements TABLE überschrieben oder durch die absoluten Spaltenbreiten bestimmt werden. Um mit einem Mix aus absoluten und relativen Spaltenbreiten zurechtzukommen, ist der erste Schritt zur Lösung, den Spalten mit absoluter Breite Raum von der Tabellenbreite zuzuweisen. Danach wird den Spalten mit relativen Breiten der übrig gebliebene Raum zugeteilt.

Die Tabellensyntax allein ist nicht ausreichend, um die Konsistenz von Attributwerten zu garantieren. Zum Beispiel kann die Anzahl der Elemente COL und COLGROUP im Widerspruch zu der Anzahl der Spalten stehen, die von den Tabellenzellen gefordert werden. Ein weiteres Problem taucht auf, wenn die Spalten zu eng sind, um ein Überlaufen des Zellinhalts zu vermeiden. Die Breite der Tabelle, die durch das Element TABLE oder COL-Elemente angegeben ist, könnte zum Überlaufen des Zellinhalts führen. Es wird empfohlen, dass Benutzerprogramme versuchen, sich aus diesen Situationen elegant herauszuwinden, z.B. durch Silbentrennung und Umverteilung in zu trennende Worte, wenn Silbentrennpunkte nicht bekannt sind.

Für den Fall, dass ein nicht teilbares Element einen Zellüberlauf verursacht, sollte das Benutzerprogramm erwägen, die Spaltenbreite anzupassen und die Tabelle neu aufzubauen. Im schlimmsten Fall sollte das Abschneiden des Inhalts erwogen werden, wenn eine Anpassung der Spaltenbreite und/oder scrollbarer Zellinhalt nicht möglich sind. In jedem Fall sollte dem Benutzer die Trennung oder ein Abschneiden von Zellinhalt in angemessener Weise angezeigt werden.

Algorithmus für automatisches Layout 

Ist die Anzahl der Spalten nicht über die Elemente COL und COLGROUP angegeben, dann sollte das Benutzerprogramm den folgenden Algorithmus für automatisches Layout verwenden. Er benötigt zwei Durchläufe durch die Tabellendaten und steigt linear mit der Größe der Tabelle.

Beim ersten Durchlauf ist Zeilenumbruch deaktiviert, und das Benutzerprogramm merkt sich die minimale und die maximale Zeilenbreite jeder Zelle. Die maximale Breite wird durch die breiteste Zeile bestimmt. Weil Zeilenumbruch nicht aktiviert ist, werden Absätze als lange Zeilen betrachtet, es sei denn, sie werden durch BR-Elemente umgebrochen. Die minimale Breite wird durch das breiteste Textelement bestimmt (Wort, Graphik und so weiter), einschließlich führender Einrückungen, Listenzeichen und so weiter. Mit anderen Worten ist: Es notwendig, die minimale Breite einer Zelle zu bestimmen, die eine Zelle in einem eigenen Fenster fordern würde, bevor sie überläuft. Dem Benutzerprogramm zu gestatten, Wörter zu trennen, wird die Notwendigkeit horizontalen Scrollens, oder im schlimmsten Fall, die Notwendigkeit zu beschneiden, minimieren.

Dieser Vorgang gilt ebenso für jede verschachtelte Tabelle im Zellinhalt. Die minimale und maximale Breite für Zellen in verschachtelten Tabellen werden verwendet, um die minimale und maximale Breite für diese Tabellen zu bestimmen und daher für die Elterntabellenzelle selbst. Der Algorithmus ist linear zum gesamten Zellinhalt und, allgemein gesprochen, unabhängig von der Tiefe der Verschachtelung.

Um mit der Zeichenausrichtung von Zellinhalt zurechtzukommen, behält der Algorithmus drei laufende min/max-Stände für jede Spalte: Links des Ausrichtungszeichens, rechts des Ausrichtungszeichens und nicht ausgerichtet. Die minimale Breite für eine Spalte ist dann: max(min_links + min_rechts, min_nicht-ausgerichtet).

Die minimalen und die maximalen Zellbreiten werden dann verwendet, um die entsprechende minimalen und maximalen Breiten für die Spalten zu bestimmen. Diese wiederum werden verwendet, um die minimale und maximale Breite der Tabelle zu finden. Beachten Sie, dass Zellen verschachtelte Tabellen enthalten können, jedoch kompliziert das den Code nicht signifikant. Der nächste Schritt ist, die Spaltenbreiten entsprechend des verfügbaren Platzes zu vergeben (d.h., den Raum zwischen dem aktuellen linken und rechten Rand).

Ein einfacher Ansat für Zellen, die sich über mehrere Spalten erstrecken, besteht darin, die min/max-Breite gleichmäßig jeder enthaltenden Zelle zuzuweisen. Eine etwas komplexere Methode verwendet die min/max-Breiten der einzelnen Zellen um abzuwägen, wie den gesamen Spalten Breiten zugeteilt werden. Experimente zeigen, dass eine Mixtur dieser beiden Methoden gute Ergebnisse für sehr viele Tabellen liefert.

Tabellenrahmen und Ränder zwischen Zellen müssen in die Verteilung der Spaltenbreiten mit eingeschlossen werden. Es gibt drei Fälle:

  1. Die minimale Tabellenbreite ist gleich oder größer als der verfügbare Raum. In diesem Fall weise die minimale Breite zu und gestatte dem Benutzer horizontal zu scrollen. Für eine Konvertierung in Braille ist es notwendig, die Zellen durch Verweise auf Anmerkungen zu ersetzen, die deren ganzen Inhalt enthalten. Per Konvention erfolgt dies vor der Tabelle.
  2. Die maximale Tabellenbreite passt in den verfügbaren Raum. In diesem Fall setze die Spalten auf ihre maximale Breite.
  3. Die maximale Breite der Tabelle ist größer als der verfügbare Raum, die minimale Tabelle ist jedoch kleiner. In diesem Fall finde den Unterschied zwischen dem verfügbaren Raum und der minimalen Tabellenbreite, nennen wir ihn W. Ebenso lassen Sie uns den Unterschied zwischen der maximalen und minimalen Breite der Tabelle D nennen.

    Für jede Spalte lass d die Differenz zwischen der maximalen und minimalen Breite der Spalte sein. Nun setze die Spaltenbreite auf die minimale Breite plus d multipliziert mit W geteilt durch D. Dies erweitert die Spalten mit großem Unterschied zwischen Minimum und Maximum mehr als Spalten mit kleineren Unterschieden.

Dieser Zuweisungsschritt wird dann für verschachtelte Tabellen unter Verwendung der minmalen und maximalen Breiten, die von all diesen Tabellen im ersten Durchlauf gewonnen wurden, wiederholt. In diesem Fall ist die Breite der Elterntabellenzelle die aktuelle Fenstergröße in der Beschreibung oben. Dieser Vorgang wird rekursiv für alle verschachtelten Tabellen wiederholt. Die äußere Tabelle wird dann mit den zugewiesenen Breiten dargestellt. Verschachtelte Tabellen werden daraufhin als Teil des Zellinhalts der Elterntabelle dargestellt.

Ist die Tabellenbreite mit dem Attribut width angegeben, versucht das Benutzerprogramm, Spaltenbreiten zuzuweisen, die passen. Das Attribut width ist nicht bindend, wenn daraus Spalten resultieren, die enger sind als die minimale (d.h., unteilbare) Breite.

Sind relative Breiten über das Element COL angegeben, wird der Algorithmus modifiziert, um Spaltenbreiten über die minimale Breite zu erweitern und die Beschränkungen für relative Breiten zu erfüllen. Das Element COL sollte nur als Anhaltspunkt verstanden werden, so sollten Spalten nicht schmaler als ihre minimale Breite gesetzt werden. Spalten sollten auf der anderen Seite nicht so breit gemacht werden, dass die Tabelle weit über die Grenzen des Fensters hinausgeht. Gibt ein COL-Element eine relative Breite von Null an, sollte die Spalte immer auf ihre minimale Breite gesetzt werden.

Wird der zweistufige Layout-Algorithmus verwendet, kann, so kein explizites oder vererbtes charoff-Attribut vorliegt, die Standardausrichtungsposition durch Auswahl der Position bestimmt werden, die Zeilen zentrieren würde, deren Breiten vor und nach dem Ausrichtungszeichen die Maximalwerte aller Zeilen in der Spalte mit align="char" sind. Für inkrementelles Tabellenlayout ist die vorgeschlagene Voreinstellung charoff="50%". Wenn mehrere Zellen in verschiedenen Zeilen derselben Spalte Zeichenausrichtung verwenden, dann sollten standardmäßig alle dieser Zellen ausgerichtet werden, unabhängig davon, welches Ausrichtungszeichen verwendet wird. Regeln für die Verarbeitung von Objekten, die zu groß für eine Spalte sind, werden dann angewendet, wenn die explizite oder implizierte Ausrichtung zu einer Situation führt, in der die Daten die zugewiesene Breite der Spalte überschreiten.

Wahl der Attributnamen: Es wäre besser gewesen, die Werte für das Attribut frame mit dem rules-Attribut und den Werten für die Ausrichtung abzustimmen. Zum Beispiel: none, top, bottom, topbot, left, right, leftright, all. Leider fordert SGML von Attributwerten des Aufzählungstyps in jedem Element eindeutig zu sein, unabhängig vom Attributnamen. Dies verursacht unmittelbare Probleme für none, left, right und all. Die Werte für das Attribut frame sind ausgewählt worden, um Kollisionen mit den Attributen rules, align und valign zu verhindern. Hieran wird sich die zukünftige Arbeit messen lassen, weil erwartet wird, dass die Attribute frame und rules zu anderen Tabellenelementen in zukünftigen Revisionen dieser Spezifikation hinzugefügt werden. Eine Alternative wäre, aus frame ein CDATA-Attribut zu machen. Der Konsens der W3C HTML Working Group war jedoch, dass die Vorteile, SGML-Validierung für Attribute des Aufzählungstyps nutzen zu können, dem Nutzen der konsistenten Namen überwiegen.

B.6 Anmerkungen zu Formularen

B.6.1 Inkrementelle Darstellung

Die inkrementelle Darstellung über das Netz empfangener Dokumente, verursacht bestimmte Probleme in Bezug auf Formulare. Benutzerprogramme sollten Formulare davor bewahren, übertragen (submitted) zu werden, bevor alle Formularelemente empfangen worden sind.

Die inkrementelle Darstellung von Dokumenten wirft einige Probleme in Bezug auf die Tabulator-Navigation auf. Das Verfahren, den Fokus auf den niedrigsten tabindex-Wert im Dokument zu lenken, scheint auf den ersten Blick vernünftig zu sein. Jedoch bedeutet dies, zu warten, bis der gesamte Dokumenttext empfangen wurde, weil sich bis zu diesem Zeitpunkt der niedrigste tabindex-Wert immer noch ändern kann. Drückt der Benutzer die Tab-Taste vorher, ist es angemessen, dass Benutzerprogramme den Fokus auf das aktuell niedrigste tabindex lenken.

Sind Formulare mit Client-seitigen Skripten verbunden, gibt es weiteres Potenzial für Probleme. Zum Beispiel kann sich ein Skript-Handler auf ein gegebenes Feld beziehen, das noch nicht existiert.

B.6.2 Zukünftige Projekte

Diese Spezifikation definiert bestimmte Elemente und Attribute, die leistungsstark genug sind, um die allgemeinen Anforderungen für die Erstellung von Formularen zu erfüllen. Jedoch gibt es noch genug Raum für viele mögliche Verbesserungen. Zum Beispiel könnten in Zukunft die folgenden Probleme aufgegriffen werden:

Eine weitere mögliche Erweiterung wäre, das Attribut usemap zum Element INPUT als Client-seitige Imagemap hinzuzufügen, wenn type=»image« gesetzt ist. Das Element AREA, das zu dem angeklickten Ort gehört, würde den an den Server zu sendenden Wert liefern. Um zu vermeiden, Serverskripte zu verändern, ist es eventuell angemessen, AREA zu erweitern, so dass es x- und y-Werte für die Verwendung mit dem Element INPUT anbietet.

B.7 Anmerkungen zu Skripten

B.7.1 Reservierte Syntax für zukünftige Skriptmakros

Diese Spezifikation reserviert eine Syntax für zukünftige Unterstützung von Skriptmakros in CDATA-Attributen. Die Absicht besteht darin, Attribute in Abhängigkeit von Objekteigenschaften zu setzen, die zuvor auf der Seiten auftreten. Die Syntax lautet:

   attribute = "... &{ Makrorumpf }; ... "

Aktuelle Verwendung von Skriptmakros 

Der Makrorumpf besteht aus einer oder mehreren Angaben in der voreingestellten Skriptsprache (wie bei eingebetteten Event-Attributen). Das der rechten geschweiften Klammer folgende Semikolon wird immer benötigt, da die rechte geschweifte Klammer »}« ansonsten als Teil des Makrorumpfes behandelt werden würde. Ebenfalls erwähnenswert ist, dass für Attribute, die Skriptmakros enthalten, immer Anführungsstriche angegeben werden müssen.

Die Verarbeitung von CDATA-Attributen geht wie folgt vonstatten:

  1. Der SGML-Parser evaluiert jedes SGML-Entity (z.B. "&gt;").
  2. Dann werden die Skriptmakros vom skriptverarbeitenden Programm evaluiert.
  3. Schließlich wird die resulierende Zeichenkette zur weiteren Bearbeitung an die Anwendung weitergegeben.

Die Makroverarbeitung findet statt, wenn das Dokument geladen (oder aktualisiert), nicht jedoch wenn das Dokument in der Größe oder Farbe verändert wird und so weiter.

MISSBILLIGTES BEISPIEL:
Hier sind einige Beispiele, die JavaScript verwenden. Das erste verändert die Hintergrundfarbe wahllos.

    
<BODY bgcolor='&{randomrgb};'>

Vielleicht möchten Sie den Hintergrund für die abendliche Betrachtung abdunkeln:

    
<BODY bgcolor='&{if(Date.getHours > 18)...};'>

Das nächste Beispiel verwendet JavaScript, um die Koordinaten für eine Client-seitige Imagemap anzugeben:

    
<MAP NAME=foo>
   <AREA shape="rect" coords="&{myrect(imageuri)};" href="&{myuri};" alt="">
 </MAP>

Dieses Beispiel gibt die Größe einer Graphik entsprechend den Dokumenteigenschaften an:

    
<IMG src="bar.gif" width='&{document.banner.width/2};' height='50%' alt="banner">

Sie können den URI für einen Verweis oder ein Bild durch ein Skript angeben:

 <SCRIPT type="text/javascript">
   function manufacturer(widget) {
       ...
   }
   function location(manufacturer) {
       ...
   }
   function logo(manufacturer) {
       ...
   }
 </SCRIPT>
  <A href='&{location(manufacturer("widget"))};'>widget</A>
  <IMG src='&{logo(manufacturer("widget"))};' alt="logo">

Dieses letzte Beispiel zeigt, wie SGML-CDATA-Attribute mit einfachen oder doppelten Anführungszeichen eingefasst werden können. Verwenden Sie einfache Anführungszeichen um eine Attributzeichenkette herum, dann können Sie doppelte Anführungszeichen als Teil der Attributzeichenkette verwenden. Eine andere Möglichkeit ist, die Zeichenkette &quot; für Anführungszeichen zu benutzen:

<IMG src="&{logo(manufacturer(&quot;widget&quot;))};" alt="logo">

Anmerkung der Übersetzer:

Im Beispiel oben wird die vielleicht etwas verwirrende Formulierung »Attributzeichenkette« verwendet. An anderer Stelle wird diese auch als Attributwert oder Wert bezeichnet.

B.8 Anmerkungen zu Frames

Es gibt keine Garantie, dass der Name eines Ziel-Frames einzigartig ist. Daher ist es angebracht, die aktuelle Vorgehensweise zu beschreiben, wie ein Frame mit gegebenem Frame-Namen zu finden ist:

  1. Ist der Zielname ein reservierter Begriff, wie im normativen Text beschrieben, wende ihn wie beschrieben an.
  2. Ansonsten führe eine Tiefensuche der Frame-Hierarchie in dem Fenster aus, das den Verweis enthält. Verwende den ersten Frame, dessen Name genau passt.
  3. Wurde solch ein Frame in (2) nicht gefunden, führe Schritt 2 in jedem Fenster aus, in der Reihenfolge von vorne nach hinten. Halte sofort an, wenn ein Frame mit genau dem gleichen Namen auftaucht.
  4. Wurde solch ein Frame in (3) nicht gefunden, erzeuge ein neues Fenster und weise ihm den Zielnamen zu.

B.9 Anmerkungen zur Zugänglichkeit

Die W3C Web Accessibility Initiative ([WAI]) erarbeitet eine Reihe von Richtlinien, um die Zugänglichkeit zum Web für Menschen mit Behinderungen zu verbessern. Es gibt drei verschiedene Richtlinien:

B.10 Anmerkungen zur Sicherheit

Anker, eingebettete Graphiken und alle anderen Elemente, die URIs als Parameter enthalten, können veranlassen, dass ein URI als Antwort auf eine Benutzereingabe aufgelöst wird. In diesem Fall sollten die Sicherheitsfragen in [RFC1738], Abschnitt 6, beachtet werden. Die weit verbreiteten Methoden, Formularanfragen zu übermitteln – HTTP und SMTP – bieten wenig Sicherheit in Bezug auf eine vertrauliche Behandlung. Informationsanbieter, die sensitive Informationen über Formulare einfordern – insbesondere mit dem Element INPUT und gesetztem type=»password« – sollten sich über diesen Mangel an Vertraulichkeit im Klaren und es ihren Benutzern bewusst machen.

Anmerkung der Übersetzer:

Neben der Verantwort der Site-Betreiber, sollten die Benutzer selbst darauf achten, welche Sicherheit eine Site bietet. Die Browser bieten in der Regel vielfältige Konfigurationsmöglichkeiten. Dazu gehört zum Beispiel die Option, beim Wechsel zwischen verschlüsselter und unverschlüsselter Datenübertragung informiert zu werden.

Sicherheitseinstellungen im Mozilla

B.10.1 Sicherheitsfragen zu Formularen

Ein Benutzerprogramm sollte keine Datei absenden, die der Benutzer nicht vorher ausdrücklich zur Absendung ausgewählt hat. Deshalb wird von Benutzerprogrammen erwartet, jeden voreingestellten Dateinamen zu bestätigen, der durch das Attribut value des Elements INPUT vorgeschlagen sein könnte. Versteckte Kontrollelemente dürfen keine Dateien angeben.

Diese Spezifikation enthält keinen Mechanismus zur Verschlüsselung von Daten; dies sollte von irgendwelchen anderen Mechanismen vorgesehen werden, die gerade für eine sichere Übertragung zur Verfügung stehen.

Wurde eine Datei hochgeladen, sollte das verarbeitende Programm sie verarbeiten und entsprechend speichern.