Semantik und Design bei <address></address>

[Thomas]

Hallöle,

Habe eine kleine Frage: Wie kann man das address-element semantisch korrekt verwenden um eine Adresse Europäisch üblich zu schreieben.

Es sollte so aussehen:

Name
Straße
PLZ Ort

Mit dem <address>-Element ist aber nur eine Adresse innerhalb einer einzigen Zeile möglich.

z.B.: Name. Straße, PLZ Ort

zugehöriger CODE:
<address>Name,
Straße,
PLZ Ort</address>

Das w3c hat auch keine Lösung parat un bietet mir <br>-Elemente an die semantisch absolut keinen Sinn machen.

Falls Ihr die Problematik ansatzweise verstanden habt, helft mir!

MfG
Thomas

[Rike-Benjamin Schuppner]

Hallo Thomas,

Mit dem <address>-Element ist aber nur eine Adresse innerhalb einer einzigen Zeile möglich.

Dann müssen wir noch ein paar span-Elemente hinzufügen.

<address>
    <span class="name">Name,</span>
    <span class="strasse">Straße,</span>
    <span class="ort">PLZ Ort</span>
</address>

Im Style sheet musst du nur noch

address span {
    display:block;
}

definieren. Dann sollte es gehen.

Wenn du PLZ und Ort noch untergliedern willst musst du es natürlich dahingehend abändern, dass diese wieder auf display:inline gesetzt werden.

Gruß

rbs

[Thomas]

Vielen Dank für eure Unterstützung,

Ich habe jedoch selber noch ein wenig nachgeforscht und habe die CSS-Eigenschaft white-space:pre entdeckt. Sie wird von Mozilla und IE6 interrpretiert und schafft den semantisch günstigsten Weg.

z.B. (natürlich besser mit class oder id):

<adsress stlye="white-space:pre;">
Name
oder sonstiges
Straße
PLZ Ort
</address>

[molily]

Hallo Thomas,

Ich habe jedoch selber noch ein wenig nachgeforscht und habe die CSS-Eigenschaft white-space:pre entdeckt. Sie wird von Mozilla und IE6 interrpretiert und schafft den semantisch günstigsten Weg.

z.B. (natürlich besser mit class oder id):

<adsress stlye="white-space:pre;">
Name
oder sonstiges
Straße
PLZ Ort
</address>

Dann fehlt bei allen Browsern, die das CSS nicht umsetzen, die klare Trennung zwischen den Zeilen, so wären wieder Kommas oder ähnliches nötig.
Das Element br ist momentan das bestmögliche und kompatibelste. Selbst wenn du es nicht für semantisch angemessen hälst, die existierenden *inhaltlichen* Trennungen über CSS zu lösen, ist semantisch gesehen noch unsinniger und dein »funktioniert auf beiden Browsern« wirklich kein hinreichendes Kriterium.

Mathias

[PeterK]

Hi

Ich glaube address ist eigentlicxh für IP-Addressen / Hostnamen gedacht.

Also <address>127.0.0.1</address>

Peter

[Michael Jendryschik]

Hallo,

Ich glaube address ist eigentlicxh für IP-Addressen / Hostnamen gedacht.

Du irrst, siehe http://www.edition-w3.de/TR/1999/REC-html401-19991224/struct/global.html#edef-ADDRESS.

Gruß,

MI

[MudGuard]

Hi,

Habe eine kleine Frage: Wie kann man das address-element semantisch korrekt verwenden um eine Adresse Europäisch üblich zu schreieben.
Es sollte so aussehen:
Name
Straße
PLZ Ort

Wie kommst Du darauf, daß das "europäisch üblich" sei?

Im United Kingdom sieht es z.B. so aus
Name
*Name des Hauses
**Hausnummer *Straße
*Ortsteil
Ort
*County
Postcode

In Irland und Isle of Man:
Name
*Name des Hauses
**Hausnummer *Straße
*Ortsteil
Ort
County

(mit * gekennzeichnete Teile müssen nicht vorhanden sein, mit ** gekennzeichnete Teile sind ebenfalls optional, aber können nur in Verbindung mit dem Rest der Zeile vorkommen - also Hausnummer ohne Straße gibt es nicht...)
Es gibt sicher noch weitere Abweichungen von dem von Dir genannten Schema - aber die such ich jetzt nicht raus...

