Ein paar Fragen zum Thema "Webdesign"

[Gunther]

Hallo werte Selfgemeinde!

Als "Hobby-Webdesigner" grübele ich ab und zu über diverse Fragen nach - nicht zuletzt auch aufgrund des einen oder anderen Postings hier im Forum.

Ich würde gerne mal eure Meinungen & Ansichten erfahren.

Als einer der wesentlichsten Vorteile des Webs wird ja u.a. immer wieder angeführt, dass es eben so "universell" sei und nicht wie etwa Print-Medien auf nur ein Ausgabeformat beschränkt sei.

Mich würde mal interessieren, ob es eigentlich irgendeine halbwegs zutreffende/ aussagekräftige Statistik darüber gibt, wieviel Prozent tatsächlich auf die verschiedenen Ausgabemedien entfallen? Und damit meine ich jetzt nicht, wenn sich jemand eine Seite aus seinem Browser heraus ausdruckt, sondern vielmehr wieviel Prozent der Webseiten tatsächlich per Braille-Zeile, am Fernseher, per Projektion usw. betrachtet werden. Oder vereinfacht ausgedrückt, wie hoch der Prozentsatz der nicht per Screen/ Bildschirm betrachteten Seiten ist?

Die nächste Frage, die mich interssiert, ist die nach dem Layout.
Fixed width, fluid oder flexible - das ist hier die Frage?

Imho ist es in der Praxis doch so, dass man mit den heutigen Mitteln (CSS) und den aktuellen Gegebenheiten (Browser), mit flexiblen Layouts vor diversen Problemen/ Schwierigkeiten steht, deren Vermeidung oder Umgehung teils nur sehr aufwändig bis gar nicht möglich ist.

Die Frage, die mich dabei vorrangig beschäftigt ist, ob angesichts einer browserinternen Zoom-Funktion in allen gängigen aktuellen Browsern heutzutage, diese Frage nicht eventuell anders beantwortet werden kann, als vielleicht noch vor einigen Jahren?
Und natürlich spielt auch die Antwort auf meine eingangs gestellte Frage u.U. eine gewisse Rolle dabei!?

Mein Eindruck beim Surfen durch das Web ist u.a. auch der, dass sich Seiten ganz grob in zwei Kategorien einteilen lassen, nämlich in optisch "aufwendig" gestaltete Seiten und vom Design her eher "simpel" gehaltene Seiten. Ein Blick auf die technische Umsetzung gibt dann zumeist auch eine Antwort auf die zuvor gestellte Frage.

Und obwohl ich selber seit Jahren eigentlich nur noch alles auf dem Bildschirm lese (wenn man mal von der Fernsehzeitschrift absieht), scheint mein persönliches Empfinden doch ausschließlich von Print-Medien geprägt zu sein, denn rein optisch als "ansprechend" empfinde ich meist die Seiten, die sich von ihrer Gestaltung her an "klassischen" Print-Layouts orientieren.

Wie geht es euch?

Das alles (und noch viel mehr ...), lässt mich immer wieder/ öfter zu dem Schluss kommen, dass

• der ursprüngliche Gedanke, dass eine Webseite ein (möglichst) "universelles" Medium ist, in der Praxis nicht zutrifft. Eine Webseite ist in allererster Linie ein visuelles Medium für die Betrachtung auf einem Bildschirm (Handy-Display, Computer-Monitor, Fernseher, etc.).
• die Mehrheit der User Seiten als "ansprechend" empfinden, die sich vom Layout und Design her an klassischen Print-Medien orientieren. Heutige Techniken und deren Implementierung in den aktuellen Browsern bieten hierfür (immer noch) nur unzureichende Möglichkeiten, weshalb sich viele der eigentlich zur Erreichung des vorgenannten Zieles/ Punktes angedachten Techniken als nicht "praxistauglich" erweisen.

Ich möchte es einmal recht drastisch formulieren:
Ich sehe den eigentlichen Ansatz von CSS als die "eierlegende Wollmilchsau" als gescheitert an. Und jeden weiteren Versuch, diesen nicht funktionierenden Ansatz wenigstens halbwegs an die tatsächlichen Erfordernisse der heutigen Praxis anzupassen, als "Flickschusterei", die in 99% der Fälle vermutlich mehr neue Probleme schafft, als bestehende zu lösen.

Als einfaches Beispiel sei nur darauf verwiesen, dass es einer Unmenge an eigentlich "unnötigem" Markup bedarf, um eine optisch ansprechende Seite zu gestalten. Und das sowohl was die rein bildliche Gestaltung anbelangt, als auch das jeweilige Layout.

Das war jetzt im groben und ganzen ein verkürzter Auszug meiner Meinung/ Ansicht, der bewußt in einigen Teilen etwas "drastisch" oder übertrieben/ überspitzt dargestellt ist.

Wie seht ihr diese Dinge?

Über eine sachliche Diskussion und einen Meinungsaustausch würde ich mich freuen.

Gruß Gunther

PS: Es geht mir nicht darum, dass die reinen Inhalte einer Webseite nicht mit jedem Ausgabemedium verfügbar sein sollten, sondern primär um die nötigen Festlegungen seitens des Autors für das Screendesign/ -layout.

[Der Martin]

Hallo,

Als einer der wesentlichsten Vorteile des Webs wird ja u.a. immer wieder angeführt, dass es eben so "universell" sei und nicht wie etwa Print-Medien auf nur ein Ausgabeformat beschränkt sei.

das ist *ein* Vorteil, aber ich würde ihn nicht als den wesentlichen betrachten. Wesentlich ist für mich eher, dass es eine betriebssystem- und rechnerübergreifend einheitliche Plattform zur Präsentation von Inhalten bietet - und darüber hinaus die Möglichkeit, Inhalte zu verlinken, zu vernetzen, oder sonstwie miteinander zu verknüpfen.

Mich würde mal interessieren, [...] wie hoch der Prozentsatz der nicht per Screen/ Bildschirm betrachteten Seiten ist?

Ich glaube nicht, dass es dazu tatsächlich belegbare Zahlen gibt. Wenn überhaupt, können das wohl nur Schätzungen sein, die mindestens so stark variieren wie Angaben zum Verbreitungsgrad bestimmter Browser.

Imho ist es in der Praxis doch so, dass man mit den heutigen Mitteln (CSS) und den aktuellen Gegebenheiten (Browser), mit flexiblen Layouts vor diversen Problemen/ Schwierigkeiten steht, deren Vermeidung oder Umgehung teils nur sehr aufwändig bis gar nicht möglich ist.

Das kommt drauf an, was du für Ansprüche stellst.

Die Frage, die mich dabei vorrangig beschäftigt ist, ob angesichts einer browserinternen Zoom-Funktion in allen gängigen aktuellen Browsern heutzutage, diese Frage nicht eventuell anders beantwortet werden kann, als vielleicht noch vor einigen Jahren?

IMHO nicht. Aber ich muss dazu erwähnen, dass ich das Web (als Nutzer) rein zweckorientiert sehe: Ich will Informationen, und das möglichst einfach, übersichtlich und bequem. Ich will nicht auf jeder Seite erstmal wieder den Zoomfaktor meines Browsers einstellen müssen, bis ich die winzige Schrift lesen kann, oder umgekehrt die Seite klein zoomen müssen, bloß weil der Autor gemeint hat, 1400px Breite wäre eine tolle Sache.
Von daher schätze ich Seiten, die möglichst wenig Angaben zum Layout machen und meinem Browser (bzw. mir) damit größtmögliche Freiheit lassen.

Und natürlich spielt auch die Antwort auf meine eingangs gestellte Frage u.U. eine gewisse Rolle dabei!?

Sicher. Je einfacher und unspezifischer ein Layout gestrickt ist, desto besser kann es auch wieder auf andere Ausgabemedien angepasst werden bzw. passt sich im Idealfall von allein an die äußeren Bedingungen an.

Mein Eindruck beim Surfen durch das Web ist u.a. auch der, dass sich Seiten ganz grob in zwei Kategorien einteilen lassen, nämlich in optisch "aufwendig" gestaltete Seiten und vom Design her eher "simpel" gehaltene Seiten.

Das ist *eine* mögliche Einteilung. Eine sehr grobe.

Ein Blick auf die technische Umsetzung gibt dann zumeist auch eine Antwort auf die zuvor gestellte Frage.

Was du damit aussagen willst, erschließt sich mir nicht.

Und obwohl ich selber seit Jahren eigentlich nur noch alles auf dem Bildschirm lese ...

Oh. Nein, auch nach rund 25 Jahre andauernder Infektion mit der Faszination Computer lese ich doch wesentlich lieber von einem bedruckten Papier. Am Bildschirm lesen ist okay, wenn's nur darum geht, mal schnell gezielt eine Kleinigkeit nachzuschlagen. Aber längere Stücke? Nein, da ziehe ich die Papierfassung vor.

rein optisch als "ansprechend" empfinde ich meist die Seiten, die sich von ihrer Gestaltung her an "klassischen" Print-Layouts orientieren.
Wie geht es euch?

Anders. ;-)

Wie gesagt: Ich schätze Webseiten mit wenig Schnickschnack, die in der Gestaltung möglichst einfach gehalten sind, so dass das für mich Wesentliche, nämlich der Inhalt, leicht zu erfassen ist.

Eine Webseite ist in allererster Linie ein visuelles Medium für die Betrachtung auf einem Bildschirm (Handy-Display, Computer-Monitor, Fernseher, etc.).

Ja, da sind wir uns einig.

[dass] die Mehrheit der User Seiten als "ansprechend" empfinden, die sich vom Layout und Design her an klassischen Print-Medien orientieren.

Kann ich nicht beurteilen. Ich glaube, das ändert sich auch sehr stark in Abhängigkeit von der befragten Zielgruppe.

Ich sehe den eigentlichen Ansatz von CSS als die "eierlegende Wollmilchsau" als gescheitert an.

Ich nicht. Im Gegenteil: Wenn ich z.B. mit Word ein Dokument verfasse, stelle ich häufig fest, dass bestimmte Formatierungen oder Effekte einfach nicht möglich sind, während das mit CSS ein Klacks wäre. Vor allem die Selektierung von Elementen anhand ihres Kontexts vermisse ich in Textverarbeitungen schmerzlich. Da habe ich Formatvorlagen, die ich einem Abschnitt zuweisen kann, mehr nicht.

Und jeden weiteren Versuch, diesen nicht funktionierenden Ansatz wenigstens halbwegs an die tatsächlichen Erfordernisse der heutigen Praxis anzupassen, als "Flickschusterei", die in 99% der Fälle vermutlich mehr neue Probleme schafft, als bestehende zu lösen.
Als einfaches Beispiel sei nur darauf verwiesen, dass es einer Unmenge an eigentlich "unnötigem" Markup bedarf, um eine optisch ansprechende Seite zu gestalten. Und das sowohl was die rein bildliche Gestaltung anbelangt, als auch das jeweilige Layout.

Das hört sich an, wie jemand, der mit CSS noch nicht viel Erfahrung (oder besser: Routine) hat. Ich stimme dir nur in einem Punkt zu: Es ist dann schwierig anzuwenden, wenn man auch ältere Browser mit eher mangelhafter CSS-Unterstützung (wie etwa unser aller Freund IE5,6,7) noch gut aussehen lassen will. Aber muss man das?

Das war jetzt im groben und ganzen ein verkürzter Auszug meiner Meinung/ Ansicht, der bewußt in einigen Teilen etwas "drastisch" oder übertrieben/ überspitzt dargestellt ist.

Allerdings. ;-)

So long,
 Martin

[Edgar Ehritt]

Hallo,

Als einer der wesentlichsten Vorteile des Webs wird ja u.a. immer wieder angeführt, dass es eben so "universell" sei und nicht wie etwa Print-Medien auf nur ein Ausgabeformat beschränkt sei.

das ist *ein* Vorteil, aber ich würde ihn nicht als den wesentlichen betrachten. Wesentlich ist für mich eher, dass es eine betriebssystem- und rechnerübergreifend einheitliche Plattform zur Präsentation von Inhalten bietet - und darüber hinaus die Möglichkeit, Inhalte zu verlinken, zu vernetzen, oder sonstwie miteinander zu verknüpfen.

letzteres wäre IMHO nur als wesentlich zu bezeichnen. Welche unsinnigen (Verständnis-)Schranken gerade diese essenzielle Eigenschaft des WWW in rechtlicher Hinsicht hier in Deutschland erfahren hat, ist sicher allen hier mit dem Nennung des Urteils Az. 312 O 85/98 geläufig.

Wie ich in meinem Posting bereits schrieb, ist die Einheitlichkeit im Sinne der Präsentation, oder wie Gunther es als Webdesign thematisiert, alles andere als einheitlich; es sei denn, Du willst hier Präsentation als das alleinige Anbieten der Information verstanden wissen. Dann läge es aber an Dir, Dich gängiger, sprachlicher Bedeutungen zu beugen. ^,-

Gruß aus Berlin!
eddi

[Der Martin]

Mahlzeit,

Wesentlich ist für mich eher, dass es eine betriebssystem- und rechnerübergreifend einheitliche Plattform zur Präsentation von Inhalten bietet
Wie ich in meinem Posting bereits schrieb, ist die Einheitlichkeit im Sinne der Präsentation, oder wie Gunther es als Webdesign thematisiert, alles andere als einheitlich

die Art und Weise, wie Informationen von verschiedenen Sites angeboten werden, ist selbstverständlich nicht einheitlich. Auch nicht einheitlich in dem Sinn, dass eine bestimmte Webseite überall gleich dargestellt wird.

Das habe ich auch nicht gemeint. Mit "betriebssystem- und rechnerübergreifend einheitliche Plattform" meine ich vielmehr, dass ich mir als Autor keinen Kopp machen muss, ob meine Webseite mit einem iMac, einem Windows-PC, einem Smartphone oder auf einer großen Sun-Workstation abgerufen wird. Alle verstehen sie ein einheitliches Datenformat, nämlich HTML+CSS; ich muss meine Seiten nicht in -zig proprietären Datenformaten für unterschiedlichste Programme vorhalten.

es sei denn, Du willst hier Präsentation als das alleinige Anbieten der Information verstanden wissen.

Im Wesentlichen auf das Anbieten der Informationen, aber selbstverständlich auch deren Aufbereitung und Darstellung. Die technisch einheitliche Basis habe ich trotzdem.

und darüber hinaus die Möglichkeit, Inhalte zu verlinken, zu vernetzen, oder sonstwie miteinander zu verknüpfen.
letzteres wäre IMHO nur als wesentlich zu bezeichnen. Welche unsinnigen (Verständnis-)Schranken gerade diese essenzielle Eigenschaft des WWW in rechtlicher Hinsicht hier in Deutschland erfahren hat, ist sicher allen hier mit dem Nennung des Urteils Az. 312 O 85/98 geläufig.

Oh ja. Armes Deutschland.
Ich bin aber überzeugt, dass der Bürokratismus in anderen Ländern ähnliche Blüten treibt.

Ciao,
 Martin

[Gunther]

Mahlzeit,

Das habe ich auch nicht gemeint. Mit "betriebssystem- und rechnerübergreifend einheitliche Plattform" meine ich vielmehr, dass ich mir als Autor keinen Kopp machen muss, ob meine Webseite mit einem iMac, einem Windows-PC, einem Smartphone oder auf einer großen Sun-Workstation abgerufen wird. Alle verstehen sie ein einheitliches Datenformat, nämlich HTML+CSS; ich muss meine Seiten nicht in -zig proprietären Datenformaten für unterschiedlichste Programme vorhalten.

da ist aber eher der fromme Wunsch der Vater des Gedanken ...!

In der Praxis musst du dir eben leider sehr wohl einen Kopf darüber machen in welchen Browsern unter welchem OS deine Seite jeweils "ordentlich" angezeigt werden soll.

Klar liegt das Problem eindeutig auf Seiten der verwendeten Hardware, sowie der zur Darstellung/ Ausgabe verwendeten Software und nicht bei den Technologien (HTML + CSS) selber. Aber was nutzen diese ohne den Rest?

Hier liegt für mich schon seit Jahren eines der größten (wenn nicht sogar_das_größte) Mankos von CSS.
Die Darstellung der zu transportierenden Informationen ist untrennbar mit den Gegebenheiten des jeweiligen Ausgabemediums verbunden. Und bislang fehlt CSS (fast) jegliche Möglichkeit, auf diese einzugehen, bzw. diese zu ermitteln und in Abhängigkeit davon zu differenzieren.

Fast nur deswegen, weil man mit Media Queries versucht, dieses schon Jahre andauernde Versäumnis nachzuholen.

Hierbei tritt aber ein weiteres Problem zu Tage. Durch die unterschiedliche und nicht koordinierte Weiterentwicklung von Standards auf der einen Seite, und den Browsern auf der anderen Seite, führt bspw. die browserinterne Zoom-Funktion der Browser in der Praxis dazu, dass Media Queries wiederum unbrauchbar werden. (Falls es dich interessiert, müsstest du im Archiv einen Beitrag von mir zu dem Thema finden.)

Anderer Punkt:
Eine HTML-Datei ist und wird immer linear aufgebaut sein, d.h. die Elemente stehen immer in einer festen Abfolge. Deren Reihenfolge kann aber je nach Ausgabemedium ganz unterschiedlich sinnvoll sein.
Das gilt imho insbesondere für Elemente der Navigation. Bei jeder anderen mir bekannten Anwendung befinden sich die grundlegenden Navigationselemente immer an derselben Stelle, nur bei Webseiten muss/kann jeder Autor diese selbst erstellen und positionieren (mit den damit verbundenen Schwierigkeiten mangels entsprechender Möglichkeiten). Warum werden bspw. die Navigationsmenüs in das jeweilige Ausgabemedium integriert? Also warum erscheint bspw. die (Haupt-)Navigation einer Webseite in meinem Browser und somit auch immer erreichbar, egal wo ich mich gerade auf der Seite befinde?
Auch für Screenreader und Braille-Zeilen Nutzer wäre das (vermutlich) wesentlich einfacher, zumal auch einheitlich und nicht von Seite zu Seite verschieden.

Meiner Meinung nach liegt der konzeptionelle "Fehler" bei CSS darin, dass es eben auch für das Layout (also die Abfolge, bzw. räumliche Aufteilung) zuständig ist/ sein soll, ohne dabei über die dafür notwendigen Möglichkeiten (einfache Logik, bzw. Fallunterscheidung, sowie Informationen über das jeweilige Aussgabemedium) verfügt. CSS taugt für die Festlegung der Darstellung/ Wiedergabe von HTML-Elementen, aber nicht für deren Gruppierung und Layout.

Und anstatt daran weiter "rumzudoktern" (nichts anderes ist CSS3 für mich aktuell), wäre die Lösung denkbar einfach. Man bräuchte lediglich eine neue zusätzliche "Sprache" rein für das Layout einführen. Keine Probleme mit Abwärtskompatibilität und für alle Hersteller von Ausgabemedien die gleiche Ausgangsbasis.
Die letzten 10 Jahre haben imho doch deutlich gemacht, dass CSS dieses nie vernünftig leisten können wird. Hinzukommt, dass es mittlerweile imo schon viel komplizierter ist, als es eigentlich nötig wäre, sodass bei jeder Neuerung oder Veränderung die Gefahr von ungewollten "Nebenwirkungen" extrem groß ist. Ganz zu schweigen von irgendwelchen Bugs in den diversen Programmen mit all ihren Auswirkungen in und für die Praxis.

Gruß Gunther

[Der Martin]

Hallo,

Das habe ich auch nicht gemeint. Mit "betriebssystem- und rechnerübergreifend einheitliche Plattform" meine ich vielmehr, dass ich mir als Autor keinen Kopp machen muss, ob meine Webseite mit einem iMac, einem Windows-PC, einem Smartphone oder auf einer großen Sun-Workstation abgerufen wird. Alle verstehen sie ein einheitliches Datenformat, nämlich HTML+CSS; ich muss meine Seiten nicht in -zig proprietären Datenformaten für unterschiedlichste Programme vorhalten.
da ist aber eher der fromme Wunsch der Vater des Gedanken ...!

