Impressum richtig auszeichnen

[Anton]

Guten Morgen,

hab eine Frage was das Markup meines Impressums angeht. Bisher hab ich das Markup folgendermaßen umgesetzt:

  
<h2>Impressum</h2>  
    <h3>Das Internetangebot wird herausgegeben von:</h3>  
    <address>  
         Firma ABC<br/>  
         Amselweg 2<br/>  
	 12345 Münchhausen<br/>  
	 Telefon: [phone]<br/>  
	 Telefax: 12345/789<br/>  
	 E-Mail: [e-mail]<br/>  
    </address>  
  
    <h3>Umsatzsteueridentnummer:</h3>  
    <p>DE...</p>  
  
    <h3>Verantwortlich:</h3>  
    <p>Harry Hirsch</p>  
  
    <h3>Redaktion:</h3>  
    <address>  
	 Firma ABC<br/>  
         Amselweg 2<br/>  
	 12345 Münchhausen<br/>  
	 Telefon: [phone]<br/>  
	 Telefax: 12345/789<br/>  
	 E-Mail: [e-mail]<br/>  
    </address>  
			  
    <h3>Bildnachweis / Copyright:</h3>  
    <p>Harry Hirsch</p>  
  
    <h3>Gestaltung, Realisierung und Technischer Betrieb:</h3>  
    <address>  
         Firma ABC<br/>  
         Amselweg 2<br/>  
	 12345 Münchhausen<br/>  
	 Telefon: [phone]<br/>  
	 Telefax: 12345/789<br/>  
	 E-Mail: [e-mail]<br/>		  
    </address>  
			  
    <h3>Hinweis:</h3>  
    <p>Für Vollständigkeit, Fehler redaktioneller und technischer Art, Auslassungen usw. sowie die Richtigkeit der Eintragungen kann keine Haftung übernommen werden. Insbesondere kann keine Gewähr für...</p>  
  
    <p>Die Verantwortlichkeit für diese fremden Inhalte liegt alleine bei dem Anbieter, der die Inhalte bereithält. Vor dem Einrichten des entsprechenden Verweises sind die Web-Seiten der anderen Anbieter mit großer Sorgfalt und nach... </p>  

Spricht irgendwas gegen diese Umsetzung?

Semantisch würde vielleicht besser eine Definitionsliste passen. Alle <h3>-Elemente würde ich dann in <dt> ändern. Die <p>- und <address>-Elemente würde ich in <dd> ändern. Das würde dann z.B. ungefähr so aussehen:

  
<dl>  
  <dt>Bildnachweis / Copyright:</dt>  
  <dd>Harry Hirsch</dd>  
  
  <dt>Gestaltung, Realisierung und Technischer Betrieb:</dt>  
  <dd>  
         Firma ABC<br/>  
         Amselweg 2<br/>  
	 12345 Münchhausen<br/>  
	 Telefon: [phone]<br/>  
	 Telefax: 12345/789<br/>  
	 E-Mail: [e-mail]<br/>		  
   </dd>  
   <h3>Hinweis:</h3>  
   <dd>Für Vollständigkeit, Fehler redaktioneller und technischer Art, Auslassungen usw. sowie die Richtigkeit der Eintragungen kann keine Haftung übernommen werden. Insbesondere kann keine Gewähr für...</dd>  
</dl>  

An dieser Umsetzung stört mich allerdings so folgends:

Die eigentliche Adresse müßte ja eigentlich wie im oberen Beispiel auch als Adresse ausgezeichnet werden. Im unteren Beispiel wird sie jetzt mit <dd> ausgezeichnet. Wäre das vertretbar, oder kann man das besser lösen?

Die Definiton für "Hinweis" war vorher ein Absatz. Das war meines erachtens semantisch auch richtig. Nun erhält die Definiton von Hinweis <dd> als Markup was doch eigentlich semantisch falsch ist.

Welche der beiden Lösungsvarianten würdet ihr bevorzugen bzw. was wäre die ideale Lösung um das Impressum auszuzeichnen?

[Cheatah]

Hi,

Spricht irgendwas gegen diese Umsetzung?

nur inhaltlich: Den Bereich "Hinweis" kannst Du komplett streichen. Er hat offenbar den Zweck, rechtliche Verantwortung abzuschieben, die die Verantwortlichen entweder haben oder nicht haben - in beiden Fällen unveränderlich. Erfahrungsgemäß ist die einzige Wirkung solcher Disclaimer ein potenziell erhöhtes Strafmaß, weil mit ihm klar gezeigt wird, dass man sich der Verantwortung bewusst war.