Mit dem <address>-Element ist aber nur eine Adresse innerhalb einer einzigen Zeile möglich.
Das w3c hat auch keine Lösung parat un bietet mir <br>-Elemente an die semantisch absolut keinen Sinn machen.

Eine weitere semantische Unterteilung ist nicht vorgesehen, benutze span (oder sonstige inline-Elemente) mit class oder ähnliches für eine weitere Unterteilung.

cu,
Andreas

[at]

Hallo.

Falls Ihr die Problematik ansatzweise verstanden habt, helft mir!

Die nach meiner Ansicht einzige semantisch korrekte Lösung sieht folgenermaßen aus:

<address>
<dl>
<dt>Name</dt><dd>Der Name</dd>
<dt>Straße</dt><dd>Diestraße 0</dd>
<dt>PLZ, Ort</dt><dd>00000 Derort</dd>
</dl>
</address>

In Verbindung mit "address dt { display:none; ... }" sieht das Ergebnis auch wie erwartet aus.
Für mein Impressum benutze ich übrigens verschachtelte Listen.
MfG, at

[Michael Jendryschik]

Hallo,

Die nach meiner Ansicht einzige semantisch korrekte Lösung sieht folgenermaßen aus:

<address>
<dl>
<dt>Name</dt><dd>Der Name</dd>
<dt>Straße</dt><dd>Diestraße 0</dd>
<dt>PLZ, Ort</dt><dd>00000 Derort</dd>
</dl>
</address>

In Verbindung mit "address dt { display:none; ... }" sieht das Ergebnis auch wie erwartet aus.

Nicht jedoch, wenn der Benutzeragent nicht CSS-fähig ist, aus welchen Gründen auch immer. Ich stelle mir die Darstellung einer Adresse anders vor als so:

Name
    Der Name
  Straße
    Diestraße 0
  PLZ, Ort
    00000 Derort

Bitte bedenke darüber hinaus, dass das Element 'address' dazu verwendet wird, »um Kontaktinformationen für ein Dokument oder für einen bedeutenden Teil eines Dokuments, wie zum Beispiel ein Formular, bereitzustellen« [http://www.edition-w3.de/TR/1999/REC-html401-19991224/struct/global.html#edef-ADDRESS]. Das kann natürlich auch die Postanschrift sein.

Gruß,

MI

[at]

Hallo

Nicht jedoch, wenn der Benutzeragent nicht CSS-fähig ist, aus welchen Gründen auch immer. Ich stelle mir die Darstellung einer Adresse anders vor als so:

Name
    Der Name
  Straße
    Diestraße 0
  PLZ, Ort
    00000 Derort

Sicher sieht dies nicht gut aus, aber für die _Darstellung_ ist HTML ja gerade _nicht_ zuständig. -- Oh Gott, wem erzähle ich das? ;-)
Es ist semantisch korrekt, weswegen jeder die Information verarbeiten kann -- und darum geht es mir.
Im übrigen schalte ich bei mir nicht einmal alle <dt>s per CSS ab, denn bei "Telefon", "Telefax" etc. ist diese Schreibweise ja sogar gängig. Das gleiche gilt für die in meinem Impressum darunter stehende <dl> mit den Angaben der Verantwortlichkeiten. Allerdings setze ich prinzipiell Doppelpunkte an das Ende der <dt>s. Die hatte ich in meinem Beispiel schlicht vergessen.