keineswegs. Oder stellt jemand seine Inhalte alternativ als PDF, als Word-Dokument, als Staroffice-Text, als Powerpoint-Datei usw. bereit? In ganz bestimmten Sonderfällen vielleicht. Normalerweise reicht eine HTML-Version.

In der Praxis musst du dir eben leider sehr wohl einen Kopf darüber machen in welchen Browsern unter welchem OS deine Seite jeweils "ordentlich" angezeigt werden soll.

Nur wenn man die visuelle, graphische Ausgestaltung bis ins letzte Detail vorgeben will. Das will ich aber nicht - weder als Autor, noch als Leser. Es widerspricht meiner Vorstellung vom Sinn des WWW (und HTML als dessen übliche Auszeichnungssprache).

Klar liegt das Problem eindeutig auf Seiten der verwendeten Hardware, sowie der zur Darstellung/ Ausgabe verwendeten Software und nicht bei den Technologien (HTML + CSS) selber. Aber was nutzen diese ohne den Rest?

Das ist aber nur dann ein Problem, wenn man -siehe oben- visuelle Effekte und filigrane Gestaltungsideen in den Vordergrund stellt, anstatt der Information an sich.

Die Darstellung der zu transportierenden Informationen ist untrennbar mit den Gegebenheiten des jeweiligen Ausgabemediums verbunden.

Und das ist gut so. Denn die Eigenschaften und Fähigkeiten (und ggf. die individuellen Einstellungen) des Ausgabemediums sollen das tatsächliche Aussehen der Seite maßgeblich bestimmen.

Und bislang fehlt CSS (fast) jegliche Möglichkeit, auf diese einzugehen, bzw. diese zu ermitteln und in Abhängigkeit davon zu differenzieren.

Ja, wenn du Spaltensatz, freie Positionierung von Elementen oder auf eine bestimmte Displaygröße angepasste Grafikeffekte meinst. Das sind aber alles Effekte, die ich nicht auch noch unterstützen möchte.
Im Gegenteil. Wenn ich mit Opera oder FF unterwegs bin, komme ich auf vielen Seiten in die Versuchung, CSS zu deaktivieren, gerade WEIL die Darstellung vom Inhalt ablenkt, weil der Autor mal wieder des Guten zuviel getan hat.

Anderer Punkt:
Eine HTML-Datei ist und wird immer linear aufgebaut sein, d.h. die Elemente stehen immer in einer festen Abfolge. Deren Reihenfolge kann aber je nach Ausgabemedium ganz unterschiedlich sinnvoll sein.

Mich wundert, dass gerade du dieses Argument bringst, obwohl du im Eingangsposting sagst, dass dir Seiten im Stil von Printmedien am besten gefallen. Da hast du doch auch die fest vorgegebene lineare Abfolge.

Das gilt imho insbesondere für Elemente der Navigation. Bei jeder anderen mir bekannten Anwendung befinden sich die grundlegenden Navigationselemente immer an derselben Stelle, nur bei Webseiten muss/kann jeder Autor diese selbst erstellen und positionieren (mit den damit verbundenen Schwierigkeiten mangels entsprechender Möglichkeiten). Warum werden bspw. die Navigationsmenüs in das jeweilige Ausgabemedium integriert? Also warum erscheint bspw. die (Haupt-)Navigation einer Webseite in meinem Browser und somit auch immer erreichbar, egal wo ich mich gerade auf der Seite befinde?

Die letzten beiden Fragen müssten wohl heißen: Warum ... nicht? Die Navi wird ja eben *nicht* ins Ausgabemedium integriert bzw. an immer gleicher Stelle im Browser.
Das ist aber ein interessantes Thema und IMHO eine gute Idee, die Sitenavigation auf diese Weise zu vereinheitlichen. Ein großer Schritt in Richtung Usability.

Auch für Screenreader und Braille-Zeilen Nutzer wäre das (vermutlich) wesentlich einfacher, zumal auch einheitlich und nicht von Seite zu Seite verschieden.

Richtig.

CSS taugt für die Festlegung der Darstellung/ Wiedergabe von HTML-Elementen, aber nicht für deren Gruppierung und Layout.

So kann man's auch sehen. Aber das gilt auch wieder nur, wenn man recht ausgefallene Wünsche hinsichtlich des Layouts hat.

Und anstatt daran weiter "rumzudoktern" (nichts anderes ist CSS3 für mich aktuell), wäre die Lösung denkbar einfach. Man bräuchte lediglich eine neue zusätzliche "Sprache" rein für das Layout einführen. Keine Probleme mit Abwärtskompatibilität und für alle Hersteller von Ausgabemedien die gleiche Ausgangsbasis.

Ups. Wie stellst du dir das im Einzelnen vor? Eine Sitemap im XML-Format, die vom UA interpretiert wird und als Seitennavigation in dessen eigene, dem Nutzer vertraute Bedienung (Menü, Toolbar) integriert wird? Wäre eine Möglichkeit ...

Die letzten 10 Jahre haben imho doch deutlich gemacht, dass CSS dieses nie vernünftig leisten können wird. Hinzukommt, dass es mittlerweile imo schon viel komplizierter ist, als es eigentlich nötig wäre, sodass bei jeder Neuerung oder Veränderung die Gefahr von ungewollten "Nebenwirkungen" extrem groß ist.

Das stimmt allerdings. Schon die Wechselwirkungen verschiedener CSS-Eigenschaften untereinander (bzw. in Kombination) sind teilweise sehr schwer nachvollziehbar.

Ganz zu schweigen von irgendwelchen Bugs in den diversen Programmen mit all ihren Auswirkungen in und für die Praxis.

Das ist dann noch ein großes Thema für sich.

So long,
 Martin

[Edgar Ehritt]

Re:

Meiner Meinung nach liegt der konzeptionelle "Fehler" bei CSS darin, dass es eben auch für das Layout (also die Abfolge, bzw. räumliche Aufteilung) zuständig ist/ sein soll, ohne dabei über die dafür notwendigen Möglichkeiten (einfache Logik, bzw. Fallunterscheidung, sowie Informationen über das jeweilige Aussgabemedium) verfügt. CSS taugt für die Festlegung der Darstellung/ Wiedergabe von HTML-Elementen, aber nicht für deren Gruppierung und Layout.

Ansich, wenn ich Deinen Gedanken richtig verstehe, bedarf es derzeit eigentlich nicht viel, dieses Manko auszugleichen. Beließe man die strukturelle Formatierung beim Server, könnte der Client im HTTP-User-Agend-Header vordefinierte Standardwerte senden. Andernfalls reicht auch DOM und Javascript aus. Die entsprechende Client-Software müsste Javascript unterstützen und zum Beispiel im Objekt navigator ähnliche Angaben wie screen, print, etc. machen. In dem Sinne bedürfte es nicht mal einer eigenen Sprache.

Gruß aus Berlin!
eddi

[Gunther]

Hi Eddi!

Ansich, wenn ich Deinen Gedanken richtig verstehe, bedarf es derzeit eigentlich nicht viel, dieses Manko auszugleichen. Beließe man die strukturelle Formatierung beim Server, könnte der Client im HTTP-User-Agend-Header vordefinierte Standardwerte senden.

Ja, wenn er nicht "manipulierbar" wäre.

Andernfalls reicht auch DOM und Javascript aus.

Ja, wenn es nicht vom User "deaktivierbar" wäre.
Ansich würde Javascript eigentlich ausreichen (wie das genau bei Braille-Zeilen u.ä. Ausgabegeräten aussieht kann ich mangels entsprechender Kenntnisse nicht genau beurteilen), wenn da nicht das Problem wäre, dass Javascript schon zu umfangreich ist, und sich auch für viele (negative) Dinge verwenden lässt, die weit über die Erfordernisse für diesen Zweck hinausgehen.

Die entsprechende Client-Software müsste Javascript unterstützen und zum Beispiel im Objekt navigator ähnliche Angaben wie screen, print, etc. machen. In dem Sinne bedürfte es nicht mal einer eigenen Sprache.

Ja genau. Aber aufgrund der o.g. Punkte würde ich eine separate "Sprache" (eine Mischung aus Javascript und CSS - somit für jeden Webautor leicht zu erlernen und zu handhaben) bevorzugen. Das KISS-Prinzip sollte dabei stets im Vordergrund stehen.

Gruß Gunther

[Gunnar Bittersmann]

@@Gunther:

nuqneH

Hier liegt für mich schon seit Jahren eines der größten (wenn nicht sogar_das_größte) Mankos von CSS.
Die Darstellung der zu transportierenden Informationen ist untrennbar mit den Gegebenheiten des jeweiligen Ausgabemediums verbunden. Und bislang fehlt CSS (fast) jegliche Möglichkeit, auf diese einzugehen, bzw. diese zu ermitteln und in Abhängigkeit davon zu differenzieren.

Nicht das Problem von CSS, sondern von den Clients. Wenn mobile Endgeräte auf '@media screen', nicht aber auf '@media handheld' ansprechen [Hazaël-Massieux], ist das deren Problem; das kann CSS nicht lösen.

Eine HTML-Datei ist und wird immer linear aufgebaut sein, d.h. die Elemente stehen immer in einer festen Abfolge. Deren Reihenfolge kann aber je nach Ausgabemedium ganz unterschiedlich sinnvoll sein.

Besser gesagt: Die Reihenfolge von deren _Ausgabe_ (visuelle Darstellung, akustische Ausgabe) kann je nach Ausgabemedium ganz unterschiedlich sinnvoll sein.

Auch dafür bietet CSS 3 eine Antwort: CSS Template Layout Module.

Und CSS ist nicht die einzige Stylesheet-Sprache: XSL existiert. Mit XSLT kann man ja auch XHTML-Quellen in XHTML-Dokumente mit anderer Reihenfolge der Inhalte oder anderen Anpassungen an das jeweilige Ausgabemedium transformieren.

Warum werden bspw. die Navigationsmenüs in das jeweilige Ausgabemedium integriert?

Du willst Framesets? Oder du willst, dass Browser endlich HTML verstehen lernen und mit 'link'-Elementen im 'head' mehr anfangen können als Stylesheets einzubinden (wozu sie eigentlich unsinnig sind)?

Also warum erscheint bspw. die (Haupt-)Navigation einer Webseite in meinem Browser und somit auch immer erreichbar, egal wo ich mich gerade auf der Seite befinde?

Weil einem unfä^Wunbedarftem Autor sein Navigationsmenü soooo wichtig ist und er nicht erkennt, dass sie den Nutzer stört. “Now leave me alone” [Brown]

Meiner Meinung nach liegt der konzeptionelle "Fehler" bei CSS darin, dass es eben auch für das Layout (also die Abfolge, bzw. räumliche Aufteilung) zuständig ist/ sein soll, ohne dabei über die dafür notwendigen Möglichkeiten (einfache Logik, bzw. Fallunterscheidung, sowie Informationen über das jeweilige Aussgabemedium) verfügt.

?? Tut es doch. S.o.

CSS taugt für die Festlegung der Darstellung/ Wiedergabe von HTML-Elementen, aber nicht für deren Gruppierung und Layout.

Noch nicht. S.o.

Und anstatt daran weiter "rumzudoktern" (nichts anderes ist CSS3 für mich aktuell)

Warum?

wäre die Lösung denkbar einfach. Man bräuchte lediglich eine neue zusätzliche "Sprache" rein für das Layout einführen.

XSLT? S.o.

Hinzukommt, dass es mittlerweile imo schon viel komplizierter ist, als es eigentlich nötig wäre

Wäre ja noch schöner, wenn das jeder beherrschen könnte. Hehe, wir wollen doch davon leben! ;-)

Ganz zu schweigen von irgendwelchen Bugs in den diversen Programmen mit all ihren Auswirkungen in und für die Praxis.

Nicht das Problem von CSS, sondern von den Clients.

Qapla'

[Gunther]

@@Gunnar:

nuqneH

Hier liegt für mich schon seit Jahren eines der größten (wenn nicht sogar_das_größte) Mankos von CSS.
Die Darstellung der zu transportierenden Informationen ist untrennbar mit den Gegebenheiten des jeweiligen Ausgabemediums verbunden. Und bislang fehlt CSS (fast) jegliche Möglichkeit, auf diese einzugehen, bzw. diese zu ermitteln und in Abhängigkeit davon zu differenzieren.

Nicht das Problem von CSS, sondern von den Clients. Wenn mobile Endgeräte auf '@media screen', nicht aber auf '@media handheld' ansprechen [Hazaël-Massieux], ist das deren Problem; das kann CSS nicht lösen.

Das ist richtig und noch ein zusätzliches Problem (für den Autor).
Das hat aber nichts damit zu tun, dass CSS jegliche Logik zur Fallunterscheidung bspw. in Abhängigkeit der jeweiligen Viewportgröße des Browsers fehlt (mal abgesehen von Media Queries, die aber eben u.a. durch die browserinternen Zoom-Funktionen praxis untauglich sind. Was aus deiner Sicht natürlich wieder ein Problem der Clients ist. Nur nützt das dem Webautor reichlich wenig - Problem bleibt Problem, egal auf welcher Seite es liegt).

Eine HTML-Datei ist und wird immer linear aufgebaut sein, d.h. die Elemente stehen immer in einer festen Abfolge. Deren Reihenfolge kann aber je nach Ausgabemedium ganz unterschiedlich sinnvoll sein.

Besser gesagt: Die Reihenfolge von deren _Ausgabe_ (visuelle Darstellung, akustische Ausgabe) kann je nach Ausgabemedium ganz unterschiedlich sinnvoll sein.

Auch dafür bietet CSS 3 eine Antwort: CSS Template Layout Module.

Ja, und wenn ich mir alleine die Liste der Abhängigkeiten angucke, dann glaube ich nicht, dass das jemals in einem relevanten Maße praktisch nutzbar sein wird.
Außerdem fehlt da für die Praxis wieder die o.g. Logik. Ich glaube nämlich nicht, dass das Media-Konzept alleine jemals ausreichen wird.
Außerdem bläht das das CSS-Konzept doch alles nur unnötig weiter auf (mit den bereits erwähnten möglichen "Nebenwirkungen" und der imho unnötigen Verkomplizierung).

Und CSS ist nicht die einzige Stylesheet-Sprache: XSL existiert. Mit XSLT kann man ja auch XHTML-Quellen in XHTML-Dokumente mit anderer Reihenfolge der Inhalte oder anderen Anpassungen an das jeweilige Ausgabemedium transformieren.

Warum werden bspw. die Navigationsmenüs in das jeweilige Ausgabemedium integriert?

Du willst Framesets?

Auf keinen Fall - Gott behüte.

Oder du willst, dass Browser endlich HTML verstehen lernen und mit 'link'-Elementen im 'head' mehr anfangen können als Stylesheets einzubinden (wozu sie eigentlich unsinnig sind)?

Jetzt verstehen wir uns ...!

Meiner Meinung nach liegt der konzeptionelle "Fehler" bei CSS darin, dass es eben auch für das Layout (also die Abfolge, bzw. räumliche Aufteilung) zuständig ist/ sein soll, ohne dabei über die dafür notwendigen Möglichkeiten (einfache Logik, bzw. Fallunterscheidung, sowie Informationen über das jeweilige Aussgabemedium) verfügt.

?? Tut es doch. S.o.

Nur in der Theorie (sprich im Working Draft). Das zeigt immerhin, dass den Verantwortlichen zumindest die Anforderung aus der Praxis gegenwärtig ist. Nur halte ich die vorgeschlagene Lösung nicht für die Beste.

CSS taugt für die Festlegung der Darstellung/ Wiedergabe von HTML-Elementen, aber nicht für deren Gruppierung und Layout.

Noch nicht. S.o.

Ja eben. Und ich halte es für fraglich, ob wir beide diesen Tag noch erleben dürfen.

Und anstatt daran weiter "rumzudoktern" (nichts anderes ist CSS3 für mich aktuell)

Warum?

Weil ich der Meinung bin, dass sich viele der aktuellen Anforderungen aus der Praxis anders besser & schneller zufriedenstellen lassen. Defakto ist es doch so, dass man viele dieser Dinge bei der Einführung von CSS schlicht nicht vorhergesehen, bzw. berücksichtigt hat. Deshalb lassen sich jetzt etliche davon nur per "Gefrickel" nachträglich integrieren. Also frage ich mich doch, warum man das überhaupt versucht, anstatt eine für alle Beteiligten wesentlich einfachere Lösung zu wählen?
Es kommt mir immer so vor, als wolle man um jeden Preis beweisen, dass CSS dies alles leisten kann - ob sinnvoll oder praktikabel, Schei.. egal.

wäre die Lösung denkbar einfach. Man bräuchte lediglich eine neue zusätzliche "Sprache" rein für das Layout einführen.

XSLT? S.o.

Korrigiere mich bitte, falls ich mich irre, aber ich wollte eigentlich auch weiterhin HTML-Dokumente erstellen und keine XML-Dokumente.

Ganz zu schweigen von irgendwelchen Bugs in den diversen Programmen mit all ihren Auswirkungen in und für die Praxis.

Nicht das Problem von CSS, sondern von den Clients.

Ja, so kann man sich die Sache auch einfach machen. Klar kann ich als Webautor auch sagen:"Die Seite wird bei Ihnen nicht korrekt dargestellt? Nicht mein Problem, sondern das Ihres Browsers!". Hilft nur in der Praxis nicht wirklich weiter.

Ich glaube, du hast den Kern meiner Kritik, bzw. meiner Vorschläge schon richtig verstanden. Klar sind viele der heutigen Problemfälle auf dem Papier schon gelöst. Nur was nützt das in Praxis?

Einer der elementaren Vorteile des Webs war es einmal, dass seine grundlegende Sprache HTML extrem einfach war und somit sehr schnell & leicht von vielen Usern verwendet werden konnte. Dank CSS und der Weiterentwicklung von HTML kann davon heutzutage keine Rede mehr sein. Das kommt dabei heraus, wenn solche Dinge nur noch von Experten weiterentwickelt werden, für die Praxistauglichkeit und Einfachheit eher Fremdwörter sind.

Gruß Gunther

[Gunnar Bittersmann]

@@Gunther:

nuqneH

Das hat aber nichts damit zu tun, dass CSS jegliche Logik zur Fallunterscheidung bspw. in Abhängigkeit der jeweiligen Viewportgröße des Browsers fehlt (mal abgesehen von Media Queries, […])

Na siehste, da isses doch! Genau an der Stelle, wo’s auch hingehört. Es wäre doch unsinnig, dasselbe nochmals an anderer Stelle vorzusehen.

die aber eben u.a. durch die browserinternen Zoom-Funktionen praxis untauglich sind.

Mir scheint, du schießt gegen das _Konzept_ von CSS, weil es einige zweifelhafte Implementierungen gibt. Dann schieß bitte gegen die Implementierungen und beurteile das Konzept als solches (d.h. völlig unabhängig von Implementierungen).

Was aus deiner Sicht natürlich wieder ein Problem der Clients ist. Nur nützt das dem Webautor reichlich wenig - Problem bleibt Problem, egal auf welcher Seite es liegt).

Damit hast du natürlich recht.

Weil ich der Meinung bin, dass sich viele der aktuellen Anforderungen aus der Praxis anders besser & schneller zufriedenstellen lassen.

Du sagst wiederholt, CSS sei unnötig kompliziert und es ginge anders einfacher. Hast du mal ein konkretes Beispiel, wo CSS kompliziert unnötig kompliziert ist und wie du es anders lösen würdest?

XSLT? S.o.
Korrigiere mich bitte, falls ich mich irre, aber ich wollte eigentlich auch weiterhin HTML-Dokumente erstellen und keine XML-Dokumente.

Siehste, und ich will weiterhin XHTML-Dokumente schreiben. Das hat einerseits den Vorteil der strengeren (ergo einfacheren) Syntax, andererseits können XHTML-Dokumente eben auch mit XML-Werkzeugen verarbeitet werden, bspw. mit XSLT-Prozessoren.