Semantisch würde vielleicht besser eine Definitionsliste passen.

Nein, eher nicht. <address> ist perfekt, und auch wenn diese in <dd> erlaubt sind, stellst Du mit Deiner Idee das Konzept von Überschriften in Frage. Hierfür sehe ich aber keinen Grund, Überschriften halte ich für eine prima Sache.

Die Definiton für "Hinweis" war vorher ein Absatz. Das war meines erachtens semantisch auch richtig. Nun erhält die Definiton von Hinweis <dd> als Markup was doch eigentlich semantisch falsch ist.

Mal angenommen, <dl> sei eine gute Lösung: Das Content-Modell von <dd> lautet (%flow;)*, was <p>-Elemente einschließt.

Cheatah

[suit]

Nein, eher nicht. <address> ist perfekt, und auch wenn diese in <dd> erlaubt sind, stellst Du mit Deiner Idee das Konzept von Überschriften in Frage. Hierfür sehe ich aber keinen Grund, Überschriften halte ich für eine prima Sache.

Sehe ich auch so - ich würde sogar noch ein address-Element zusätzlich einfügen

    <h3>Verantwortlich:</h3>  
    <p>Harry Hirsch</p>

ersetzen durch

    <h3>Verantwortlich:</h3>  
    <address>Harry Hirsch</address>

Da das Element zum Auszeichenen von Kontaktinformationen gedacht ist - und auch die richtige Ansprechperson ist imho eine Kontaktinformation.

Zudem würde ich auf die Doppelpunkte hinter den Überschriften verzichten und diese, wenn sie denn gestalterisch notwendig sind, per CSS (:after und notfalls als Hintergrundbild) einfügen.

[molily]

Zudem würde ich auf die Doppelpunkte hinter den Überschriften verzichten und diese, wenn sie denn gestalterisch notwendig sind, per CSS (:after und notfalls als Hintergrundbild) einfügen.

Das ist absolut Banane! after & content können nicht alle Browser und ein Hintergrundbild ist aus verschiedenen Gründen unangebracht: Man bringt Schrift in einer Grafik unter (unzugänglich, schmiegt sich nicht ein, skaliert nicht, wird hässlich aussehen), man bindet eine weitere Ressource ein, die vom Browser geholt werden muss, man muss ggf. ein weiteres span einfügen, um das Hintergrundbild hinter dem Text zu positionieren.

Wenn man auf die Doppelpunkte verzichten will, okay, dann soll man sie einfach weglassen, aber diese Vorschläge machen es nur schlechter.

Mathias

[Struppi]

Das ist absolut Banane! after & content können nicht alle Browser ...

und deshalb rätst du dazu, es nicht zu verwenden?

Da es i.d.R. um gestalterische Elemente geht, deren fehlen den Nutzen der Seite nicht einschränken, halte ich das für kein Problem. Ich nutze :before/:after schon seit mehreren Jahren, ohne irgendwelche Hemmungen.

Struppi.

[Anton]

»» Das ist absolut Banane! after & content können nicht alle Browser ...

und deshalb rätst du dazu, es nicht zu verwenden?

Da es i.d.R. um gestalterische Elemente geht, deren fehlen den Nutzen der Seite nicht einschränken, halte ich das für kein Problem. Ich nutze :before/:after schon seit mehreren Jahren, ohne irgendwelche Hemmungen.

Struppi.

Nach dem Prinzip, wenns klappt dann sieht die Seite besser aus, wenns nicht klappt ist die Seite trotzdem in Ordnung...

[molily]

Das ist absolut Banane! after & content können nicht alle Browser ...

und deshalb rätst du dazu, es nicht zu verwenden?

Nein, aber ich kenne wenige sinnvolle Anwendungen von content im Zusammenhang mit before und after (einige Beispiele v.a. für Benutzerstylesheets), und wenn ich recht nachdenke, war es höchstens der Clearfix, den ich auf breiter Basis verwendet habe.

Was jedenfalls das Einfügen von »:« angeht, so weiß ich nicht, wieso man eine derartige Komplexität einbauen sollte, wo der Aufwand in keinem Verhältnis zum Nutzen steht.

Mathias

[molily]

Da es i.d.R. um gestalterische Elemente geht, deren fehlen den Nutzen der Seite nicht einschränken, halte ich das für kein Problem.