Bitte bedenke darüber hinaus, dass das Element 'address' dazu verwendet wird, »um Kontaktinformationen für ein Dokument oder für einen bedeutenden Teil eines Dokuments, wie zum Beispiel ein Formular, bereitzustellen« [http://www.edition-w3.de/TR/1999/REC-html401-19991224/struct/global.html#edef-ADDRESS]. Das kann natürlich auch die Postanschrift sein.

Sicher kennzeichne ich auf meinen Seiten ausschließlich meine eigene Adresse mit <address>, da ich ja Urheber und Eigentümer meiner Seiten bin, also ein direkter Zusammenhang zwischen Adresse und Dokument besteht. Meinen Kunden setze ich ebenfalls nur deren Adresse in diese Tags. Bei Adressenlisten à la Gelbe Seiten haben <address>-Tags natürlich nichts zu suchen. Aber die Definitionslisten tangiert dies nicht.
MfG, at

[Michael Jendryschik]

Hallo,

Name
    Der Name
  Straße
    Diestraße 0
  PLZ, Ort
    00000 Derort

Sicher sieht dies nicht gut aus, aber für die _Darstellung_ ist HTML ja gerade _nicht_ zuständig.

Adressblöcke, wie ich sie kenne, zum Beispiel in Briefköpfen, sehen immer wie folgt aus (um bei dem Beispiel zu bleiben):

Der Name
  Diestraße 0

00000 Derort

Mit einer Definitionsliste, so wie du sie verwendest, zeichnest du zusätzlich nur implizit vorhandene Informationen aus (die Bedeutung der einzelnen Adresszeilen). Das mag in einer Umgebung, in der das wichtig ist, eine gute Idee sein. In einem XML-Dokument zum Beispiel, in dem mehrere Adressdaten festgehalten werden sollen, mit dem Ziel, Abfragen darauf zu realisieren wie »Wie viele Personen leben in Derort?«. Oder in einem HTML-Dokument, wenn es darum geht, Teile der Adresse per CSS differenziert formatieren zu können. Aber auch dann würde man womöglich eine andere Art der Auszeichnung wählen.

Natürlich ist HTML nicht für die Darstellung von Inhalten gedacht. Aber man sollte die Defaultdarstellung von Elementen im Auge behalten und darauf achten, dass man es mit der Auszeichnung impliziter Information nicht übertreibt. So kenne ich zum Beispiel kaum eine Seite, die ihren Navigationsblock zusätzlich noch mit

<h2 style="display:none">Navigation</h2>

überschreibt, obwohl das im Hinblick auf die Struktur der Seite durchaus sinnvoll sein könnte.

Gruß,

MI

[at]

Hallo.

Adressblöcke, wie ich sie kenne, zum Beispiel in Briefköpfen, sehen immer wie folgt aus (um bei dem Beispiel zu bleiben):

Der Name
  Diestraße 0

00000 Derort

Die Leerzeile ist ein Liebling der Post und lediglich bei Zieladressen gängig, wenngleich nicht notwendig.
Und um einmal von der Beispieladresse loszukommen, stell dir doch einfach mal vor, wie ein der deutschen Sprache nur eingeschränkt mächtiger eine Adresse wie die folgende sinnvoll um eine Zeile kürzt, weil seine Adressdatenbank zu wenig Platz dafür bereit hält:

XYZ GmbH
Gesellschaft für dies und das
Im Industriegebiet Ganzweitdraußen
Diestraße 0 (im Hof)
00000 Derort-Stadtteil

Diese Adressen sind in den oft hochschulnahen technikorientierten Gewerbe-/Industrie/-Technologie-"Parks"/-gebieten übrigens gängig, wie ich aus leidvoller Erfahrung als Gestalter von Briefbögen, Visitenkarten etc. berichten kann. Auch das Weglassen von Hausnummern bei kleinen Straßen und das Nennen von "Eigennamen" einen Hauses oder kurze Lagebeschreibungen à la "Ecke A/B" gehören zu diesen Informationen, die eigentlich sogar offen gekennzeichnet werden sollten, bei den dies jedoch meist aus gestalterischen Gründen unterbleibt.

Mit einer Definitionsliste, so wie du sie verwendest, zeichnest du zusätzlich nur implizit vorhandene Informationen aus (die Bedeutung der einzelnen Adresszeilen).

Genau das tut das "alt"-Attribut auch.

Das mag in einer Umgebung, in der das wichtig ist, eine gute Idee sein. In einem XML-Dokument zum Beispiel, in dem mehrere Adressdaten festgehalten werden sollen, mit dem Ziel, Abfragen darauf zu realisieren wie »Wie viele Personen leben in Derort?«. Oder in einem HTML-Dokument, wenn es darum geht, Teile der Adresse per CSS differenziert formatieren zu können. Aber auch dann würde man womöglich eine andere Art der Auszeichnung wählen.

Es steht dir frei das zu tun, auch wenn ich die von mir eingebrachte Idee für eine sinnvolle halte.

Natürlich ist HTML nicht für die Darstellung von Inhalten gedacht. Aber man sollte die Defaultdarstellung von Elementen im Auge behalten und darauf achten, dass man es mit der Auszeichnung impliziter Information nicht übertreibt.

Was ist übertrieben, was nicht? Diese Grenze wird wohl jeder selbst ziehen (müssen), da es keine Norm dafür gibt.

So kenne ich zum Beispiel kaum eine Seite, die ihren Navigationsblock zusätzlich noch mit

<h2 style="display:none">Navigation</h2>

überschreibt, obwohl das im Hinblick auf die Struktur der Seite durchaus sinnvoll sein könnte.

Und weil die meisten diese oft sinnvolle Ergänzung -- hattest du nicht auch anderswo auf http://www.w3.org/Consortium/Offices/Germany/Trans/WAI/webinhalt.html und besonders auf den Punkt der Möglichkeit, die Navigation in textbasierten Browsern zu überspringen, hingewiesen? -- sparen, soll man auch andere Nachlässigkeiten begehen?
Meine Navigationsleiste hat übrigens eine versteckte Überschrift -- schon deshalb, weil auf meinen Seiten einige verlinkte Listen kurzer Begriffe stehen, die eine Verwechselung begünstigen würden.
MfG, at

[Michael Jendryschik]

Und um einmal von der Beispieladresse loszukommen, stell dir doch einfach mal vor, wie ein der deutschen Sprache nur eingeschränkt mächtiger eine Adresse wie die folgende sinnvoll um eine Zeile kürzt, weil seine Adressdatenbank zu wenig Platz dafür bereit hält:

Wollen wir jetzt über das Konzept einer Adressdatenbank reden?

Mit einer Definitionsliste, so wie du sie verwendest, zeichnest du zusätzlich nur implizit vorhandene Informationen aus (die Bedeutung der einzelnen Adresszeilen).

Genau das tut das "alt"-Attribut auch.

Nein, ganz im Gegenteil. Der Aspekt der Zugänglichkeit erfordert oftmals, dass die gleiche Information auf unterschiedliche Arten bereitgestellt wird, zum Beispiel sowohl als Grafik als auch als Text. Beide Formate transportieren gewissermaßen die »gleiche« Information, allerdings auf zwei unterschiedlichen Ebenen. Durch eine Definitionsliste zur Auszeichnung von Adressen erreichst du etwas anderes, du fügst nämlich Informationen hinzu.

So kenne ich zum Beispiel kaum eine Seite, die ihren Navigationsblock zusätzlich noch mit

<h2 style="display:none">Navigation</h2>

überschreibt, obwohl das im Hinblick auf die Struktur der Seite durchaus sinnvoll sein könnte.

Und weil die meisten diese oft sinnvolle Ergänzung -- hattest du nicht auch anderswo auf http://www.w3.org/Consortium/Offices/Germany/Trans/WAI/webinhalt.html und besonders auf den Punkt der Möglichkeit, die Navigation in textbasierten Browsern zu überspringen, hingewiesen? -- sparen, soll man auch andere Nachlässigkeiten begehen?

Ich sehe keinen Zusammenhang zwischen einer zusätzlichen Überschrift und der Möglichkeit, die Navigation zu überspringen, um direkt zum relevanten Teil des Dokuments zu gelangen.

Gruß,

MI

[at]

Hallo.

Wollen wir jetzt über das Konzept einer Adressdatenbank reden?

Meinetwegen können wir das, auch wenn es mir nicht darum ging.
Wichtig ist mir, den von mir produzierten Dokumenten eindeutige Informationen angedeihen zu lassen. Ich verzichte im Sinne einer gebräuchlichen Schreibweise lediglich auf die explizite grafische Darstellung dieser -- wenn man so will -- Metainformation.

Nein, ganz im Gegenteil. Der Aspekt der Zugänglichkeit erfordert oftmals, dass die gleiche Information auf unterschiedliche Arten bereitgestellt wird, zum Beispiel sowohl als Grafik als auch als Text. Beide Formate transportieren gewissermaßen die »gleiche« Information, allerdings auf zwei unterschiedlichen Ebenen. Durch eine Definitionsliste zur Auszeichnung von Adressen erreichst du etwas anderes, du fügst nämlich Informationen hinzu.

Nein, der Begriff "Definition" sollte bereits klarstellen, dass hier lediglich ein Begriff (z. B. "Straße") im Sinne des Dokuments -- insbesondere bei <address> -- definiert bzw. genauer spezifiziert wird. Wenn das nicht "gewissermaßen die »gleiche« Information, allerdings auf zwei unterschiedlichen Ebenen" ist, was dann?
Aber wenn dir "alt"-Angaben nicht hinreichend ähnlich sind, werfe ich dir eben Metaangaben vor die Füße.

Ich sehe keinen Zusammenhang zwischen einer zusätzlichen Überschrift und der Möglichkeit, die Navigation zu überspringen, um direkt zum relevanten Teil des Dokuments zu gelangen.

Nun, beides stellt einen Mehrwert für Benutzer nichtgrafischer User-Agents dar. Es täte mir sehr leid, wenn du diesen Zusammenhang also tatsächlich nicht erkennen könntest. Oder versuchst du nur, mir nicht Recht geben zu müssen? ;-)
MfG, at