Einer der elementaren Vorteile des Webs war es einmal, dass seine grundlegende Sprache HTML extrem einfach war und somit sehr schnell & leicht von vielen Usern verwendet werden konnte. Dank CSS und der Weiterentwicklung von HTML kann davon heutzutage keine Rede mehr sein.

Dank CSS bleibt HTML (wenn man denn die Präsentation vom Markup trennt) einfach.

Und einer der elementaren Vorteile des Webs 2.0 ist es nun einmal, dass man keinerlei Kenntnisse in HTML oder CSS benötigt, um seine Inhalte im Web zu publizieren.

Die Kenntnisse in HTML und CSS sind bei der Entwicklung von Web-2.0-Software (bspw. Blogsoftware) gefragt, nicht bei deren Anwendung. Und das ist auch gut so.[tm]

Qapla'

[Struppi]

Als einer der wesentlichsten Vorteile des Webs wird ja u.a. immer wieder angeführt, dass es eben so "universell" sei und nicht wie etwa Print-Medien auf nur ein Ausgabeformat beschränkt sei.

Zu dieser universialität zählt auch, dass man Dank HTML, sich um die Größe des Anzeigebereichs keine Gedanken machen muss.

Die nächste Frage, die mich interssiert, ist die nach dem Layout.
Fixed width, fluid oder flexible - das ist hier die Frage?

flüssig.

Imho ist es in der Praxis doch so, dass man mit den heutigen Mitteln (CSS) und den aktuellen Gegebenheiten (Browser), mit flexiblen Layouts vor diversen Problemen/ Schwierigkeiten steht, deren Vermeidung oder Umgehung teils nur sehr aufwändig bis gar nicht möglich ist.

findest du? Sehe ich nicht so.

Mein Eindruck beim Surfen durch das Web ist u.a. auch der, dass sich Seiten ganz grob in zwei Kategorien einteilen lassen, nämlich in optisch "aufwendig" gestaltete Seiten und vom Design her eher "simpel" gehaltene Seiten.

Da ist die Frage was du als optisch aufwändig bezeichnest. Ich finde auch viele Seiten sehr überladen (z.b. viele oder fast alle Fernsehsender), weil eben anscheinend oft versucht wird eine Internetseite so wie eine Zeitschrift zu gestalten.

Und obwohl ich selber seit Jahren eigentlich nur noch alles auf dem Bildschirm lese (wenn man mal von der Fernsehzeitschrift absieht), scheint mein persönliches Empfinden doch ausschließlich von Print-Medien geprägt zu sein, denn rein optisch als "ansprechend" empfinde ich meist die Seiten, die sich von ihrer Gestaltung her an "klassischen" Print-Layouts orientieren.

Wie geht es euch?

Bei mir ist es umgekehrt - die Seiten, die sich optisch an das Medium Bildschirm orientieren gefallen mir besser, als die sich an Zeitschriften orientieren.

Wobei das ganze aber auch eine müsige Diskussion ist. Denn du wirst kaum Seiten finden, die sich wirklich vergleichen lassen. Da jede Seite erstmal ihren Anspruch und Zielpublikum hat.

Ich habe keine Seite in meinen Feeds oder Lesezeichen, die dieses typische Zeitschriften/Portal Design haben. Ich finde sowas furchtbar. Ich lese überwiegend Blogs, die über fachliche oder politische Themen, die mich interessieren berichten, da ist mir auch das Design relativ egal. Aber bei Suchmaschinen, Übersetzungstools o.ä. ist meiner Meinung nach weniger mehr.

• der ursprüngliche Gedanke, dass eine Webseite ein (möglichst) "universelles" Medium ist, in der Praxis nicht zutrifft. Eine Webseite ist in allererster Linie ein visuelles Medium für die Betrachtung auf einem Bildschirm (Handy-Display, Computer-Monitor, Fernseher, etc.).

Das mag stimmen, aber wie du hier schreibst, es gibt viele Arten von Ausgabemedien. Und ich weiß nicht, ob diese überladenen Seiten wirklich auf einem Handydisplay rüberkommen.

• die Mehrheit der User Seiten als "ansprechend" empfinden, die sich vom Layout und Design her an klassischen Print-Medien orientieren. Heutige Techniken und deren Implementierung in den aktuellen Browsern bieten hierfür (immer noch) nur unzureichende Möglichkeiten, weshalb sich viele der eigentlich zur Erreichung des vorgenannten Zieles/ Punktes angedachten Techniken als nicht "praxistauglich" erweisen.

Diese Aussage halte ich für falsch, da die meisten User nach meinen Beobachtungen eher Schwierigkeiten haben, sich auf so Seiten zurecht zu finden.

Ich möchte es einmal recht drastisch formulieren:
Ich sehe den eigentlichen Ansatz von CSS als die "eierlegende Wollmilchsau" als gescheitert an. Und jeden weiteren Versuch, diesen nicht funktionierenden Ansatz wenigstens halbwegs an die tatsächlichen Erfordernisse der heutigen Praxis anzupassen, als "Flickschusterei", die in 99% der Fälle vermutlich mehr neue Probleme schafft, als bestehende zu lösen.

Das ist eine interessante Aussage, aber wo siehst du den konkret die Probleme von CSS? Ich finde es eine optimale Technik, um eine HTML Seite zu gestalten. Es gibt einige Probleme, wenn du versuchst ein Tabellenlayout ohne Tabellen zu gestalten, aber ansonsten ist es eine gelungene Technik, deren weiterentwicklung immer mehr visuelle Effekte zuläßt.

Als einfaches Beispiel sei nur darauf verwiesen, dass es einer Unmenge an eigentlich "unnötigem" Markup bedarf, um eine optisch ansprechende Seite zu gestalten.

Die Frage ist, was du als optisch ansprechend erachtest. Du redest evtl. von so Sachen wie runden Ecken - die mittlerweile in vielen Browsern ohne zusätzliches Markup gestaltet werden können - oder dem oben angesprochenen Tabellenlayout ohne Tabellen. Mehr fällt mir aber nicht ein, wo zusätzliches Markup nötig wäre. Und schon gar kein "einfaches Beispiel", dass ich in deiner Aussage vermisse.

Ich beobachte in den letzten Jahren eher eine Entwicklung hin zu Webdesign, weg von den knalligen, überladenen Werbeflyer- oder Revolverblattlayouts. Vermutlich, weil mittlerweile doch eine grosse Anzahl der Agenturen die solche Seiten machen, das Web und die Techniken verstanden haben.

Struppi.

[Edgar Ehritt]

Hallo Gunther,

Die nächste Frage, die mich interssiert, ist die nach dem Layout.
Fixed width, fluid oder flexible - das ist hier die Frage?

genau diese Frage berührt meiner Meinung nach den eigentlichen Punkt Design. Design ist hier die Verpackung des zu transportierenden Inhalts. Dabei gibt es für Webs keine grundlegenden Maßstäbe, wie diese bei realen Verpackungen der Fall wenn. Wenn der Inhalt bspw. Jogurt wäre, bestimmt sich die Form der Becher (und deren Umverpackung[en]) letztendlich durch die Maße der Europoolpalette (DIN EN 13698). Das mag im Hinblick auf die unglaublich vielfältigen Verpackungsformen etwas zweifelhaft erscheinen. Dennoch werden Jogurts letztendlich auf dies Paletten gestapelt. Wobei auch die Ladeflächen der LKWs, die diese dann transportieren, wiederum (zumeist) ein vielfaches der Abmaße sind.

In diesem Zusammenhang steht nach meinem Verständnis ja auch Deine vorangestellte Frage der statistischen Verteilung einzelner Ausgabegeräte. (Dazu weiß ich leider nichts beizutragen.) Für Layouts von Webs (screen) steht bekanntlich ja kein grundlegendes Maß zur Verfügung. Hierbei wird ja immer wieder auf den so genannten Viewport verwiesen. Dabei ist die Sache erheblich komplexer. Betrachtet man allein die Schriftarten, lässt sich nach derzeitigem Stand nicht mal exakt sagen, wie groß ein Text tatsächlich sein wird. Jedes System (Browser, installierte Fonts) kann hier zu unterschiedlichen Ausgaben führen. Auch für Ausgaben am Drucker stellt sich prinzipiell, makrographische Phänomen ein. Dabei hat man hier sogar DIN-genormte Abmaße als Grundlage. Zu allem Überfluss kommt dann auch noch eine mögliche Konfiguration des Nutzers.

Mit Blick auf den kommenden Standard HTML5 scheint zumindest was Schriften anbelangt, eine einheitliche Darstellung gesichert zu werden. Insbesondere bei Ausdrucken macht einem dies die Gestaltung in Seitenzahl und was an Inhalten sich wie auf die einzelnen Seiten verteilt vorhersagbarer.

Imho ist es in der Praxis doch so, dass man mit den heutigen Mitteln (CSS) und den aktuellen Gegebenheiten (Browser), mit flexiblen Layouts vor diversen Problemen/ Schwierigkeiten steht, deren Vermeidung oder Umgehung teils nur sehr aufwändig bis gar nicht möglich ist.

In Anbetracht nur dieser oben genannten Tatsachen, will ich die unterschiedlichen Auflösungen von Bildschirmen einfach nur am Rande erwähnen. Ein flexibles Layout kann mit wenig zu transportierenden Inhalt auf einer Auflösung von 1920*1080 verdammt dämlich aussehen als ein fixiert und zentrierter Kasten. Meiner Ansicht nach, auch wenn es ach so gute Gründe für flexibles Layouts gibt, die hier all die Jahre hinuntergebetet wurden, legst Du als Gestalter das Layout fest - wie, ist nicht weiter diskussionsbedürftig. Michelangelo Buonarroti hatte anfangs auch nur Marmor, den er nach Aussagemaßgaben unter den damals geltenden Normen nach eigenem Gutdünken bearbeitete. Braucht der Nutzer an einem Deiner Webs seinen eigens getrüffelten Kuckuck, wird er ihn ohnehin Konfigurieren.

Die Frage, die mich dabei vorrangig beschäftigt ist, ob angesichts einer browserinternen Zoom-Funktion in allen gängigen aktuellen Browsern heutzutage, diese Frage nicht eventuell anders beantwortet werden kann, als vielleicht noch vor einigen Jahren?

Früher wurde allein die Schrift vergrößert. Bei fixierten Maßen der Webdokumente war das schon ein großes Problem, was es so nicht mehr gibt. Heute wird die Seite mit allen eingebetteten Medien (Bidler, Flash) als ganze vergrößert. Ich für meinen Teil sehe es also genau so, wie es Deine Frage hier impliziert. Ich empfinde es daher auch als eine Art kreativer Bevormundung, fließende Layouts nutzen zu müssen.

Mein Eindruck beim Surfen durch das Web ist u.a. auch der, dass sich Seiten ganz grob in zwei Kategorien einteilen lassen, nämlich in optisch "aufwendig" gestaltete Seiten und vom Design her eher "simpel" gehaltene Seiten. Ein Blick auf die technische Umsetzung gibt dann zumeist auch eine Antwort auf die zuvor gestellte Frage.

Die Gestaltung, wirklich mal so grob in aufwendig und simpel gegliedert, richtet sich dabei nach meinem Geschmack vorwiegend auch an das angesprochene Publikum und dessen Erwartungen. Wer das Web eines Möbelhaus aufsucht, wird eher Seiten (wenn nicht sogar [Flash-]Applikationen) vorfinden wollen, welche sich in der Gestaltung nah an einem Prospekt oder Katalog halten. Er braucht Bilder, aber nur das Nötigste an Daten. Bei einem Web, was (abstrakte) Informationen thematisch aufbereitet (z. B. Spezifikationen) werden Bilder nur für nötige Schemata erwartet. Hier ist Inhalt wichtig, wie der Formatiert ist, spielt vierte (Fakten, Fakten, Fakten ;) Geige.

Dabei übernimmt die technische Umsetzung nach meinem Dafürhalten außerhalb der erstrebenswerten Validität nur in Randbereichen tatsächlich eine Rolle. Insbesondere das eigentliche Anliegen HTMLs eine _semantische_ Beschreibungs- bzw. Auszeichnersprache zu sein, lässt sich mit den herkömmlichen Browsern faktisch nicht erfahren. Denn ob etwas emotional oder einfach nur schräg dargestellt wird, kann man, will man nicht ständig den Quelltext durcharbeiten, ohne weitergehende Konfiguration des Browsers (ich sprach den getrüffelten Kuckuck ja am Rande schon an) nicht differenzieren. Mit Sprachausgabe wäre dies eher möglich.

Bezüglich der hier im Forum von einigen Hardlinern so strikte Auftrennen in Layout und Inhalt, was ja auch Frage technischen Umsetzung ist und Basis der Gestaltung wird, bleibt allemal anzumerken, dass dann sogar HTML nicht weiter entwickelt werden braucht. Inhalt sollte nur in XML strukturiert werden, während das semantische dann vollends, was es, ersichtlich im Steuern der Sprachausgabe, teils ja schon jetzt ist, CSS überlassen werden. In dem Sinne, was jetzt über Deine Betrachtung technischer Umsetzungen hinausgeht, wäre das von meinem Standpunkt aus sogar begrüßenswert.

Ich sehe den eigentlichen Ansatz von CSS als die "eierlegende Wollmilchsau" als gescheitert an. Und jeden weiteren Versuch, diesen nicht funktionierenden Ansatz wenigstens halbwegs an die tatsächlichen Erfordernisse der heutigen Praxis anzupassen, als "Flickschusterei", die in 99% der Fälle vermutlich mehr neue Probleme schafft, als bestehende zu lösen.

Von meiner oben kurz umrissenen Warte aus ist CSS (noch) nicht Fisch - nicht Fleisch. Es gestaltet Strukturen und sollte alleiniges Werkzeug semantischer Auszeichnung werden. Das wäre meiner Meinung nach dann eine konsequente Trennung, der es derzeit ermangelt.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Insbesondere das eigentliche Anliegen HTMLs eine _semantische_ Beschreibungs- bzw. Auszeichnersprache zu sein

Es ist _nicht_ das Anliegen HTMLs, Inhalte _semantisch_ auszuzeichnen. Unterliegst du dem Irrtum, was „semantisches Markup“ bedeuten soll?

HTML soll die Dokument_struktur_ semantisch beschreiben, nicht den Dokument_inhalt_. Für Letzteres sind HTML-Elemente nicht geeignet; lediglich Mikroformate und RDFa können das.

Siehe http://forum.de.selfhtml.org/archiv/2008/11/t178802/#m1179638 und dortige Links.

Ich sehe den eigentlichen Ansatz von CSS als die "eierlegende Wollmilchsau" als gescheitert an.

Warum?

Und jeden weiteren Versuch, diesen nicht funktionierenden Ansatz wenigstens halbwegs an die tatsächlichen Erfordernisse der heutigen Praxis anzupassen, als "Flickschusterei"

CSS 3 ist an die tatsächlichen Erfordernisse der heutigen Praxis angepasst. Die Umsetzung von CSS 3 in Browsern ist es nicht.

die in 99% der Fälle vermutlich mehr neue Probleme schafft, als bestehende zu lösen.

Wie meinen?

[CSS] gestaltet Strukturen und sollte alleiniges Werkzeug semantischer Auszeichnung werden.

Hä?? Wie meinen?

Qapla'

[Edgar Ehritt]

Hallo Gunnar,

wenn Du zitierst, tue es richtig oder stelle Deine Fragen dem jeweiligem Autor und nicht alles mir!

Insbesondere das eigentliche Anliegen HTMLs eine _semantische_ Beschreibungs- bzw. Auszeichnersprache zu sein

Es ist _nicht_ das Anliegen HTMLs, Inhalte _semantisch_ auszuzeichnen. Unterliegst du dem Irrtum, was „semantisches Markup“ bedeuten soll?

Wie zu lesen war, hatte ich das Beispiel mit <em>- und <i>-Element bemüht.

[CSS] gestaltet Strukturen und sollte alleiniges Werkzeug semantischer Auszeichnung werden.

Hä?? Wie meinen?

HTML stellt Strukturen (bereit). Das ist ja auch Grund, warum Du oben mit Deiner Frage interveniertest.
CSS formatiert diese Strukturen. Dabei habe ich mich allgemein auf Strukturen festgelegt, weil CSS eben nicht nur separat Element für Element formatiert, sondern durch Selektoren auch Abhängikeiten erkennt, die eben Strukturen darstellen. Soweit ist der Sinn also nochmals als gemeinsame Basis klargestellt. Dann hatte ich geschrieben, dass die Entwicklung von HTML aufgegeben werden sollte und CSS semantische Aufgaben gleich mitübernehmen könnte:

<?xml version="1.1"?>  
<!DOCTYPE a SYSTEM "a.dtd">  
<?xml-stylesheet type="text/css" href="a.css" ?>  
<a>  
 <b>huhu</b>  
 <c>Tschö mit Ö</c>  
 <d/>  
 <e>22.01.2010</e>  
</a>

/*  
Spezifikationserweiterungen:  
  
   & wird neuer Selector für semantische Terme.  
   (verkürzte) Liste semantischer Terme:  
   title, line, meta, header  
*/  
&title   {font-weight:bold;margin:20px}  
&line    {border-top:solid 1px black}  
&meta    {display:none}  
  
b        {semantic:title header;font-size:20px}  
d        {semantic:line;margin:0px 20px 0px 20px}  
e        {semantic:meta}

Ich hoffe es ist dann klar, was ich damit meine.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

wenn Du zitierst, tue es richtig

?? Tat ich das nicht?

oder stelle Deine Fragen dem jeweiligem Autor und nicht alles mir!

?? Du warst doch der Autor von „Insbesondere das eigentliche Anliegen HTMLs eine _semantische_ Beschreibungs- bzw. Auszeichnersprache zu sein […]“?

Es ist _nicht_ das Anliegen HTMLs, Inhalte _semantisch_ auszuzeichnen. Unterliegst du dem Irrtum, was „semantisches Markup“ bedeuten soll?

Wie zu lesen war, hatte ich das Beispiel mit <em>- und <i>-Element bemüht.

Du übersetzt 'em' mit „emotional“?

Weder 'em' noch 'i' zeichnen Inhalte semantisch aus. Genug Lesestoff dazu hatte ich verlinkt.

Dann hatte ich geschrieben, dass die Entwicklung von HTML aufgegeben werden sollte und CSS semantische Aufgaben gleich mitübernehmen könnte:

Sehe ich nicht so; not its job.

Ich finde die Trennung von Auszeichnungs-, Präsentations- und Verhaltensschicht schon sinvoll. Was ein Titel ist und was Meta-Information, gehört in die Auszeichnungsschicht.

Qapla'

[Edgar Ehritt]

Re:

wenn Du zitierst, tue es richtig
?? Tat ich das nicht?

Offensichtlich nicht.

oder stelle Deine Fragen dem jeweiligem Autor und nicht alles mir!
?? Du warst doch der Autor von „Insbesondere das eigentliche Anliegen HTMLs eine _semantische_ Beschreibungs- bzw. Auszeichnersprache zu sein […]“?

Ja, dazu habe ich auch Stellung bezogen; zum übrigen nicht.

Es ist _nicht_ das Anliegen HTMLs, Inhalte _semantisch_ auszuzeichnen. Unterliegst du dem Irrtum, was „semantisches Markup“ bedeuten soll?
Wie zu lesen war, hatte ich das Beispiel mit <em>- und <i>-Element bemüht.
Du übersetzt 'em' mit „emotional“?
Weder 'em' noch 'i' zeichnen Inhalte semantisch aus. Genug Lesestoff dazu hatte ich verlinkt.

Da gebe ich dir recht. Es zeichnet Inhalt als emphatisch aus, was aber nichts zur Sache tut.

Dann hatte ich geschrieben, dass die Entwicklung von HTML aufgegeben werden sollte und CSS semantische Aufgaben gleich mitübernehmen könnte:
Ich finde die Trennung von Auszeichnungs-, Präsentations- und Verhaltensschicht schon sinvoll. Was ein Titel ist und was Meta-Information, gehört in die Auszeichnungsschicht.