Was sind denn gestalterische Elemente. Wenn ich z.B. vor jedem Link irgendein Zeichen haben soll, dann, weil dieser Link irgendeine spezielle Bedeutung hat. Diese Symbolik und diesen Wiedererkennungswert will ich dann natürlich auch IE-Nutzern angedeihen lassen, und schon schränkt deren Fehlen den Nutzen ein, weil die UI-Logik dann in einem Browser inkonsistent ist.

Mathias

[suit]

Was sind denn gestalterische Elemente. Wenn ich z.B. vor jedem Link irgendein Zeichen haben soll, dann, weil dieser Link irgendeine spezielle Bedeutung hat. Diese Symbolik und diesen Wiedererkennungswert will ich dann natürlich auch IE-Nutzern angedeihen lassen, und schon schränkt deren Fehlen den Nutzen ein, weil die UI-Logik dann in einem Browser inkonsistent ist.

Wenn ich jeden externen Link mit einem Symbol kennzeichnen und die Sprache ebenfalls mit einem ISO-Code suffixen will, kann ich das mit dem Attribut-Selektor machen. Der IE6 versteh diesen nicht, muss ich daher eine Information die im HTML bereits enthalten ist (z.B. im rel- und hreflang-Attribut) jetzt nochmal redundant einfügen, nur weil ein Browser zu dämlich dafür ist?

Muss jeder Mehrwert jedem Benutzer zur Verfügung stehen?

[molily]

Wenn ich jeden externen Link mit einem Symbol kennzeichnen

ist das eine wichtige UI-Konvention, die ich auf einer Site jedem Benutzer zukommen lassen will, gleich welchen Browser er verwendet. Ich bin wirklich dafür, jeden Browser nach seinen Fähigkeiten zu behandeln, aber wenn man eine UI baut, ist es vor allem wichtig, dass diese Cross-Browser dieselbe intuitive Sprache spricht, anstatt dass gewisse hilfreiche Strukturen einfach fehlen. Wenn nichtmal derselbe Benutzer auf verschiedenen Browsern denselben Look & Feel vorfindet, wie soll ich dann allen die Benutzung beibringen und dokumentieren.

und die Sprache ebenfalls mit einem ISO-Code suffixen will

Gut, das erachte ich für weniger wichtig, also könnte dafür meinetwegen after/content verwendet werden.

Der IE6 versteh diesen nicht, muss ich daher eine Information die im HTML bereits enthalten ist (z.B. im rel- und hreflang-Attribut) jetzt nochmal redundant einfügen

Es gibt sehr viele Informationen, die im HTML enthalten sein können, ohne dass sie je dem Benutzer kommuniziert werden. Wozu bringe ich sie dort unter, wenn sie es nicht werden und ich auch keine Workarounds einbaue, damit sie es werden?

Mathias

[suit]

Wozu bringe ich sie dort unter, wenn sie es nicht werden und ich auch keine Workarounds einbaue, damit sie es werden?

Der Workaround für nicht-:content-fähige Browser ist die Hintergrundgrafik-Variante, aber das ist für dich ja Banane :)

Ein Workaround heisst für mich nicht, den HTML-Code zu "versauen".

[ChrisB]

Hi,

Ein Workaround heisst für mich nicht, den HTML-Code zu "versauen".

Workaround heisst fuer mich, ein nicht zufriedenstellend auf andere Weise loesbares Problem unter einem vertretbaren Masz an "Mehraufwand" zu umgehen, wobei man eine Abweichung von einer "reinen Lehre" auch mal bewusst in Kauf nimmt.

Und HTML in seiner derzeitigen Form ist zur adaequaten Auszeichnung der Inhalte, fuer die es heutzutage verwendet wird, eh dermaszen unzulaenglich, dass sich solche Kleinigkeiten auch durchaus verschmerzen lassen.

MfG ChrisB

[Struppi]

» Da es i.d.R. um gestalterische Elemente geht, deren fehlen den Nutzen der Seite nicht einschränken, halte ich das für kein Problem.

Was sind denn gestalterische Elemente. Wenn ich z.B. vor jedem Link irgendein Zeichen haben soll, dann, weil dieser Link irgendeine spezielle Bedeutung hat. Diese Symbolik und diesen Wiedererkennungswert will ich dann natürlich auch IE-Nutzern angedeihen lassen, und schon schränkt deren Fehlen den Nutzen ein, weil die UI-Logik dann in einem Browser inkonsistent ist.