[Michael Jendryschik]

Hallo,

Nein, ganz im Gegenteil. Der Aspekt der Zugänglichkeit erfordert oftmals, dass die gleiche Information auf unterschiedliche Arten bereitgestellt wird, zum Beispiel sowohl als Grafik als auch als Text. Beide Formate transportieren gewissermaßen die »gleiche« Information, allerdings auf zwei unterschiedlichen Ebenen. Durch eine Definitionsliste zur Auszeichnung von Adressen erreichst du etwas anderes, du fügst nämlich Informationen hinzu.

Nein, der Begriff "Definition" sollte bereits klarstellen, dass hier lediglich ein Begriff (z. B. "Straße") im Sinne des Dokuments -- insbesondere bei <address> -- definiert bzw. genauer spezifiziert wird. Wenn das nicht "gewissermaßen die »gleiche« Information, allerdings auf zwei unterschiedlichen Ebenen" ist, was dann?

Bei

<dt>Straße:</dt>
  <dd>DieStraße 0</dd>

handelt es sich mitnichten um die gleiche Information. Es handelt sich um ein Paar aus »definition term« und »definition description«, das einen Listenpunkt einer Definitionsliste darstellt. Der Inhalt des einen Elements ersetzt nicht den Inhalt des anderen, vielmehr ergänzen sich beide Elemente zu einer Einheit. Vergleiche das mit folgendem:

<img src="http://w3.org/Icons/w3c_main" alt="World Wide Web Consortium (W3C)" />

Dabei handelt es sich um folgendes Bild:

<img src="http://www.w3.org/Icons/w3c_main" border="0" alt="">

Das alternative Attribut ist keine Ergänzung, sondern ein *Ersatz* für die grafische Darstellung des Bildes mit dem Ziel, die Information des Bildes zu transportieren, falls dieses nicht angezeigt werden kann. Ich hoffe, du verstehst den Unterschied.

Um es noch einmal deutlich zu machen: Ich sehe überhaupt keinen Mehrwert für den Betrachter deiner Seiten, wenn du ihm Informationen vorsetzt, die er nicht benötigt. Angaben wie »Name:«, »Straße:« oder »Ort:« vor den Adresszeilen sind vollkommen überflüssig, vor allem auch deswegen, weil er diese im alltäglichen Gebrauch mit Adressen auch nicht benötigt. Du wirst vermutlich argumentieren, dass du sie aus eben diesem Grund ausblendest, übersiehst dabei aber, dass es Benutzeragenten gibt, die mit CSS nicht viel am Hut haben und diese überflüssigen Informationen darstellen.

Aber wenn dir "alt"-Angaben nicht hinreichend ähnlich sind, werfe ich dir eben Metaangaben vor die Füße.

Du müsstest mir näher erläutern, was du damit sagen möchtest.

Gruß,

MI

[Tim Tepaße]

Hallo ihr zwei,

(Diskussionen über semantisch korrekte Auszeichnungen von Adressen, die
vollkommen ignorieren, daß address keine Blockelemente enhalten darf)