Betrachte alles erstmal wie ein Programmierer als Daten bzw. dessen Struktur (Eigenschaft, Inhalt). Da sind wir dann bei XML. Das lässt sich wunderbar z. B. mittels DOM oder XPath beschreiben. Alles weitere sind HTML-Eigenschaften, die im Bedeutungsgehalt einer Hintergrundfarbe entsprechen. Sie sind HTML-spezifisch, weil sie die Daten nur in diesem Kontext attribuieren.

Des Weiteren war hier nicht die Rede von der Verhaltensschicht. Die bleibt davon funktionell unberührt. Betroffen sind also nur die Markup- und Präsentationsschicht. Heutigen Browsern ist augenscheinlich außer im Quelltext nichts an Semantik zu entnehmen, da die Formatierung, also CSS, für das Hervorheben der Semantik sorgt. Wenn dem ohnehin schon so ist, kann alles gleich in einen Top, denn es macht aus Sicht der Verarbeitung der Daten keinerlei Unterschiede, eben weil die Verhaltensschicht sich nicht ändert. Selbst ein Crawler kann sich ohne weiteres die Semantik aus einem Stylesheet holen.

Der Vorteil ist dabei, dass Semantik nicht mehr starr zu postulieren wäre und die Daten ohne XLS-Aufbereitung Verwendet werden könnten.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

wenn Du zitierst, tue es richtig
?? Tat ich das nicht?
Offensichtlich nicht.

Na viele Dank für die Hilfe mir zu zeigen, an welcher Stelle ich das nicht tat.

Du übersetzt 'em' mit „emotional“?
Es zeichnet Inhalt als emphatisch aus, was aber nichts zur Sache tut.

Ich dachte, 'em' stünde für emmanuellisch.

Alles weitere sind HTML-Eigenschaften, die im Bedeutungsgehalt einer Hintergrundfarbe entsprechen. Sie sind HTML-spezifisch, weil sie die Daten nur in diesem Kontext attribuieren.

Was willst du damit sagen?

Heutigen Browsern ist augenscheinlich außer im Quelltext nichts an Semantik zu entnehmen, da die Formatierung, also CSS, für das Hervorheben der Semantik sorgt.

Was willst du damit sagen?

Der Vorteil ist dabei, dass Semantik nicht mehr starr zu postulieren wäre und die Daten ohne XLS-Aufbereitung Verwendet werden könnten.

Warum sollte CSS die Funktion von XSLT übernehmen?

Qapla'

[Edgar Ehritt]

Re:

wenn Du zitierst, tue es richtig
?? Tat ich das nicht?
Offensichtlich nicht.
Na viele Dank für die Hilfe mir zu zeigen, an welcher Stelle ich das nicht tat.

Solltest Du das tatsächlich ernst meinen, hattest Du wohl den Hinweis überlesen, dass ich nur zu meinen Aussagen Stellung bezog; und im Übrigen: Keine Ursache. ;-P

Du übersetzt 'em' mit „emotional“?
Es zeichnet Inhalt als emphatisch aus, was aber nichts zur Sache tut.
Ich dachte, 'em' stünde für emmanuellisch.

Ganz nebenbei: http://www.roesler-ac.de/wolfram/acro/HTML.htm

Wofür es auch immer stehen mag, tut rein gar nichts zur Sache. Es wird wie <i> default als kursiv dargestellt. Nochmals, das ist der Punkt: Semantik ist in heutigen Browsern nicht wirklich erfahrbar.

Alles weitere sind HTML-Eigenschaften, die im Bedeutungsgehalt einer Hintergrundfarbe entsprechen. Sie sind HTML-spezifisch, weil sie die Daten nur in diesem Kontext attribuieren.
Was willst du damit sagen?

Das was ich geschrieben habe, will ich damit sagen. Es ist ein Argument dafür, dass CSS alleiniges semantisches Werkzeug werden sollte.

Heutigen Browsern ist augenscheinlich außer im Quelltext nichts an Semantik zu entnehmen, da die Formatierung, also CSS, für das Hervorheben der Semantik sorgt.
Was willst du damit sagen?

Das was ich geschrieben habe, will ich damit sagen. Es ist ein Argument dafür, dass CSS alleiniges semantisches Werkzeug werden sollte.

Der Vorteil ist dabei, dass Semantik nicht mehr starr zu postulieren wäre und die Daten ohne XLS-Aufbereitung Verwendet werden könnten.
Warum sollte CSS die Funktion von XSLT übernehmen?

Kann es die Funktion XSLTs überhaupt übernehmen? Nein! Dann wird wohl XSLT durch mein Gedankenspiel überflüssig werden.

(Was ist denn heute los mit Dir?)

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Nochmals, das ist der Punkt: Semantik ist in heutigen Browsern nicht wirklich erfahrbar.

Doch. Wenn der Autor wirklich Inhalte semantisch ausgezeichnet hat (Microformats: hCard, hCalender), dann ist dies bspw. Firefox mit Add-on Operator durchaus erfahrbar.

Es ist ein Argument dafür, dass CSS alleiniges semantisches Werkzeug werden sollte.

Nein, Semantik gehört zum Markup.

Qapla'

[Edgar Ehritt]

Re:

Nochmals, das ist der Punkt: Semantik ist in heutigen Browsern nicht wirklich erfahrbar.

Doch. Wenn der Autor wirklich Inhalte semantisch ausgezeichnet hat (Microformats: hCard, hCalender), dann ist dies bspw. Firefox mit Add-on Operator durchaus erfahrbar.

Beziehe meine Aussage bitte auf das angerissene Themengebiet, statt Dich kontextgelöst an der Aussage abzuarbeiten! Bei dieser Art des Diskussionsstils fühle ich mich lediglich, wie ich Dir hier nicht zum ersten Mal entgegne, ans Bein gepinkelt. Wenn Du nicht beim Thema bleiben willst, spare Dir Antworten, die Du explizit an mich richtest, ganz!

Es ist ein Argument dafür, dass CSS alleiniges semantisches Werkzeug werden sollte.

Nein, Semantik gehört zum Markup.

Begründe das endlich mal! Gunnar, Deine argumentloser Dogmatismus kotzt mich einstweilen schon an.

Extensible Markup Language hat nichts mit Semantik zu tun. In ihr können XHMTL-Dokumente beschrieben werden. XML ist also Grundlage von HTML hinreichend verwendbar. Warum soll künstlich die Sprache HTML verwendet werden, wenn sie sich vollständig durch XML ersetzen ließen; mit dem Zusatz CSS dafür zu nutzen, um neben der Demonstration der Bedeutung (durch Formatierung in Farbe, Schrift, etc.) _die Bedeutung selbst_ gleich mitanzulegen?

Ich erwarte mehr als ein völlig unbegründetes "ich finde"!

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Beziehe meine Aussage bitte auf das angerissene Themengebiet

Das wäre welches? Ich dachte, es wäre semantische Auszeichnung …

statt Dich kontextgelöst an der Aussage abzuarbeiten!

… und in diesem Kontext hatte ich deine Aussgae betrachtet.

Bei dieser Art des Diskussionsstils fühle ich mich lediglich, wie ich Dir hier nicht zum ersten Mal entgegne, ans Bein gepinkelt.

Du wirst es nicht glauben: Ich rieche auch nach Hund.

Nein, Semantik gehört zum Markup.

Begründe das endlich mal!

Die Semantik von Daten kann doch nur dort angegeben werden, wo die Daten selbst sind. Also zusammen mit den Daten im Markup.

Um es nochmal zu wiederholen: Mit Semantik von Daten ist nicht gemeint: Dieses Datum steht in einer Überschrift/einer Tabellenzelle/einem Listenelement/einem Textabsatz/… Sondern mit Semantik von Daten ist gemeint: Dieses Datum beschreibt eine Person/einen Zeitpunkt (um hier den doppeldeutigen Begriff Datum im Sinne von Jahr-Monat-Tag zu vermeiden)/… Sowie auch Beziehungen zwischen diesen Daten, bspw. <Person> wurde geborem am <Zeitpunkt>.

Extensible Markup Language hat nichts mit Semantik zu tun.

Kann man so nicht sagen.

In ihr können XHMTL-Dokumente beschrieben werden.

In ihr können auch RDF-Dokumente geschrieben werden. Und diese haben sehr wohl was mit Semantik zu tun.

Warum soll künstlich die Sprache HTML verwendet werden, wenn sie sich vollständig durch XML ersetzen ließen

Willst du RDF-Dokumente an Browser ausliefern und mit CSS versuchen, diese menschenlesbar darzustellen?

mit dem Zusatz CSS dafür zu nutzen, um neben der Demonstration der Bedeutung (durch Formatierung in Farbe, Schrift, etc.)

Die Bedeutung (Semantik von Daten) wird üblicherweise nicht durch Formatierung dargestellt. Oder würdest du bei „Leonardo da Vinci wurde geboren am 15. April 1452“ die Satzteile „Leonardo da Vinci“ (Person), „wurde geboren am“ (Beziehung) und „15. April 1452“ (Zeitpunkt) in unterschiedlichen Farben darstellen?

Die Semantik von Daten ergibt sich für Menschen aus dem Kontext. Für Menschen ist semantische Auszeichnung deshalb nicht unmittelbar wichtig. HTML hatte nicht das Ziel, Daten semantisch auszuzeichnen.

Semantische Auszeichnung ist für Maschinen wichtig. Beispielsweise, damit ein Nutzer ein auf einer Webseite angegebenen (und mit hCalender semantisch ausgezeichnetem) Termin auf Knopfdruck in seinen Kalender übernehmen kann.

_die Bedeutung selbst_ gleich mitanzulegen?

Mich deucht, du bist dir der Bedeutung der Bedeutung (s.o.) nicht bewusst.

Qapla'

[Edgar Ehritt]

Re:

Beziehe meine Aussage bitte auf das angerissene Themengebiet
Das wäre welches? Ich dachte, es wäre semantische Auszeichnung …

Lies es nach!

Bei dieser Art des Diskussionsstils fühle ich mich lediglich, wie ich Dir hier nicht zum ersten Mal entgegne, ans Bein gepinkelt.
Du wirst es nicht glauben: Ich rieche auch nach Hund.

Raus, waschen!

Nein, Semantik gehört zum Markup.

Würde ich alles genau so aus dem Kontext reißen, hätte ich Dir dort schon schreiben könnten, das XML als extensible MARKUP language keinerlei Semantik hat. Formal betrachtet Du also auf dem Holzweg bist.

Begründe das endlich mal!

Die Semantik von Daten kann doch nur dort angegeben werden, wo die Daten selbst sind. Also zusammen mit den Daten im Markup.

Um es nochmal zu wiederholen: Mit Semantik von Daten ist nicht gemeint: Dieses Datum steht in einer Überschrift/einer Tabellenzelle/einem Listenelement/einem Textabsatz/… Sondern mit Semantik von Daten ist gemeint: Dieses Datum beschreibt eine Person/einen Zeitpunkt (um hier den doppeldeutigen Begriff Datum im Sinne von Jahr-Monat-Tag zu vermeiden)/… Sowie auch Beziehungen zwischen diesen Daten, bspw. <Person> wurde geborem am <Zeitpunkt>.

Jain. Für einen Crawler ist die Semantik der Struktur eines Dokuments sehr wohl wichtig. Er misst Inhalten in Überschriften oder Titeln (beispielsweise google) qualitativ andere Bedeutungen zu. Damit sind wir an dem Punkt, dass HTML eine semantische Auszeichnersprache ist, die Daten sowohl bezüglich der Struktur des Dokuments (vgl. HTML4; 7) als auch bezüglich ihres Inhalts (vgl. z. B. HTML4; 9.2.1) Bedeutungen zuteilt.

Extensible Markup Language hat nichts mit Semantik zu tun.
Kann man so nicht sagen.

Die Spezifikation sagt es so!

This specification does not constrain the application semantics, use,
   or (beyond syntax) names of the element types and attributes, except
   that names beginning with a match to (('X'|'x')('M'|'m')('L'|'l'))
   are reserved for standardization in this or future versions of this
   specification.

Was Du meinst, sind Dinge, die auf XML _aufsetzen_, ihrerseits semantisch spezifiziert sind; klassisches Bsp. RDF - hattest Du selbst schon ins Spiel gebracht.

Warum soll künstlich die Sprache HTML verwendet werden, wenn sie sich vollständig durch XML ersetzen ließen
Willst du RDF-Dokumente an Browser ausliefern und mit CSS versuchen, diese menschenlesbar darzustellen?

Auf welche abstrusen Fragen Du kommst... Wo habe ich dieses durchblickenlassen, dass Du Dich dessen jetzt mit dieser Frage vergewissern willst? Nur weil RDF sich aus XML ableitet sprach ich von explizit von XML - nicht von RDF!

mit dem Zusatz CSS dafür zu nutzen, um neben der Demonstration der Bedeutung (durch Formatierung in Farbe, Schrift, etc.)#
Die Bedeutung (Semantik von Daten) wird üblicherweise nicht durch Formatierung dargestellt. Oder würdest du bei „Leonardo da Vinci wurde geboren am 15. April 1452“ die Satzteile „Leonardo da Vinci“ (Person), „wurde geboren am“ (Beziehung) und „15. April 1452“ (Zeitpunkt) in unterschiedlichen Farben darstellen?

Nein. Alles Browser stellen aber Überschriften größer und gewichtiger dar. Alle Browser stellen den Inhalt von <head> gar nicht dar. (<em> war ja schon im spiel.) Hm... Woran das wohl liegen mag? Weil sie unterschiedliche BEDEUTUNGEN haben? ^,-

Die Semantik von Daten ergibt sich für Menschen aus dem Kontext. Für Menschen ist semantische Auszeichnung deshalb nicht unmittelbar wichtig. HTML hatte nicht das Ziel, Daten semantisch auszuzeichnen.

Ob das für Browser vielleicht nicht so ist? Könnte die Semantik der Struktur des Dokuments sich für diese einfach aus der per Spezifikation postulierten Bedeutung der einzelnen Elemente herleiten? Ist das schlimm, dass das gegen Dein Dogma verstößt und der Grund dafür, dass Du teilweise abstruse Fragen stellst?

Semantische Auszeichnung ist für Maschinen wichtig. Beispielsweise, damit ein Nutzer ein auf einer Webseite angegebenen (und mit hCalender semantisch ausgezeichnetem) Termin auf Knopfdruck in seinen Kalender übernehmen kann.

Semantische Auszeichnung ist (und wiederholt habe ich Dich in dieser Debatte auf Crawler hingewiesen, aber Du nimmst es schlichtweg nicht zur Kenntnis) vordergründig für verarbeitende Software von Bedeutung.

_die Bedeutung selbst_ gleich mitanzulegen?

Mich deucht, du bist dir der Bedeutung der Bedeutung (s.o.) nicht bewusst.

Überschriften, Absätze, andere Blockelemente, Zitate, und so weiter, und so fort haben eine Formatierung per default durch CSS. Überschriften haben ihre Bedeutung, sind größer als gewöhnlicher Text und haben ein großes Margin. Andere Elemente haben andere Bedeutungen für das Dokument und dementsprechende defaults. Sofern Dir das nicht einleuchtend, und Du immer wieder mit Deinem unterstellten Verständnis ankommst, ist das Gespräch dann besser abzubrechen.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Jain. Für einen Crawler ist die Semantik der Struktur eines Dokuments sehr wohl wichtig. Er misst Inhalten in Überschriften oder Titeln (beispielsweise google) qualitativ andere Bedeutungen zu.

Für einen Crawler wäre semantische Auszeichnung der _Inhalte_ eines Dokuments allerbestes Futter. Da er solches in den allermeisten HTML-Dokumenten nicht bekommt, muss er sich halt anders behelfen.

Wenn du den Begriff „Bedeutung“ schon abwechselnd im Sinne von Semantik und im Sinne von Wichtigkeit verwendest, tu bitte nicht so, als sei beides dasselbe.

Damit sind wir an dem Punkt, dass HTML eine semantische Auszeichnersprache ist, die Daten sowohl bezüglich der Struktur des Dokuments […]

Ja, jetzt hat er’s!

[…] als auch bezüglich ihres Inhalts […] Bedeutungen zuteilt.

Nein, doch nicht!

(vgl. z. B. HTML4; 9.2.1)

Nichts von dem zeichnet Inhalte semantisch aus.

Auf welche abstrusen Fragen Du kommst... Wo habe ich dieses durchblickenlassen, dass Du Dich dessen jetzt mit dieser Frage vergewissern willst?

Du erkennst Polemik?

Nur weil RDF sich aus XML ableitet

Das ist nicht richtig. (Aber das nur BTW.)

Alles Browser stellen aber Überschriften größer und gewichtiger dar. Alle Browser stellen den Inhalt von <head> gar nicht dar. (<em> war ja schon im spiel.) Hm... Woran das wohl liegen mag? Weil sie unterschiedliche BEDEUTUNGEN haben? ^,-

Nein. Weil sie unterschiedliche Regeln im Browserstylesheet haben. :-b

Du sprichst von der Semantik der HTML-Elemente bezüglich der Dokument_struktur_. Ich sprach von semantischer Auszeichnung des Dokument_inhalts_. Ich dachte, ich hätte den Unterschied anschaulich dargestellt.

Qapla'

[Edgar Ehritt]

Re:

Jain. Für einen Crawler ist die Semantik der Struktur eines Dokuments sehr wohl wichtig. Er misst Inhalten in Überschriften oder Titeln (beispielsweise google) qualitativ andere Bedeutungen zu.

Für einen Crawler wäre semantische Auszeichnung der _Inhalte_ eines Dokuments allerbestes Futter. Da er solches in den allermeisten HTML-Dokumenten nicht bekommt, muss er sich halt anders behelfen.

Wenn du den Begriff „Bedeutung“ schon abwechselnd im Sinne von Semantik und im Sinne von Wichtigkeit verwendest, tu bitte nicht so, als sei beides dasselbe.

Semantik ist nun einmal eine Bedeutungslehre. Ist etwas von Bedeutung ist es wichtig. Die Klassifizierung eines Inhalts mittels einer Überschrift ist zweifelsohne wichtig. Damit eine Überschrift bei der Datenverarbeitung eines Dokuments erkannt werden kann, bedient man sich semantischer Regeln. Diese Regeln sind im Standard für HTML zusammen gefasst. Die Bedeutung wird also durch die vereinheitlichte Festlegung der semantischen Deutung der Elemente spezifiziert. Das Wichtigkeit untrennbar an die Bedeutung eines Elementes gekoppelt ist, obwohl ich Dir ja zustimme, dass es (formal) nicht dasselbe sein kann, wird allein daran ersichtlich, dass aufgrund ihrer Bedeutung strukturelle Elemente mindestens in einem HTML-Dokument vorhanden sein müssen. Dazu zählen, abgesehen vom Wurzelelement <html>, die Elemente <head>, <body>, <title> z. T. auch ein Blockelement innerhalb des Elements <body>. Daher ist ein synonymer Gebrauch von Wichtigkeit und Bedeutung aufgrund der Symbiose beider nicht wirklich unverständlich.

Wenn ich mir aber durchlese, was ich schrieb, habe ich Semantik konsequent mit Bedeutung gleichgesetzt. Andernfalls hätte ich Wichtigkeit, statt qualitativer Bedeutung, geschrieben. Wo also tue ich so, als sei beides dasselbe?

[…] als auch bezüglich ihres Inhalts […] Bedeutungen zuteilt.
Nein, doch nicht!
(vgl. z. B. HTML4; 9.2.1)
Nichts von dem zeichnet Inhalte semantisch aus.

Im Verlinkten Abschnitt lese ich:

Phrase elements add structural information to text fragments. The usual
   meanings of phrase elements are following:

EM:      Indicates emphasis.
   STRONG:  Indicates stronger emphasis.
   CITE:    Contains a citation or a reference to other sources.
   DFN:     Indicates that this is the defining instance of the enclosed
            term.
   CODE:    Designates a fragment of computer code.
   SAMP:    Designates sample output from programs, scripts, etc.
   KBD:     Indicates text to be entered by the user.
   VAR:     Indicates an instance of a variable or program argument.
   ABBR:    Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass.,
            etc.).
   ACRONYM: Indicates an acronym (e.g., WAC, radar, etc.).