Der Nutzen wird doch nicht eingeschränkt, wenn ein externer Link nicht sofort optisch erkannt wird. Ich hab' keine Probleme dieses Gimmick den IE Nutzern vorzuhalten.

Wofür ich es z.b. auch verwende:

#werbung:before {  
    content:"Anzeige";  
    font-size:0.7em;  
    display:block;  
    text-align:left;  
}  

Struppi.

[molily]

Wofür ich es z.b. auch verwende:
#werbung:before {
    content:"Anzeige";

Das wäre für mich eine essentielle inhaltliche Information, die nichts mit einer spezifischen optionalen Präsentation zu tun hat, welche das Stylesheet regelt - zumal mit Techniken, die nur von einigen CSS-fähigen Browsern dargestellt werden.

Mathias

[Struppi]

» Wofür ich es z.b. auch verwende:
» #werbung:before {
»     content:"Anzeige";

Das wäre für mich eine essentielle inhaltliche Information, die nichts mit einer spezifischen optionalen Präsentation zu tun hat, welche das Stylesheet regelt - zumal mit Techniken, die nur von einigen CSS-fähigen Browsern dargestellt werden.

Tja, so sieht es jeder anders. Für mich ist das lediglich ein zusätzlicher Hinweis, den ich den meisten Besucher der Seite anbiete, ohne den Quellcode im Skript ändern zu müssen (wobei das im konkreten Fall eine zwiespältige Sache ist, da die Anwendung noch ohne Templates umgesetzt wurde, dort wäre so ein Hinweis eher aufgebhoben).

Essentiell ist diese Information aber nicht, da die Werbung auch so erkennbar ist.

Struppi.

[Gunnar Bittersmann]

@@Struppi:

Tja, so sieht es jeder anders. […]
Essentiell ist diese Information aber nicht, da die Werbung auch so erkennbar ist.

Anwälte könnten das anders sehen.

Die Kennzeichnung „Anzeige“ gehört für mich zum Inhalt, also ins HTML.

Live long and prosper,
Gunnar

[Struppi]

» Tja, so sieht es jeder anders. […]
» Essentiell ist diese Information aber nicht, da die Werbung auch so erkennbar ist.

Anwälte könnten das anders sehen.

Ja in einem redaktionellen Umfeld.

Die Kennzeichnung „Anzeige“ gehört für mich zum Inhalt, also ins HTML.

D.h. noch ein DIV (oder SPAN) Elemente, mit einer ID?
Für mich ist ein zusatzfeature, wenn der Browser das kann.

Struppi.

[suit]

Essentiell ist diese Information aber nicht, da die Werbung auch so erkennbar ist.

Ich kenne da jetzt die Rechtslage nicht, aber ich meine irgendwo gehört zu haben, dass man in Deutschland Werbung als solche kennzeichnen MUSS wenn es nicht ersichtlich ist, dass es Werbung ist - und was als Werbung ersichtlich ist oder nicht, ist teilweise schon sehr schwer zu sagen :)

[suit]

Wenn man auf die Doppelpunkte verzichten will, okay, dann soll man sie einfach weglassen, aber diese Vorschläge machen es nur schlechter.

Ganz darauf verzichten ist auch ok - aber ich sehe das wie Struppi: bei Browsern, die :after ohnehin nicht verstehen, ist das egal - es bietet halt einen mehrwert für Benutzer vernünftiger Browser.

Und ein Hintergrundbild für den IE6 einfügen ist auch nicht so das Problem, der tut sich ohnehin schwer mit dem skalieren von Schriften :) - aber auch das könnte man weglassen.

[dedlfix]

echo $begrüßung;

Semantisch würde vielleicht besser eine Definitionsliste passen.

Das finde ich auch. Ich sehe nämlich keinen (Fließ-)Text mit diversen Kapiteln und Zwischenüberschriften.

Die eigentliche Adresse müßte ja eigentlich wie im oberen Beispiel auch als Adresse ausgezeichnet werden. Im unteren Beispiel wird sie jetzt mit <dd> ausgezeichnet. Wäre das vertretbar, oder kann man das besser lösen?

Ein dd-Element darf ein address-Element enthalten.

<h3>Hinweis:</h3>
    <p>Für Vollständigkeit, Fehler redaktioneller und technischer Art, Auslassungen usw. sowie die Richtigkeit der Eintragungen kann keine Haftung übernommen werden. Insbesondere kann keine Gewähr für...</p>