Wie lange dauert es noch, bis Ihr beide euch einen eigenen RDF/OWL-Standard
für das Auszeichnen von postalischen Adressen bastelt? ;-)

So wie die hier:

http://space.frot.org/index.html
  http://www.w3.org/2000/10/swap/pim/usps

(Oder ihr benutzt gleich Länge und Breite bzw. nearestAirport, wie es die
FOAF-Jungs tun)

Tim

[at]

Hallo.

(Diskussionen über semantisch korrekte Auszeichnungen von Adressen, die
vollkommen ignorieren, daß address keine Blockelemente enhalten darf)

Das war mir bisher nicht aufgefallen, aber ich werde das <address>-Tag dann wohl nicht weiter verwenden, da es sich damit selbst disqualifiziert :-(

Wie lange dauert es noch, bis Ihr beide euch einen eigenen RDF/OWL-Standard
für das Auszeichnen von postalischen Adressen bastelt? ;-)

Sobald ich meine Seiten in XML/XSLT schreibe, werde ich diese Dinge wohl in eine DTD bannen :-)

So wie die hier:

http://space.frot.org/index.html
  http://www.w3.org/2000/10/swap/pim/usps

Das mag seltsam anmuten, aber wenn es der Sache dienlich ist, ist es gut :-)

(Oder ihr benutzt gleich Länge und Breite bzw. nearestAirport, wie es die
FOAF-Jungs tun)

Das würde das Problem leider nur auf eine andere Ebene verschieben, aber es wäre sicher ebenso korrekt wie unterhaltsam ;-)
MfG, at

[Michael Jendryschik]

Hallo,

(Diskussionen über semantisch korrekte Auszeichnungen von Adressen, die
vollkommen ignorieren, daß address keine Blockelemente enhalten darf)

Das war mir bisher nicht aufgefallen, aber ich werde das <address>-Tag dann wohl nicht weiter verwenden, da es sich damit selbst disqualifiziert :-(

Das ist die falsche Konsequenz. Verwende doch statt dessen einfach keine Definitionsliste darin. :-)

Gruß,

MI

[at]

Hallo.

Das ist die falsche Konsequenz. Verwende doch statt dessen einfach keine Definitionsliste darin. :-)

Nein, da ich die Information, dass es sich um eine Adresse handelt, ja sowohl menschenlesbar im <body>-Bereich, als auch maschinenlesbar im <head>-Bereich stehen habe, verringere ich gern ein wenig Redundanz :-)
MfG, at

[at]

Hallo.

Bei

<dt>Straße:</dt>
  <dd>DieStraße 0</dd>

handelt es sich mitnichten um die gleiche Information. Es handelt sich um ein Paar aus »definition term« und »definition description«, das einen Listenpunkt einer Definitionsliste darstellt. Der Inhalt des einen Elements ersetzt nicht den Inhalt des anderen, vielmehr ergänzen sich beide Elemente zu einer Einheit.

In diesem Fall kann ich mich nur selbst zitieren: Es wird "im Sinne des Dokuments [...] definiert bzw. genauer spezifiziert".

Du müsstest mir näher erläutern, was du damit sagen möchtest.

Metaangaben sind zusätzliche Informationen, die nicht wahrgenommen werden müssen, aber einen Mehrwert bieten, obwohl sie im Normalfall nicht dargestellt werden. Ich schreibe also gewissermaßen die Schlüsselworte "Straße", "Ort" etc. als Metaangaben in den Text, so wie andere dies auch mit ihren Angaben zur Urheberschaft etc. tun.
MfG, at

[Michael Jendryschik]

Bei

<dt>Straße:</dt>
  <dd>DieStraße 0</dd>

handelt es sich mitnichten um die gleiche Information. Es handelt sich um ein Paar aus »definition term« und »definition description«, das einen Listenpunkt einer Definitionsliste darstellt. Der Inhalt des einen Elements ersetzt nicht den Inhalt des anderen, vielmehr ergänzen sich beide Elemente zu einer Einheit.

In diesem Fall kann ich mich nur selbst zitieren: Es wird "im Sinne des Dokuments [...] definiert bzw. genauer spezifiziert".

Halten wir fest, dass wir unterschiedlicher Ansicht sind.

Gruß,