Ich Weiß nicht, wie Du in "The usual meanings of phrase elements are following" meanings übersetzt. Ich übersetze es immer noch als Bedeutung. Semantik ist nun einmal eine Bedeutungslehre. Durch oben zitierte, der Spezifikation entnommene Definitionen sind die Bedeutungen des Inhalts dieser Elemente festgeschrieben. Dem Inhalt solcher Elemente wird per Standard also Bedeutung zugewiesen. Nicht zuletzt darum werden einige davon auch per default anders formatiert dargestellt.

Selbes ist ja auch bei verschiedenen Attributen analog zu beobachten (lang, alt, title), durch die der Inhalt spezifische Bedeutungen bekommt. All dies aber ist eben auch Semantik, und nicht nur &#0D; korrekt darzustellen!

Auf welche abstrusen Fragen Du kommst... Wo habe ich dieses durchblickenlassen, dass Du Dich dessen jetzt mit dieser Frage vergewissern willst?
Du erkennst Polemik?

Ich bringe Beispiel für Beispiel, suche Dir die Zitate aus der Spezifikation heraus, setze mich mit dem Inbegriff von Semantik auseinander und was kommt von Dir?

Hey, Ernie, ich mag hier nicht mehr Bert abgeben! ^^
(Oder bevorzugst Du eher Hein Blöd und Käpt'n Blaubär, was farblich auf die selbe Männerkonstellation hinausliefe...)

Nur weil RDF sich aus XML ableitet
Das ist nicht richtig. (Aber das nur BTW.)

Ich korrigiere mich also: Nur weil RDF in der weit verbreiteten Repräsentation in XML dieses erweitert...

Alles Browser stellen aber Überschriften größer und gewichtiger dar. Alle Browser stellen den Inhalt von <head> gar nicht dar. (<em> war ja schon im spiel.) Hm... Woran das wohl liegen mag? Weil sie unterschiedliche BEDEUTUNGEN haben? ^,-
Nein. Weil sie unterschiedliche Regeln im Browserstylesheet haben. :-b

Daher ist es ja auch mein Ansatz, die Bedeutung eines Elements im Stylesheet definieren zu können. Bedeutungen sind herkömmlich nur über die Formatierung eines HTML-Dokuments erfahrbar; also an diese gekoppelt. Was es schon zusammenhängt, kann auch in einem Topf untergebracht werden.

Du sprichst von der Semantik der HTML-Elemente bezüglich der Dokument_struktur_. Ich sprach von semantischer Auszeichnung des Dokument_inhalts_. Ich dachte, ich hätte den Unterschied anschaulich dargestellt.

Ja, schon die ganze Zeit hämmert es mir lauwarmgelb ans Knie mit wirklich allen Korinthen die man am Wegesrand so finden kann. Inhaltlich kommt aber rein gar nichts. Nur, Polemik ersetzt das Befassen mit den aufgeworfenen Vorstellungen eben auch nicht.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

(vgl. z. B. HTML4; 9.2.1)
Nichts von dem zeichnet Inhalte semantisch aus.

Im Verlinkten Abschnitt lese ich:

Phrase elements add structural information to text fragments. The usual
   meanings of phrase elements are following:

EM:      Indicates emphasis. […]

Ich Weiß nicht, wie Du in "The usual meanings of phrase elements are following" meanings übersetzt. Ich übersetze es immer noch als Bedeutung.

Du sprichst von der Semantik der HTML-Elemente bezüglich der Dokument_struktur_. Ich sprach von semantischer Auszeichnung des Dokument_inhalts_.

Du sprichst von der Semantik der HTML-Elemente bezüglich der Dokument_struktur_. Ich sprach von semantischer Auszeichnung des Dokument_inhalts_. Ich dachte, ich hätte den Unterschied anschaulich dargestellt.

Ja, schon die ganze Zeit hämmert es mir lauwarmgelb ans Knie mit wirklich allen Korinthen die man am Wegesrand so finden kann.

Aber wenn du den Unterschied, den ich für essentiell halte, als Korinthenkackerei abtust, können wir noch tagelang aneinander vorbei reden, ohne dass du verstehst, was ich meine.

Ich sehe darin keinen Sinn (in dem Aneinender-vorbei-Reden, nicht in dem, was ich meine).

Qapla'

[Edgar Ehritt]

Re:

Du sprichst von der Semantik der HTML-Elemente bezüglich der Dokument_struktur_. Ich sprach von semantischer Auszeichnung des Dokument_inhalts_.
Aber wenn du den Unterschied, den ich für essentiell halte, als Korinthenkackerei abtust, können wir noch tagelang aneinander vorbei reden, ohne dass du verstehst, was ich meine.

Ich sprach beides (struktureller und inhaltlicher Art) am Rande an, was eben die eigentliche, von Dir aufgelesene Korinthe war. Mir ging es nämlich tatsächlich doch darum, Semantik, gleich welcher Art sie sein mag, durch CSS auszeichnen zu lassen. Außer einem völlig unbegründetem "ich finde ... [das so gut]" kamen von Dir dazu nichts - nur unterstellte Verständnisfehler, was Semantik sei.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Ich sprach beides (struktureller und inhaltlicher Art) am Rande an,

Nein. Du sprachst jene struktureller Art an; jene inhaltlicher Art nicht einmal am Rande.

Die hatte ich ins Spiel gebracht, weil ich deine Aussage „Insbesondere das eigentliche Anliegen HTMLs eine _semantische_ Beschreibungs- bzw. Auszeichnersprache zu sein“ so nicht stehenlassen konnte.

Mir ging es nämlich tatsächlich doch darum, Semantik, gleich welcher Art sie sein mag, durch CSS auszeichnen zu lassen.

Dass Semantik inhaltlicher Art durchs Markup ausgedrückt werden muss, sollte klar sein. Um auf mein dortiges Beispiel zurückzukommen:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">  
<html  
  xmlns="http://www.w3.org/1999/xhtml"  
  xmlns:foaf="http://xmlns.com/foaf/0.1/"  
  xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#"  

>  

  <head>  
    <title>Leonardo da Vinci</title>  
  </head>  
  <body>  
    <p typeof="foaf:Person">  
      <span property="foaf:name">Leonardo da Vinci</span>  
      wurde geboren am  
      <span property="vCard:BDAY" content="1452-04-15">15. April 1452</span>  
    </p>  
  </body>  
</html>

Dass Semantik struktureller Art auch durchs Markup ausgedrückt werden sollte, eigentlich auch. Alles andere würde das Konzept „Auszeichnungssprache“ ad absurdum führen.

Um auf dein Beispiel zurückzukommen: Welchen Sinn haben die bedeutungsleeren Elemente a, b, c, d, e? Sieht irgendwie nach Divitis aus.

Qapla'

[Edgar Ehritt]

Re:

Ich sprach beides (struktureller und inhaltlicher Art) am Rande an,
Nein. Du sprachst jene struktureller Art an; jene inhaltlicher Art nicht einmal am Rande.

<em> stellvertretend für andere Elemente (mir fiele da sonst <address>, <blockquote> oder auch <cite> ein), Attribute lang, title oder alt hatte ich auch am Rande angeführt.

Die hatte ich ins Spiel gebracht, weil ich deine Aussage „Insbesondere das eigentliche Anliegen HTMLs eine _semantische_ Beschreibungs- bzw. Auszeichnersprache zu sein“ so nicht stehenlassen konnte.

Dein eingefügtes Beispiel zeigt recht anschaulich, was Du bezogen auf Dein Beispiel da Vincis meinst. Es zeigt aber auch sehr deutlich, was an Namensräumen hinzukommen muss, um die entsprechenden Bedeutungen überhaupt setzen zu können. HTML hat genauso nicht alle Möglichkeiten, zeichnet aber sehr wohl Bedeutungen für Passagen aus.

Mir ging es nämlich tatsächlich doch darum, Semantik, gleich welcher Art sie sein mag, durch CSS auszeichnen zu lassen.
Dass Semantik inhaltlicher Art durchs Markup ausgedrückt werden muss, sollte klar sein. Um auf mein dortiges Beispiel zurückzukommen:

Dass Semantik inhaltlicher Bezüge durch Markup ausgedrückt werden kann...

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">

<html
  xmlns="http://www.w3.org/1999/xhtml"
  xmlns:foaf="http://xmlns.com/foaf/0.1/"
  xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#"

<head>
    <title>Leonardo da Vinci</title>
  </head>
  <body>
    <p typeof="foaf:Person">
      <span property="foaf:name">Leonardo da Vinci</span>
      wurde geboren am
      <span property="vCard:BDAY" content="1452-04-15">15. April 1452</span>
    </p>
  </body>
</html>

  
Dein Beispiel zeigt recht beeindruckend, dass von Sicht des DOMs aus bspw. dem Objekt document.getElementsByTagName('span')[0] im Gegensatz zu document.getElementsByTagName('span')[1] unterschiedliche Eigenschaften zugewiesen wurden:  
  
~~~javascript
var $d=document.getElementsByTagName('span');  
$d.item(0).setAttribute('property',"foaf:name");  
$d.item(1).setAttribute('property',"vCard:BDAY");

Darin verhält sich Dein vermeintlicher Zwang, inhaltliche Bezüge, was übrigens strenggenommen nichts mit Semantik zutun hat, und da liegt IMHO Deine elementarer Verständnisfehler, durch Markup ausdrücken zu müssen, in nichts anders als eben Stylesheets:

$d.item(0).setAttribute('style',"background-color:navy");  
$d.item(1).setAttribute('style',"visibility:visible");

Dass Semantik struktureller Art auch durchs Markup ausgedrückt werden sollte, eigentlich auch. Alles andere würde das Konzept „Auszeichnungssprache“ ad absurdum führen.

Nein. Das ist einfach nur Dein Dogma.
Gunner, langsam werde ich sauer. In https://forum.selfhtml.org/?t=194561&m=1301673 hatte ich auf die Spezifikation XMLs verwiese. XML _ist_eine Auszeichersprache ohne jedwede semantischen Definitionen. Sonst wäre die nicht (oder bestenfalls eingeschränkt) _extensible_. XML kann aber allein mit CSS zur anzeige gebracht werden, ohne strukturelle Bedeutungen zu transportieren und ohne das Konzept eines Markup Language ad absurdum zuführen.

Um auf dein Beispiel zurückzukommen: Welchen Sinn haben die bedeutungsleeren Elemente a, b, c, d, e? Sieht irgendwie nach Divitis aus.

Das Beispiel ist selbstredend. Bedeutung wird, so mein Vorschlag, durch CSS zugewiesen.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Nein. Du sprachst jene struktureller Art an; jene inhaltlicher Art nicht einmal am Rande.

<em>

Nei-en! Kannst du nicht oder willst du nicht verstehen, was ich mit semantischer Auszeichnung des Inhalts meine?

'em' sagt, DASS der Textinhalt dieses Elements eine Bedeutung hat (und zwar „Bedeutung“ im Sinne von Wichtigkeit, aber so wolltest du den Begriff nicht verwendet haben).

Es wird nicht gesagt, WELCHE Bedeutung (im Sinne von Semantik) der Textinhalt dieses Elements hat. Eben das wäre für mich aber semantische Auszeichnung des Inhalts.

Bspw: <em property="foaf:name">Leonardo da Vinci</em>. Die semantische Auszeichnung des Inhalts ist nicht 'em', sondern "foaf:name".

(mir fiele da sonst <address>, <blockquote> oder auch <cite> ein), Attribute lang, title oder alt hatte ich auch am Rande angeführt.

Aus deiner Liste geht einzig 'address' in die Richtung.

HTML hat genauso nicht alle Möglichkeiten […]

Sag ich doch.

[…] zeichnet aber sehr wohl Bedeutungen für Passagen aus.

Nein. (Es sei denn, du verwendest „Bedeutung“ wider deiner Aussage im Sinne von Wichtigkeit.)

XML _ist_eine Auszeichersprache ohne jedwede semantischen Definitionen.

ACK. XML bietet als Metasprache die Grundlage (Syntax) für Anwendungen.

Diese Anwendendungen werden den Elementen üblicherweise Bedeutungen geben – und zwar bezüglich der Dokument_struktur_ (und nicht des Inhalts), so wie es auch (X)HTML tut.

Warum du eben dies nicht tun willst, sondern dies an CSS delegieren willst, bleibt mir nach wie vor ein Rätsel.

Qapla'

[Edgar Ehritt]

Re:

Bspw: <em property="foaf:name">Leonardo da Vinci</em>. Die semantische Auszeichnung des Inhalts ist nicht 'em', sondern "foaf:name".

Bezüglich der Strukturellen Bedeutung ist <em> sehr wohl semantische Auszeichnung!

(mir fiele da sonst <address>, <blockquote> oder auch <cite> ein), Attribute lang, title oder alt hatte ich auch am Rande angeführt.
Aus deiner Liste geht einzig 'address' in die Richtung.

Wenn <address> Inhalt semantisch als Adresse auszeichnet, dann Zeichnet <cite> beziehungsweise <blockqote cite=""> Inhalt semantisch nicht als Zitat aus? Was für einen widersprüchlichen Stuss Du doch schreibst. Aber letztentlich schießt Du Dir mit Deiner Aussage auch in anderer Hinsicht in diesem Disput ins Knie. Denn meine Aussage, dass das Anliegen von HTML sei, semantische Auszeichnersprache zu sein, gar nicht so falsch ist. Im Gegensatz zu XML, wie Du ja im Verlauf dazulernen durftest, setzt HTML diesbezüglich ganz andere Akzente. Das wird insbesondere aus den Attributen lang oder auch alt ersichtlich. <p lang="de"> ist eine eindeutige, semantische Aussage bezüglich des Inhalts. Aber anstatt Du darauf argumentativ reagierst, nach dem ich es Dir hier drittmalig unter die Nase halte, verfolgst Du stur Dein Dogma.

HTML hat genauso nicht alle Möglichkeiten […]
Sag ich doch.

Keine Deine hinzugezogenen Namensräume hat alle Möglichkeiten, daher brauchst Du ja drei. Das aber siehst Du bei Deinem Beispiel nicht ein. Insbesondere siehst Du nicht, dass Du im eigentlichen, wenn Du von inhaltlicher Semantik sprichst, tatsächlich inhaltliche Bezüge meinst, was nicht Anliegen der Semantik ist, wie ich Dir jetzt zweitmalig schreibe.

[…] zeichnet aber sehr wohl Bedeutungen für Passagen aus.
Nein. (Es sei denn, du verwendest „Bedeutung“ wider deiner Aussage im Sinne von Wichtigkeit.)

Gunnar, hast Du oben <address> akzeptiert oder nicht? Wirst Du aufgrund dessen zwangsläufig <p lang="de">, <cite>, etc. auch akzeptieren? Siehst Du eigentlich mit welcher Inkonsistenz Deinerseits ich hier seit Tagen zu kämpfen habe?

XML _ist_eine Auszeichersprache ohne jedwede semantischen Definitionen.
ACK. XML bietet als Metasprache die Grundlage (Syntax) für Anwendungen.

Hura, Du kannst tatsächlich mal was einsehen.

Diese Anwendendungen werden den Elementen üblicherweise Bedeutungen geben – und zwar bezüglich der Dokument_struktur_ (und nicht des Inhalts), so wie es auch (X)HTML tut.

Das ist mal wieder: Gunnar haftet am Dogma fest, wie ein Kind das nicht geboren werden will am Mutterkuchen...

Warum du eben dies nicht tun willst, sondern dies an CSS delegieren willst, bleibt mir nach wie vor ein Rätsel.

Die Vorteile liegen auf der Hand, sind Dir mehrfach hier im Threat aufgezeigt worden. Ich pule sie Dir nicht mehr raus, wenn Du so halsstarrig bist, und sie beim ersten Lesen nicht gedanklich bedacht hast.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Bspw: <em property="foaf:name">Leonardo da Vinci</em>. Die semantische Auszeichnung des Inhalts ist nicht 'em', sondern "foaf:name".

Bezüglich der Strukturellen Bedeutung ist <em> sehr wohl semantische Auszeichnung!

Ja, natürlich. Das sag ich doch die ganze Zeit. Bezüglich der strukturellen Bedeutung, ja! Aber nicht bezüglich der inhaltlichen Bedeutung. Ha’m wa’s jetzt?

Wenn <address> Inhalt semantisch als Adresse auszeichnet,

Nicht so wirklich. Richtig semantisch wird’s mit Auszeichnungen für Name, Vorname, E-Mail-Adresse, Wohnort, PLZ, Straße etc. Deshalb schrieb ich „geht in die Richtung“, nicht „ist schon dort“.

dann Zeichnet <cite> beziehungsweise <blockqote cite=""> Inhalt semantisch nicht als Zitat aus?

'blockqote' sagt, DASS der Textinhalt dieses Elements ein Zitat ist. Es wird nicht gesagt, WELCHE Bedeutung (im Sinne von Semantik) der Textinhalt dieses Zitats hat. Eben das wäre für mich aber semantische Auszeichnung des Inhalts.

(Ich glaub, ich wiederhole mich. Gut, dass ich zwei Freunde hab: Copy und Paste.)

Und ich glaube, du hast eine falsche Vorstellung der Semantik (bezogen auf die Dokumentstruktur) des 'cite'-Elements. Es zeichnet nicht Zitiertes aus, sondern Quellen.

<p lang="de"> ist eine eindeutige, semantische Aussage bezüglich des Inhalts.

Ach ja, @lang="de" gibt an, WAS im Inhalt drinsteht? Denk nochmal drüber nach!

@lang ist keine semantische Aussage bezüglich des Inhalts, sondern eine Meta-Information über den Inhalt.

HTML hat genauso nicht alle Möglichkeiten […]
Sag ich doch.

Keine Deine hinzugezogenen Namensräume hat alle Möglichkeiten, daher brauchst Du ja drei. Das aber siehst Du bei Deinem Beispiel nicht ein.

Hä? Was seh ich nicht ein? Warum sollen es nicht mehrere Vokabulare sein? Es ist ein grundlegendes Konzept von RDF, vorhandene Vokabule zu nutzen. “URIrefs from different vocabularies can be freely mixed in RDF graphs.” [RDF-PRIMER §2.2]

Insbesondere siehst Du nicht, dass Du im eigentlichen, wenn Du von inhaltlicher Semantik sprichst, tatsächlich inhaltliche Bezüge meinst, was nicht Anliegen der Semantik ist, wie ich Dir jetzt zweitmalig schreibe.

Mag sein, dass wir ein unterschiedliches Verständnis von Begriffen haben. Nenn du es von mir aus „Bezüge“. Was ich darunter verstehe, hab ich oft genug dargestellt. So oft, dass du eigentlich keinen Grund mehr haben solltest, das nicht zu verstehen.

Siehst Du eigentlich mit welcher Inkonsistenz Deinerseits ich hier seit Tagen zu kämpfen habe?

Jaja, ist ja gut, ich fang ja schon an, dich zu bemitleiden.

Das ist mal wieder: Gunnar haftet am Dogma fest, wie ein Kind das nicht geboren werden will am Mutterkuchen...

Je öfter du den Begriff „Dogma“ gebrauchst, desto lächerlicher wird es. Besonders, wenn du ihn noch bildhaft illustrierst. (Tautology intended.)

Die Vorteile liegen auf der Hand, sind Dir mehrfach hier im Threat aufgezeigt worden.

Jetzt drohst du gar schon damit, strukturelle Semantik per CSS zu vermitteln.

wenn Du so halsstarrig bist, und sie beim ersten Lesen nicht gedanklich bedacht hast.

Das liegt vielleicht daran, dass du sie nicht plausibel geschildert hast. Falls es sie gibt.

Qapla'

[Edgar Ehritt]

Allo Schön, dann eben den großen Problemaufriss:

Bspw: <em property="foaf:name">Leonardo da Vinci</em>. Die semantische Auszeichnung des Inhalts ist nicht 'em', sondern "foaf:name".

Bezüglich der Strukturellen Bedeutung ist <em> sehr wohl semantische Auszeichnung!

Ja, natürlich. Das sag ich doch die ganze Zeit. Bezüglich der strukturellen Bedeutung, ja! Aber nicht bezüglich der inhaltlichen Bedeutung. Ha’m wa’s jetzt?

Nein. Denn Du siehst nur den Teil, bis zu Deinem Dogma.

Als ein weitestgehend bedeutungsfreies Element HTMLs könnte man auch, wie in Deinem Beispiel, <span property="foaf:name">Inhalt</span> notieren. Hierbei ist der alleinige Bedeutungsträger das Attribut property. Denn die Bedeutung als einen (Eigen-)Namen wird dem Inhalt durch dieses zugewiesen. Dabei ist die Semantik, soweit sie - lexikalisch gesehen - sich eines anderen Elements zur Strukturierung der sich abgrenzender Bedeutungen bedient, nur struktureller Natur. (Das hat zwar marginale Auswirkungen auf die Verhaltensschicht, ist aber zu vernachlässigen.)  <em>, wie der HTML-Standard sagt, wohnt ohne Attribuierung eine eigenständige Bedeutung bei. Der Inhalt dieses Elements hat gegenüber anderen Elementen emphatisch Charakter, was seinerseits eine implizite Attribuierung ist. Selbes gilt ja analog für "name" im FOAF-Schema. Deine im Archivbeitrag gemachte Aussage, dass HTML-Elementen keinerlei Semantik innewohne ist alos jedenfalls haltlos.

Halten wir also fest, beides sind Attribuierungen. Während FOAF u. a. Namen semantisch auszeichnen kann, Passagen (in unserem Fall HTML-Elementen bzw. DOM-Objekten) also als die Bedeutung "Inhalt ist ein Name" zuweist, erhält <em> seine Bedeutung "Inhalt ist eindringlich/nachdrücklich" implizit, wie das beim Term foaf:name der Fall ist. FOAF hat keine Möglichkeiten Passagen als emphatisch zu attribuieren. HTML hat dagegen Möglichkeiten Passagen als Namen _und_ als empatisch zu attribuieren. Das hängt eben mit der strukturellen Natur HTMLs zusammen, logische Relationen setzen zu können, wie ich weiter unten noch aufzeigen werde.

Selbes gilt im Vergleich FOAFs zu HTML, wenn die Bedeutung "Inhalt ist eine Adresse" zugewiesen werden soll. RDF kann dies. RDF und FOAF können dennoch keine Bedeutung "Inhalt ist eindringlich" zuweisen. So haben diese drei betrachtungsgegenständlichen, semantischen Sprachen lexikalische Grenzen. Das aber nutzt Du völlig unreflektiert als Basis Deiner Argumentation aus. So hast Du nicht grundlos das Beispiel "Leonardo da Vinci wurde geboren am 15. April 1452" gewählt. Versuche doch mal mit FOAF, RDF und XML folgendes Beispiel bedeutungsgleich auszuzeichnen:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">  
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#">  
  <head><title>Leonardo da Vinci</title></head>  
  <body>  
    <p typeof="foaf:Person">  
      <span property="foaf:name">Leonardo da Vinci</span>  
      wurde  
      <em>erst</em>  
      am  
      <span property="vCard:BDAY" content="1452-04-15">15. April 1452</span>  
      geboren, und  
      <em>nicht</em> schon am  
      <span property="vCard:BDAY" content="1452-01-15">15. Januar 1452</span>  
    </p>  
  </body>  
</html>

Das aber war der Einwand, den ich nicht weiter ausgeführt hatte, als ich auf die lexikalischen Möglichkeiten der einzelnen Namensräume hingewiesen hatte. Aber nehmen wir mal ein ganz anderes Beispiel:

Die USS Midway kreuzte unter rauer See von New York über London nach Rotterdam.
      Ein anderer Carrier folgte ihr später in ruhiger See aus dem Panamakanal.

Zeichne diese Texte dabei so aus, dass "USS Midway" und "[nicht näher benannt}" Schiffe sind, ihre Fahrbedingungen semantisch erwähnt werden und beschreibe ebenso semantisch ihre Route. So, Gunnar, ich hoffe, Du siehst langsam, wo Du Dein Gaul von hinten aufgezäumt hast und ihn so völlig ungeniert mir las Geschenk zur Maulkontrolle schickst.

Nochmals: Du instrumentalisierst bei Deiner Argumentation den lexikalisch begrenzten Bereich der einzelnen Schemata zur semantischen Auszeichnung und sprichst völlig selbstgefällig offensichtlich spezifizierte Implizitbedeutungen HTMLs ab. Das ist keine Art des Umgangs hier im Forum, den ich gutheiße. Das ist ein auf kniehöhe Anpinkeln von der Seite. Dabei hatte ich klargestellt, dass von Sicht der Verhaltensschicht Deine Art der Zuweisung in nichts anders ist als das Zuweisen von CSS-Eigenschaften.

Kommen wir also darauf zurück, dass ich behauptet habe, ohne FOAF und RDF aufgrund der Semantik mancher HTML-Strukturen Dein da-Vinci-Beispiel _gänzlich_ auszeichnen kann:

<table>  
 <thead>  
  <tr>  
   <th>Name</th>  
   <th>Datum der Geburt</th>  
  </tr>  
 </thead>  
 <tbody>  
  <tr>  
   <td>Leonardo da Vinci</td>  
   <td><em><del>15. Januar 1452</del><em><br>15. April 1452</td>  
  </tr>  
 </tbody>  
</table>

Mein Beispiel der Schiffe:

<table>  
 <thead>  
  <tr>  
   <th>Schiffe</th>  
   <th>Fahrbedingungen</th>  
   <th>Route</th>  
  </tr>  
 </thead>  
 <tbody>  
  <tr>  
   <td>USS Midway</td>  
   <td>raue See</td>  
   <td>  
    <ul>  
     <li>New York</li>  
     <li>London</li>  
     <li>Rotterdam</li>  
    </ul>  
   </td>  
  </tr>  
  <tr>  
   <td>nicht näher benannt</td>  
   <td>ruhige See</td>  
   <td>  
    <ul>  
     <li>Panamakanal</li>  
     <li>Rotterdam</li>  
    </ul>  
   </td>  
  </tr>  
 </tbody>  
</table>

Das ist ja gerade eines der Konzepte HTMLs, übrigens XML nicht unähnlich, in Teilen Semantik den Autor durch logisch relationale Auszeichnung selbst zu überlassen. Du magst sicher einwenden, dass dies keine Semantik ist, es seien Bedeutungen, die sich aus der logischen Relation zueinander ergeben. An diesem Punkt aber rufe ich Dir endgültig zu, schlage den Begriff Semantik nach, wenn Du es im Studium nicht hattest.
 Sei es, wie es sei. Selbst diese Relationen werden heute sogar schon durch CSS hergestellt (vgl. W3C; CSS - table-layout). Warum soll also die Semantik nicht komplett dort abgelegt werden?

Dass das aus Sicht der Datenverarbeitung nicht einheitlich ist, wie etwas bei thematischen Inselsemantiken, wie FOAF oder RDF, in ihrem spezifischen Einsatzbereich sein wird, ist klar. Dass das zu technischen Schwierigkeiten führt, zeigt die Crawlerentwicklung seit über einem Jahrzehnt. Es ist nur bei der Betrachtung "Semantik" als "Bedeutungslehre" innerhalb von Markups kein hinderliches Argument. Es bietet auch keinerlei Grundlage dafür, <em> semantische Bedeutung bezüglich des Inhalts abzusprechen.

Gruß aus Berlin!
eddi

[apsel]

Om nah hoo pez nyeetz,

Es macht richtig Spaß, euch "zuzulesen".
Ich hoffe, ich mache mich nicht unbeliebt, aber ist es nicht so, dass, wenn man das CSS ausschaltet, immer noch die inhaltliche Bedeutung erkennbar sein soll und die kann ich nunmal mit <b> oder <i> nicht klarmachen. Insofern spricht dies gleichermaßen für Edgars Tabelle als auch für Gunnars <p  typeof="foaf:Person"> ... Beide erlauben eine Zuordnung.

Matthias

[Edgar Ehritt]

Hallo Matthias,

danke für den Einwand.

@Gunnar:

aber ist es nicht so, dass, wenn man das CSS ausschaltet,

So einfach kann ein Argument gegen meinen Vorschlag aussehen, während man in Deinem widersprüchlichem Kudelmudel Gefahr läuft, sich zu verheddern. Denn gemessen an den praktischen Möglichkeiten heutzutage, erweist sich hier ein Lücke, wenn man Semantik und Daten zu weit voneinander separiert. Dies müsste also ebenso in Angriff genommen werden, was entweder die Diktatur der Webgestalters einläutete, oder Informationsverlust bedeutete.

Gruß aus Berlin!
eddi

[apsel]

Om nah hoo pez nyeetz,

manchmal kann man aber doch versucht sein, Elemente mit CSS semantisch auszuzeichnen, z.B. bei einem Kalender. So wie man sich bei seinem eigenen Tischkalender vielleicht den Urlaub mit einem Textmarker hervorhebt, könnte man eine Hervorhebung mit CSS gestalten (siehe z.B. hier bei Frederik41. Beim Ausschalten des CSS geht natürlich diese semantische Information verloren.

Matthias

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

@Gunnar:

aber ist es nicht so, dass, wenn man das CSS ausschaltet,

So einfach kann ein Argument gegen meinen Vorschlag aussehen,

Ich dachte, du wolltest ein grundlegend neues Konzept diskutieren, dessen Umsetzung natürlich neuer Clients bedürfte. Was hat die Möglichkeit der Deaktivierung von Stylesheets in heutigen UAs damit zu tun?

Qapla'

[Edgar Ehritt]

Re:

Ich dachte, du wolltest ein grundlegend neues Konzept diskutieren, dessen Umsetzung natürlich neuer Clients bedürfte. Was hat die Möglichkeit der Deaktivierung von Stylesheets in heutigen UAs damit zu tun?

Gunnar, manchmal kannst Du ein richtiger Spielverderber sein. Die Falle war so schön... :(((

Natürlich hast Du Recht. Es bedürfte auch hier nicht sehr viel mehr als eine Trennung (oder Stufe bei der Verarbeitung der Anweisungen) zwischen Formatierung und semantischer Auszeichnung in heutigen Browser; sodass die Formatierung hinzugeschaltet, jedoch semantische Auszeichnung aber nicht abgeschaltet werden kann.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@apsel:

nuqneH

Es macht richtig Spaß, euch "zuzulesen".

Ich hatte schon befürchtet, dieses Subthread hätte nicht einmal Unterhaltungswert.

Qapla'

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Halten wir also fest, beides sind Attribuierungen. Während FOAF u. a. Namen semantisch auszeichnen kann, Passagen (in unserem Fall HTML-Elementen bzw. DOM-Objekten) also als die Bedeutung "Inhalt ist ein Name" zuweist, erhält <em> seine Bedeutung "Inhalt ist eindringlich/nachdrücklich" implizit

Dennoch ist zwischen beidem ein Unterschied: "foaf:name" sagt, WAS die Textpassage ist; 'em' sagt, WIE die Textpassage ist.

HTML hat dagegen Möglichkeiten Passagen als Namen _und_ als empatisch zu attribuieren.

So einfühlsam ist HTML nicht. ;-)

(BTW, ich hab wirklich was in diesem Thread von dir gelernt: nichts über XML, was ich nicht schon wusste, aber dass es das Wort „emphatisch“ im Deutschen gibt. Ich hatte zuerst „empathisch“ gelesen und gedacht: Was will er denn?)

RDF und FOAF können dennoch keine Bedeutung "Inhalt ist eindringlich" zuweisen.

Bist du *sicher*?

<rdf:RDF  
  xmlns:foaf="http://xmlns.com/foaf/0.1/"  
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
  xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#"  

>  

  <foaf:Person rdf:ID="Rosi">  
    <vCard:FN>Rosi</vCard:FN>  
    <vCard:TEL rdf:parseType="Resource">  
      <rdf:value>[phone]</rdf:value>  
      <rdf:type rdf:resource="http://www.w3.org/2001/vcard-rdf/3.0#home"/>  
      <rdf:type rdf:resource="http://www.w3.org/2001/vcard-rdf/3.0#pref"/>  
   </vCard:TEL>  
    <vCard:TEL rdf:parseType="Resource">  
      <rdf:value>[phone]</rdf:value>  
      <rdf:type rdf:resource="http://www.w3.org/2001/vcard-rdf/3.0#cell"/>  
    </vCard:TEL>  
  </foaf:Person>  
</rdf:RDF>

Die Festnetznummer ist durch "http://www.w3.org/2001/vcard-rdf/3.0#pref" als bevorzugte Telefonnummer eindringlich hervorgehoben. Das sagt dem Anrufer: erst diese versuchen, dann die Mobilfunknummer.

(Ich kann’s auch nicht leiden, wenn ich gemütlich nebem meinem Telefon sitze und in den Flur rennen muss, weil in der Jackentasche das Handy klingelt.)

Diese Art der semantischen Hervorhebung geht sogar noch weiter als 'em' in HTML: Es wird nicht nur gesagt, DASS hervorgehoben wird, sondern auch, WARUM.

Versuche doch mal mit FOAF, RDF und XML folgendes Beispiel bedeutungsgleich auszuzeichnen:
    <p typeof="foaf:Person">
      <span property="foaf:name">Leonardo da Vinci</span>
      wurde
      <em>erst</em>
      am
      <span property="vCard:BDAY" content="1452-04-15">15. April 1452</span>
      geboren, und
      <em>nicht</em> schon am
      <span property="vCard:BDAY" content="1452-01-15">15. Januar 1452</span>
    </p>

Das Beispiel ist falsch. "vCard:BDAY" sagt aus: „ist Geburtstag von“; für „ist nicht Geburtstag von“ darf es nicht verwendet werden.

Per OWL lässt sich angeben, dass "foaf:Person" nur einmal "vCard:BDAY" darf. [OWL-FEATURES §3.5] Damit wäre ausgedrückt, dass alles andere als das per "vCard:BDAY" Angegebene nicht der Geburtstag ist.

Die USS Midway kreuzte unter rauer See von New York über London nach Rotterdam.
      Ein anderer Carrier folgte ihr später in ruhiger See aus dem Panamakanal.

Zeichne diese Texte dabei so aus, dass "USS Midway" und "[nicht näher benannt}" Schiffe sind, ihre Fahrbedingungen semantisch erwähnt werden und beschreibe ebenso semantisch ihre Route.

<!DOCTYPE rdf:RDF [  
  <!ENTITY schiff "http://example.net/schiffahrt/schiff#">  
  <!ENTITY ort "http://example.net/schiffahrt/ort#">  
  <!ENTITY fahrt "http://example.net/schiffahrt/fahrt#">  
]>  
<rdf:RDF  
  xmlns="http://example.net/schiffahrt/ns#"  
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  

>  

  <Ort rdf:about="&ort;London">  
    <Name>London</Name>  
  </Ort>  
  <Ort rdf:about="&ort;NewYork">  
    <Name>New York</Name>  
  </Ort>  
  <Ort rdf:about="&ort;Panamakanal">  
    <Name>Panamakanal</Name>  
  </Ort>  
  <Ort rdf:about="&ort;Rotterdam">  
    <Name>Rotterdam</Name>  
  </Ort>  
  <Schiff rdf:about="&schiff;USSMidway">  
    <Name>USS Midway</Name>  
  </Schiff>  
  <Fahrt rdf:about="&fahrt;1">  
    <Carrier>  
      <Schiff rdf:about="&schiff;USSMidway"/>  
    </Carrier>  
    <Route rdf:parseType="Resource">  
      <von>  
        <Ort rdf:about="&ort;NewYork"/>  
      </von>  
      <über>  
        <Ort rdf:about="&ort;London"/>  
      </über>  
      <nach>  
        <Ort rdf:about="&ort;Rotterdam"/>  
      </nach>  
    </Route>  
    <Bedingung>raue See</Bedingung>  
  </Fahrt>  
  <Fahrt rdf:about="&fahrt;2">  
    <späterAls>  
      <Fahrt rdf:about="&fahrt;1"/>  
    </späterAls>  
    <andererCarrierAls>  
      <Schiff rdf:about="&schiff;USSMidway"/>  
    </andererCarrierAls>  
    <Route rdf:parseType="Resource">  
      <über>  
        <Ort rdf:about="&ort;Panamakanal"/>  
      </über>  
      <nach>  
        <Ort rdf:about="&ort;Rotterdam"/>  
      </nach>  
    </Route>  
    <Bedingung>ruhige See</Bedingung>  
  </Fahrt>  
</rdf:RDF>

Mein Beispiel der Schiffe:
  <tr>
   <td>USS Midway</td>
  </tr>
  <tr>
   <td>nicht näher benannt</td>
  </tr>

Hehe, „nicht näher benannt“ ist was anderes als „anderer Carrier [als USS Midway]“. Diese Beziehung hast du nicht hergestellt.

Sei es, wie es sei. Selbst diese Relationen werden heute sogar schon durch CSS hergestellt (vgl. W3C; CSS - table-layout).

Nein, CSS gibt die Darstellung (Anordnung) an, mehr nicht. Die Zuordnungen Schiff – USS Midway, Bedingung – raue See, Route – New York–London–Rotterdam finden anhand der Anordnung im Kopf des Lesers statt.

Wenn sie nicht im Markup verankert sind. Durch die Zuordnungen der 'td'-Elemente zu den jeweiligen 'th'-Elementen ist dies gewissermaßen bei einer Tabelle gegeben. Durch das Markup.

Warum soll also die Semantik nicht komplett dort abgelegt werden?

Warum sollte? Was versprichst du dir davon?

Kommt jetzt wieder nur „Dazu habe ich schon alles gesagt“? Nein, hast du nicht.

Qapla'

[Edgar Ehritt]

Re:

<Schiff rdf:about="&schiff;USSMidway"/>

Die Zuordnungen Schiff – USS Midway, Bedingung – raue See, Route – New York–London–Rotterdam finden anhand der Anordnung im Kopf des Lesers statt.

Und Du meinst jetzt das sei bei Deinem Beispiel anders? Dann sind wir nämlich bei den extra von mir im letzten Beitrag nicht angesprochenen Attributen:

<span title="Schiff">USS Midway</span>

Und warum es für Semantik (als Bedeutungslehre) ein Unterschied sein soll, ob etwas ausgezeichnet wird, wie oder was es ist, hast Du, wie eigentlich immer bei Dir, nicht ausgeführt.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Die Zuordnungen Schiff – USS Midway, Bedingung – raue See, Route – New York–London–Rotterdam finden anhand der Anordnung im Kopf des Lesers statt.

Und Du meinst jetzt das sei bei Deinem Beispiel anders?

Ja. Zum einen geht das schon aus der XML-Struktur hervor: das Element 'Schiff[@rdf:about="http://example.net/schiffahrt/schiff#USSMidway"]' ist innerhalb des 'Carrier'-Elements; "raue See" ist Inhalt des 'Bedingung'-Elements.

Aus RDF-Sicht: "http://example.net/schiffahrt/schiff#USSMidway" ist das zugehörige Objekt zum Prädikat "http://example.net/schiffahrt/ns#Carrier"; "raue See"  ist das zugehörige Objekt zum Prädikat "http://example.net/schiffahrt/ns#Bedingung". (Das Subjekt ist jeweils "http://example.net/schiffahrt/fahrt#1".)

Du kannst ja den RDF-Validator mit meinem Beispiel füttern und die Triplets und den Graphen anzeigen lassen.

Und warum es für Semantik (als Bedeutungslehre) ein Unterschied sein soll, ob etwas ausgezeichnet wird, wie oder was es ist, hast Du, wie eigentlich immer bei Dir, nicht ausgeführt.

Oh, entschuldige bitte. Ich hatte wohl in diesem Thread noch nicht oft genug erwähnt, dass ich zwischen Semantik bezüglich des Dokumentinhalts und Semantik bezüglich der Dokumentstruktur einen Unterschied sehe.

Qapla'

[Edgar Ehritt]

Re:

Die Zuordnungen Schiff – USS Midway, Bedingung – raue See, Route – New York–London–Rotterdam finden anhand der Anordnung im Kopf des Lesers statt.

Und Du meinst jetzt das sei bei Deinem Beispiel anders?

Ja. Zum einen geht das schon aus der XML-Struktur hervor: das Element 'Schiff[@rdf:about="http://example.net/schiffahrt/schiff#USSMidway"]' ist innerhalb des 'Carrier'-Elements; "raue See" ist Inhalt des 'Bedingung'-Elements.

(Nebenbei bemerkt: Nach einem Doppelpunkt beginnt ein neuer Satz.)

Nur weil Du Elemente wie <Carrier>, <Bedingung>, etc. notierst, geht daraus für ein (unspezifisches) XML-RDF-Programm keinerlei Semantik hervor. Das ist der Punkt, Gunnar. Wenn ich "kjdfakjhfkhlka" als Daten in welchem Format auch immer speichere, mag mein spezifisches Programm dem (besondere) Bedeutung beimessen. Andere Programme tun das schlicht weg nicht. Anders sieht das bei meinen Beispielen (Table und Attribut-title) aus. Darauf gehst Du gar nicht ein.

Aus RDF-Sicht: "http://example.net/schiffahrt/schiff#USSMidway" ist das zugehörige Objekt zum Prädikat "http://example.net/schiffahrt/ns#Carrier"; "raue See"  ist das zugehörige Objekt zum Prädikat "http://example.net/schiffahrt/ns#Bedingung". (Das Subjekt ist jeweils "http://example.net/schiffahrt/fahrt#1".)

Du kannst ja den RDF-Validator mit meinem Beispiel füttern und die Triplets und den Graphen anzeigen lassen.

Du kannst auch meine Beispiele dem HTML-Validator verfüttern; nur dadurch wird sich nichts an der Tatsache ändern, dass HTML (mindestens, was Deine letzten Beispiele anbelangt sogar bessere) adäquate Möglichkeiten hat. Bisher kam immer noch kein Argument, warum Du dort so interveniertest und auf ein altes Posting verweist, das haltlose Aussagen machen.

Und warum es für Semantik (als Bedeutungslehre) ein Unterschied sein soll, ob etwas ausgezeichnet wird, wie oder was es ist, hast Du, wie eigentlich immer bei Dir, nicht ausgeführt.

Oh, entschuldige bitte. Ich hatte wohl in diesem Thread noch nicht oft genug erwähnt, dass ich zwischen Semantik bezüglich des Dokumentinhalts und Semantik bezüglich der Dokumentstruktur einen Unterschied sehe.

Erwähnt hattest Du es, begründet hattest Du es aber nicht. Lies doch mal! Da steht ein Interrogativpronomen "warum". Es ist nicht ersichtlich, warum Du zwischen zwei Attribute zweier Elementen jeweils in ihrem Markup einen Unterschied siehst . Eben sowenig gest Du auf das Beispiel der Table ein. Das sehe ich als typisch für Dich an und hatte es (nicht nur in diesem Thread immer wieder) bemängelt. Was ich bisher zusammenfassen kann: Du gehst auf die eigentlichen Argumente gar nicht ein, sondern löscht sie und beißt Dich an Sachen im verbleibenden Rest fest. Dabei mag es ja sein, dass Du Recht hast. Du begründest es stehts nie - ein absolute Unart.

Gruß aus Berlin!
eddi

[apsel]

Om nah hoo pez nyeetz,

Du begründest es stehts nie - ein absolute Unart.

Was denn nun, stets oder nie? ;-)

wenn man Semantik und Daten zu weit voneinander separiert.

aus meiner Sicht kann man Semantik und Daten garnicht von einander trennen, denn die inhaltliche Bedeutung liegt in den Daten selbst. Dass der Webseitenersteller irgendwelche Dinge besonders auszeichnen möchte, z.B. als <h1> oder <b>, liegt daran, dass er sich selbst über die inhaltliche Bedeutung Gedanken gemacht hat. Ansonsten gilt nach wie vor:

Insofern spricht dies gleichermaßen für Edgars Tabelle als auch für Gunnars <p  typeof="foaf:Person"> ... Beide erlauben eine Zuordnung.

So wie ich das verstehe, ist CSS ausschließlich für die optische Gestaltung zuständig, der Inhalt und seine semantische Bedeutung gehört ins html. Eine Ausnahme mit dem damit verbundenen Nachteil siehe mein Kalenderposting.

Matthias

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Nur weil Du Elemente wie <Carrier>, <Bedingung>, etc. notierst, geht daraus für ein (unspezifisches) XML-RDF-Programm keinerlei Semantik hervor.

Das hatte ich auch nicht behauptet. Ich hatte gesagt, dass die _Zuordnungen_ Schiff – USS Midway, Bedingung – raue See im XML durch die Eltern-Kind-Beziehungen gegeben sind.

Solche Eltern-Kind-Beziehungen waren bei nicht dir nicht der Fall; ich hatte aber zugestanden, dass bei einer Tabelle Beziehungen der Zelle der i-ten Spalte der j-ten Zeile sowohl zu allen anderen Zellen der i-ten Spalte als auch zu allen anderen Zellen der j-ten Zeile bestehen.

Bei nichttabellarischen Inhalten bestehen solche nicht (außer vielleicht noch bei 'dt'/'dd' und 'input[@id="foo"]'/'label[@for="foo"] (und vielleicht noch etwas, was mir gerade nicht einfällt)). Werden solche Inhalte ohne im Markup ausgedrückte Zuordnung direkt nebeneinander (oder untereinander) präsentiert, stellt der Leser eine Zuordnung her.

Bei RDF stellt das Prädikat "http://example.net/schiffahrt/ns#Carrier" die Zuordnung zwischen dem Subjekt "http://example.net/schiffahrt/fahrt#1" und dem Objekt "http://example.net/schiffahrt/schiff#USSMidway" und das Prädikat "http://example.net/schiffahrt/ns#Bedingung" die Zuordnung zwischen dem Subjekt "http://example.net/schiffahrt/fahrt#1" und dem Objekt "raue See" her. (Dadurch, dass beide Objekte zum selben Subjekt gehören, besteht auch eine Beziehung zwischen diesen.)

Wenn du mit mir über RDF diskutieren möchtest, machst du dich bitte mit dessen Konzept vertraut?

Wenn ich "kjdfakjhfkhlka" als Daten in welchem Format auch immer speichere, mag mein spezifisches Programm dem (besondere) Bedeutung beimessen. Andere Programme tun das schlicht weg nicht.

Ja, natürlich. Bedeutung kann eine Software nur erkennen, wenn sie verwendete Syntax und Vokabular kennt.

Anders sieht das bei meinen Beispielen (Table und Attribut-title) aus.

Wo hast du denn bei deiner Tabelle die Bedeutung von "raue See"? Im Markup? Nein, in der Beschriftung der Tabellenspalte. Aber sprachen wir nicht über semantische Auszeichnung? Ja, taten wir. Du schweifst vom Thema ab.

Um semantische Auszeichnung in HTML unterzubringen, würde ich nicht @title verwenden, sondern @class oder @role [XHTML-ROLE]. Bevor du jetzt an die Decke hüpfst und denkst, jetzt hätte ich gesagt, dass HTML doch Inhalte semantisch auszeichnet, nein das tut nicht HTML an sich, sondern RDFa oder Mikroformate.

Da steht ein Interrogativpronomen "warum". […] Du begründest es stehts nie - ein absolute Unart.

Zum Thema „Hund“ hatte ich – glaube ich – schon genug gesagt. Du zum Thema „Warum Bedeutung mit CSS ausdrücken?“ übrigens nicht.

Qapla'

[Edgar Ehritt]

Re:

Wenn du mit mir über RDF diskutieren möchtest, machst du dich bitte mit dessen Konzept vertraut?

Warum sollte ich? Du hast eingeräumt, dass Du lediglich strukturelle Semantik mit Deinem RDF-Beispiel betreiben kannst. Du hast eingeräumt, dass HTML dem gleichwertig ist. Mehr konnte ich doch gar nicht erwarten, als dass Du von Deiner seltendämlichen Überzeugung RDF-XML schafft es, inhaltliche Bedeutungen (außerhalb des spezifizierten lexikalischen Bereich) auszuzeichnen, so deutlich abrücken musst.

Wenn ich "kjdfakjhfkhlka" als Daten in welchem Format auch immer speichere, mag mein spezifisches Programm dem (besondere) Bedeutung beimessen. Andere Programme tun das schlicht weg nicht.

Ja, natürlich. Bedeutung kann eine Software nur erkennen, wenn sie verwendete Syntax und Vokabular kennt.

Und warum hast Du dann solche Korinthen unter https://forum.selfhtml.org/?t=194561&m=1301444 gekackt? HTML hat für das Auszeichenn von Inhalten genauso wie RDF jeweils begrenzte Möglichkeiten.

Anders sieht das bei meinen Beispielen (Table und Attribut-title) aus.

Wo hast du denn bei deiner Tabelle die Bedeutung von "raue See"? Im Markup? Nein, in der Beschriftung der Tabellenspalte. Aber sprachen wir nicht über semantische Auszeichnung? Ja, taten wir. Du schweifst vom Thema ab.

<td>raue See</td> ist nicht im Markup... Gunnar, sieh es ein, die Runde hast Du einfach mal vollends vergeigt; in jeder Hinsicht und mit fast jedem Einwand.

Um semantische Auszeichnung in HTML unterzubringen, würde ich nicht @title verwenden, sondern @class oder @role [XHTML-ROLE].

Noch mehr Schwachsinn. Attribut Role hältst Du mir in einer "second Last Call Working Draft" für den nicht verabschiedeten XHTML2-Standard unter die Nase. Du redest also von etwas, was Du machen würdest, wenn es XHML2 bereits gäbe. Derweil hatte ich immer von HTML geredet. Das kennt Attribut title. Ende Gelände!

Bevor du jetzt an die Decke hüpfst und denkst, jetzt hätte ich gesagt, dass HTML doch Inhalte semantisch auszeichnet, nein das tut nicht HTML an sich, sondern RDFa oder Mikroformate.

Nochmals, oben musstest Du einräumen, dass sie das eben nicht können sondern nur in struktureller Hinsicht außerhalb ihres lexikalischen Bereich. Darin sind sie HTML absolut gleich.

Da steht ein Interrogativpronomen "warum". […] Du begründest es stehts nie - ein absolute Unart.
Zum Thema „Hund“ hatte ich – glaube ich – schon genug gesagt. Du zum Thema „Warum Bedeutung mit CSS ausdrücken?“ übrigens nicht.

Dann suche Dir ein Herrchen, was diese Töle ordentlich erzieht. Vorteile von von CSS als Träger der Semantik waren jedenfalls an vielen Stellen ersichtlich. Übrigens ließe sich auch RDF so transportieren.

Und warum es für Semantik (als Bedeutungslehre) ein Unterschied sein soll, ob etwas ausgezeichnet wird, wie oder was es ist, hast Du, wie eigentlich immer bei Dir, nicht ausgeführt.

Zu dieser Frage hast Du immer noch keinen Ton verloren.

Alles in allem bin ich es müde Deine dämlichen und unüberlegten Einwende in ellenlangen Debatten auseinander zu nehmen. Warum auch, auf klärende Fragen, Argumente  und eigene Widersprüche reagierst Du eh in.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Wenn du mit mir über RDF diskutieren möchtest, machst du dich bitte mit dessen Konzept vertraut?

Warum sollte ich?

Damit du nicht solch einen Schwachsinn daherredest.

Du hast eingeräumt, dass Du lediglich strukturelle Semantik mit Deinem RDF-Beispiel betreiben kannst.

Nein. Ich hatte gesagt: „Zum einen geht das schon aus der XML-Struktur hervor […]“ Und danach die in RDF ausgedrückten Beziehungen aufgezeigt.

RDF ist nicht an XML gebunden; dies ist nur eine der möglichen Notationsformen.

Du hast eingeräumt, dass HTML dem gleichwertig ist.

Das Gegenteil ist der Fall.

<td>raue See</td> ist nicht im Markup...

Die Auszeichnung der Bedeutung von "raue See" geschieht nicht _durch_ Markup, also nicht durch Elemente oder Attribute. (Nein, 'td' zeichnet nicht die Bedeutung des Inhalts aus.)

Zieh dich nicht ständig an etwas auf, was ich gar nicht gesagt habe! Lern endlich lesen! Bis dahin …

Alles in allem bin ich es müde […]

Na wenigstens darin sind wir uns einig.

Qapla'

[Edgar Ehritt]

Re:

Das hatte ich auch nicht behauptet. Ich hatte gesagt, dass die _Zuordnungen_ Schiff – USS Midway, Bedingung – raue See im XML durch die Eltern-Kind-Beziehungen gegeben sind.

<>

Bevor du jetzt an die Decke hüpfst und denkst, jetzt hätte ich gesagt, dass HTML doch Inhalte semantisch auszeichnet, nein das tut nicht HTML an sich, sondern RDFa oder Mikroformate.

Wenn du mit mir über RDF diskutieren möchtest, machst du dich bitte mit dessen Konzept vertraut?
Warum sollte ich?
Damit du nicht solch einen Schwachsinn daherredest.

Ich brauchte nur Deine in sich vollends widersprüchlichen Aussagen in https://forum.selfhtml.org/?t=194561&m=1303063 nehmen. Damit hast Du Dich am besten selbst widerlegt. Warum also sollte ich mich mit RDF befassen, wenn es nach Deinen eigenen Ausführungen außerhalb der lexikalischen Definitionen haargenau Gleiches kann wie HTML?

Du hast eingeräumt, dass Du lediglich strukturelle Semantik mit Deinem RDF-Beispiel betreiben kannst.

Nein. Ich hatte gesagt: „Zum einen geht das schon aus der XML-Struktur hervor […]“ Und danach die in RDF ausgedrückten Beziehungen aufgezeigt.

RDF ist nicht an XML gebunden; dies ist nur eine der möglichen Notationsformen.

Wie hirnlos willst Du eigentlich noch an den offensichtlichen Tatsachen vorbeireden? Außerhalb des semantisch zugeordneten/definierten "Wortschatzes" (lexikalischer Bereich) hast Du faktisch einräumen müssen, dass Du nur Strukturelle Auszeichnungen vornehmen konntest. Darin, hast Du ebenso eingeräumt, steht meinen Tabelen-Beispiel dem gleich, da die logischen Bezüge sich hier nicht aus der Verschachtelung der Elemente sondern dessen Bedeutungen zueinander ergeben. Da kannst Du jetzt also noch so oft "Nein[, ich habe nichts eingeräumt]" schreiben.

Soweit Du Dich jetzt auf Beziehungen berufst, die aus RDF herrühren, fehlt es an einem Vergleich hinsichtlich der Semantik zwischen strukturellen Bezügen, die sich bspw. in HTML mittels DOM repräsentieren lassen und den Deiner Meinung nach elementaren Unterschieden RDFs. Du wirst bei dem Versuch feststellen, dass es wie DOM und XPath zwei varianten sind, sich demselben zu nähern.

Gerade daraus ist ja immer Deine Unüberlegtheit ersichtlich, was die Diskussion so uneinsichtig Deinerseits und ermüdend meinerseits gestaltet.

Du hast eingeräumt, dass HTML dem gleichwertig ist.
Das Gegenteil ist der Fall.

Du bist ja oben aufgefordert, die elementaren Unterschiede aufzuzeigen.

<td>raue See</td> ist nicht im Markup...

Die Auszeichnung der Bedeutung von "raue See" geschieht nicht _durch_ Markup, also nicht durch Elemente oder Attribute. (Nein, 'td' zeichnet nicht die Bedeutung des Inhalts aus.) Zieh dich nicht ständig an etwas auf, was ich gar nicht gesagt habe! Lern endlich lesen! Bis dahin …

  <Fahrt>  
    <Bedingung>raue See</Bedingung>  
  </Fahrt>

Das ist richtig, was Du schreibst. Du hast es in Deinem nur nicht anders gemacht. <Bedingung> weist, wie <td> nur strukturell einen Bezug zu. Was soll ich Dir jetzt zurufen? Lerne endlich verstehend Lesen?

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Ich brauchte nur Deine in sich vollends widersprüchlichen Aussagen in https://forum.selfhtml.org/?t=194561&m=1303063 nehmen. Damit hast Du Dich am besten selbst widerlegt. Warum also sollte ich mich mit RDF befassen

Um zu begreifen, dass meine Aussagen nicht widersprüchlich sind.

Du kannst es aber auch sein lassen, dich mit RDF zu befassen, für den Fall gibt(’s) nuhr einen Ratschlag.

wenn es nach Deinen eigenen Ausführungen außerhalb der lexikalischen Definitionen haargenau Gleiches kann wie HTML?

Ich führe die ganze Zeit an, dass es was völlig anderes tut und du unterstellst mir das Gegenteil? Du bist eine echte Witzfigur.

Qapla'

[Edgar Ehritt]

Re:

wenn es nach Deinen eigenen Ausführungen außerhalb der lexikalischen Definitionen haargenau Gleiches kann wie HTML?

Ich führe die ganze Zeit an, dass es was völlig anderes tut und du unterstellst mir das Gegenteil?

Tut es nicht. Daher kommen von Dir auch keine Argumente. ;)

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Wo wir jetzt bei den Einzeilern angekommen sind, will ich es auch bei „Jaja, is’ jut“ bewenden lassen. ;->

Qapla'

[Edgar Ehritt]

Re:

Wo wir jetzt bei den Einzeilern angekommen sind, will ich es auch bei „Jaja, is’ jut“ bewenden lassen. ;->

Eine Töle mag ja noch gehen; aber dann mit Pferdeschwanz, den die sich auch noch einklemmt... ^,-

Ich hatte mir alles so schön zurecht gelegt, um die einzeln angebrachten Spitzen sorgfältig zum finalen Feuerwerk zu komponieren.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Ich hatte mir alles so schön zurecht gelegt, um die einzeln angebrachten Spitzen sorgfältig zum finalen Feuerwerk zu komponieren.

Na dann …

Qapla'

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Ich hatte mir alles so schön zurecht gelegt, um die einzeln angebrachten Spitzen sorgfältig zum finalen Feuerwerk zu komponieren.

Wo wir bei Farben und Formen angekommen sind: Eben gefunden in [RDFa-PRIMER §1]: ein Bild, das dir vielleicht mehr sagt als meine 1000 Worte. Vielleicht auch nicht, dann belassen wir’s dabei.

Qapla'

[Edgar Ehritt]

Re:

Ich hatte mir alles so schön zurecht gelegt, um die einzeln angebrachten Spitzen sorgfältig zum finalen Feuerwerk zu komponieren.

Wo wir bei Farben und Formen angekommen sind: Eben gefunden in [RDFa-PRIMER §1]: ein Bild, das dir vielleicht mehr sagt als meine 1000 Worte. Vielleicht auch nicht, dann belassen wir’s dabei.

Offensichtlich willst Du es nicht begreifen, dass, wie Du selbst zugeben musstest, RDF inhaltliche Bedeutung _nur_ im Bereich des spezifizierten Wortschatzes zuweisen - und darüber hinaus _nur_ strukturelle Informationen bereitstellen kann. Es zeichnet also Informationen aus, die einem HTML-Attribut oder einer HTML-Struktur gleichwertig sind. Da kannst Du mir also noch so oft vorwerfen, ich hätte mich mit RDF nicht beschäftigt. Es ist im Merkmal Semantik, wie HTML auch, lexikalisch begrenzt. Das wird auch daraus deutlich, dass unter W3C: RDFa in XHTML: Syntax and Processing -> Beispiele ausgerechnet HTML bemüht wird, um zu zeigen, dass man das, was HTML mit Metainformationen nur an einer Stelle zulässt (beschränkter lexikalischer Bereich) nun datenbezogen auf Passagen anwenden kann. Trotzdem kann es mir eine Passage als emphatisch auszeichnen. RDF nicht; womit wir wieder bei den Grenzen von RDF angekommen sind. Sicher definiert RFC einiges deutlicher und die Möglichkeiten innerhalb strukturellem Markups sind in Teilbereichen besser. Ich erwarte aber auch, dass Du dann die Teilbereiche von HTML dem klar gegenüber stellst, statt dogmatisch HTML Semantik abzusprechen.
 Soweit Du Dich auch auf RDFa berufst, um Bezüge zwischen Subjekt <-> Prädikat <-> Objekt herstellen zu können, ist dies bei genauerer Betrachtung einigen Strukturen HTMLs nicht unähnlich. Das ergibt sich beim Blick aufs DOM, wie ich bereits angedeutet hatte.

Warum Du das nicht begreifen willst, ist mir schleierhaft. Ich brauch jedenfalls keine Diskussion mit jemanden, der nur plump voreingenommen anderen an den Kopf wirft, sie sollen sich mit Dingen beschäftigen, mit denen Du Dich offensichtlich nähergehend - im Sinne von bis zum Schluss durchdenkend - nie befasst hast.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Offensichtlich willst Du es nicht begreifen, dass […] RDF inhaltliche Bedeutung _nur_ im Bereich des spezifizierten Wortschatzes zuweisen […] kann.

Natürlich kann RDF nur „verstanden“ werden, wenn der verarbeitenden Software die verwendeten Vokabulare „bekannt“ sind. Darin gibt es nichts, was ich nicht begreifen wollen würde.

Das ist auch bei Maschinen nicht anders als bei Menschen. Du versteht mich ja auch nicht.

[RDF] zeichnet also Informationen aus, die einem HTML-Attribut oder einer HTML-Struktur gleichwertig sind.

Nein, RDF zeichnet Inhalte semantisch aus, HTML tut das nicht. Wie oft denn noch?

[RDF] im Merkmal Semantik, wie HTML auch, lexikalisch begrenzt.

Nein. RDF bietet das Gerüst (das sagt ja schon das F im Namen), man kann darin sein eigenes passendes Vokabular entwerfen. Das habe ich dir am Beispiel der Schifffahrt gezeigt.

HTML ist bei der semantischen Auszeichnung von Inhalten begrenzt, ja. Sehr begrenzt sogar. Die Grenze liegt bei Null.

Das wird auch daraus deutlich, dass unter W3C: RDFa in XHTML: Syntax and Processing -> Beispiele ausgerechnet HTML bemüht wird

Du hast verstanden, dass RDFa lediglich eine Möglichkeit ist, RDF in (X)HTML (o.a. Auszeichnungssprachen) einzubetten? Sieht nicht so aus.

Trotzdem kann [HTML] mir eine Passage als emphatisch auszeichnen.

Ja und? Semantische Auszeichnung des Inhalts ist dies nicht. Wie oft denn noch?

Qapla'

[Edgar Ehritt]

Re:

Offensichtlich willst Du es nicht begreifen, dass […] RDF inhaltliche Bedeutung _nur_ im Bereich des spezifizierten Wortschatzes zuweisen […] kann.
Natürlich kann RDF nur „verstanden“ werden, wenn der verarbeitenden Software die verwendeten Vokabulare „bekannt“ sind. Darin gibt es nichts, was ich nicht begreifen wollen würde.
Das ist auch bei Maschinen nicht anders als bei Menschen. Du versteht mich ja auch nicht.

Schön, dass Du das einräumst; schade, dass Du das auf unsere Beispiele nicht anzuwenden weist. Darin liegt ja nunmehr, neben Deiner sturen Haltung bezüglich des Inbegriffs von Semantik, der eigentliche Diskussionspunkt. Aber in diesem Punkt der Verständlichkeit (oder maschineller Verarbeitung) eigener Definitionen verhalten sich HTML und RDF schon gleich. Du scheinst der Meinung zu sein, das spiele nur bei HTML eine Rolle.

[RDF] zeichnet also Informationen aus, die einem HTML-Attribut oder einer HTML-Struktur gleichwertig sind.
Nein, RDF zeichnet Inhalte semantisch aus, HTML tut das nicht. Wie oft denn noch?

Beschäftige Dich mit der Grundlage "Semantik"! Wie oft denn noch?

[RDF] im Merkmal Semantik, wie HTML auch, lexikalisch begrenzt.
Nein. RDF bietet das Gerüst (das sagt ja schon das F im Namen), man kann darin sein eigenes passendes Vokabular entwerfen. Das habe ich dir am Beispiel der Schifffahrt gezeigt. HTML ist bei der semantischen Auszeichnung von Inhalten begrenzt, ja. Sehr begrenzt sogar. Die Grenze liegt bei Null.

Gemessen an Deiner Aussage fehlt es immer noch am differenzierten Auseinandersetzen deinerseits mit meinem Beispiel der Tabellen.

Das wird auch daraus deutlich, dass unter W3C: RDFa in XHTML: Syntax and Processing -> Beispiele ausgerechnet HTML bemüht wird
Du hast verstanden, dass RDFa lediglich eine Möglichkeit ist, RDF in (X)HTML (o.a. Auszeichnungssprachen) einzubetten? Sieht nicht so aus.

Das erscheint mir unerheblich, in welcher Form RDF genutzt wird. Wenn es Dir wichtig wäre zu differenzieren, gehe ich davon aus, Du wärst auf die einzelnen Möglichkeiten gesondert eingegangen. Bisher kommt aber in jeder Hinsicht nichts tiefgründiges.

Trotzdem kann [HTML] mir eine Passage als emphatisch auszeichnen.
Ja und? Semantische Auszeichnung des Inhalts ist dies nicht. Wie oft denn noch?

Beschäftige Dich mit der Grundlage "Semantik"! Wie oft denn noch?

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Beschäftige Dich mit der Grundlage "Semantik"! Wie oft denn noch?

Ich darf dich daran erinnnern: Wir philosophieren hier nicht über die „Grundlage "Semantik"“, sondern wir (ich zumindest) diskutieren darüber, was es heißt, inhaltlich semantisch auszuzeichnen.

Gemessen an Deiner Aussage fehlt es immer noch am differenzierten Auseinandersetzen deinerseits mit meinem Beispiel der Tabellen.

Ich hatte erklärt, dass es durch HTML eine Zuordnung bspw. der Datenzelle mit dem Inhalt "Leonardo da Vinci" zur Kopfzelle mit dem Inhalt "Name" gibt. Eine semantische Auszeichnung des Inhalts "Leonardo da Vinci" ist dies nicht; '<p typeof="foaf:Person"><span property="foaf:name">Leonardo da Vinci</span> …</p>' wäre eine solche.

Das wird auch daraus deutlich, dass unter W3C: RDFa in XHTML: Syntax and Processing -> Beispiele ausgerechnet HTML bemüht wird
Das erscheint mir unerheblich, in welcher Form RDF genutzt wird.

Eben erschien es dir noch erheblich.

Lass gut sein. Wenn du dir widersprichst und wir uns nur im Kreise drehen, kommen wir nicht weiter.

Qapla'

[Edgar Ehritt]

Re:

Beschäftige Dich mit der Grundlage "Semantik"! Wie oft denn noch?
Ich darf dich daran erinnnern: Wir philosophieren hier nicht über die „Grundlage "Semantik"“, sondern wir (ich zumindest) diskutieren darüber, was es heißt, inhaltlich semantisch auszuzeichnen.

Das tut wir tatsächlich nicht. Wir sollten aber schon die gleiche Basis als Ausgangspunkt der Betrachtungen haben. Deine Polemik ist also keineswegs angebracht!

Gemessen an Deiner Aussage fehlt es immer noch am differenzierten Auseinandersetzen deinerseits mit meinem Beispiel der Tabellen.
Ich hatte erklärt, dass es durch HTML eine Zuordnung bspw. der Datenzelle mit dem Inhalt "Leonardo da Vinci" zur Kopfzelle mit dem Inhalt "Name" gibt. Eine semantische Auszeichnung des Inhalts "Leonardo da Vinci" ist dies nicht; '<p typeof="foaf:Person"><span property="foaf:name">Leonardo da Vinci</span> …</p>' wäre eine solche.

Warum? -> Da, Gunnar, setzt Dein Denkfehler ein. Da habe ich oft genug vom lexikalischen Bereich gesprochen.

Das wird auch daraus deutlich, dass unter W3C: RDFa in XHTML: Syntax and Processing -> Beispiele ausgerechnet HTML bemüht wird
Das erscheint mir unerheblich, in welcher Form RDF genutzt wird.
Eben erschien es dir noch erheblich.

Das die Beispiele machen sich die semantische Auszeichnung HTMLs zunutze, um weitergehende Möglichkeiten von RDFa zu demonstrieren. Das zeigt also, wie ich schrieb, zum einen die bestehenden Möglichkeiten beider Auszeichnungen. Du sprichst HTML wider diesem Beispiel Semantik ab, was sich nicht auf die Form von RDF bezieht. Daher erscheint mir unerheblich zu sein, in welcher Form RDF genutzt wird.

Wenn du dir widersprichst und wir uns nur im Kreise drehen, kommen wir nicht weiter.

Wenn Du meine Aussagen nicht einmal inhaltlich verstehen kannst, drehst Du Dich im Kreis, auch wenn Du glaubst mir entgegenzukommen!

Lass gut sein.

Mangels Argumenten oder Einsicht deinerseits würde ich Dein Schweigen begrüßen!

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Ich hatte erklärt, dass es durch HTML eine Zuordnung bspw. der Datenzelle mit dem Inhalt "Leonardo da Vinci" zur Kopfzelle mit dem Inhalt "Name" gibt. Eine semantische Auszeichnung des Inhalts "Leonardo da Vinci" ist dies nicht; '<p typeof="foaf:Person"><span property="foaf:name">Leonardo da Vinci</span> …</p>' wäre eine solche.

Warum?

Was warum? Warum ich die Zuordnung von Zellen in einer HTML-Tabelle nicht für semantische Auszeichnung des Inhalts halte oder warum ich RDFa für semantische Auszeichnung des Inhalts halte?

Das die Beispiele machen sich die semantische Auszeichnung HTMLs zunutze, um weitergehende Möglichkeiten von RDFa zu demonstrieren.

Nein, die Beispiele machen sich die semantische Auszeichnung von RDF zunutze. Und die Struktur von HTML, um diese semantische Auszeichnung von RDF in Form von RDFa auszudrücken.

Qapla'

[Edgar Ehritt]

EOD

Nein, die Beispiele machen sich die semantische Auszeichnung von RDF zunutze. Und die Struktur von HTML, um diese semantische Auszeichnung von RDF in Form von RDFa auszudrücken.

Damit hat sich dann ein ernsthafter Diskurs über Semantik von HTML mit Dir erübrigt, da Du dem Element <meta> keinerlei Bedeutung im Sinne einer semantischen Auszeichnung zugestehen willst.

Gruß aus Berlin!
eddi

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Damit hat sich dann ein ernsthafter Diskurs über Semantik von HTML mit Dir erübrigt, da Du dem Element <meta> keinerlei Bedeutung im Sinne einer semantischen Auszeichnung zugestehen willst.

Hör auf mir hier unbegründet irgendwas zu unterstellen! Natürlich ist mit
<meta name="author" content="Leonardo da Vinci"/>
"Leonardo da Vinci" semantisch als Autor ausgezeichnet. Oder in einem anderen Vokabular:

  <link rel="schema.DC" href="http://purl.org/dc/terms/"/>  
  <meta name="DC.creator" content="Leonardo da Vinci"/>

Ich habe nie semantische Auszeichnung bei Meta-Angaben in Abrede gestellt. Schon deshalb nicht, weil dies hier noch nie Thema war.

Ich sprach die ganze Zeit von semantischer Auszeichnung des Dokument_inhalts_ und womit kommst du jetzt an? Mit semantischer Auszeichnung der Meta-Information über ein Dokument. Du willst dich nicht lächerlich machen, oder?

Kannst du natürlich gerne tun, nur sprich dann bitte nicht von „ernsthaftem Diskurs“.

Qapla'

[Edgar Ehritt]

Das wird auch daraus deutlich, dass unter W3C: RDFa in XHTML: Syntax and Processing -> Beispiele ausgerechnet HTML bemüht wird
Das die Beispiele machen sich die semantische Auszeichnung HTMLs zunutze, um weitergehende Möglichkeiten von RDFa zu demonstrieren.
Ich sprach die ganze Zeit von semantischer Auszeichnung des Dokument_inhalts_ und womit kommst du jetzt an? Mit semantischer Auszeichnung der Meta-Information über ein Dokument. Du willst dich nicht lächerlich machen, oder?

Nicht ich und auch nicht jetzt komme damit an, Gunnar. Das war das Beispiel, was ich vom W3C hatte. Zur Erläuterung der weitergehenden Möglichkeiten von RDF wurde HTMLs Semantik genutzt (in Form des Elements <meta>). Das Du das anders verstehen wolltest, ist klar geworden. Das ist aber nur (D)eine Sichtweise des Verständnisses, was sich aus meinem Satz ergab.

Wie schon geschrieben. Ich bin es Leid jedem Missverständnis Deinerseits und den Konsequenzen ewig hinterher zu diskutieren.

[Gunnar Bittersmann]

@@Edgar Ehritt:

nuqneH

Das war das Beispiel, was ich vom W3C hatte.

Das Beispiel war hier völlig unpassend, egal wo du es her hattest.

Wie schon geschrieben. Ich bin es Leid jedem Missverständnis Deinerseits und den Konsequenzen ewig hinterher zu diskutieren.

Damit wären wir dann wieder bei „Jaja, is’ jut“ angekommen.

Qapla'

[Encoder]

Ich erzähl jetzt einfach was ich so denke. Vielleicht wirds bisschen chaotisch, aber dafür ists ehrlich :-)
Hobby, das sagt schon dass du keine Seiten machst die man auch mit IE 1.0 auf Windows 95 ansehen können muss, weil sonst ein potentieller Kunde verloren geht. Halte ich auch so. Die Seiten die ich mache sind nicht so kritisch.

... per Braille-Zeile, am Fernseher, per Projektion usw. betrachtet werden. Oder vereinfacht ausgedrückt, wie hoch der Prozentsatz der nicht per Screen/ Bildschirm betrachteten Seiten ist?

Fernseher und Projektion ist doch auch Screen/Bildschirm, oder sehr vergleichbar. Bei beiden kommt es auf die Auflösung an, der Rest ist das selbe. Schon ein Handy fällt für mich flach, wenns nicht wirklich ein besonderer Notfall ist. Ein paar Textzeilen oder ein kleines Bild zu sehen, reicht halt nicht für das was ne Webseite kann.
Braille ist was anderes. Gerade da ist dann doch wieder von Vorteil dass man Inhalt und Layout trennt, z.B. per CSS.

Fixed width, fluid oder flexible - das ist hier die Frage?

Ich mach es so dass es in Grenzen flexibel ist. Fix würde bedeuten dass man jemandem Umstände macht, der seinen Browser nicht auf Vollbild hat. Wobei eine Mindestgröße schon auch sinnvoll ist, damit es nach was aussieht.
Beliebig breit möchte ich es aber auch wieder nicht werden lassen. Die Breitbildschirme erlauben zwar eine wahnsinns Breite. Aber ich kenn keine Seite die noch gut aussieht, wenn jeder Absatz aus max. 2 Zeilen besteht und alles total auseinander gerissen ist. Da darfs dann schon irgendwann mal Ränder haben.

Imho ist es in der Praxis doch so, dass man mit den heutigen Mitteln (CSS) und den aktuellen Gegebenheiten (Browser), mit flexiblen Layouts vor diversen Problemen/ Schwierigkeiten steht, deren Vermeidung oder Umgehung teils nur sehr aufwändig bis gar nicht möglich ist.

Wenn man nicht allzuviel will, gehts. Und ich erlaube mir einen dezenten Hinweis, dass es mit nicht aktuellen Browsern eben auch nicht aktuell aussieht. Wir sind ja längst nicht mehr bei dem Unsinn wie "best viewed with Netscape" oder so. Und wenns auf nem zweizeiligen Taschenrechner nicht nach Webseite aussieht ... na so what?

Die Frage, die mich dabei vorrangig beschäftigt ist, ob angesichts einer browserinternen Zoom-Funktion in allen gängigen aktuellen Browsern heutzutage, diese Frage nicht eventuell anders beantwortet werden kann, als vielleicht noch vor einigen Jahren?

Das heißt?
Schrift sollte schon lesbar sein, ohne dass man die allerbesten Augen hat und 3 cm vom Bildschirm entfernt liest.
Ich teste auch mit der Zoomfunktion, obs noch was gleich sieht. Z.B. ob irgendeine Navigation schon bei den ersten zwei Vergrößerungsstufen aus ihrem Rahmen hüpft oder so. Aber auch hier sag ich mir, bei 500% gibts halt keine schöne Seite mehr. Man kriegt alles kaputt, wenn man nur genügend Willen dazu hat ...

... scheint mein persönliches Empfinden doch ausschließlich von Print-Medien geprägt zu sein, denn rein optisch als "ansprechend" empfinde ich meist die Seiten, die sich von ihrer Gestaltung her an "klassischen" Print-Layouts orientieren.

Mit dem Unterschied dass Artikel im Web (meist) nicht mehrspaltig erscheinen.
Was ich mich grad frag, an was könnte es sich sonst orientieren? Die Grundsätze zum Betrachten einer Seite sind halt wirklich die gleichen wie bei einer Zeitung, Zeitschrift und ähnlichem.

Eine Webseite ist in allererster Linie ein visuelles Medium für die Betrachtung auf einem Bildschirm (Handy-Display, Computer-Monitor, Fernseher, etc.).

Vorlesen lassen kann man sich es natürlich auch, allerdings halt nicht unbedingt wenns ne Bildergallerie ist. Ich seh das gar nicht als Allerweltsmedium. Ich wüsst auch gar nicht wo sie sonst erscheinen sollte. Du?

Als einfaches Beispiel sei nur darauf verwiesen, dass es einer Unmenge an eigentlich "unnötigem" Markup bedarf, um eine optisch ansprechende Seite zu gestalten.

Wirklich eine Unmenge? Und warum unnötig, wenns dem optischen Anspruch dient?
Mit CSS kann man doch schon einiges machen. Und es wird schon meistens dabei bleiben, dass man Text und Bilder darstellen will. Auch in einer gewissen Reihenfolge. Die Anordnung variiert, durch zentrale Formatierungen mit CSS. Aber auch hier komm ich selten in die Verlegenheit, dass ich die Reihenfolge komplett durcheinander werfen möchte.

[Gunnar Bittersmann]

@@Encoder:

nuqneH

Beliebig breit möchte ich es aber auch wieder nicht werden lassen.

ACK. Ein erzwungener Tennis-Blick ist der Lesbarkeit nicht dienlich. Bei fließenden Layouts sollte man für Fließtext eine Maximalbreite angeben; so um die 50em dürfte ein vernünftiger Wert sein.

Die Grundsätze zum Betrachten einer Seite sind halt wirklich die gleichen wie bei einer Zeitung, Zeitschrift und ähnlichem.

Es gibt bedeutende Unterschiede zwischen Bildschirm und Papier.

(1) Die Punktdichte (dpi/ppi) von Gedruckten ist (noch) höher als bei Bildschirmen.

(2) Bildschirme passen sich i.d.R. nicht der Umgebungshelligkeit an, störende hohe Kontraste die Folge. Anders beleuchtetes Papier: ist die Umgebung hell, ist es auch das Papier. Hinzu kommen die störenden Spiegelungen auf Bildschirmen.

(3) Beim Lesen am Bildschirm ist man an seine Platz (Stuhl) gefesselt. Beim Lesen von Gedruckten kann man leicht seine Position wechseln, sich auf der Couch von einer Seite auf die andere drehen, auch Bauch- und Rückenlage sind problemlos. Das ist auch mit einem Netbook so nicht möglich.

(4) Bei Gedrucktem ist mehrspaltiger Satz möglich; bei ein Webseite problematisch, da Viewporthöhe und Schriftgröße beim Nutzer dem Seitenautor unbekannt sind, er also nicht sicherstellen kann, dass der Nutzer nicht wiederholt hin- und herscrollen muss.

(5) …

Qapla'