<p>Die Verantwortlichkeit für diese fremden Inhalte liegt alleine bei dem Anbieter, der die Inhalte bereithält. Vor dem Einrichten des entsprechenden Verweises sind die Web-Seiten der anderen Anbieter mit großer Sorgfalt und nach... </p>

Diese Hinweise halte ich für unsinnig bis kontraproduktiv. Solange du keinen Vertrag mit irgendwem hast, bist du nicht verpflichtet ihm irgendwelche Informationen zukommen zu lassen, dass deine Seiten fehlerfrei funktionieren oder haftbar, wenn du sie vorenthältst. Vorausgesetzt, du machst nicht vorsätzlich irgendetwas Unrechtes. Wenn du gesetzliche Vorgaben nicht beachtest, helfen dir diese Ausreden (Disclaimer) überhaupt nichts. Sie können im Gegenteil so interpretiert werden, dass du weißt, dass dein Angebot rechtlich nicht einwandfrei ist, aber nichts dagegen unternimmst, dies abzustellen. Außerdem stehen diese Informationen "irgendwo in einer Ecke" und werden damit nicht automatisch zum Bestandteil eines explizit oder implizit geschlossenen Vertrages.

Abgesehen vom rechtlichen Aspekt wäre das allerdings ein Fließtext.

Die Definiton für "Hinweis" war vorher ein Absatz. Das war meines erachtens semantisch auch richtig. Nun erhält die Definiton von Hinweis <dd> als Markup was doch eigentlich semantisch falsch ist.

Du kannst den Text ja außerhalb der Liste lagern (oder löschen, dann löst sich auch das Problem).

echo "$verabschiedung $name";

[molily]

Ich sehe nämlich keinen (Fließ-)Text mit diversen Kapiteln und Zwischenüberschriften.

Wo ist denn festgelegt, dass nach einer Überschrift ein Fließtext folgen muss und dass man Überschriftenstrukturen nur in dokumenten nutzen soll, die über Kapitel verfügen?
Das machen ohnehin die wenigsten Webdokumente. Aber deshalb ist es doch nicht sinnvoll, dort auf Überschriften zu verzichten.

Mathias

[dedlfix]

echo $begrüßung;

» Ich sehe nämlich keinen (Fließ-)Text mit diversen Kapiteln und Zwischenüberschriften.
Wo ist denn festgelegt,

Ich schrieb und meinte nicht, "es ist festgelegt" sondern "ich sehe".

echo "$verabschiedung $name";

[Anton]

Nun hätte ich noch drei Fragen zu dem Adressmarkup:

  
<address>  
         Firma ABC<br/>  
         Amselweg 2<br/>  
         12345 Münchhausen<br/>  
         Telefon: [phone]<br/>  
         Telefax: 12345/789<br/>  
         E-Mail: [e-mail]<br/>  
</address>  

1.)
Ist es vertrebar, das der Zeilenumbruch per </br> durchgeführt wird. Eigentlich handelt es sich bei </br> ja um eine Formatierung die im HTML nix zu suchen hat.

2.)
Vor der Telefonnummer würde ich gerne eine Leerzeile einfügen. Kann ich das umsetzen in dem ich einfach in die Zeile mit der PLZ noch ein <br/> hinzufüge?:

  
<address>  
         Firma ABC<br/>  
         Amselweg 2<br/>  
         12345 Münchhausen<br/><br/>  
         Telefon: [phone]<br/>  
         Telefax: 12345/789<br/>  
         E-Mail: [e-mail]<br/>  
</address>  

3.)
In Typo3 muß ich das mit der Leerzeile zwischen PLZ und Telefonnummer ja auch irgendwie hinbekommen. Dazu habe ich zunächst den ganzen unformatierten Addressblock in den RTE eingefügt. Anschließend habe ich ihn komplett als address gekenntzeichnet. Im letzten Schritt habe ich über den RTE eine Leerzeile zwischen PLZ und Telefon eingefügt. Im Quellcode generiert mir Typo3 folgendes:

  
<address>  
    Firma ABC<br />  
    Amselweg 2<br />  
    12345 Münschhausen  
</address>  
<address>  
    <br />Telefon: [phone]<br />  
    Telefon: [phone]<br />  
    E-Mail: [e-mail]<br />  
</address>  