MI

[at]

Hallo.

Halten wir fest, dass wir unterschiedlicher Ansicht sind.

Zumindest da sind wir uns einig ;-)
MfG, at

[molily]

Hallo Michael,

Ich sehe überhaupt keinen Mehrwert für den Betrachter deiner Seiten, wenn du ihm Informationen vorsetzt, die er nicht benötigt. Angaben wie »Name:«, »Straße:« oder »Ort:« vor den Adresszeilen sind vollkommen überflüssig, vor allem auch deswegen, weil er diese im alltäglichen Gebrauch mit Adressen auch nicht benötigt.

Das kann ich mir nicht vorstellen. Bereits bei einigen längeren englischen Adressen ist mir unbekannt, was die einzelnen Zeilen bedeuten. Ich verlasse mich ausschließlich auf die Reihenfolge, aber die Bedeutung der Wörter und Zahlen verschließt sich mir oft (man kann Eigennamen und Nummern unterschiedlich deuten usw.). Ich könnte beispielsweise nicht ohne weiteres anhand einer solchen Anschrift das betreffende Haus finden. Mein teilweises Verständnis fußt lediglich auf Vermutungen und ebenso hypothetische Schlussfolgerungen aus dem Kontext und einigen bekannten Begriffen. Bei Adressen aus Ländern am anderen Ende der Welt in tiefster Provinz in einer Sprache, die mir komplett unbekannt ist, beschränke ich mich darauf, die Adresse eins zu eins auf die Sendung zu übertragen. Aber was das alles bedeutet usw., ist für mich beileibe nicht selbstverständlich bzw. selbsterklärend.
Das ist nur meine persönliche Erfahrung - nun bedenke man, dass es in der Welt unzählige Sprachen und Schriften sowie unzählige Adresschemen und -varianten gibt. Es ist vor allem im WWW jederzeit möglich, dass ein Leser die Adresse benutzen und verstehen muss, obwohl er der Sprache nicht hinreichend mächtig ist, die regionale Begrifflichkeiten und Abkürzungen ungewohnt sind, das Adressschema absolut fremd oder möglicherweise die Fähigkeit des logischen Kombinierens eingeschränkt ist. Für ihn ist ebenfalls nichts selbstverständlich, und die Zusatzinformationen, welche Eindeutigkeit schaffen, wären sehr hilfreich.
Verallgemeinert gesehen ist Eindeutigkeit meiner Meinung nach ein Grundbaustein einer zugänglichen Seite, das gilt prinzpiell auch für die hinterletzte private Homepage, aber vor allem wenn das Publikum breiter und der Anspruch der Seite entsprechend anders ist, sehe ich Notwendigkeit und praktische Relevanz diesbezüglich und erkenne in deiner pauschalen Aussage keine Wahrheit.

Grüße,
Mathias

[at]

Hallo.

Das kann ich mir nicht vorstellen. Bereits bei einigen längeren englischen Adressen ist mir unbekannt, was die einzelnen Zeilen bedeuten. Ich verlasse mich ausschließlich auf die Reihenfolge, aber die Bedeutung der Wörter und Zahlen verschließt sich mir oft (man kann Eigennamen und Nummern unterschiedlich deuten usw.). Ich könnte beispielsweise nicht ohne weiteres anhand einer solchen Anschrift das betreffende Haus finden. Mein teilweises Verständnis fußt lediglich auf Vermutungen und ebenso hypothetische Schlussfolgerungen aus dem Kontext und einigen bekannten Begriffen. Bei Adressen aus Ländern am anderen Ende der Welt in tiefster Provinz in einer Sprache, die mir komplett unbekannt ist, beschränke ich mich darauf, die Adresse eins zu eins auf die Sendung zu übertragen. Aber was das alles bedeutet usw., ist für mich beileibe nicht selbstverständlich bzw. selbsterklärend.

Erst vor kurzem war ich in einer solchen Situation: Als ich die Anschrift eines italienischen Unternehmens notierte, wies mich ein nebenstehender Deutsch-Italiener darauf hin, dass ich nicht nur die Anschrift, sondern die in Italien für die Rechnungstellung offenbar notwendige Steuernummer (USt-ID?) notiert hatte, die sein italienischer Kollege zusätzlich notiert hatte. Ich hätte diese Nummer sicher auf jeden Brief und jedes Paket für dieses Unternehmen geschrieben.
Das hat mich in Bezug auf dieses Thema weiter sensibilisiert, weswegen ich auch Telefonnummern und Postleitzahlen inzwischen international angebe.
MfG, at

[molily]

Hallo,

Natürlich ist HTML nicht für die Darstellung von Inhalten gedacht. Aber man sollte die Defaultdarstellung von Elementen im Auge behalten und darauf achten, dass man es mit der Auszeichnung impliziter Information nicht übertreibt. So kenne ich zum Beispiel kaum eine Seite, die ihren Navigationsblock zusätzlich noch mit

<h2 style="display:none">Navigation</h2>

überschreibt, obwohl das im Hinblick auf die Struktur der Seite durchaus sinnvoll sein könnte.

Das mag daran liegen, dass der Anteil der Seiten, welche sich um Barrierefreiheit bzw. Benutzbarkeit und Verständlichkeit unter verschiedenen Umständen und Voraussetzungen bemühen, verschwindend gering ist. Dahinter steckt eher Unkenntnis als Kalkül.
Ich halte diese Zusatzinformation durchaus für verständnisfördernd, gerade im Hinblick auf Orientierung und Rückmeldung/Bestätigung dokumentinterner Querlinks. Allerdings ist »Navigation« m.E. unpräzise, meist ist »Hauptrubriken« gemeint, bei Sekundärnavigationen und »verwandte Dokumente« müssen entsprechend andere passende Begriffe her; aber das hängt von der jeweiligen Sitestruktur und -ordnung ab, man denke an verschachtelte Navigationen, bei welchen die Verschachtelungsebenen nicht in jedem Fall eindeutig kommuniziert werden, da *können* Zusatzinformationen helfen, oder ein Überdenken des Navigationskonzepts.

Mathias

[at]

Hallo.

Ich halte diese Zusatzinformation durchaus für verständnisfördernd, gerade im Hinblick auf Orientierung und Rückmeldung/Bestätigung dokumentinterner Querlinks. Allerdings ist »Navigation« m.E. unpräzise, meist ist »Hauptrubriken« gemeint, bei Sekundärnavigationen und »verwandte Dokumente« müssen entsprechend andere passende Begriffe her; aber das hängt von der jeweiligen Sitestruktur und -ordnung ab, man denke an verschachtelte Navigationen, bei welchen die Verschachtelungsebenen nicht in jedem Fall eindeutig kommuniziert werden, da *können* Zusatzinformationen helfen, oder ein Überdenken des Navigationskonzepts.

Wobei zu bedenken ist, dass bei nicht eindeutigen Navigationen, also eben solchen, "bei welchen die Verschachtelungsebenen nicht in jedem Fall eindeutig kommuniziert werden", das Kind bereits in den Brunnen gefallen ist. Aber ich gebe gern zu, dass eine vernünftige Navigation auf weit gefächerten Seiten sehr schwierig umzusetzen ist, wenn man den Nutzer nicht überforden oder zumindest überfrachten will.
MfG, at

[Tim Tepaße]

Hallo at,

Es ist semantisch korrekt, weswegen jeder die Information verarbeiten kann

Es liefert vielleicht semantischen Mehrwert für denjenigen, der noch nie
eine postalische Adresse gesehen hat. Maschinenlesbare Semantik ist dies
jedoch nicht.
(Und es ist syntaktisch flasch)

In XHTML 2 ist meines Wissens eine genauere Definition des Inhaltmodells
von <address> geplant.

Tim

[at]

Hallo.

Es liefert vielleicht semantischen Mehrwert für denjenigen, der noch nie
eine postalische Adresse gesehen hat. Maschinenlesbare Semantik ist dies
jedoch nicht.

Für wen schreibst du deine Seiten?

(Und es ist syntaktisch flasch)

Das kann ich nicht finden, weswegen ein Hauch von Erklärung sicher nicht schaden kann.

In XHTML 2 ist meines Wissens eine genauere Definition des Inhaltmodells
von <address> geplant.

Du wirst verstehen, dass ich nicht bis dahin warten werde ;-)
MfG, at