Ist ja leider nicht das gleiche wie in der händischen Variante (siehe 2.)). Mach ich das bezüglich Typo3 überhaupt richtig bzw. macht es Sinn css_styled_content so zu modifizieren, dass der Quellcode genauso aussieht wie in der händischen Variante?

[suit]

Ist ja leider nicht das gleiche wie in der händischen Variante (siehe 2.)). Mach ich das bezüglich Typo3 überhaupt richtig bzw. macht es Sinn css_styled_content so zu modifizieren, dass der Quellcode genauso aussieht wie in der händischen Variante?

Ich hab' dir bereits in deinem anderen Post gesagt, dass du zwischen "Absatz" und "Leerzeile" unterscheiden musst.

Shift+Enter, Shift+Enter führt zu <p>foo<br /><br />bar</p> nur Enter führt zu <p>foo</p><p>bar</p> - nachdem <address /> vom RTE als Absatz interpretiert wird, gelten dafür die selben Regeln.

[Anton]

»» Ist ja leider nicht das gleiche wie in der händischen Variante (siehe 2.)). Mach ich das bezüglich Typo3 überhaupt richtig bzw. macht es Sinn css_styled_content so zu modifizieren, dass der Quellcode genauso aussieht wie in der händischen Variante?

Ich hab' dir bereits in deinem anderen Post gesagt, dass du zwischen "Absatz" und "Leerzeile" unterscheiden musst.

Shift+Enter, Shift+Enter führt zu <p>foo<br /><br />bar</p> nur Enter führt zu <p>foo</p><p>bar</p> - nachdem <address /> vom RTE als Absatz interpretiert wird, gelten dafür die selben Regeln.

Cool...

Du hattest geschrieben "Eine Leerzeile ist durch <br /><br /> zu erreichen, meistens aber typographischer Unsinn"

In diesem Fall (bei Leerzeichen in <address>) ist das dann wohl kein typographischer Unsinn, da <br/> bei Adressen ja im HTML-Code OK ist.

[suit]

Du hattest geschrieben "Eine Leerzeile ist durch <br /><br /> zu erreichen, meistens aber typographischer Unsinn"

In diesem Fall (bei Leerzeichen in <address>) ist das dann wohl kein typographischer Unsinn, da <br/> bei Adressen ja im HTML-Code OK ist.

Die schreibweise von Adressen ist z.B. in DIN 5008 (bzw DIN 676) festgelegt - damit die Adressen maschinenlesbar sind, ist es wichtig dass Leerzeilen wirklich Leerzeilen sind und keine Absätze (deren Abstand unabhängig von der Zeilenhöhe sein kann).

Zwar spielt das in deinem Fall keine wirkliche Rolle, da du die Adressen ja nicht zum Ausdrucken und Aufkleben auf Kuverts erstellst, aber imho doch vertretbar.

[Gunnar Bittersmann]

@@Anton:

Wenn du soviel Wert aufs Markup legst, sind Mikroformate was für dich (speziell hCard). Und mit entsprechendendem Browserplugin gibt’s Mehrwert für die Nutzer. Adresse im Markup richtig auszeichnen

Live long and prosper,
Gunnar

[Anton]

@@Anton:

Wenn du soviel Wert aufs Markup legst, sind Mikroformate was für dich (speziell hCard). Und mit entsprechendendem Browserplugin gibt’s Mehrwert für die Nutzer. Adresse im Markup richtig auszeichnen

Live long and prosper,
Gunnar

Dank dir, denn Link hab ich eben gesucht. Hab ihn leider nichtmehr gefunden. Ich war das der schonmal danach gefragt hatte ;-).

[Gunnar Bittersmann]

@@Anton:

Dank dir, denn Link hab ich eben gesucht. Hab ihn leider nichtmehr gefunden. Ich war das der schonmal danach gefragt hatte ;-).

Die Suche bietet einige Möglichkeiten (dort erklärt). "author:Anton" könnte hilfreich gewesen sein.

Live long and prosper,
Gunnar

[MichiN]

Hi Gunnar,

ich kannte die von Dir verlinkten hCards bis heute nicht, mir gefällt die Sache aber _sehr_ gut. Nun habe ich das gleich ausprobieren wollen und eine Beispielseite mit fiktiven Angaben geschreiben und mir im Firefox das 'Operator' Add-On installiert.

Die Sache funktioniert prinzipiell, nur happert es mit Umlauten. Wenn ich auf der Seite bin, wird in der Operator-Leiste wie erwartet der Punkt "Kontakte" aktivierbar. Wenn ich dann auf Kontakte => Günther Göllemann => Kontakt exportieren => Öffnen mit Adress Book (Standard) klicke, sind dort sämtliche Umlaute falsch dargestellt, wie Du ja selbst online überprüfen kannst.

Kann _ich_ da was dran ändern oder liegt das Problem bei Windows? Die Testseite ist in validem xhtml 1.0 strict, utf-8 codiert, geschrieben und ich habe, wie Du im Quelltext sehen kannst, eine Definitionsliste verwendet.

Vielleicht weißt Du ja eine Lösung.

Mit lieben Grüßen aus Wien

Michi

[Gunnar Bittersmann]

@@MichiN:

Kann _ich_ da was dran ändern oder liegt das Problem bei Windows?

Sieht so aus, als ob die Anwendung die ankommenden Daten behandelt, als wären sie Windows-1252-codiert.

Live long and prosper,
Gunnar

[MichiN]

Hi Gunnar,

Sieht so aus, als ob die Anwendung die ankommenden Daten behandelt, als wären sie Windows-1252-codiert.

bei Dir ist das nicht so? Oder stört Dich das nicht bzw. ist Dir das noch nie aufgefallen? Man könnte natürlich statt 'Günther Göllemann, Plücherweg 2, Göppelsbach' ein 'Guenther Goellemann, Pluecherweg 2, Goeppelsbach' schreiben, aber das ist nicht wirklich eine Lösung, die mir zusagt. Hm, also offenbar keine Lösung. Schade.

Mit lieben Grüßen aus Wien

Michi

[Gunnar Bittersmann]

@@MichiN:

»» Sieht so aus, als ob die Anwendung die ankommenden Daten behandelt, als wären sie Windows-1252-codiert.

bei Dir ist das nicht so?

Doch.

Das FF-Plugin gibt aus:

BEGIN:VCARD  
PRODID:-//kaply.com//Operator 0.8//EN  
SOURCE:http://bitfeed.net/public/michin/sites/003_hcard/hcard.html  
NAME:hCard Test  
VERSION:3.0  
N;CHARSET=UTF-8:Göllemann;Günther;;;  
FN;CHARSET=UTF-8:Günther Göllemann  
UID:  
ADR;CHARSET=UTF-8:;;Plücherweg 2;Göppelsbach;;999000;Dreamland  
END:VCARD

Die 2.1er Spec [VCARD] sagt:
“The default character set is ASCII. The default character set can be overridden for an individual property value by using the "CHARSET" property parameter.”

Die 3er Spec [RFC2425] in §5 jedoch:
“The [VCARD] CHARSET type parameter has been eliminated. Character set can only be specified on the CHARSET parameter on the Content-Type MIME header field.”

“IMC hopes that all vCard developers take advantage of these new open standards and make their software compatible with both vCard v2.1 and vCard v3.0.” [IMC]

Microsoft scheint den Teil mit v2.1 nicht verstanden zu haben.

Live long and prosper,
Gunnar

[Tim Tepaße]

Hallo,

wenn ihr schon in semantisch-strukurelles Grenzland geht, wieder mal meine übliche Anmerkung zu <address>, das in allen drei HTML-Dialekten gleich definiert ist:

HTML 4:
  “The ADDRESS element may be used by authors to supply contact information for a
  document or a major part of a document such as a form. This element often
  appears at the beginning or end of a document.”

HTML 5 Working Draft:
  “The address element represents the contact information for the section it
  applies to. If it applies to the body element, then it instead applies to the
  document as a whole.” [...]
  “The address element must not be used to represent arbitrary addresses (e.g.
  postal addresses), unless those addresses are contact information for the
  section. (The p element is the appropriate element for marking up such
  addresses.)”

XHTML 2 Working Draft:
  “The address element may be used by authors to supply contact information for
  a document or a major part of a document such as a form.”

Sprich: <address> ist in dieser Interpretation ein (ungünstig benanntes) strukturierendes Element für das ganze Dokument (wie z.B. <style>), kein Element, mit dem man die Bedeutung von einem Abschnitt Text verleihen kann (wie z.B. <blockquote>). Wenn man es richtig machen will, wäre dies also eine leicht falsche Nutzung. Geht man streng nach diesen definierten Bedeutungen, dann sagt die Nutzung von <address> in den in diesem Thread genannten Fällen nur aus, dass die Kontaktdaten nur die Einzelseite Impressum gelten; es sagt aber nichts über die restlichen Ressourcen der Domain aus.

Wieviele Engel passen noch mal auf eine Nadelspitze?

Tim

[molily]

Wenn man es richtig machen will, wäre dies also eine leicht falsche Nutzung.

Genau, siehe auch hCard-FAQ »Should I use the more semantic <address> element for my hCards?«, um wieder die Brücke zu Mikroformaten zu schlagen.

[Auge]

Hallo

wenn ihr schon in semantisch-strukurelles Grenzland geht, wieder mal meine übliche Anmerkung zu <address>, das in allen drei HTML-Dialekten gleich definiert ist:

HTML 4
  HTML 5 Working Draft
  XHTML 2 Working Draft

Sprich: <address> ist in dieser Interpretation ein (ungünstig benanntes) strukturierendes Element für das ganze Dokument (wie z.B. <style>), kein Element, mit dem man die Bedeutung von einem Abschnitt Text verleihen kann (wie z.B. <blockquote>). Wenn man es richtig machen will, wäre dies also eine leicht falsche Nutzung. Geht man streng nach diesen definierten Bedeutungen, dann sagt die Nutzung von <address> in den in diesem Thread genannten Fällen nur aus, dass die Kontaktdaten nur die Einzelseite Impressum gelten; es sagt aber nichts über die restlichen Ressourcen der Domain aus.

Wenn ich das so lese, frage ich mich, was denn eine Kontaktinformation für ein Dokument oder eine Gruppe von Dokumenten ist? Ich kann mir keinen praktischen Einsatzfall für Kontaktinformationen für einzelne Dokumente vorstellen, weiß jetzt nur, dass <address> *nicht* für die Postadresse des Anbieters einer Domain oder darauf angebotener anderer Postadressen gedacht ist.

Tschö, Auge

[dedlfix]

echo $begrüßung;

Wenn ich das so lese, frage ich mich, was denn eine Kontaktinformation für ein Dokument oder eine Gruppe von Dokumenten ist? Ich kann mir keinen praktischen Einsatzfall für Kontaktinformationen für einzelne Dokumente vorstellen,

Dazu musst du sicherlich einen Blick in die Geschichte werfen. Entwickelt wurde HTML nicht für Lieschen-Müller- und kommerzielle Seiten sondern eher um Wissenschaftliches zu publizieren und da ist eine Autoreninformation schon sinnvoll. Das address-Element gab es auch schon in HTML 1.

echo "$verabschiedung $name";

[Auge]

Hallo

»» Wenn ich das so lese, frage ich mich, was denn eine Kontaktinformation für ein Dokument oder eine Gruppe von Dokumenten ist? Ich kann mir keinen praktischen Einsatzfall für Kontaktinformationen für einzelne Dokumente vorstellen,

Dazu musst du sicherlich einen Blick in die Geschichte werfen. Entwickelt wurde HTML nicht für Lieschen-Müller- und kommerzielle Seiten sondern eher um Wissenschaftliches zu publizieren und da ist eine Autoreninformation schon sinnvoll.

Ahh ja, klingt schlüssig. Danke.

*btw* Dabei fällt mir auf, dass der Titel des Postings "<address>" in der "Neue-Antworten-Funktion" im Kopf des Forums zu "<address<" verbogen wird. Sollte ich dafür ein neues Ticket im Bugtracker eröffnen?

Tschö, Auge

[molily]

*btw* Dabei fällt mir auf, dass der Titel des Postings "<address>" in der "Neue-Antworten-Funktion" im Kopf des Forums zu "<address<" verbogen wird. Sollte ich dafür ein neues Ticket im Bugtracker eröffnen?

Ja, mach mal bitte. Ist ein Fehler in Zeile 57:

String.prototype.escapeHTML = function () {
return this.replace(/&/g, "&amp;").replace(/</g, "&lt;").replace(/>/g, "&lt;").replace(/"/g, "&quot;").replace(/'/g, "&#39;");
};

Muss natürlich .replace(/>/g, "&gt;") heißen

Mathias

[Auge]

Hallo

»» *btw* Dabei fällt mir auf, dass der Titel des Postings "<address>" in der "Neue-Antworten-Funktion" im Kopf des Forums zu "<address<" verbogen wird. Sollte ich dafür ein neues Ticket im Bugtracker eröffnen?

Ja, mach mal bitte.

done (#605)

Tschö, Auge