emu: Zu Navigationsleisten und deren Umsetzung

0 65

Zu Navigationsleisten und deren Umsetzung

emu
  • html
  1. 0
    Jeena Paradies
    1. 0
      emu
      1. 0
        Orlando
      2. 0
        Jeena Paradies
        1. 0
          Jeena Paradies
  2. 0
    Andreas-Lindig
    1. 0
      emu
  3. 0
    Cheatah
    1. 0
      emu
      1. 0
        Cheatah
      2. 0
        wahsaga
    2. 0
      molily
      1. 0
        Cheatah
        1. 0
          molily
  4. 0
    Armin G.
    1. 0
      emu
      1. 0
        Armin G.
        1. 0
          at
      2. 0
        Chräcker Heller
        1. 0

          Innovation offener Standards und deren Entwicklung durch Firmen

          Tim Tepaße
          • sonstiges
  5. 0
    Chräcker Heller
    1. 0
      emu
      1. 0
        wahsaga
        1. 0
          molily
      2. 0
        Chräcker Heller
  6. 0
    Cyx23
    1. 0
      molily
      1. 0
        emu
        1. 0
          at
          1. 0
            molily
            1. 0
              at
              1. 0
                Cyx23
                1. 0
                  at
  7. 0

    Zu Navigationslisten in XHTML 2

    Tim Tepaße
    1. 0
      emu
      1. 0
        Tim Tepaße
  8. 0
    Tim Tepaße
    1. 0
      emu
      1. 0
        Tim Tepaße
        1. 0
          Cyx23
          1. 0
            Tim Tepaße
            1. 0
              Cyx23
              1. 0
                at
                1. 0
                  Cyx23
                  1. 0
                    at
                    1. 0
                      Cyx23
                      1. 0
                        at
                        1. 0
                          Cyx23
                          1. 0
                            Tim Tepaße
                            1. 0
                              Cyx23
                              1. 0
                                Tim Tepaße
                                1. 0
                                  Cyx23
                                  1. 0
                                    at
                                  2. 0
                                    molily
                                    1. 0
                                      Cyx23
                                      1. 0
                                        molily
                                        1. 0
                                          Cyx23
                                          1. 0
                                            molily
                    2. 0
                      molily
                      1. 0
                        at
                        1. 0
                          molily
                          1. 0
                            at
              2. 0
                Tim Tepaße
                1. 0
                  Cyx23

Die Diskussionen, zuweilen Streitereien, ob man Navigationsleisten korrekterweise mit Framesets, Tabellen oder durch CSS positionierte (generische) Elemente umsetzen soll, führt in die Irre. Schon in der Vergangenheit habe ich darauf hingewiesen, dass das Konzept von HTML nicht vorsieht, solche Navigationsleisten einzusetzen, da die Navigation einerseits und hauptsächlich durch Hyperlinks im Text an dafür sinnvollen Stellen und andererseits, innerhalb der Menge von Seiten, die der Autor als zusammengehörig sieht (»Webpräsenz«), durch Links, die mittels <link> definiert sind, zu erfolgen hat.

Da diese Möglichkeit durch die derzeitige Dominanz von Browsern, die diese Möglichkeit nicht oder nur unzureichend bieten, nur eingeschränkt möglich ist (in weiten Teilen des WWW allerdings sehr wohl, siehe meine Seiten abgesehen von den Blindtexten), ist diese Ansicht nicht für die Praxis relevant.

Ich erhebe daher nicht den Anspruch darauf, dass diese utopische Forderung aufgegriffen wird, möchte jedoch darauf hinweisen, dass es keineswegs aus semantischer Sicht korrekt ist, Navigationsleisten mit Listen und/oder ausgerichteten Elementen (»CSS-Layout«) umzusetzen. Die Entscheidung, ob Tabellen oder eben diese Techniken eingesetzt werden, hat daher nicht anhand von semantischen Maßstäben zu erfolgen, sondern einzig und allein anhand des Benutzers, der Barrierefreiheit und der Browserunterstützung. Ich rate von der Benutzung von klassischen CSS-Layouts ab.

Dies ist eine Privatmeinung.

  1. Hallo,

    Ich rate von der Benutzung von klassischen CSS-Layouts ab.

    Zu was rätst du dann?

    Grüße
    Jeena Paradies

    --
    Alkoholverbot in der gesammten Bamberger Innenstadt!
    http://www.jeenaparadies.de/alkoholverbot/
    1. Hallo!

      Ich rate von der Benutzung von klassischen CSS-Layouts ab.
      Zu was rätst du dann?

      Wenn die Navigationsleiste erforderlich ist, empfehle ich, Layout-Tabellen einzusetzen.

      emu

      1. Seas emu,

        Ich rate von der Benutzung von klassischen CSS-Layouts ab.

        Zu was rätst du dann?

        Wenn die Navigationsleiste erforderlich ist, empfehle ich, Layout-Tabellen einzusetzen.

        ich frage mich, welchen Vorteil das bringt und vor allem wem. Wenn du Listen-Elemente für eine Anhäufung von Links als falsch empfindest, wie rechtfertigst du dann eine Tabelle? Oder ist einfach nur ohnehin schon alles wurscht?

        Grüße,
         Roland

      2. Hallo,

        Wenn die Navigationsleiste erforderlich ist, empfehle ich, Layout-Tabellen einzusetzen.

        Welche konkreten Vorteile bietet diese einer Liste?

        Grüße
        Jeena Paradies

        --
        Alkoholverbot in der gesammten Bamberger Innenstadt!
        http://www.jeenaparadies.de/alkoholverbot/
        1. Hallo,

          Welche konkreten Vorteile bietet diese einer Liste?

          gegenüber einer Liste?

          sollte es eigentlich heißen :-)

          Grüße
          Jeena Paradies

          --
          Alkoholverbot in der gesammten Bamberger Innenstadt!
          http://www.jeenaparadies.de/alkoholverbot/
  2. Hallo emu,

    [...]
    Dies ist eine Privatmeinung.

    hab' ich ja nochmal Schwein gehabt ;)

    Gruß, Andreas

    1. Hallo!

      Dies ist eine Privatmeinung.
      hab' ich ja nochmal Schwein gehabt ;)

      Weiter unten im Forum wird darum gestritten, inwiefern man betonen muss, dass es Gegenmeinungen gibt. Deswegen wollte ich klarstellen, dass es keinesfalls Konsens hier ist, die Dinge so zu sehen wie ich.

      emu

  3. Hi,

    Die Diskussionen, zuweilen Streitereien, ob man Navigationsleisten korrekterweise mit Framesets, Tabellen oder durch CSS positionierte (generische) Elemente umsetzen soll, führt in die Irre.

    nein, nur die Begrifflichkeit. "Navigationsleiste" ist nichts, was in HTML, CSS etc. existiert; es ist eine Interpretation des Menschen, genau wie z.B. "Footer". Daher ist es absurd anzunehmen, es gäbe in einer dieser Techniken ein Äquivalent des Begriffes. Es gibt nur das, was dann vom Menschen zur Navigationsleiste interpretiert wird - und zwar (i.d.R.) eine positionierte, ungeordnete Liste von Links.

    Für diese Begriffe gibt es in HTML, CSS etc. Äquivalente.

    Dies ist eine Privatmeinung.

    Dies ist meine fachliche Meinung.

    Cheatah

    --
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. Hallo!

      "Navigationsleiste" ist nichts, was in HTML, CSS etc. existiert;

      Natürlich nicht. Aber in der Realität des WWW existiert es an jeder Ecke.

      Listen von Links im Sinne eines Inhaltsverzeichnisses (also nicht auf jeder einzelnen Seite eines »Projekts«) sind selbstverständlich mit den Listen-Elementen, die HTML vorsieht, auszuzeichnen. Für die klassische Navigationsleiste, die projektintern gleichbleibt, sind Listen und CSS die richtige Art das Falsche zu machen und wiegen den Webautoren daher in einer Scheinsicherheit korrekter Semantik.

      emu

      1. Hi,

        "Navigationsleiste" ist nichts, was in HTML, CSS etc. existiert;
        Natürlich nicht. Aber in der Realität des WWW existiert es an jeder Ecke.

        klar, aber was soll das mit HTML, CSS & Co. zu tun haben?

        Listen von Links im Sinne eines Inhaltsverzeichnisses (also nicht auf jeder einzelnen Seite eines »Projekts«) sind selbstverständlich mit den Listen-Elementen, die HTML vorsieht, auszuzeichnen.

        Da sind wir uns einig :-)

        Für die klassische Navigationsleiste, die projektintern gleichbleibt, sind Listen und CSS die richtige Art das Falsche zu machen und wiegen den Webautoren daher in einer Scheinsicherheit korrekter Semantik.

        Sorry, aber das kann ich kein Stück nachvollziehen. Was ist falsch daran, das Richtige zu machen? Warum ist die Sicherheit nur Schein? Und wo soll es stören, richtig vorzugehen, anstatt auf Dinosauriern zu beharren?

        Cheatah

        --
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
      2. hi,

        Listen von Links im Sinne eines Inhaltsverzeichnisses (also nicht auf jeder einzelnen Seite eines »Projekts«) sind selbstverständlich mit den Listen-Elementen, die HTML vorsieht, auszuzeichnen. Für die klassische Navigationsleiste, die projektintern gleichbleibt, sind Listen und CSS die richtige Art das Falsche zu machen und wiegen den Webautoren daher in einer Scheinsicherheit korrekter Semantik.

        warum ist eine liste von links plötzlich keine liste mehr, nur weil sie auf jeder seite wiederholt wird?

        gruss,
        wahsaga

    2. "Navigationsleiste" ist nichts, was in HTML, CSS etc. existiert;

      Nein, es existiert aber als Strategie der hypertextuellen Vernetzung.

      es ist eine Interpretation des Menschen, genau wie z.B. "Footer".

      Auch Footer müssen sterben, die dort gelieferten Informationen sind meist Metadaten, dafür existieren meta und link, die entsprechende Umsetzung dieser Daten ist Aufgabe eines guten Hypertextleseprogramms. Selbst Abstracts und Zusammenfassungen müssen als willkürliche Bestandteile von body sterben. Ja, so ist es, und nicht anders.

      Daher ist es absurd anzunehmen, es gäbe in einer dieser Techniken ein Äquivalent des Begriffes. Es gibt nur das, was dann vom Menschen zur Navigationsleiste interpretiert wird - und zwar (i.d.R.) eine positionierte, ungeordnete Liste von Links.

      Es sind nicht irgendwelche Links, sie haben einen bestimmten logischen Charakter, da sie Dokumente mit zusammengehörigen Informationen oder einen Zusammenhang von mehreren Dokumenten, die insgesamt einem mehr oder weniger abgrenzbaren Hypertext angehören, mit jedem beliebigen Dokument der »Präsenz« verknüpfen.

      1. Hi,

        Auch Footer müssen sterben, die dort gelieferten Informationen sind meist Metadaten, dafür existieren meta und link,

        hm, jein. Erstens liegt eine gewisse Betonung auf dem Wort "meist", und zweitens gibt es unterschiedlichste Arten von Footern, für die dies mehr oder weniger gilt. Wie dem auch sei, es sollte nur ein Beispiel sein, kein Argument.

        Selbst Abstracts und Zusammenfassungen müssen als willkürliche Bestandteile von body sterben. Ja, so ist es, und nicht anders.

        Ich denke, darüber muss im Einzelfall noch mal geredet werden - nachdem der Begriff "Bestandteil" einer präzisen Definition unterzogen wurde ;-) Ist beispielsweise ein longdesc-Attribut bzw. die dahinter liegende Ressource ein Bestandteil?

        Es sind nicht irgendwelche Links, sie haben einen bestimmten logischen Charakter, da sie Dokumente mit zusammengehörigen Informationen oder einen Zusammenhang von mehreren Dokumenten, die insgesamt einem mehr oder weniger abgrenzbaren Hypertext angehören, mit jedem beliebigen Dokument der »Präsenz« verknüpfen.

        Genau das sehe ich anders: Der logische Charakter ist die angesprochene Interpretation des Menschen, und nichts, was von HTML etc. gehandhabt[1] werden muss (darf?). Die Links einer Navigation unterscheiden sich höchstens in ihrer wiederkehrenden Ähnlichkeit (bemerke: nicht Gleichheit) in anderen Ressourcen von anderen Links, die z.B. auch innerhalb eines Fließtextes mit den Links der Navigation identisch sein können - und je nach subjektiver Definition des Begriffes ebenfalls Navigation sind, oder es eben nicht sind.

        Ich kann allerdings verstehen, wenn Deine Ansicht durch die Überschneidungen typischer in Navigationen anzufindenden Links mit diversen <link>-Elementen geprägt ist. In dem Fall darf (IMHO) jedoch _nur_ jene Ansammlung der <link>-Elemente als Navigation bezeichnet werden, während die auf der Seite angesiedelten navigationsangeordneten Links schlicht und ergreifend eine ungeordnete Liste von Links sind, jedoch _keine_ Navigation. Redundant, ja, aber nicht unbedingt überflüssig.

        Cheatah

        [1] Damit ist explizit _nicht_ gemeint, eine entsprechende Struktur zu ermöglichen, wie z.B. ein <div id="navigation">.

        --
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
        1. Selbst Abstracts und Zusammenfassungen müssen als willkürliche Bestandteile von body sterben. Ja, so ist es, und nicht anders.

          Ich denke, darüber muss im Einzelfall noch mal geredet werden - nachdem der Begriff "Bestandteil" einer präzisen Definition unterzogen wurde ;-)

          Bei Abstracts ist es m.M.n. eindeutig. Von einer Hypertext-Auszeichnungssprache erwarte ich, dass solche Dokumentteile explizit in ihrer Funktion ausgezeichnet werden können, damit sie flexibel gemäß dieser Funktion verarbeitet werden können. Da HTML dies nicht bietet, ist höchstens description, tablesOfContents und abstract von Dublin Core angemessen, allerdings bekommen diese »Elemente« erst ihren Sinn, wenn sie Hypertext enthalten können, also direkt in (X)HTML einbettbar sind, der möglichst einem Kodierungsschema folgt. Aber bevor mir emu Reformismus vorwirft, muss ich sagen, dass ich nicht glaube, dass (X)HTML gerettet werden kann, indem Elemente aus dem Dublin-Core-Namespace verwendet werden, um Defizite auszugleichen.

          Ist beispielsweise ein longdesc-Attribut bzw. die dahinter liegende Ressource ein Bestandteil?

          Nein, wenn es eine eigenständige Ressource ist, ist es ein Extraknoten(*), der sich in der Hierarchie der Knoten verorten lässt. Es sollte eine bidirektionale Verbindung zwischen der Langbeschreibung und dem Kontext geben, in den das Bild eingebunden ist, und es existiert idealerweise nur diese Verbindung.

          (* Nun könnte man sich darüber streiten, ob nicht alles Adressierbare ein Knoten ist und longdesc="#langbeschreibung" als Verweis zu einer Art Fußnote mit einem »Zurück zum Bild«-Link bereits ebenfalls ein eigenständiger Knoten ist. Genauso sind eingebettete Ressourcen ebenfalls eigenständig, zumindest technisch, nicht »kohäsiv geschlossen«.)

          Es sind nicht irgendwelche Links, sie haben einen bestimmten logischen Charakter, da sie Dokumente mit zusammengehörigen Informationen oder einen Zusammenhang von mehreren Dokumenten, die insgesamt einem mehr oder weniger abgrenzbaren Hypertext angehören, mit jedem beliebigen Dokument der »Präsenz« verknüpfen.

          Genau das sehe ich anders: Der logische Charakter ist die angesprochene Interpretation des Menschen, und nichts, was von HTML etc. gehandhabt[1] werden muss (darf?).

          Die Sprache HTML erlaubt durch die Attribute rel und rev, den logischen Charakter eines Hyperlinks formal und maschinenlesbar im Markup unterzubringen und die Art der Beziehung von Dokumenten auzuzeichnen. Der logische Charakter entsteht dadurch, dass das referenzierte Dokument durch diese bedeutungsvollen Verweise in den Gesamthypertext einer Site eingeordnet wird. Hypertext ist in der Regel ohne diese Art von herausgearbeiteten Beziehungen nicht denkbar, insofern würde ich sagen, dass es eine Kernaufgabe von HTML ist, diese logischen Beziehungen auszuzeichnen.

          Die Links einer Navigationsliste beziehen sich immer auf ganz bestimmte Knoten mit einem bestimmten Platz und einer bestimmten Bedeutung in der Sitehierarchie, landläufig mit rel="chapter" ausgezeichnet, in der Sekundärnavigation dann mit rel="section" und Tertiärnavigation mit rel="subsection". Die Zugehörigkeit des aktuellen Dokuments lässt sich dann noch weiter durch sibling, up/parent/dc:isPartOf und anders herum mit child/dc:hasPart und so weiter auszeichnen.

          Die Links einer Navigation unterscheiden sich höchstens in ihrer wiederkehrenden Ähnlichkeit (bemerke: nicht Gleichheit) in anderen Ressourcen von anderen Links

          Die Links der Navigation haben eine bestimmte Funktion und eine bestimmte Bedeutung für das aktuelle Navigation, die andere Links im Dokument nicht haben.

          die z.B. auch innerhalb eines Fließtextes mit den Links der Navigation identisch sein können - und je nach subjektiver Definition des Begriffes ebenfalls Navigation sind, oder es eben nicht sind.

          Richtig, aber da ist ein gewaltiger Unterschied. In der Navigationsliste tauchen alle »Rubriken« der Seite auf, ganz gleich, ob sie im speziellen etwas mit dem Inhalt des jeweiligen Dokuments zu tun haben. Jedes Dokument der Site wird mit allen (zumindest Ober-)Rubriken der Site verknüpft. Dabei besteht nicht notwendigerweise ein direkter inhaltlicher Bezug. Die Rubriken können Themen behandeln bzw. Dokumente zu Themen gruppieren, die miteinander nichts zu tun haben, außer, dass sie einer Site angehören.
          Wenn sich jedoch Links im Fließtext zu bestimmten Rubriken befinden, dann besteht in der Regel ein inhaltlicher Bezug. Diese Links stellen keine vollständige Liste der Rubriken dar, und wenn, dann macht der Fließtext spezielle Aussagen über die verlinkten Rubriken, die die Primärrubriklinkliste so nicht macht.

          Ich kann allerdings verstehen, wenn Deine Ansicht durch die Überschneidungen typischer in Navigationen anzufindenden Links mit diversen <link>-Elementen geprägt ist.

          Die Navigationsformen im Web sind nicht mannigfaltig, die meisten Hypertextstrukturen im Web sind ähnlich aufgebaut und arbeiten mit ähnlichen Techniken des Navigierens. Insofern beziehe ich mich und bezog sich offenbar emu auf sogenannte Primär-/Sekundär-/Tertiärrubriknavigationen (»Menüs«, Listen der [Unter-]Verzeichnisse bzw. [Unter-]Ordner), wie ich sie im Thread mehrfach geschildert habe. Diese können in all diesen Fällen durch <link rel="chapter/section/subsection"> ersetzt werden bzw. in Unterdokumenten weggelassen werden zugunsten fisheye-views in Form von link-Elementen (Verweise in der Hierarchie nach oben <link rel="parent chapter/section/subsection" rev="child dc:isPartOf"> und nach unten <link rel="section/subsection child dc:hasPart" rev="parent chapter/section">).

  4. Tach auch,

    Die Diskussionen, zuweilen Streitereien, ob man Navigationsleisten korrekterweise mit Framesets, Tabellen oder durch CSS positionierte (generische) Elemente umsetzen soll, führt in die Irre.

    Tut sie? Oder koennte sie vielleicht zur Weiterentwicklung von HTML beitragen?

    Schon in der Vergangenheit habe ich darauf hingewiesen, dass das Konzept von HTML nicht vorsieht, solche Navigationsleisten einzusetzen, da die Navigation einerseits und hauptsächlich durch Hyperlinks im Text an dafür sinnvollen Stellen und andererseits, innerhalb der Menge von Seiten, die der Autor als zusammengehörig sieht (»Webpräsenz«), durch Links, die mittels <link> definiert sind, zu erfolgen hat.

    Nur ist in meinen Augen die Definition von <link> ziemlich unausgereift und undurchdacht. Verschiedene Unstimmigkeiten, unklare Definitionen usw, wie man ja an verschiedenen Diskussionen wofuer denn nun was benutzt werden sollte sehen kann. Je nachdem was Deine Definition von "Navigationsleiste" umfasst gibt es verschiedene Funktionen unter <link> nicht oder sie sind sehr schwammig beschrieben.

    Ebenso wirft sich fuer mich die Frage auf ob das Konzept von HTML so wie Du es darstellst noch der Wirklichkeit und der Entwicklung wie das Web heutzutage benutzt wird mitgehalten hat. Oder anders gesagt, ist das Konzept noch zeitgemaess?

    Der Ursprung waren wissenschaftliche Arbeiten, was sich ja ganz besonders am <link> Element sehr gut sehen laesst. Besteht das Web heutzutage vorwiegend aus wissenschaftlichen Arbeiten? Nein, weit entfernt davon.

    Da diese Möglichkeit durch die derzeitige Dominanz von Browsern, die diese Möglichkeit nicht oder nur unzureichend bieten, nur eingeschränkt möglich ist (in weiten Teilen des WWW allerdings sehr wohl, siehe meine Seiten abgesehen von den Blindtexten), ist diese Ansicht nicht für die Praxis relevant.

    Liegt das wirklich nur an den Browsern? Oder vielleicht auch an der schlechten Definition von <link>? Nicht zu vergessen der Weiterentwicklung des Webs?

    Dies ist eine Privatmeinung.

    Im Gegensatz zu was?
    Der Meinung

    • der Firma bei der Du arbeitest?
    • der Uni an der Du studierst?
    • des Mobs im SelfForum?
    • des W3C?

    Gruss,
    Armin

    --
    Location: Swindon/Wiltshire/England/UK/Europe/Northern Hemisphere/Planet Earth/Solar System/Milky Way Galaxy/Universe
    http://www.ministryofpropaganda.co.uk/
    1. Hallo!

      Nur ist in meinen Augen die Definition von <link> ziemlich unausgereift und undurchdacht.

      Ja. Insofern ist das Element auch nur beschränkt einsatzfähig, das ändert jedoch nichts an meiner Argumentation, dass es nämlich letztlich egal ist, ob man »Tabellen oder CSS« für den »Seitenaufbau« verwendet.

      Ebenso wirft sich fuer mich die Frage auf ob das Konzept von HTML so wie Du es darstellst noch der Wirklichkeit und der Entwicklung wie das Web heutzutage benutzt wird mitgehalten hat.

      Die Inhalte haben sich an das Medium zu halten, nicht das Medium an die Inhalte. Leider ist das Gegenteil derzeit der Fall.

      emu

      1. Tach auch,

        Die Inhalte haben sich an das Medium zu halten, nicht das Medium an die Inhalte. Leider ist das Gegenteil derzeit der Fall.

        Das sehe ich genau andersherum. Das Medium sollte sich weiterentwickeln und neuen Inhalten die Gelegenheit geben sich zu entfalten. Ansonsten bleibt nur Stagnation.

        Gruss,
        Armin

        --
        Location: Swindon/Wiltshire/England/UK/Europe/Northern Hemisphere/Planet Earth/Solar System/Milky Way Galaxy/Universe
        http://www.ministryofpropaganda.co.uk/
        1. Hallo.

          Ansonsten bleibt nur Stagnation.

          Ich muss dich beunruhigen: Stagnation bleibt in jedem Fall ;-)
          MfG, at

      2. Hallo,

        Die Inhalte haben sich an das Medium zu halten

        Es ist genau auch dieses Denken der eher technik und Theorielastigen Entwickler des freien Standards im Web das dazu führte, das das Medium "aneinandergeschlossene Computer die Tag und Nacht weltweit angeschaltet sind" in vielen Anwendungsfällen nur noch von kommerziell ausgerichteten Firmen weiterentwickelt wird. Die meisten Techniken neben(!) html wurden von Firmen als in sich gekapselte Lösungen entwickelt, wie eben das viel geschmäte Flash. Die freien Pendants dümpeln was die Comsumerfreundlichkeit angeht, weit hinterher. Man hat ja html und habe sich daran zu halten. Das ist nicht nur unsinnig der Entwicklung gegenüber sondern was die Qualitätsicherung von html-Seiten angeht auch geradezu kontraproduktiv. Html würde viel weniger schlecht eingesetzt, wenn es für die gewünschten Einsatzmöglichkeiten ebenfalls weit entwickelte freie Alternativtechniken gäbe.

        Wie gut das es einige Menschen gab, denen der Stummfilm nicht ausreichte und sich nicht sagten: "unsere Inhalte haben sich an das Medium zu halten."

        Chräcker

        1. Hallo Chräcker,

          Es ist genau auch dieses Denken der eher technik und Theorielastigen
          Entwickler des freien Standards im Web das dazu führte, das das Medium
          "aneinandergeschlossene Computer die Tag und Nacht weltweit angeschaltet
          sind" in vielen Anwendungsfällen nur noch von kommerziell ausgerichteten
          Firmen weiterentwickelt wird.

          Diese Behauptung halte ich in Teilen für unsinnig. Zum einen weil die
          Strukturen des Internet, wie wir es kennen, das WWW eingeschlossen, im
          Großteil von der wissenschaftlichen Gemeinde und von Privatpersonen
          entwickelt wurde, also das, was man am ehesten bei freien Standards
          assoziert. Aber auch die anderen Standards, die von Firmen entwickelt
          wurden und sich größtenteils durchgesetzt haben, sind als frei zu
          betrachten. Viele der vom W3C empfohlenen Standards haben ihren Ursprung
          in Firmen, schließlich ist das W3C (und andere internationale Gremien
          zur Standardisierung) ein Industriekonsortium. Der Gedanke dahinter
          scheint mir zu sein, daß ein größerer Markt entstehen kann, wenn die
          Spezifikation frei ist, die Produkte jedoch unterschiedlich sind und
          das dies unter dem Strich betrachtet mehr bringen kann als eine
          Insellösung. Wobei Microsoft als Quasi-Monopolist gesondert zu
          betrachten ist, gebe ich gerne zu.

          Größere Firmen leisten sich dafür Deine theorielastigen Entwickler.
          Weil diese stark theoretische Arbeit geleistet doch geleistet werden
          muß und die Forschungen an Universitäten eher in die andere Richtung
          gehen. Also macht es die Privatwirtschaft, entweder eigens dafür
          angestellte Leutchen in größeren Firmen oder nebenbei Entwickler in
          den kleineren. (Joel von Joel On Software hat diese Entwickler mal mit
          dem schönen Begriff "Architecture Astronauts" bezeichnet. Könntest Du
          glatt übernehmen, nicht? ;)

          Zum Beispiel: Javascript. Es wurde von Netscape entwickelt, von Microsoft
          in den Browserwars nach dem VBScript-Desaster als JScript kopiert. Dann
          hat Netscape die Basis als ECMAScript von der ECMA standardisieren lassen
          und so wie es aussieht basieren jetzt Javascript und JScript beide auf
          ECMAScript. Und Du lebst nicht schlecht damit, oder? ;-)

          (Jetzt besser überspringen)

          Zum (ausgedehnteren) Beispiel: Das unter Weblogautoren im Moment so
          beliebte XML-Format RSS.
          In der Mitte der 90er entwickelte ein Kerl namens Guha für Apple ein
          Format namens MCF. Dann wechselte er zu Netscape und sollte dort dieses
          Format weiterentwickeln, weil Microsoft mit dem CDF ein XML-Format auf
          dem Markt rollte. Nebenbei: XML ist ein freier Standard, der unter der
          Schirmherrschaft des W3Cs von Microsoft und Sun mitentwickelt wurde.
          Eine Verschmelzung von MCF und XML ging dann als Vorschlag an das W3C.
          Aus XML-MCF entwickelte sich unter Netscape dann RSS 0.9. Gleichzeitig
          entwickelte David Winer für seine eigene Firma Userland am Beispiel des
          Formates CDF sein ScriptingNews-Format. Dieses entwickelte er dann,
          immer noch für seine Firma zu RSS 0.91 und dessen Nachfolgern weiter.
          Gleichzeitig wurde RSS 0.9 von einer Working Group des W3C weiterentwickelt,
          im Kernteam von Leuten, die diversesten Firmen angehören (So zum Beispiel
          O'Reilly, um die bekannteste zu nennen), aber die Entwicklungsmailingliste
          war für jeden offen. Man wollte RSS 0.9 mit dem anscheinend an XML-MCF
          angelehnte Metadatenformat RDF (Unter der Schirmherschaft des W3Cs von
          eine Nokia-Angestellten entwickelt) darin einbringen und dies natürlich
          mit den später zur XML Spezifikation hinzugefügten Namespaces (Eine
          Spezifikation von HP und Microsoft Angestellten). So entstand RSS 1.0.
          Dave Winer von Userland, obwohl am Anfang mitwirkend war damit unzufrieden
          und veröffentlichte für seine Firma RSS 2.0, in dem der die Möglichkeit
          der Namespaces mit übernahm. Später stellte er diese Spezifikation wegen
          einiger öffentlicher Proteste (Es gibt viele politische Differenzen um RSS)
          unter die Schirmherrschaft der Rechtsfakultät der Universität Harvard.

          (Jetzt bitte wieder anfangen zu lesen)

          Was will ich mit dem ganzen Wust sagen? Freie oder besser offene Standards
          sind keine Domäne von irgendwelchen idealistischen Privatpersonen. Sie
          werden von Theoretikern angedacht und von etwas pragmatischeren Jungs in
          tatsächliche Standards umgesetzt. Und all diese sind von Firmen angestellt,
          die sich in Gremien zu Standardisierung, seien es institutionalisierte,
          seien es unformelle wie das Wiki zu Entwicklung vom RSS-Konkurrenten Atom
          engagieren. Es gibt einen langfristigeren Trend hin zu offeneren Standards,
          die Märkte für Produkte und Services entstehen lassen. Zähl mal alleine die
          Zahl der kommerziellen und nicht-kommerziellen Produkte, die RSS ausspucken
          und konsumieren können. Und oft schafft dies mehr als proprietäre
          Insellösungen.

          Die freien Pendants dümpeln was die Comsumerfreundlichkeit angeht, weit
          hinterher.

          Ich sehe ein Hinterherdümpeln in der Technologie- und Marktdurchsetzung.
          Aber in der Consumerfreundlichkeit?

          Man hat ja html und habe sich daran zu halten.

          Ich sehe niemanden, der eine Weiterentwicklung blockieren würde. (Das mit
          dem daran zu halten spare ich mal aus, angesichts der Erfahrungen aus den
          Browserkriegen der 90er dürfte das so langsam als Selbstverständlichkeit
          ins Bewußtsein einfließen. Schließlich sind es Standards) Aber wo siehst
          Du eine Blockadementalität gegen Weiterentwicklung?

          (..) wenn es für die gewünschten Einsatzmöglichkeiten ebenfalls weit
          entwickelte freie Alternativtechniken gäbe.

          Die gibt es. Sie haben es aber noch nicht wirklich als Implementierung
          wirklich in den Markt gebracht, einfach weil der Platz schon teilweise
          besetzt ist. Aber schau Dir mal an, was Thomas Meinike da für Dinge mit
          SVG macht. Guck Dir an, was mit PNG geschieht.

          Wie gut das es einige Menschen gab, denen der Stummfilm nicht ausreichte
          und sich nicht sagten: "unsere Inhalte haben sich an das Medium zu
          halten."

          Um nochmal zum Threadthema zurückzukehren: Ich glaube hier mißverstehst
          Du emu, auch wenn dieser sich recht kontrovers und missverständlich
          ausgedrückt hat. Wenn das Medium aus naheliegenden Gründen einem
          technischen Standard zu folgen hat, kann ein durch Inhalte bedingter
          Bruch dieses Standards im Gegensatz zu Brüchen in kompromissbereiteren
          Medien recht chaotische Züge an sich nehmen. Es hat seinen Grund,
          weswegen es einen Standard gibt.

          In Beispielen: Eine Buchseite verdaut es wunderbar, wenn statt des von
          Gutenberg inspirierten Einheitsdruck plötzlich ein Textkunstwerk von
          Jandl zu sehen ist. Ein Filmprojektor kriegt arge Schwierigkeiten, wenn
          der Regisseur plötzlich meint statt in 35mm Film in 47,8mm-Film filmen
          zu müssen. Nicht, daß keine standardisierte Weiterentwicklung in diesem
          Bereich existieren würde; es gibt entsprechendes in Industriekonsortien
          entwickeltes (HighDefinition, THX und wie es alles heißt). Aber auch das
          muß sich am Markt durchsetzen.

          emus Satz ist recht kontrovers zu sehen. Ich persönlich neige mich so
          langsam einer eher pragmatischen Sichweise zu, könnte aus der prinzipiellen
          Ecke aber nicht wirklich etwas dagegen sagen.

          Denn schließlich: In diesem Thread geht es nicht um den tatsächlichen
          Alltag, sondern um Utopien. Wir Architekturastronauten, wir.

          Tim

          --
          Meine persönlichen Utopien bräuchten zum Beispiel ein Grafikprogramm,
          recht viel Zeit und genauer ausformulierte Ideen zum umgestalten der
          Browsermetapher.
  5. Hallo,

    mir ist nicht klar worüber Du redest. Überspitzt formuliert (und bitte nur so überspitzt sehen) Redest Du von Navigationsstrukturen in Spielemenüs? Im Bedienmenü von Textverarbeitungen? Oder von "Besuchergesteurten" Filmpräsentationen?

    Ich weiß natürlich, und damit federe ich die Überspitzung wieder etwas ab, das Du natürlich Präsentationen innerhalb des Netzes meinst. Aber hier ist die Welt mindestens genauso vielfältig. Auch weiß ich, um "mich" weiter zurück zu nehmen, das Du das Themengebiet HTML angesprochen hast. Allerdings wird die Auszeichnungssprache nicht nur für reine semantisch korekt aufgebaute Hypertexte genutzt. Das hat auch etwas damit zu tun, das die Entwicklung "Projektgerechtere" Techniken und vor allem die Verbreitung entsprechender Zugangssoftware sich noch nicht so durchsetzen konnte. (was auch daran liegt, das die technikvorantreibende Fraktion eben tendenziell eher diesen alternativen Techniken skeptisch gegenüber stehen....)

    Man kann also aus der Nutzung der Auszeichnungsprache html nicht davon ausgehen, das nacher auch reine html-Seiten erwünscht oder gar zweckmässig sind. Solange es noch keinen Schraubenzieher gibt, nehmen eben nicht wenige die Rohrzange um die Schraube rein zu bekommen. Natürlich mit den gleichen negativen Nebenwirkungen.

    Deswegen kann ich solch paiuschale Aussagen, wie man "mit html" nun dies und das allein richtig zu tun hat nur sehr bedingt nachvollziehen.

    Dies ist eine Privatmeinung.

    Chräcker

    1. Hallo!

      mir ist nicht klar worüber Du redest.

      Ich rede von dem, was klassischerweise als Navigationsleiste bezeichnet wird, eine projektintern an einer bestimmten Stelle und mit einem bestimmten, von Seite zu Seiten entweder gar nicht oder nicht strukturell Inhalt. Das ist in der Regel eine Spalte links oder oben, manchmal beides.

      Der Sinn meines Postings war einzig und allein (und diese Aussage dürfte dir sehr entgegenkommen, ist es doch das, was du seit Jahr und Tag predigst): Es ist irrelevant, ob man Navigationsleisten mit Tabellen, Listen, CSS, Frames, Flash oder Erdnussbutter macht. Sie können semantisch nicht richtig sein.

      Wer argumentiert, Layout-Tabellen seien böse, weil unsemantisch, und daher durch klassische »CSS-Layouts« zu ersetzen, irrt. Meiner Meinung nach.

      emu

      1. hi,

        Es ist irrelevant, ob man Navigationsleisten mit Tabellen, Listen, CSS, Frames, Flash oder Erdnussbutter macht. Sie können semantisch nicht richtig sein.

        mir leuchtet immer noch nicht ein, warum für dich eine liste von links nicht auch semantisch eine liste ist.

        Wer argumentiert, Layout-Tabellen seien böse, weil unsemantisch, und daher durch klassische »CSS-Layouts« zu ersetzen, irrt. Meiner Meinung nach.

        meiner meinung nach nicht.

        wenn du die navigation einer seite in tabellenform aufbaust, ist das m.E. noch halbwegs korrekt. es handelt sich nun mal um daten gleicher art, nämlich links zu verschiedenen (unter-)seiten. (allerdings dürfte man dann streng genommen nur jeden link in eine einzelne <tr> packen, denn zwischen zwei links besteht ja von der datenart her kein derartiger unterschied, dass sie in zwei nebeneinander liegende <td> gehören würden.)

        das ändert doch aber nichts daran, dass es wenig sinnvoll ist, eine tabelle zum layouten zu verwenden, wenn man damit lediglich eine "korrekte" _positionierung_ von header/inhalt/footer/... erreichen will. zwischen _diesen_ elementen besteht nämlich kein zwingender logischer zusammenhang bzw. eine gleichartige datenstruktur.

        gruss,
        wahsaga

        1. Es ist irrelevant, ob man Navigationsleisten mit Tabellen, Listen, CSS, Frames, Flash oder Erdnussbutter macht. Sie können semantisch nicht richtig sein.

          mir leuchtet immer noch nicht ein, warum für dich eine liste von links nicht auch semantisch eine liste ist.

          Es geht nicht um Listen im Allgemeinen, es geht um Navigationslisten, ich würde sie Primär- und Sekundärnavigationen nennen, die die sogenannten Hauptrubriken bzw. thematisch geordneten Verzeichnisse (»Ordner«, wobei ich diese Symbolik im Grunde für lächerlich halte, aber wie auch immer) abbilden sowie site-zentrale Einrichtungen wie Glossar, Index, Suche, Kontakt, Hilfe, Sitemap, Impressum usw. zugänglich machen. All diese Verknüpfungen sind nicht assoziativ und haben keine konkrete Verbindung zum Inhalt, sondern umschreiben die Struktur des Hypertextes, also die umliegenden Knoten, in den das Dokument eingebunden ist. Sie sind nicht der Knoten an sich und sind nur begrenzt Kontextbildner (im Vergleich zu assoziativen Querverbindungen). All diese Verknüpfungen sind formalisiert mit maschinenlesbaren link-Elementen auszuzeichnen, die weitesgehend alle Navigationsschritte in Hierarchie und Sequenz abdecken.

          Aus einem anderen Posting von emu </archiv/2002/5/12885/#m71213>:
          »Das Konzept von HTML sieht doch ein Menü an sich gar nicht vor. Blättern, Glossar, Inhaltsverzeichnis, Anfänge von Kapitel und Projekt, Copyright und haufenweise mehr lässt sich durch Verwendung von <link> machen. Die Meta-Angaben weisen den Autor und noch einige wichtige andere Dinge aus. Von der einen Seite zur anderen sind im eigentlichen Dokument nur sinnhafte Links, die einen logischen Bezug zum Text haben [!], notwendig, denn der eigentliche Hypertext macht keinen Unterschied zwischen verschiedenen Projekten.«

      2. Hallo,

        ich habe ja nie was dagegen, wenn jemand meine unausgegorene und nicht selten über Ziel schiessende Bauchmeinung nacher mit Wissen hinterlegt, eine Praxiz, die ja hier nicht selten zu netten Schulterschlüssen führt ;-)

        Was ich wissen möchte war nur: wer sagt, das ein Navigationsbereich/Navigationsleiste oder wie auch immer semantisch nur "richtig", wenn sie in einer bestimmten Technik eingearbeitet wurde? Kann ich anhand der eingesetzten Technik ersehen, ob ein Menü in meinem neuen PC-Spiel nun semantisch richtig ist? (Auch wenn es ein Spiel ist, das ich per html übers Web auf die Browseroberfläche bringe....) Ist die zugrundegelegte Technik für das semantische Verständnis des Nutzers (hier Spieler) nur dann richtig, wenn es mit einer bestimmten Technik hinterlegt wurde? Wo ist nun der Unterschied eines Menüs in einem Spiel, in einem Grafikprogramm oder auf einer Webseite? Ich glaube zu wissen, wo der unterschied in Deinem  "Betrachtungsfall" ist (Du meinst wohl das, was ich immer gerne und nicht herablassend sondern eher würdigend als "reinrassige html-Seiten" nenne), aber dieser Unterschied wurde mir ein klitzeklein zu wenig herausgestellt. (oder ich habe es überlesen, kann natürlich gut sein)

        Chräcker

  6. Hallo,

    Ich erhebe daher nicht den Anspruch darauf, dass diese utopische Forderung aufgegriffen wird, möchte jedoch darauf hinweisen, dass es keineswegs aus semantischer Sicht korrekt ist, Navigationsleisten mit Listen und/oder ausgerichteten Elementen (»CSS-Layout«) umzusetzen.

    die Möglichkeit deine Vorstellung von HTML mit Anforderungen an Barrierefreiheit und Browserunterstützung alltagstauglich zu verbinden bietet allerdings besonders das Frameset.

    Ansonsten sind viele derartige Betrachtungen grundsätzlich fragwürdig weil meist weder beim Rezipienten noch beim Autor solche einseitige "semantische Sicht" einen Nutzen bringt.

    Auch der Ansatz einer klaren Trennung von Form und Inhalt oder selbst von GUI und angezeigter Seite ist als Hilfmittel zur Analyse zwar nützlich, aber deswegen nicht automatisch legitim oder richtig.

    Grüsse

    Cyx23

    1. die Möglichkeit deine Vorstellung von HTML mit Anforderungen an Barrierefreiheit und Browserunterstützung alltagstauglich zu verbinden bietet allerdings besonders das Frameset.

      Im Gegenteil, Framesets führen dazu, dass Verknüpfungen eines Dokuments mit den umliegenden Knoten der Sitehierarchie gar nicht mehr explizit ausgedrückt werden. Ein Verzeichnisdokument aka »Navigationsframe« ist wieder nichts anderes als eine Primär- und Sekundärnavigation, und dass sie vollkommen und ersatzlos ausgelagert wird, ist nur ein Nachteil und in der Regel so unsemantisch wie es nur geht.

      Wie wird bei einem Frameset kommuniziert, wie sich das Dokument in die umliegende Struktur einfügt? Etwa durch den Framekontext, ohne den alle Verbindungen des Dokuments zum Kontext der Sitehierarchie gekappt sind?

      Ansonsten sind viele derartige Betrachtungen grundsätzlich fragwürdig weil meist weder beim Rezipienten noch beim Autor solche einseitige "semantische Sicht" einen Nutzen bringt.

      Im Gegenteil, emu kritisiert die einseitige semantische Sicht, die sich mit den Fragen aufhält, ob Tabelle oder CSS angemessen sind, um eine Primärrubriknavigation in einer bestimmten Weise zum Hauptinhalt anzuordnen. emu ging es aber darum, dass diese Verzeichnisse nichts im Dokument verloren haben und alle Kontextverweise der Hierarchie (top-parent-*-child) und der Sequenz (first-prev-*-next-last) über link ausgezeichnet werden. Die richtige Markupstruktur, um ein klassisches »Menü« zu realisieren, wäre also höchstens <link rel="chapter href="1"><link rel="chapter" href="2"><link rel="chapter" href="2">...<link rel="chapter" href="n"> im rev="top"-Dokument.

      Auch der Ansatz einer klaren Trennung von Form und Inhalt oder selbst von GUI und angezeigter Seite ist als Hilfmittel zur Analyse zwar nützlich, aber deswegen nicht automatisch legitim oder richtig.

      Was ist die Trennung von GUI und angezeigter Seite?

      Es geht hier übrigens nicht um Alltagstauglichkeit, sondern darum, dass wirkliche Semantik in diesem Punkt nie erreicht werden kann, man also nie davon sprechen kann, dass das, was man landläufig als »Navigation« versteht, semantisch umgesetzt sein kann, weil diese Vorstellung per se unsemantisch ist. Das System ist Schuld.(tm)

      1. Hallo!

        Es geht hier übrigens nicht um Alltagstauglichkeit, sondern darum, dass wirkliche Semantik in diesem Punkt nie erreicht werden kann, man also nie davon sprechen kann, dass das, was man landläufig als »Navigation« versteht, semantisch umgesetzt sein kann, weil diese Vorstellung per se unsemantisch ist.

        Ja. Navigationsleisten sind semantisch ohnehin schon so falsch, dass es keinen Unterschied mehr macht, ob sie als Listen oder Tabellen in HTML gespeichert werden.

        emu

        1. Hallo.

          Ja. Navigationsleisten sind semantisch ohnehin schon so falsch, dass es keinen Unterschied mehr macht, ob sie als Listen oder Tabellen in HTML gespeichert werden.

          In einem eigenen <frame> könnten Navigationsleisten gleichbedeutend mit und auch visuell ähnlich einer Sitemap sein, deren semantischer Gehalt mir nicht fragwürdig scheint, wenn sie ein eine abgeschlossene Informationseinheit innerhalb eines einzelnen Dokumentes darstellt. Genau das ist bei Frames der Fall, was mich allerdings in keinster Weise dazu verleiten könnte, diese Technik zu verwenden. Mir genügt stattdessen eine inhaltliche Abschirmung mittels ID und eine visuelle Abtrennung als Ergänzung einer weitreichenden Hypertext-Struktur. So habe ich erst vor kurzem unter anderem die Straßenangaben auf Kontaktseiten und im Impressum mit Verweisen auf die Anfahrskizze versehen. Um aber der plötzlichen Eingebung eines Nutzers nicht entgegenzustehen, wenn er sich während des Lesens einer völlig anderen Seite fragt, wie er physisch zum Autoren gelangen könnte, biete ich ihm diese Möglichkeit natürlich auch weiterhin auf allen Seiten. Semantik entsteht nämlich erst beim Empfänger und was wir betreiben, ist eine bloße Prophezeihung oder Suggestion dessen Gedankengänge.
          MfG, at

          1. Ja. Navigationsleisten sind semantisch ohnehin schon so falsch, dass es keinen Unterschied mehr macht, ob sie als Listen oder Tabellen in HTML gespeichert werden.

            In einem eigenen <frame> könnten Navigationsleisten gleichbedeutend mit und auch visuell ähnlich einer Sitemap sein, deren semantischer Gehalt mir nicht fragwürdig scheint,

            Die im Sitemap-Frame gezeigten Links haben nicht notwendigerweise etwas mit dem Inhalt des Dokuments zu tun. Das ist wie gesagt derselbe Rückschritt gegenüber dem Anspruch, die direkten Zusammenhänge eines Dokuments mit anderen Knoten aus der Sicht des Einzeldokuments herauszuarbeiten.

            Um aber der plötzlichen Eingebung eines Nutzers nicht entgegenzustehen, wenn er sich während des Lesens einer völlig anderen Seite fragt, wie er physisch zum Autoren gelangen könnte, biete ich ihm diese Möglichkeit natürlich auch weiterhin auf allen Seiten.

            Wie ich bereits in [pref:t=67816&m=388377] beschrieben habe, sind Links auf solche site-zentralen Dokumente tatsächlich von jedem Knoten der Seite aus relevant, um schnelle Zugänglichkeit zu ermöglichen. Insofern würde es in das Konzept mit link passen, auch wenn mir gerade kein eindeutiger Relationstyp vorschwebt. Hier in Selfhtml wird in solchen Fällen rel="bookmark" verwendet, allerdings bedeutet das gemäß den Specs eigentlich etwas anderes (http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html#bookmark).

            Semantik entsteht nämlich erst beim Empfänger und was wir betreiben, ist eine bloße Prophezeihung oder Suggestion dessen Gedankengänge.

            Dann wäre es müßig, sich darüber zu streiten, ob diese oder jene Umsetzung semantisch ist oder nicht, wenn sowieso alles im Auge des Betrachters liegt und unendlich viele Sichtweisen als gleich wahr angenommen werden und der Autor alle berücksichtigen will.

            1. Hallo.

              Die im Sitemap-Frame gezeigten Links haben nicht notwendigerweise etwas mit dem Inhalt des Dokuments zu tun.

              Nein, sie stellen ja auch eine geschlosse Einheit dar, nämlich eine eigenständige Seite.

              Das ist wie gesagt derselbe Rückschritt gegenüber dem Anspruch, die direkten Zusammenhänge eines Dokuments mit anderen Knoten aus der Sicht des Einzeldokuments herauszuarbeiten.

              In diesem abgeschlossenen Dokument geht es aber ausschließlich um diese Knoten.

              Semantik entsteht nämlich erst beim Empfänger und was wir betreiben, ist eine bloße Prophezeihung oder Suggestion dessen Gedankengänge.

              Dann wäre es müßig, sich darüber zu streiten, ob diese oder jene Umsetzung semantisch ist oder nicht, wenn sowieso alles im Auge des Betrachters liegt und unendlich viele Sichtweisen als gleich wahr angenommen werden und der Autor alle berücksichtigen will.

              Der Autor kann lediglich Sichtweisen nahelegen oder suggerieren, da ihm die Auffassung der Inhalte nicht obliegt.
              MfG, at

              1. Hallo,

                Dann wäre es müßig, sich darüber zu streiten, ob diese oder jene Umsetzung semantisch ist oder nicht, wenn sowieso alles im Auge des Betrachters liegt und unendlich viele Sichtweisen als gleich wahr angenommen werden und der Autor alle berücksichtigen will.

                Der Autor kann lediglich Sichtweisen nahelegen oder suggerieren, da ihm die Auffassung der Inhalte nicht obliegt.

                der Autor wird oder kann seine Aussage anhand der Wirkung seiner Präsentation überprüfen, ggf. überprüfen lassen.
                Wenn sich natürlich Kultur und Sprache ändern wie etwa nach der Rechtschreibreform bedarf es erneuter Überprüfung und ggf. Übersetzung.
                Ähnlich könnte eine Änderung der Darstellung berücksichtigt werden, so die dichteren Pixel bei 17" TFTs, selbst wenn zunächst Sinnänderungen wenig plausibel scheinen.

                Grüsse

                Cyx23

                1. Hallo.

                  Der Autor kann lediglich Sichtweisen nahelegen oder suggerieren, da ihm die Auffassung der Inhalte nicht obliegt.

                  der Autor wird oder kann seine Aussage anhand der Wirkung seiner Präsentation überprüfen, ggf. überprüfen lassen.

                  Wenn ihm etwas an seiner Sichtweise liegt, wird er dies tun, ja.

                  Wenn sich natürlich Kultur und Sprache ändern wie etwa nach der Rechtschreibreform bedarf es erneuter Überprüfung und ggf. Übersetzung.

                  Im Prinzip hast du Recht, aber diese Veränderungen sind ja eher schleichender Natur. Außerdem kenne ich persönlich sie mehr in Bezug auf einzelne Begriffe (Paradebeispiel: "geil") als in Bezug auf die Struktur eines Dokumentes.

                  Ähnlich könnte eine Änderung der Darstellung berücksichtigt werden, so die dichteren Pixel bei 17" TFTs, selbst wenn zunächst Sinnänderungen wenig plausibel scheinen.

                  Die derzeitigen Mittel scheinen mir darauf nicht ausgelegt zu sein. Mit "em", "ex" oder "%" zu arbeiten ist sicher ein Anfang, aber das Skalieren von Bildern diesen Techniken und damit den Browsern zu überlassen, halte ich für derzeit wenig hilfreich. Jenseits deines Beispiels ist die Berücksichtigung sehr unterschiedlicher Medien aber sicher sinnvoll, etwa für Westentaschen-Computer, web-Taugliche Armbanduhren etc.
                  Das prinzipielle Problem wird also bleiben, dass sich der Autor mit seinen Inhalten, deren Wirkung, seiner Absicht und der der Präsentation zu Grunde liegenden Technik noch eingehender befassen muss -- gerade in Hinblick auf das semantische Web.
                  MfG, at

  7. Ich erhebe daher nicht den Anspruch darauf, dass diese utopische Forderung
    aufgegriffen wird, möchte jedoch darauf hinweisen, dass es keineswegs aus
    semantischer Sicht korrekt ist, Navigationsleisten mit Listen und/oder
    ausgerichteten Elementen (»CSS-Layout«) umzusetzen.

    Der derzeitige Mißbrauch von generellen Listen zu Navigationszwecken dürfte
    ein Übergangsverhalten zu dem Navigationslistenelement in XHTML 2 sein. Es
    scheint aber noch unklar zu sein, ob <nl> im Dokumentenkopf oder im
    Dokumentenkörper angesiedelt sein wird, noch, was es enthalten darf.
    http://www.w3.org/TR/xhtml2/mod-list.html#edef_list_nl

    Dies wurde mir von dem kleinen, grünen Männchen ins Ohr geflüstert, das
    links auf meiner rechten Schulter sitzt und hat nichts mit meinen
    privaten Utopien zu tun.

    --
    Neuer Trend unter molilys Jüngern: Sich nicht begrüßen oder verabschieden.
    Jetzt aufgreifen, ehe es zu spät ist! Siehe Flashmobs.
    1. Der derzeitige Mißbrauch von generellen Listen zu Navigationszwecken dürfte
      ein Übergangsverhalten zu dem Navigationslistenelement in XHTML 2 sein.

      Ein neuer Kompromiss, das braucht die Welt, besonders in einer Auszeichnungssprache, die ausdrücklich nicht mehr kompatibel zu vorhergehenden Versionen sein will. Hurra!

      --
      Semantik?
      Sehr lobenswert, ich bin auch dafür.
      1. Hallo,

        Ein neuer Kompromiss, das braucht die Welt, besonders in einer
        Auszeichnungssprache, die ausdrücklich nicht mehr kompatibel zu
        vorhergehenden Versionen sein will. Hurra!

        XHTML 2 leidet eindeutig darunter, daß es XHTML 2 ist. Allerdings: Die
        Kombination URI/HTTP dient ja nicht nur für HTML und ähnliches. Das
        HTTP-Modell funktioniert auch prima mit anderen Ansätzen, wenn man sich
        man die REST-Initiative ansieht. Interessant war für mich zu beobachten
        wie man sich im Atom-Wiki mit dem Syndication-Format und der API recht
        auf die ursprünglichen Gedanken zurückbesonnen hat, wohl auch ein Effekt
        der üblichen teilnehmenden puristischen Apologeten und Evangelisten. Ab
        und an sollte man sich tatsächlich erinnern, daß HTML nur eine ausgelieferte
        Erscheinungsart einer Ressource sein kann. Wobei ich den Grand Unified
        Browser in den nächsten zehn oder mehr Jahren nicht sehe, nicht mal eine
        eventuelle Unterstützung für RDF.

        Tim

        --
        Trotzdem wird Marc Andreesen bei der Revolution an die Wand gestellt.
  8. Hallo emu nochmal,

    (..) Menge von Seiten, die der Autor als zusammengehörig sieht (»Webpräsenz«)

    »Eigentlich« gibt es keine Webpräsenzen, es gibt nur Ressourcen.

    1. Hallo!

      (..) Menge von Seiten, die der Autor als zusammengehörig sieht (»Webpräsenz«)
      »Eigentlich« gibt es keine Webpräsenzen, es gibt nur Ressourcen.

      Da hast du recht, aber du ahnst ja nicht, wie oft ich diesen Teil umformuliert habe. Schließlich habe ich mich für Anführungszeichen, die noch von Klammern beschützt werden, entschieden und ausdrücklich darauf hingewiesen, dass [nur] der Autor die Seiten als zusammengehörig sieht. Das wäre ja schon wieder das nächste Problem, dass im WWW gerade von Extremisten in den dafür vorgesehenen Newsgroups Seiten, die nicht im entferntesten zusammen gehören, in ein einheitliches »Design« gezwängt werden, nur weil sie zufällig vom selben Autor stammen. Das ist ekelhaft, gegen den Hypertextgedanken, gegen technische und semantische Logik und im übrigen böse[tm].

      Das werde ich in der Newsgroup, die wir alle kennen, auch noch einmal schreiben, aber derzeit habe ich keinen Nerv auf Flamewars.

      emu

      --
      Tim lernt schnell. Bald wird er seinen Guru überrunden.
      Gut, dass es Wettbewerb unter den Molilysten gibt!
      1. Hallo emu,

        Das wäre ja schon wieder das nächste Problem, dass im WWW (..) Seiten, die
        nicht im entferntesten zusammen gehören, in ein einheitliches »Design«
        gezwängt werden, nur weil sie zufällig vom selben Autor stammen. Das ist
        ekelhaft, gegen den Hypertextgedanken, gegen technische und semantische
        Logik und im übrigen böse[tm].

        Es gibt immer noch das Konzept der Domäne, die einen einzelne Einheit
        im Web/Netz repräsentiert. Wäre eine mögliche Rechtfertigung. Eine
        andere ist natürlich die, daß mehr oder minder zentrale, möglichst
        geprüfte Stylesheets besser sind als ad hoc erstellte. Ausnahmen bestätigen
        irgendwelche Regeln.

        Das werde ich in der Newsgroup, die wir alle kennen, auch noch einmal
        schreiben, aber derzeit habe ich keinen Nerv auf Flamewars.

        Oh, sollte ich tatsächlich mal wieder Halimé anschmeißen müssen?

        Tim

        --
        Neues Jahr, neue Distinktionsbemühungen.
        1. Hallo,

          Das wäre ja schon wieder das nächste Problem, dass im WWW (..) Seiten, die
          nicht im entferntesten zusammen gehören, in ein einheitliches »Design«
          gezwängt werden, nur weil sie zufällig vom selben Autor stammen. Das ist
          ekelhaft, gegen den Hypertextgedanken, gegen technische und semantische
          Logik und im übrigen böse[tm].

          Es gibt immer noch das Konzept der Domäne, die einen einzelne Einheit
          im Web/Netz repräsentiert. Wäre eine mögliche Rechtfertigung. Eine
          andere ist natürlich die, daß mehr oder minder zentrale, möglichst
          geprüfte Stylesheets besser sind als ad hoc erstellte. Ausnahmen bestätigen
          irgendwelche Regeln.

          was meint hier "nicht im entferntesten zusammen gehören"?

          Oft ist es ja sowieso die Umsetzung einer Corporate Identity durch verschiedene Bereiche gewünscht, und bei CI geht es nicht nur um Marketing, CI kann den Kundenkontakt verbessern oder auch intern Vorteile haben. Hinsichtlich der Navigation ist ja Gleichförmigkeit i.d.R. auch vorteilhaft.

          "einheitliches »Design«" meint wohl einheitliches Layout als Designleistung, da ist die Frage ob Einheitlichkeit automatisch als (gutes) Design erkannt wird. Und der Nachteil eines einheitlichen »Design« wäre doch erstmal kaum fehlende semantische Logik; um welche konkreten Beispiele geht es überhaupt?

          Grüsse

          Cyx23

          1. Hallo Cyx,

            wolltest Du nicht eher auf emus Posting antworten? So scheint es mir
            jedenfalls. ;)

            Hinsichtlich der Navigation ist ja Gleichförmigkeit i.d.R. auch vorteilhaft.

            Das würde ich so unterschreiben.

            Und der Nachteil eines einheitlichen »Design« wäre doch erstmal kaum
            fehlende semantische Logik; um welche konkreten Beispiele geht es überhaupt?

            Ein bestehendes Design _kann_ eine Seite in ein Konzept einsperren und so
            eine andere Art von Auszeichnung erzwingen, die nicht unbedingt dem Inhalt
            der Seite angemessen ist. Aber hey: Um konkrete Beispiele zu fordern, bist
            Du hier im falschen Thread. ;-)

            Tim

            1. Hallo Tim,

              wolltest Du nicht eher auf emus Posting antworten? So scheint es mir
              jedenfalls. ;)

              nun, die Überlegungen zur CI beziehen sich schon auf dein "Wäre eine mögliche Rechtfertigung."

              Ein bestehendes Design _kann_ eine Seite in ein Konzept einsperren und so
              eine andere Art von Auszeichnung erzwingen, die nicht unbedingt dem Inhalt

              Das Problem ist mir klar, aber da überschneiden sich m.E. sowieso Unzulänglichkeiten (Browser, HTML, CSS) mit der Frage der semantischen Bedeutung von Layout.
              Dazu kann das Problem nicht nur als Problem der betr. Seiten oder deren einheitlicher Behandlung verstanden werden, sondern auch als vielleicht korrigierbarer Fehler des jeweiligen für alle Seiten angewandten Konzepts.
              Und die Feststellung dass Seiten nicht "in ein einheitliches »Design« gezwängt werden" könnnen liesse sich eigentlich fast immer treffen, schon bei einer üblichen 'Homepage' mit Startseite und Impressum.

              der Seite angemessen ist. Aber hey: Um konkrete Beispiele zu fordern, bist
              Du hier im falschen Thread. ;-)

              Da das Thema doch nicht rein abstrakt ist, steht einer Konkretisierung doch nicht so viel im Wege ?-)

              Und für das Ausgangsposting des Thread bleibe ich bei dem konkreten Vorschlag sich Frames oder ggf. Iframes zu bedienen, um Interfrenzen zu vermeiden. Wär doch was nach dem XML-Hype Frames zu entdecken!

              Grüsse

              Cyx23

              1. Hallo.

                Und die Feststellung dass Seiten nicht "in ein einheitliches »Design« gezwängt werden" könnnen liesse sich eigentlich fast immer treffen, schon bei einer üblichen 'Homepage' mit Startseite und Impressum.

                Das "fast" bezeichnet dann wahrscheinlich alle Ausnahmen durch _gutes_ Design, welches solche Umstände ja berücksichtigt ;-)
                MfG, at

                1. Hallo,

                  Und die Feststellung dass Seiten nicht "in ein einheitliches »Design« gezwängt werden" könnnen liesse sich eigentlich fast immer treffen, schon bei einer üblichen 'Homepage' mit Startseite und Impressum.

                  Das "fast" bezeichnet dann wahrscheinlich alle Ausnahmen durch _gutes_ Design, welches solche Umstände ja berücksichtigt ;-)

                  wenn dann mit dem guten Design auch semantische Anforderungen beim HTML-Code verbunden sind, kann ja der übliche Navigationsblock wie schon im Thread geschehen betrachtet werden, aber es gibt ja auch Sonderfälle wie "Impressum".

                  Bei einer auch üblichen separaten Anordnung der Links "Home" und "Impressum" bietet es sich m.E. an beide in ein address-Tag zu setzen. Wäre es nun sinnvoll in einem Link-Block, z.B. als Liste, auch <adress> zu verwenden, und für wen abgesehen vom Autor macht sich solch eine Auszeichnung derzeit irgendwie bemerkbar?

                  Grüsse

                  Cyx23

                  1. Hallo.

                    wenn dann mit dem guten Design auch semantische Anforderungen beim HTML-Code verbunden sind, kann ja der übliche Navigationsblock wie schon im Thread geschehen betrachtet werden, aber es gibt ja auch Sonderfälle wie "Impressum".

                    Das halte ich -- wie bereits erwähnt -- für zu kurz gegriffen, denn meine Gedankensprünge beim Betrachten einer Präsentation kann der Autor niemals zuverlässig vorhersagen, weswegen ich als Autor dem Nutzer prinzipiell den Umweg über etwa "Home" erspare. Stattdessen biete ich ihm eine möglichst vollständige Navigation innerhalb der Seite -- im Sinne des Hypertextes wäre hier eine Sitemap im <frame> angebracht, was ich aber ablehne --, um die meisten Anflüge von spontaner Wissbegier, Neugier etc. in die richtigen Kanäle zu leiten.

                    Bei einer auch üblichen separaten Anordnung der Links "Home" und "Impressum" bietet es sich m.E. an beide in ein address-Tag zu setzen. Wäre es nun sinnvoll in einem Link-Block, z.B. als Liste, auch <adress> zu verwenden, und für wen abgesehen vom Autor macht sich solch eine Auszeichnung derzeit irgendwie bemerkbar?

                    Inwieweit sich etwas bemerkbar macht, obliegt nicht HTML, sondern CSS, weswegen meine Antwort lautet: Natürlich macht es sich bemerkbar, wenn ich das will. Ich halte allerdings <a href...> für hinreichend kennzeichnend für eine URL. Hinzu kommt, dass ich <address> für Adressen verwende, die nicht mittels <a href...> erreichbar sind, und so zumindest eine Unterscheidbarkeit gewährleiste. Das einzige gemeinsame Auftreten von <address> und <a href...> sind bei mir Hausanschriften (<address>) mit einem integrierten Verweis (<a href...>) auf die Anfahrtskizze. Ein Klick beamt mich also nicht zur physischen Adresse, sondern zu einer weiteren HTTP-Ressource.
                    MfG, at

                    1. Hallo,

                      Inwieweit sich etwas bemerkbar macht, obliegt nicht HTML, sondern CSS,

                      ich dachte da eher an ein "semantic web", welches sich bislang wohl nur als Screenreader oder Google manifestiert.
                      Das Impressum ist m.E. ein gutes Beispiel für die Interferenz verschiedener Hierarchien, u.U. auch "Home".
                      Der adress-Tag bietet womöglich eine semantische Zuordnung von Impressum oder Kontakt-e-mail, hat allerdings vmtl. nur begrenzt die Möglichkeit eingebundene Links als weniger zum eigentlichen Inhalt gehörig zu charakterisieren.

                      Grüsse,

                      Cyx23

                      1. Hallo.

                        ich dachte da eher an ein "semantic web", welches sich bislang wohl nur als Screenreader oder Google manifestiert.

                        _Screen_reader? _News_reader und Programme wie http://www.apple.com/macosx/features/sherlock/ sind für mich Inbegriffe des semantischen Web -- aber vielleicht irre ich mich da auch.

                        Das Impressum ist m.E. ein gutes Beispiel für die Interferenz verschiedener Hierarchien, u.U. auch "Home".
                        Der adress-Tag bietet womöglich eine semantische Zuordnung von Impressum oder Kontakt-e-mail, hat allerdings vmtl. nur begrenzt die Möglichkeit eingebundene Links als weniger zum eigentlichen Inhalt gehörig zu charakterisieren.

                        Das <address>-Tag ist mir zu allgemein spezifiziert, als dass ich mir vorstellen könnte, mich in Bezug auf wichtige Dinge wie eine Kontakt-eMail-Adresse oder ein Impressum darauf zu verlassen. Aber im Zusammenhang mit dem semantischen Web messe ich den Meta-Angaben auch wieder eine größere Bedeutung bei, so dass wieder ganz andere Möglichkeiten zur Verfügung stehen.
                        MfG, at

                        1. Hallo,

                          ich dachte da eher an ein "semantic web", welches sich bislang wohl nur als Screenreader oder Google manifestiert.

                          _Screen_reader? _News_reader und Programme wie http://www.apple.com/macosx/features/sherlock/ sind für mich Inbegriffe des semantischen Web -- aber vielleicht irre ich mich da auch.

                          den Ansatz formulierte Berners-Lee als Ziel "Machine-Understandable information: Semantic Web" und "not only for human-human communication, but also that machines would be able to participate and help.".
                          Dann bemängelte er "that the structure of the data is not evident to a robot browsing the web" und führt aus dass es ihm nicht um bessere "artificial intelligence" sondern um  " languages for expressing information in a machine processable form" geht.

                          Auf die konkrete Situation und auf kurzfristige Ziele bezogen komme ich zuerst auf Screenreader oder Google wenn ich mal proprietäre Ansätze und Werbeideen weniger berücksichtige; der von dir genannte Sherlock ist allerdings interessant, Newsreader scheinen mir eher ein Sonderfall zu sein.

                          Aber im Zusammenhang mit dem semantischen Web messe ich den Meta-Angaben auch wieder eine größere Bedeutung bei, so dass wieder ganz andere Möglichkeiten zur Verfügung stehen.

                          Das war ja auch meine Frage bzw. d. Ausgangsproblem, dass Google als z.Zt. grösster potentieller Nutzniesser eines "semantic web" Meta-Angaben kaum nutzt, beim adress-Tag mag es ähnlich sein.
                          Immer noch soll ein Impressum-Link womöglich ohne Scrollen erreichbar sein, eine naheliegende Angabe im Head, Quelltext oder Link-tag sind auch hier zumindest hinsichtlich der Impressumspflicht nutzlos.
                          Und die eigentliche Bedeutung oder auch mal Unwichtigkeit des bzw. dieses Impressums ist wieder eine andere Geschichte.

                          Grüsse

                          Cyx23

                          1. Hallo Cyx,

                            Auf die konkrete Situation und auf kurzfristige Ziele bezogen komme ich
                            zuerst auf Screenreader (..)

                            Was immer noch nicht erklärt, was Screenreader (als Synonym für Audiobrowser?)
                            mehr mit dem semantischen Web zu tun haben als die gewöhnten grafischen
                            Browser. Erklärst Du das nochmal, bitte?

                            Tim

                            1. Hallo Tim,

                              Auf die konkrete Situation und auf kurzfristige Ziele bezogen komme ich
                              zuerst auf Screenreader (..)

                              Was immer noch nicht erklärt, was Screenreader (als Synonym für Audiobrowser?)
                              mehr mit dem semantischen Web zu tun haben als die gewöhnten grafischen
                              Browser. Erklärst Du das nochmal, bitte?

                              wenn ich entspr. den vorher genannten Zitaten weniger auf die Ablage von Datensätzen abziele, sondern die Kommunikation und die erwähnten teilhabenden und helfenden Maschinen betrachte, ist es doch naheliegend, so fehlt ja dem Screenreader genau der beim grafischen Browser durch Layout und CSS vorhandene Kontext, an spezielle Anforderungen wie lang-Attribute hatte ich weniger gedacht, aber die Forderung "Machine-Understandable information" per (HTM-)Sprache könnte sogar das abdecken.

                              Grüsse

                              Cyx23

                              1. Hallo Cax,

                                (..) so fehlt ja dem Screenreader genau der beim grafischen Browser durch
                                Layout und CSS vorhandene Kontext, an spezielle Anforderungen wie
                                lang-Attribute hatte ich weniger gedacht, aber die Forderung
                                "Machine-Understandable information" per (HTM-)Sprache könnte sogar das
                                abdecken.

                                Mhh. Das würde ich höchstens als Semantisches Web auf niedrigstem Niveau
                                durchgehen lassen. Schließlich ist die »machine-understandable information«,
                                die durch HTML abgedeckt wird noch auf sehr niedrigem Niveau, mehr kann
                                ein derzeitiger Screenreader nicht zu Verfügung haben.

                                Aber interessant, daß Du dem durch ein CSS-Layout gegebenen Kontext ein
                                soviel mehr an Information zugestehst. Hast Du dafür ein konkretes Beispiel,
                                an dem ich diese Vermutung nachvollziehen könnte? Ich meine hier konkret
                                eine HTML-Seite, in der die Variante der Darstellung mit Layout gegenüber
                                der Darstellung ohne Layout einen wirklichen informationellen Mehrwert hat.
                                Ich meine nicht Seiten, in denen der Autor sich nicht wirklich um angemessene
                                Auszeichnung bemüht hat bzw. sich nur auf Grafiken verlässt. Das ist dann
                                doch ein Unterschied, meine ich.

                                Mir würde da höchstens molilys Schachtelmodell einer HTML Dokumentenstruktur
                                auf dieser Seite einfallen: http://molily.de/dokumentmodelle.
                                (Runterscrollen bis Schachtelmodell, es gibt leider keine Anker.)

                                molily hat die Verschachtelung zwar als verschachtelte Liste ausgezeichnet,
                                die grafische Variante als Kästchen in Kästchen gibt jedoch ein kleines
                                bischen mehr an Information, meine ich. Hast Du vielleicht etwas adäquates?

                                Tim

                                1. Hallo,

                                  Aber interessant, daß Du dem durch ein CSS-Layout gegebenen Kontext ein
                                  soviel mehr an Information zugestehst. Hast Du dafür ein konkretes Beispiel,
                                  an dem ich diese Vermutung nachvollziehen könnte? Ich meine hier konkret
                                  eine HTML-Seite, in der die Variante der Darstellung mit Layout gegenüber
                                  der Darstellung ohne Layout einen wirklichen informationellen Mehrwert hat.
                                  Ich meine nicht Seiten, in denen der Autor sich nicht wirklich um angemessene
                                  Auszeichnung bemüht hat bzw. sich nur auf Grafiken verlässt. Das ist dann
                                  doch ein Unterschied, meine ich.

                                  nicht unbedingt. Wenn ein Autor die Unzulänglichkeiten und Begrenzheit
                                  des Sprachumfangs, also auch den Punkt ab welchem Layout noch bedeutsamer
                                  wird, besonders berücksichtigt und die Seite z.B. barrierefrei nachrüstet
                                  bestätigt das ja den Informationscharakter von Layout.
                                  Die möglichen Vorteile eines stimmigen reduzierten und vielleicht auch textbasierten
                                  Layouts änderen daran nichts und sind eben keine Bestätigung dafür den verfügbaren
                                  Leistungsumfang und Wortschatz immer weiter zu reduzieren.

                                  Einfache Beispiele sind farbliche Differenzierungen, oder das Beispiel
                                  (rechtliches) Impressum und seine oft fehlende inhaltliche Bedeutung trotz
                                  prominenter Platzierung (oft ausserhalb d. Navigation, z.B. oben rechts).

                                  molily hat die Verschachtelung zwar als verschachtelte Liste ausgezeichnet,
                                  die grafische Variante als Kästchen in Kästchen gibt jedoch ein kleines
                                  bischen mehr an Information, meine ich. Hast Du vielleicht etwas adäquates?

                                  Ich bring da mal einige -wenn die betr. Seite barrierefrei sein soll teilweise
                                  unpassende- Punkte an da molily vmtl. mitliest und es zum Thema passt.
                                  Bei den Schachteln wären farbige Rahmen statt der grauen Hintergründe möglich,
                                  und die Beispiele mit den Tags wären durch Farbe u.U. übersichtlicher.
                                  In der Tabelle "Syntaxbestandteile und deren Bezeichnungen" ist dann
                                  doch mal Farbe, aber da hätte es <strong> alleine m.E. besser getan, auch wenn
                                  ich die Farbe grundätzlich als wohltuend empfand.

                                  Gleichzeitig könnte die Farbe beim Schachtelmodell natürlich weitere Bedeutungen
                                  oder Schwerpunkte entstehen lassen, so wäre eine Hervorhebung der Elemente im
                                  Body interessant um den Bezug zur dargestellten Seite zu verdeutlichen, ansatzweise
                                  geschieht das bereits durch die heller werdenden Grautöne.
                                  Wäre solch eine Variante nun angemessen auszuzeichnen?
                                  Kann ich die durch eine bestimmte Farbe etwa verringerte Bedeutung eines
                                  Links angemessen auszuzeichnen?
                                  Lässt sich der bei üblichen grösser/gleich 1024er Auflösungen entstehende
                                  Abstand bzw. Leerraum zwichen zwei oben rechts und links
                                  in einer Zeile platzierten Links, die sogar inhaltlich zusammengehören
                                  und etwa in <adress> stehen könnten, angemessen auszeichnen?

                                  Grüsse

                                  Cyx23

                                  1. Hallo.

                                    nicht unbedingt. Wenn ein Autor die Unzulänglichkeiten und Begrenzheit
                                    des Sprachumfangs, also auch den Punkt ab welchem Layout noch bedeutsamer
                                    wird, besonders berücksichtigt und die Seite z.B. barrierefrei nachrüstet
                                    bestätigt das ja den Informationscharakter von Layout.
                                    Die möglichen Vorteile eines stimmigen reduzierten und vielleicht auch textbasierten
                                    Layouts änderen daran nichts und sind eben keine Bestätigung dafür den verfügbaren
                                    Leistungsumfang und Wortschatz immer weiter zu reduzieren.

                                    Ich wollte gerade protestieren und auf bereits geführte Diskussionen zu diesem Thema hinweisen, ...

                                    Einfache Beispiele sind farbliche Differenzierungen, oder das Beispiel
                                    (rechtliches) Impressum und seine oft fehlende inhaltliche Bedeutung trotz
                                    prominenter Platzierung (oft ausserhalb d. Navigation, z.B. oben rechts).

                                    ... als du mich daran erinnert hast, wie weit du den Begriff "Layout" fasst :-)
                                    MfG, at

                                  2. Ich bring da mal einige -wenn die betr. Seite barrierefrei sein soll teilweise unpassende- Punkte an da molily vmtl. mitliest und es zum Thema passt.

                                    Nein, ich lese nicht mit. Aber es gibt ja Referrer. Also demnächst eher als E-Mail schicken, wenn die Kommentare ankommen sollen.

                                    Bei den Schachteln wären farbige Rahmen statt der grauen Hintergründe möglich,

                                    Ich wüsste nicht, wie (unterschiedlich) farbige Rahmen (was heißt das? etwa auf erster Ebene rot, darin blau, darin grün?) das ausdrücken können, was ich mit Hintergründen mit verschiedenen Grautönen ausdrücken möchte, nämlich die Abstufung der Hierarchie.

                                    und die Beispiele mit den Tags wären durch Farbe u.U. übersichtlicher.

                                    Wenn du auf das Codebeispiel im Abschnitt »Einrückungen im gekürzten Markup« anspielst, so ist es durchaus bewusst, dass der Code dort nicht weiter hervorgehoben ist und die Knotentypen bzw. syntaktischen Bestanteile nicht weiter unterschieden werden sollen. Es ging mir ja nur darum, diese eine Möglichkeit der Visualisierung zu beschreiben, was du anscheinend meinst, wäre bereits eine Kombination aus Syntax-Highlighting und Hierarchieverdeutlichung.

                                    In der Tabelle "Syntaxbestandteile und deren Bezeichnungen" ist dann doch mal Farbe, aber da hätte es <strong> alleine m.E. besser getan, auch wenn ich die Farbe grundätzlich als wohltuend empfand.

                                    Alleine durch die strong-Hervorhebung war in meinen Tests nicht so gut erkennbar, welcher Codeteil gemeint war. Das gilt auch jetzt noch, Netscape 4 wendet die Farben nämlich nicht an. Außerdem wollte ich an die Farbgebung des Diagramms darüber anknüpfen (vielleicht siehst du nur den Alternativinhalt... muss ich mal anders umsetzen, momentan zeigt bspw. MSIE gar nichts an).

                                    Gleichzeitig könnte die Farbe beim Schachtelmodell natürlich weitere Bedeutungen oder Schwerpunkte entstehen lassen,

                                    Inwiefern?

                                    so wäre eine Hervorhebung der Elemente im Body interessant um den Bezug zur dargestellten Seite zu verdeutlichen, ansatzweise geschieht das bereits durch die heller werdenden Grautöne.

                                    Das verstehe ich nicht. »Der Bezug zur dargestellten Seite« ist bei dieser Analyse im Prinzip unwichtig, was brächte es im Kontext meiner Überlegungen, den body-Elemente im Gegensatz zu head-Elementen hervorzuheben, weil die Elemente darin für gewöhnlich sichtbare Boxen erzeugen? Es geht um die Untersuchung der Elementhierarchie, also um die Frage der richtigen Einordnung von Informationen (passt dieses und jenes Element in die Schachtel/Kategorie XYZ, welche Gemeinsamkeiten hat es mit den anderen Elementen in der Schachtel, ergibt die Sequenz Sinn, ...). Das gilt nicht nur oder im speziellen für die Elemente im body. In diesem Thread kam z.B. die Frage auf, ob so etwas wie eine sogenannte Primärnavigation wirklich in den Körper gehört oder ob es sich bei rel="chapter"-Links eher um »Kopfdaten« und Meta-Verknüpfungen handelt, die eher in die Kiste head gehören. Das Verfahren, auf das ich hinaus will, sollte auch darauf eine Antwort geben können (von praktischen Umständen einmal abgesehen - die Methode hat ja auch bewusst einen begrenzten Anwendungsbereich und soll auch nicht alleinig seelig machen).

                                    Wäre solch eine Variante nun angemessen auszuzeichnen?
                                    Kann ich die durch eine bestimmte Farbe etwa verringerte Bedeutung eines
                                    Links angemessen auszuzeichnen?
                                    Lässt sich der bei üblichen grösser/gleich 1024er Auflösungen entstehende
                                    Abstand bzw. Leerraum zwichen zwei oben rechts und links
                                    in einer Zeile platzierten Links, die sogar inhaltlich zusammengehören
                                    und etwa in <adress> stehen könnten, angemessen auszeichnen?

                                    Ähm - wie bitte?

                                    1. Bei den Schachteln wären farbige Rahmen statt der grauen Hintergründe möglich,

                                      Ich wüsste nicht, wie (unterschiedlich) farbige Rahmen (was heißt das? etwa auf erster Ebene rot, darin blau, darin grün?) das ausdrücken können, was ich mit Hintergründen mit verschiedenen Grautönen ausdrücken möchte, nämlich die Abstufung der Hierarchie.

                                      auch wenn ich die genannten Punkte begründen kann sollte mein Posting keine ausgefeilte Kritik mit besseren Lösungen sein, aber mal schauen.
                                      Die Hierarchien so per Graustufen darzustellen wäre mir nicht so wichtig da ich die räumliche Aussage der Rahmen oder den Schachtelcharakter wichtiger oder ohne Graustufen vielleicht deutlicher fände.

                                      und die Beispiele mit den Tags wären durch Farbe u.U. übersichtlicher.

                                      Wenn du auf das Codebeispiel im Abschnitt »Einrückungen im gekürzten Markup« anspielst, so ist es durchaus bewusst, dass der Code dort nicht weiter hervorgehoben ist und die Knotentypen bzw. syntaktischen Bestanteile nicht weiter unterschieden werden sollen. Es ging mir ja nur darum, diese eine Möglichkeit der Visualisierung zu beschreiben, was du anscheinend meinst, wäre bereits eine Kombination aus Syntax-Highlighting und Hierarchieverdeutlichung.

                                      Die Probleme und Interferenzen möglicher Interpretationen und Bedeutungen könnten natürlich durch das Wissen um Syntax-Highlighting noch grösser werden, aber ich meinte besonders eine angenehmere schnellere Erfassung, wenn natürlich solch ein Komfort -sofern er wirklich möglich ist- die Aussage verändert wird es schwierig.

                                      Das verstehe ich nicht. »Der Bezug zur dargestellten Seite« ist bei dieser Analyse im Prinzip unwichtig, was brächte es im Kontext meiner Überlegungen, den body-Elemente im Gegensatz zu head-Elementen hervorzuheben, weil die Elemente darin für gewöhnlich sichtbare Boxen erzeugen? Es geht um die Untersuchung der Elementhierarchie, also um die Frage der richtigen Einordnung von Informationen (passt dieses und jenes Element in die Schachtel/Kategorie XYZ, welche Gemeinsamkeiten hat es mit den anderen Elementen in der Schachtel, ergibt die Sequenz Sinn, ...). Das gilt nicht nur oder im speziellen für die Elemente im body. In diesem Thread kam z.B. die Frage auf, ob so etwas wie eine sogenannte Primärnavigation wirklich in den Körper gehört oder ob es sich bei rel="chapter"-Links eher um »Kopfdaten« und Meta-Verknüpfungen handelt, die eher in die Kiste head gehören. Das Verfahren, auf das ich hinaus will, sollte auch darauf eine Antwort geben können (von praktischen Umständen einmal abgesehen - die Methode hat ja auch bewusst einen begrenzten Anwendungsbereich und soll auch nicht alleinig seelig machen).

                                      Es ist vielleicht auch besser in einer Darstellung nicht zuviele Themen zu vermengen , aber »Der Bezug zur dargestellten Seite« bzw. eine Abgrenzung des Body könnte vielleicht die Anschaulichkeit etwas verbessern, und eine farbliche Gruppierung Body vs Head würde m.E. einfach die Wahrnehmung vereinfachen, ich hab es allerdings nicht getestet.

                                      Wäre solch eine Variante nun angemessen auszuzeichnen?
                                      Kann ich die durch eine bestimmte Farbe etwa verringerte Bedeutung eines
                                      Links angemessen auszuzeichnen?
                                      Lässt sich der bei üblichen grösser/gleich 1024er Auflösungen entstehende
                                      Abstand bzw. Leerraum zwichen zwei oben rechts und links
                                      in einer Zeile platzierten Links, die sogar inhaltlich zusammengehören
                                      und etwa in <adress> stehen könnten, angemessen auszeichnen?

                                      Ähm - wie bitte?

                                      Meine angenommene Beispielseite sieht ganz oben so aus ([link]):

                                      [www.muster.de]/[beispiel]/diesedatei.html               [impressum]

                                      also schamtisch auch so
                                      [w..e]/[b..l]/di..i.html  -  L   E   E   R   R   A   U   M  - [i..m]

                                      und wenn das Impressum inhaltlich weniger wichtig ist, erhält der betr. a-tag [impressum] z.B. ein color:silver.

                                      Wie würde nun diese Farbgebung bzw. die etwas geringer Auffälligkeit und Wichtigkeit für ein "sematic web" dargestellt werden, wie der beabsichtigte und bei den meisten üblichen Auflösungen vorhandene Leerraum, der vielleicht mit <div><span><a...></span><span><a..>impressum</a></span></div> nicht deutlich wird, aber natürlich kein eigenes Element erhalten soll.

                                      1. Bei den Schachteln wären farbige Rahmen statt der grauen Hintergründe möglich,

                                        Ich wüsste nicht, wie (unterschiedlich) farbige Rahmen (was heißt das? etwa auf erster Ebene rot, darin blau, darin grün?) das ausdrücken können, was ich mit Hintergründen mit verschiedenen Grautönen ausdrücken möchte, nämlich die Abstufung der Hierarchie.

                                        auch wenn ich die genannten Punkte begründen kann sollte mein Posting keine ausgefeilte Kritik mit besseren Lösungen sein, aber mal schauen.
                                        Die Hierarchien so per Graustufen darzustellen wäre mir nicht so wichtig da ich die räumliche Aussage der Rahmen oder den Schachtelcharakter wichtiger oder ohne Graustufen vielleicht deutlicher fände.

                                        Was ist die »räumliche Aussage der Rahmen«? Die Rechtecke enthalten einander, da müsste ich im Prinzip weder an Rahmen noch an Hintergrundfarbe viel ändern, das würde auch so deutlich.  Ich will ja gerade den Schachtelcharakter hervorheben, inwiefern ist das ohne Graustufen deutlicher und wie könnte ich den sonst betonen?
                                        Während der Rahmen den Raum umgrenzt und die Kanten bietet, füllt die Hintergrundfarbe den entstehenden Raum als begrenzte Fläche aus, daher würde ich unterschiedliche Rahmenfarben nicht als Indikator der Ebenentiefe auffassen, sondern als Typangabe eines Elements. Aber diese zu kategorisieren, etwa nach Namen oder Bedeutung, ist auf dieser Ebene der Analyse zumindest nicht das, was ich mit der grafischen Darstellung aufzeigen wollte.

                                        und die Beispiele mit den Tags wären durch Farbe u.U. übersichtlicher.

                                        Wenn du auf das Codebeispiel im Abschnitt »Einrückungen im gekürzten Markup« anspielst, so ist es durchaus bewusst, dass der Code dort nicht weiter hervorgehoben ist und die Knotentypen bzw. syntaktischen Bestanteile nicht weiter unterschieden werden sollen. Es ging mir ja nur darum, diese eine Möglichkeit der Visualisierung zu beschreiben, was du anscheinend meinst, wäre bereits eine Kombination aus Syntax-Highlighting und Hierarchieverdeutlichung.

                                        Die Probleme und Interferenzen möglicher Interpretationen und Bedeutungen könnten natürlich durch das Wissen um Syntax-Highlighting noch grösser werden, aber ich meinte besonders eine angenehmere schnellere Erfassung, wenn natürlich solch ein Komfort -sofern er wirklich möglich ist- die Aussage verändert wird es schwierig.

                                        Ja gut, uninteressant finde ich solche Möglichkeiten und solchen Komfort ja nicht, vielleicht bündle ich verschiedene Darstellungen irgendwann zu einer. Nach welchem Schema könnten die Tags denn eventuell gefärbt sein? Meintest du generell eine Unterscheidung zwischen Markup und natürlicher Sprache (Tags in einer Farbe, normaler Text - das sind ja immer Textknoten - in einer Farbe)? Das könnte ich dort sogar machen, weil Textknoten im Schachtelmodell ebenfalls eine andere Farbe habe (eigentlich deshalb, weil sie selbst keine Schachteln sind, sondern das, was es einzusortieren gilt).

                                        Das verstehe ich nicht. »Der Bezug zur dargestellten Seite« ist bei dieser Analyse im Prinzip unwichtig, was brächte es im Kontext meiner Überlegungen, den body-Elemente im Gegensatz zu head-Elementen hervorzuheben, weil die Elemente darin für gewöhnlich sichtbare Boxen erzeugen? [...]

                                        Es ist vielleicht auch besser in einer Darstellung nicht zuviele Themen zu vermengen , aber »Der Bezug zur dargestellten Seite« bzw. eine Abgrenzung des Body könnte vielleicht die Anschaulichkeit etwas verbessern, und eine farbliche Gruppierung Body vs Head würde m.E. einfach die Wahrnehmung vereinfachen, ich hab es allerdings nicht getestet.

                                        Möglich, aber ich sehe nicht, wie diese Dimension im speziellen Kontext meines Artikels relevant ist. Sicherlich sind head und body genauso wie title exponierte »Schachteln«, dieser grundlegende Aufbau jedes Dokuments prägt alle weiteren Entscheidungen, aber diesen Aufbau will ich an dieser Stelle nicht als solchen veranschaulichen noch finde ich es wichtig, ihn dort anzusprechen. Dann nehme ich mich dieser und anderer Markupstrukturen lieber noch einmal gesondert an, indem ich sie einzeln betrachte und bspw. die grundlegende Unterscheidung zwischen head und body behandle.
                                        Was ich mir denken kann, ist eine Abtrennung in Form von mehr Leerraum um head und body... aber auf diese stärkeren Einschnitte bzw. Zusammenhänge, die nicht bei der gleichmacherischen Darstellung zu Tage treten bzw. nicht explizit in Form von Schachteln auftreten, wollte ich sowieso an anderer Stelle noch eingehen.

                                        Kann ich die durch eine bestimmte Farbe etwa verringerte Bedeutung eines Links angemessen auszuzeichnen?

                                        Mangels logischer Alternative zum small-Element wohl durch ein generelles Unscheinbarmachen bzw. Abschwächen der Links des jeweiligen Elterncontainers und ein Hervorheben der Links mit wichtigerer, im Vergleich »normal wichtigen« Links mit dem em-Element...

                                        Meine angenommene Beispielseite sieht ganz oben so aus ([link]):

                                        [www.muster.de]/[beispiel]/diesedatei.html               [impressum]

                                        also schamtisch auch so
                                        [w..e]/[b..l]/di..i.html  -  L   E   E   R   R   A   U   M  - [i..m]

                                        und wenn das Impressum inhaltlich weniger wichtig ist, erhält der betr. a-tag [impressum] z.B. ein color:silver.

                                        Wie würde nun diese Farbgebung bzw. die etwas geringer Auffälligkeit und Wichtigkeit für ein "sematic web" dargestellt werden,

                                        Im Sinne des formalisierten und maschinenlesbaren Webs wohl gar nicht, siehe Ausgangsposting. ;)

                                        wie der beabsichtigte und bei den meisten üblichen Auflösungen vorhandene Leerraum, der vielleicht mit <div><span><a...></span><span><a..>impressum</a></span></div> nicht deutlich wird, aber natürlich kein eigenes Element erhalten soll.

                                        Was mir noch einfallt, was semantisch treffend (aber nicht praktikabel) ist, ist a[rel~="meta"]:link usw. und <a rel="meta author [...]">Impressum</a>
                                        im Kontext des div-Containers. Dementsprechend fände ich eine Klasse, die auf den Linktyp anspielt (a.meta etwa) und an dieser Wesensart des Links die geringere Wichtigkeit festmacht, für einen annehmbaren und vergleichsweise semantischen Kompromiss. Diese Lösung würde zumindest informal herausstellen, warum der Link so-und-so formatiert wird und nicht nur dass er sich optisch von anderen Verweisen unterscheidet. rel="meta ..." kann ja schon jetzt eingebaut werden.

                                        1. Mir noch etwas beim Text aufgefallen, Zitate: "HTML-Dokument ist in der statisch gespeicherten Form zunächst einmal eine Datei" .. "Die kleinste Einheit der Auszeichnungssprache ist ein Paar von in Beziehung stehenden Tags."
                                          Es geht dir um HTML als Auszeichnungssprache, dennoch wäre es möglich das HTML-Dokument durch seinen Suffix, den Inhalt (z.B. Text) und die Browser festzulegen. Wenn "Hallo Welt" ohne Tags vom Browser wie gewünscht ausgegeben wird, ist es nun HTML, falsches HTML oder gar kein HTML?

                                          Was ist die »räumliche Aussage der Rahmen«? Die Rechtecke enthalten einander, da müsste ich im Prinzip weder an Rahmen noch an Hintergrundfarbe viel ändern, das würde auch so deutlich.  Ich will ja gerade den Schachtelcharakter hervorheben, inwiefern ist das ohne Graustufen deutlicher und wie könnte ich den sonst betonen?

                                          als zweidimensionale Darstellung fände ich Rahmen (wie die Kreise der Mengenlehre) richtiger als Flächen. Bei einer 3D-Interpretation deiner Darstellung kommt mir eher die Assoziation an Pyramiden als an Schachteln. Wenn ich der Vorstellung einer Hierarchie folge, stört mich dass Inhalte je nach umgebenden Schachteln unterschiedlich hell ausfallen, da müsste vielleicht die Endhelligkeit von Inhalten foo, bar immer gleich ausfallen.

                                          Bei einer bunteren Gestaltung, auch bei den anderen Darstellungen, müsste wohl überprüft werden welche möglichen Bedeutungen entstehen könnten, und ob Vermischungen von verschiedenen Modellen sich gegenseitig verstärken und ergänzen oder nicht. HTML-Syntax die per Einrückung veranschaulicht ist mag es u.U. sogar ohne verschiedene Farben besser ermöglichen sich auf das Schema zu konzentrieren, während es sonst vielleicht unnötig trocken wird. Ähnlich die Frage per zusätzlicher Leerzeilen Code übersichtlicher zu machen; ich finde es für mich vorteilhaft viel Code auf einmal überblicken zu können und schreibe sehr dicht, was aber allgemein wohl eher nicht empfehlenswert ist. Aber wenn nun ein aufgelockerter Code ohne Scrollen nicht mehr überschaubar ist mag dann doch zusätzliche Gestaltung oder vielleicht noch deutlichere Einrückung hilfreich sein.

                                          1. Mir noch etwas beim Text aufgefallen, Zitate: "HTML-Dokument ist in der statisch gespeicherten Form zunächst einmal eine Datei" .. "Die kleinste Einheit der Auszeichnungssprache ist ein Paar von in Beziehung stehenden Tags."
                                            Es geht dir um HTML als Auszeichnungssprache, dennoch wäre es möglich das HTML-Dokument durch seinen Suffix, den Inhalt (z.B. Text) und die Browser festzulegen. Wenn "Hallo Welt" ohne Tags vom Browser wie gewünscht ausgegeben wird, ist es nun HTML, falsches HTML oder gar kein HTML?

                                            Wo kein Markup ist, dort ist kein HTML. Die Zuschreibung des Inhaltstyp durch die Dateiendung hat nichts damit zu tun, ob der Inhalt Markup enthält und ein Dokument bildet. Ein Dokument mit dem Inhalt »<h1>Hallo Welt</h1>« enthält HTML-Code, wird aber nur durch die Verarbeitung der Browser zum Dokument, denn diese denken sich den Rest hinzu und machen ein Dokument daraus. Wo nicht einmal die notwendigen Grundzüge eines Dokuments vorhanden sind (Doctype, html, head, title, body), dort ist kein HTML-Dokument. Freilich können diese in HTML implizit vorhanden sein, sodass nur das title-Element und ein body-Kindelement explizit genannt werden.

                                            Was ist die »räumliche Aussage der Rahmen«? Die Rechtecke enthalten einander, da müsste ich im Prinzip weder an Rahmen noch an Hintergrundfarbe viel ändern, das würde auch so deutlich.  Ich will ja gerade den Schachtelcharakter hervorheben, inwiefern ist das ohne Graustufen deutlicher und wie könnte ich den sonst betonen?

                                            als zweidimensionale Darstellung fände ich Rahmen (wie die Kreise der Mengenlehre) richtiger als Flächen.

                                            Ja, dabei verliert man jedoch schnell die Übersicht, welcher Rahmen zu welchem Element gehört und warum ich keine Rahmenfarben benutzen möchte, sagte ich ja.

                                            Bei einer 3D-Interpretation deiner Darstellung kommt mir eher die Assoziation an Pyramiden als an Schachteln.

                                            Ich weiß, das ruft die Farbabstufung natürlich hervor. Das ist mir auch aufgefallen und ich finde diese Sichtweise recht passend, obwohl sie dort nicht im Vordergrund stehen sollte. An sich ist das Modell »aus Element X geht Element Y hervor, X bringt Y hervor, X fundiert Y, Y baut auf X auf, X bietet Raum für Y« usw. wie auch teilweise angesprochen eine wichtige, obwohl ich vielleicht gesondert darauf eingehen sollte, als darauf in der grafischen Darstellung implizit hinzuweisen, aber der Artikel ist ja noch nicht annähernd vollständig.
                                            Ich haderte, ob nicht vielleicht das umgekehrte Schema passender sei (von hell zu dunkel mit zunehmender Tiefe), allerdings ändert das m.E. nichts Grundlegendes und dein Einwand gälte trotzdem.

                                            Wenn ich der Vorstellung einer Hierarchie folge, stört mich dass Inhalte je nach umgebenden Schachteln unterschiedlich hell ausfallen, da müsste vielleicht die Endhelligkeit von Inhalten foo, bar immer gleich ausfallen.

                                            Das verstehe ich nicht, die Textknoten liegen nunmal auf unterschiedlicher Hierarchieebene und nur das ist das Kriterium der Farbgebung; zur Verdeutlichung der Textknoten und zur Unterscheidung von Elementknoten ist der Text bereits blau. Um die Bedeutung der Ebene, also etwa um »hier ist die unterste und letzte Ebene erreicht, hier liegen die Textinhalte, auf die sich alles bezieht, sie besitzen keine weiteren Kindknoten«, geht es mir dort eigentlich nicht.

                                            Ähnlich die Frage per zusätzlicher Leerzeilen Code übersichtlicher zu machen; ich finde es für mich vorteilhaft viel Code auf einmal überblicken zu können und schreibe sehr dicht, was aber allgemein wohl eher nicht empfehlenswert ist. Aber wenn nun ein aufgelockerter Code ohne Scrollen nicht mehr überschaubar ist mag dann doch zusätzliche Gestaltung oder vielleicht noch deutlichere Einrückung hilfreich sein.

                                            Was das Einrückungsbeispiel angeht, so wäre es nicht in meinem Sinne, wenn ich das Markup strukturieren würde, indem ich Leerzeilen einfüge. Diese Abstraktionsebene habe ich strenggenommen schon selbstverständlich und unbewusst beim Notieren des Codes des Beispieldokuments gebraucht, indem ich etwa die h2/p-Gruppen voneinander abgetrennt habe. Das ermöglicht natürlich die Übersichtlichkeit, weil es die Semantik des Codes in der Präsentation widerspiegelt. Aber gerade diese will ich analysieren, da geht es darum, sich diese Zusammenhänge bewusst zu machen, insofern wäre bzw. ist eine äußerliche Strukturierung auf dieser Ebene irreführend, denn der Code an sich gibt diese Verbindungen nicht explizit her, weil die Gruppen nicht als solche ausgezeichnet sind.

                    2. wenn dann mit dem guten Design auch semantische Anforderungen beim HTML-Code verbunden sind, kann ja der übliche Navigationsblock wie schon im Thread geschehen betrachtet werden, aber es gibt ja auch Sonderfälle wie "Impressum".

                      Das halte ich -- wie bereits erwähnt -- für zu kurz gegriffen, denn meine Gedankensprünge beim Betrachten einer Präsentation kann der Autor niemals zuverlässig vorhersagen, weswegen ich als Autor dem Nutzer prinzipiell den Umweg über etwa "Home" erspare. Stattdessen biete ich ihm eine möglichst vollständige Navigation innerhalb der Seite -- im Sinne des Hypertextes wäre hier eine Sitemap im <frame> angebracht, was ich aber ablehne --, um die meisten Anflüge von spontaner Wissbegier, Neugier etc. in die richtigen Kanäle zu leiten.

                      Diese Verknüpfungen sind aber aus objektivierter Sicht willkürlich und nicht assoziativ. Was das Denken des Benutzers angeht, bei dem eigenständig Bezüge hergestellt werden, deren Sinn sich nicht intersubjektiv vermitteln lässt und die sich wie du sagst nicht voraussehen lassen, so ließe sich genauso rechtfertigen, auf jeder Seite zufällige Links unter anderem hinaus ins Web unterzubringen, weil die Gedanken des Benutzers ja springen und er plötzlich in einem irrationalen Anflug vom Hölzchen aufs Stöckchen will. Nur ist es wirklich angebracht, solche Kanäle anzulegen, ist das die Aufgabe des Autors? Wenn ein Frameset genutzt wird, um die sogenannte Navigation auszulagern, gar eine Sitemap ständig im Blickfeld haben, fehlt wie gesagt jede Herausarbeitung der Beziehungen eines Einzelknoten. Es wird ganz und gar dem Benutzer überlassen, zwischen beabsichtigten und unbeabsichtigten Kontext zu unterscheiden. Der Leser wird nicht durch wenige vorangelegte Kanäle geleitet, deren beschreiten sich lohnt, er steht nur vor einer Flut von Verweisen, deren kein Zusammenhang mitgegeben ist. Die Links sind einfach deshalb da, weil es das Zieldokument gibt.

                      Der Sinn des Hypertext ist m.E. eben nicht, von jedem Knoten einen Sprung zu jedem anderen Knoten zu ermöglichen, sondern kontextuelle Verweise zu bieten und damit kohärente Netzwerke an Informationen zu weben, die nicht nur im Kopf des Betrachters entstehen und eine andere Person kein bisschen nachvollziehen kann, wieso das eine mit dem anderen in Verbindung/Wechselwirkung steht. Dieser Vorstellung nach referenziert der Verweis immer etwas an sich Angeschlossenes, Weiterführendes, Verwandtes und Verbundenes bzw. der Autor will diese Verbindung dem Leser nahelegen. Demnach ist »Querverweis« auch nicht so gemeint, dass der Verweis aus der gegenwärtigen Knotenstruktur heraus in eine andere nicht den Anspruch hat, einen verständlichen und nachvollziehbaren Zusammenhang zu kennzeichnen.

                      Angenommen, ich verstehe dieses Posting als Teil der Site »SELFHTML«, so wären folgende Links möglich, um Wissbegier und Neugier des Lesers entgegenzukommen:

                      http://aktuell.de.selfhtml.org/sonst/userwatch.shtml
                      http://aktuell.de.selfhtml.org/links/datenbank.htm#buecher_german
                      http://forum.de.selfhtml.org/archiv/2003/2/37926/#m207867
                      http://selfhtml.teamone.de/html/verweise/tastatur.htm#kuerzel

                      Nicht, dass die Seiten etwas mit dem hier behandelten Thema zu tun haben, aber wer weiß, irgendein Leser könnte ja entsprechende Assoziationen haben, daher sind diese Links wohl angemessen und würden in einer ständig sichtbaren Sitemap angezeigt (von der überwältigenden Komplexität einer solchen einmal abgesehen). Oder vielleicht denkt er plötzlich an Nacktaugenkakadus http://www.nymphensittiche.com/heiligenk_augu02.htm, wieso sollte man nicht solche Verweise anlegen?

                      Im Assoziations-Blaster werden solche Assoziationen gerne durch ironische Verweise von beliebigen Einträgen auf den Eintrag »Erinnertmichimmeranficken« ausgedrückt, und deiner Auffassung zufolge wären all diese Verweise sinnvoll...

                      1. Hallo.

                        Diese Verknüpfungen sind aber aus objektivierter Sicht willkürlich und nicht assoziativ.

                        Natürlich sind sie das. -- Ich möchte sogar sagen: Sie sind suggestiv, denn sie sind nur ein Hilfsmittel, die ohnehin nicht vollständig zu lenkende Ausmerksamkeit etwas breiter zu kanalisieren.

                        Was das Denken des Benutzers angeht, bei dem eigenständig Bezüge hergestellt werden, deren Sinn sich nicht intersubjektiv vermitteln lässt und die sich wie du sagst nicht voraussehen lassen, so ließe sich genauso rechtfertigen, auf jeder Seite zufällige Links unter anderem hinaus ins Web unterzubringen, weil die Gedanken des Benutzers ja springen und er plötzlich in einem irrationalen Anflug vom Hölzchen aufs Stöckchen will.

                        Das ist richtig, aber warum sollte mir als Autor daran gelegen sein?

                        Nur ist es wirklich angebracht, solche Kanäle anzulegen, ist das die Aufgabe des Autors?

                        Das ist eine Frage der Absicht, die der Autor verfolgt. Wenn ich meine Präsentation als Dienstleistung auffasse, ist es töricht, darauf zu verzichten. Wenn ich jedoch einen Fachartikel, mag das anders sein.

                        Wenn ein Frameset genutzt wird, um die sogenannte Navigation auszulagern, gar eine Sitemap ständig im Blickfeld haben, fehlt wie gesagt jede Herausarbeitung der Beziehungen eines Einzelknoten.

                        Nein, auch eine Sitemap kann sich durch das Neuladen des des gesamten <frameset> dem Kontext anpassen. Es gibt sogar Suchmaschinen, die darauf basieren und diese Knoten visuell darstellen. Eine solche Suchmaschine in einen <frame> einzubinden, während ein zweiter den Inhalt des Dokuments anzeigt, wird meinen Ansprüchen an die Methode gerecht.

                        Es wird ganz und gar dem Benutzer überlassen, zwischen beabsichtigten und unbeabsichtigten Kontext zu unterscheiden. Der Leser wird nicht durch wenige vorangelegte Kanäle geleitet, deren beschreiten sich lohnt, er steht nur vor einer Flut von Verweisen, deren kein Zusammenhang mitgegeben ist. Die Links sind einfach deshalb da, weil es das Zieldokument gibt.

                        Der Aufbau einer Navigation hat sich nach der Präsentation zu richten, so dass ein Kontext immer gegeben ist. So findet man auf vielen Seiten eine entsprechend abgespeckte Version der Navigation mit einem zusätzlichen Verweis auf die Sitemap, die als Inhaltsverzeichnis ja per se einen Bezug zum Inhalt des Dokumentes hat.

                        Der Sinn des Hypertext ist m.E. eben nicht, von jedem Knoten einen Sprung zu jedem anderen Knoten zu ermöglichen, sondern kontextuelle Verweise zu bieten und damit kohärente Netzwerke an Informationen zu weben, die nicht nur im Kopf des Betrachters entstehen und eine andere Person kein bisschen nachvollziehen kann, wieso das eine mit dem anderen in Verbindung/Wechselwirkung steht.

                        Und eine übegreifende Navigation erweitert meines Erachtens lediglich diesen Kontext.

                        Im Assoziations-Blaster werden solche Assoziationen gerne durch ironische Verweise von beliebigen Einträgen auf den Eintrag »Erinnertmichimmeranficken« ausgedrückt, und deiner Auffassung zufolge wären all diese Verweise sinnvoll...

                        Vielleicht sollten wir dies weiter erörtern, wenn du meine Auffassung richtig einsortiert hast.
                        MfG, at

                        1. Diese Verknüpfungen sind aber aus objektivierter Sicht willkürlich und nicht assoziativ.

                          Natürlich sind sie das. -- Ich möchte sogar sagen: Sie sind suggestiv, denn sie sind nur ein Hilfsmittel, die ohnehin nicht vollständig zu lenkende Ausmerksamkeit etwas breiter zu kanalisieren.

                          Was ich eben sagen wollte, ist, dass das Anlegen von zahllosen Kanälen durch »eine möglichst vollständige Navigation« nichts mit dem Lenken der Aufmerksamkeit auf die im Besonderen relevanten Verknüpfungen liegt, die nicht nur existieren, weil sie angelegt wurden und vom Besucher begangen werden, sondern weil die Inhalte korrespondieren. Ich streite nicht ab, dass viele Leser beim Bewegen durch die Site die Lust zu Quersprüngen zu anderen Teilen der Site haben, die mit dem Ursprungsdokument nichts direkt zu tun haben. Auch ist ihnen durch eine vollständige Navigation immer bewusst, was es »sonst noch« auf der Site gibt. Es ist natürlich legitim, diese Bedürfnisse zu bedienen. Allerdings sehe ich auch das Bedürfnis, sich in der Sitestruktur innerhalb der Pfade zu bewegen, die inhaltlichen Zusammenhang markieren. Anstatt dem Benutzer also einen Haufen von Links vorzusetzen, von denen der Leser nicht direkt weiß, ob und wie sie mit dem gegenwärtigen Dokument zu tun haben, sehe ich es als wichtig an, kontextuelle Verweise als solche deutlich zu machen. Das kann natürlich auch dadurch geschehen, eine Sitestruktur so auszuarbeiten, dass eine »Navigation« Schwerpunkt auf diesen engeren Kontext eines Dokuments setzt, aber auch darüber hinaus geht, um Quersprünge zu erlauben (was ich persönlich nicht für wichtig halte und den Umweg über einen rel="up"- bzw. rel="start"-Link für zumutbar halte, aber ich kann den Sinn nachvollziehen).

                          Was das Denken des Benutzers angeht, bei dem eigenständig Bezüge hergestellt werden, deren Sinn sich nicht intersubjektiv vermitteln lässt und die sich wie du sagst nicht voraussehen lassen, so ließe sich genauso rechtfertigen, auf jeder Seite zufällige Links unter anderem hinaus ins Web unterzubringen, weil die Gedanken des Benutzers ja springen und er plötzlich in einem irrationalen Anflug vom Hölzchen aufs Stöckchen will.

                          Das ist richtig, aber warum sollte mir als Autor daran gelegen sein?

                          Nun, unter dem Aspekt, dem Besucher auf der Site zu behalten, habe ich es noch nicht gesehen. Das ist auch ein Argument, das völlig andere Kriterien zugrunde legt, als diejenigen, die gegen das verbreitete Konzept der »Navigationsleiste« genannt wurden. Es hat wenig mit der Frage nach der richtigen semantischen Auszeichnung gemein.

                          Nur ist es wirklich angebracht, solche Kanäle anzulegen, ist das die Aufgabe des Autors?

                          Das ist eine Frage der Absicht, die der Autor verfolgt. Wenn ich meine Präsentation als Dienstleistung auffasse, ist es töricht, darauf zu verzichten. Wenn ich jedoch einen Fachartikel, mag das anders sein.

                          Das mag stimmen. Wobei ich dies eher als eine Reaktion auf ein bestimmtes unerfreuliches Leserverhalten ansehe und nicht von einem grundlegenden Zusammenhang des Hypertexts sprechen würde. Prinzipiell sehe ich diesbezüglich auch keinen notwendigen Unterschied zwischen verschiedenen Absichten von Sites. Vor allem möchte ich »Präsentation einer Dienstleistung« (was immer das sein mag) nicht so selbstverständlich mit einer vergleichsweise aufdringlichen Inhaltsaufbereitung verstanden wissen. Diejenigen Besucher, die wirklich Wissbegier und Neugier zeigen, werden einen Navigationsschritt mehr in Kauf nehmen, um zu den Inhalten zu kommen, die mit dem gegenwärtigen Dokument nur indirekt in Verbindung stehen. Alles Vorhandene möglichst kompakt zu zeigen und Quersprünge zu ermöglichen, spricht meinem Verständnis nach eher diejenigen an, die nicht von sich selbst zum Stöbern bzw. zum sogenannten Flanieren bereit sind, was m.E. nicht dermaßen verhindert ist, wenn nicht in jedem einzelnen Dokument die komplette Sitemap wiederholt wird bzw. parallel zum Dokument angezeigt wird.

                          Wenn ein Frameset genutzt wird, um die sogenannte Navigation auszulagern, gar eine Sitemap ständig im Blickfeld haben, fehlt wie gesagt jede Herausarbeitung der Beziehungen eines Einzelknoten.

                          Nein, auch eine Sitemap kann sich durch das Neuladen des des gesamten <frameset> dem Kontext anpassen.

                          Darum geht es doch gar nicht. Das ist ja im Prinzip noch schlimmer (und praktikabel schon gar nicht, weil es soviele Sitemap-Dokumente und soviele Framesets erzeugt, wie es Dokumente gibt - von JavaScript/Flash/Java-Lösungen einmal abgesehen). Ich wollte sagen, dass das Auslagern selbst das Problem ist. Jedes Dokument hat in der Sitestruktur einen bestimmten Platz. Dieser individuelle Kontext lässt teilweise etwa sich durch einen entsprechenden Ausschnitt der Sitehierarchie beschreiben, vereinfacht:

                          ...
                          <a rel="chapter" rev="child">B</a>
                           \  |- <a rel="section [prev]">1</a>
                           |- <strong title="aktuelles Dokument">2</strong>
                           - <a rel="section [next]">2</a>
                          ...

                          Zum Kontext gehören neben dem Bewegen in Hierarchie und Sequenz auch Querverweise (verwandte, weiterführende Infos usw.) und die site-zentralen Einrichtungen, wie gesagt. Es ist in der Regel notwendig, diesen individuellen Kontext als solchen herauszuarbeiten, um grundlegende Navigation zu ermöglichen (was darüber hinaus möglich und aus anderen Gründen ratsam ist, lasse ich einmal außen vor, das ist dann m.E. eher Kür statt Pflicht). Das hatte ich mit »die direkten Zusammenhänge eines Dokuments mit anderen Knoten aus der Sicht des Einzeldokuments herauszuarbeiten« angesprochen. HTML bietet, wie ich in [pref:t=67816&m=388766] geschildert habe, die Möglichkeit, diesen Kontext explizit semantisch und formal angemessen auszuzeichnen - und zwar individuell aus der Fischaugenperspektive. Jedes Dokument enthält dadurch Verweise zum individuellen Kontext (und ist damit autonom, was später eine Rolle spielen wird).

                          Demgegenüber steht nun die Vorgehensweise, auf diese Auszeichnung ganz oder weitesgehend zu verzichten und den individuelle Kontext nur noch implizit durch die Position des Titels des jeweiligen Dokuments bzw. Position des Links zum jeweiligen Dokument in der Listenhierarchie der Sitemap zu erkennen ist. Anstatt jedem Dokument diese Informationen mitzugeben, wird nur noch ein Meta-Dokument geboten, dass alle Zusammenhänge aus der Vogelperspektive beschreibt. Von typisierten Verweisen, die die Einordnung eines Dokuments in den jeweiligen Kontext vornehmen, ist dabei keine Spur mehr, auch wird keine Unterscheidung von direktem und entfernterem Kontext gemacht.
                          Selbst wenn jedes an sich mit anderen nicht vernetzte Dokument ein eigenes Frameset mit einer eigenen angepassten Sitemap erhält, in der das jeweillige Dokument irgendwie markiert ist (wie oben etwa durch strong) und der spezielle Kontext hervorgehoben ist, kann darin nie diejenige Semantik untergebracht werden, die das lokale, individuelle Auszeichnen des Dokumentkontexts ermöglicht. Das hatte ich schon in [pref:t=67816&m=388762] anklingen lassen und Tim hat es in [pref:t=67816&m=393891] schön auf den Punkt gebracht.

                          Der praktische Nachteil davon, dass das Dokument nur durch Drittdokumente in seinen Kontext eingeordnet wird und nicht durch Metadaten in Form von link-Verknüpfungen (oder pragmatisch: breadcrumb trails, kleinere Sitemapausschnitte wie oben gezeigt), ist die fehlende Navigierbarkeit, wenn das Dokument außerhalb des Framezusammenhangs steht. Aber das ist ein generelles Problem von Frames, da verweise ich auf meine Postings im Archiv, welche die Notwendigkeit hervorheben, dass ein Dokument in dieser Weise autonom sein muss bzw. sollte, um unter verschiedenen Bedingungen benutzbar zu sein.

                          Es gibt sogar Suchmaschinen, die darauf basieren und diese Knoten visuell darstellen.

                          Wie hat man sich diese vorzustellen, als eine Art dynamisches Menü? Woher bekommt sie die Information über die Struktur und den jeweiligen Kontext, oder soll sie die Verbindungen gar nicht visualisieren? Sie müsste ja irgendwo die Daten hernehmen, etwa aus einem globalen RDF-Dokument.

                          Eine solche Suchmaschine in einen <frame> einzubinden, während ein zweiter den Inhalt des Dokuments anzeigt, wird meinen Ansprüchen an die Methode gerecht.

                          Wie gesagt, das Dokument verliert ohne diese Navigationshilfe jegliche Verbindungen zum Kontext bzw. hatte sie an sich nie.

                          Es wird ganz und gar dem Benutzer überlassen, zwischen beabsichtigten und unbeabsichtigten Kontext zu unterscheiden. Der Leser wird nicht durch wenige vorangelegte Kanäle geleitet, deren beschreiten sich lohnt, er steht nur vor einer Flut von Verweisen, deren kein Zusammenhang mitgegeben ist. Die Links sind einfach deshalb da, weil es das Zieldokument gibt.

                          Der Aufbau einer Navigation hat sich nach der Präsentation zu richten, so dass ein Kontext immer gegeben ist.

                          Ansonsten plädierst du dafür, die Präsentation bei der Auszeichnung zunächst zu ignorieren und die Auszeichnung an sich zu betrachten, wieso stellst du hier die Präsentation über alles und fragst nicht nach Semantik? Und wieso ist der Kontext immer gegeben? Wenn die Präsentation als Fundament defizitär ist, dann ist eine darauf aufbauende und dem entsprechende Navigationstrategie nicht per se angemessen und der entstehende Kontext muss nicht kohärent sein. Sowieso zieht die Präsentation an sich Fragen der Hypertextualisierung nicht in Betracht...?

                          So findet man auf vielen Seiten eine entsprechend abgespeckte Version der Navigation mit einem zusätzlichen Verweis auf die Sitemap, die als Inhaltsverzeichnis ja per se einen Bezug zum Inhalt des Dokumentes hat.

                          Abgesehen davon, dass auch dies im Sinne des Ursprungsposting unsemantisch ist (krchch) und die link-Elemente die Navigation formalisieren könnten und damit das Problem der besagten »Interferenzen« lösen würden, halte ich es für einen alltagstauglichen/praktikablen Schritt, wenn die besonders relevanten Beziehungen herausgearbeitet werden. Davon, fast alle Navigationsbewegungen über reine Meta-Dokumente wie Sitemaps laufen zu lassen (Benutzer geht immer wieder zur Sitemap, zu einem Dokument, zur Sitemap, zur einem weiterem Dokument usw.), halte ich wiederum wenig.

                          Der Sinn des Hypertext ist m.E. eben nicht, von jedem Knoten einen Sprung zu jedem anderen Knoten zu ermöglichen, sondern kontextuelle Verweise zu bieten und damit kohärente Netzwerke an Informationen zu weben, die nicht nur im Kopf des Betrachters entstehen und eine andere Person kein bisschen nachvollziehen kann, wieso das eine mit dem anderen in Verbindung/Wechselwirkung steht.

                          Und eine übegreifende Navigation erweitert meines Erachtens lediglich diesen Kontext.

                          Sie verwischt den ursprünglichen Kontext m.E. vollkommen. Das Netzwerk konstituiert sich nicht in seinen Bestandteilen und deren Beziehungen mit Subjekten, Prädikaten (rel) und Objekten (href) bzw. umgekehrten Beziehungen, sondern nur in einem zentralen Metadokument.

                          1. Hallo.

                            Was ich eben sagen wollte,

                            [...]

                            Ich stimme da vollkommen mit dir überein. Ich baue gerne ergänzend zu Navigation, die bei mir im Übrigen nur auf sehr kompakten Seiten vollständig ist, häufig noch eine kleine Liste der Rubrik "In diesem Zusammenhang ebenfalls interessant:" hinzu, gegebenenfalls sogar strukturiert oder kurz erläutert. Alternativ hätte ich thematisch naheliegende Referenzen auch innerhalb der Nauptnavigation mittels logischer Auszeichnung hervorheben können, aber meine Befürchtung war, mit unterschiedlichen hervorgehobenen Links innerhalb der gleichen Navigationselemente auf unterschiedlichen Seiten die Nutzer unnötig zu verwirren.

                            Nun, unter dem Aspekt, dem Besucher auf der Site zu behalten, habe ich es noch nicht gesehen. Das ist auch ein Argument, das völlig andere Kriterien zugrunde legt, als diejenigen, die gegen das verbreitete Konzept der »Navigationsleiste« genannt wurden. Es hat wenig mit der Frage nach der richtigen semantischen Auszeichnung gemein.

                            Stimmt, während die Semantik im Kopf des Betrachter entsteht, geht die Intention vom Autoren aus. Diese beiden Dinge haben also wirklich wenig miteinander gemein. Aber ohne Intention müsste ich auch keine Informationen zur Verfügung stellen. -- Sie sind ja kein Selbstzweck.

                            Wobei ich dies eher als eine Reaktion auf ein bestimmtes unerfreuliches Leserverhalten ansehe und nicht von einem grundlegenden Zusammenhang des Hypertexts sprechen würde.

                            Da hast du sicher Recht, aber das rechtfertigt meines Erachtens nicht, diesen Aspekt völlig zu ignorieren und auf eine Navigation zu verzichten, denn reinen Hypertext zu verwenden, ohne Begleiteffekte zu berücksichtigen, hielte ich für einen Tanz um das falsche goldene Kalb.

                            Vor allem möchte ich »Präsentation einer Dienstleistung« (was immer das sein mag) nicht so selbstverständlich mit einer vergleichsweise aufdringlichen Inhaltsaufbereitung verstanden wissen.

                            Nun, "aufdringlich" ist in diesem Zusammenhang sicher relativ, und "vergleichsweise" zu einem Hypertext der reinen Lehre ist eine Navigation immer sehr viel der guten Absicht. Unter einer Präsentation als Dienstleistung verstehe ich, nicht nur das naheliegende zu bieten (Hypertext), sondern eine darüber hinaus gehende Vernetzung zu schaffen, die einzelnen Wörtern oder Passagen des Textes nicht eindeutig zuzuordnen ist, so dass dies nicht mittels Hypertext geschehen kann. Zwar versuche ich auch das, aber ein gesonderter Punkt "Wegbegeschreibung" innerhlab der Navigation scheint vielen Nutzern wahrscheinlich aus Gewohnheit eingänglicher als mein Ansatz, einzelne Adresszeilen mit einem Link auf die Wegbeschreibung zu versehen.

                            Diejenigen Besucher, die wirklich Wissbegier und Neugier zeigen, werden einen Navigationsschritt mehr in Kauf nehmen, um zu den Inhalten zu kommen, die mit dem gegenwärtigen Dokument nur indirekt in Verbindung stehen.

                            Je nach Konzept wird ihnen ja auch wenig anderes übrig bleiben ;-)

                            Alles Vorhandene möglichst kompakt zu zeigen und Quersprünge zu ermöglichen, spricht meinem Verständnis nach eher diejenigen an, die nicht von sich selbst zum Stöbern bzw. zum sogenannten Flanieren bereit sind, was m.E. nicht dermaßen verhindert ist, wenn nicht in jedem einzelnen Dokument die komplette Sitemap wiederholt wird bzw. parallel zum Dokument angezeigt wird.

                            Hier sehe ich eine Parallele, denn die, "die nicht von sich selbst zum Stöbern bzw. zum sogenannten Flanieren bereit sind," haben es häufig schlicht eilig. Ich muss darauf keine Rücksicht nehmen oder kann versuchen, sie mittels meiner Inhalte ein wenig auszubremsen, aber ich kann ihnen auch einige Sprungbretter zur Verfügung stellen, die die Flaneure sicher auch gern übersehen.

                            Nein, auch eine Sitemap kann sich durch das Neuladen des des gesamten <frameset> dem Kontext anpassen.

                            Darum geht es doch gar nicht. Das ist ja im Prinzip noch schlimmer (und praktikabel schon gar nicht, weil es soviele Sitemap-Dokumente und soviele Framesets erzeugt, wie es Dokumente gibt - von JavaScript/Flash/Java-Lösungen einmal abgesehen).

                            Auch wenn es dir nicht darum ging, geht es mir sehr wohl darum. Und technisch ist so etwas auch durch mehrere Sitemaps mit unterschiedlichen Mittelpunkten (Standorten) innerhalb eines Dokumentes zu lösen -- aber das tatsächlich nur am Rande.

                            Ich wollte sagen, dass das Auslagern selbst das Problem ist. Jedes Dokument hat in der Sitestruktur einen bestimmten Platz. Dieser individuelle Kontext lässt teilweise etwa sich durch einen entsprechenden Ausschnitt der Sitehierarchie beschreiben, vereinfacht:

                            ... <a rel="chapter" rev="child">B</a>  
                             |- <a rel="section [prev]">1</a>  |- <strong title="aktuelles Dokument">2</strong>  - <a rel="section [next]">2</a>

                            Ja, soweit jedenfalls bei einer linearen Struktur. Innerhalb einer nicht-linearen Struktur hilf t dann wohl eher wieder reiner Hypertext -- gegebenenfalls auch mit Navigation.

                            Zum Kontext gehören neben dem Bewegen in Hierarchie und Sequenz auch Querverweise (verwandte, weiterführende Infos usw.) und die site-zentralen Einrichtungen, wie gesagt. Es ist in der Regel notwendig, diesen individuellen Kontext als solchen herauszuarbeiten, um grundlegende Navigation zu ermöglichen (was darüber hinaus möglich und aus anderen Gründen ratsam ist, lasse ich einmal außen vor, das ist dann m.E. eher Kür statt Pflicht). Das hatte ich mit »die direkten Zusammenhänge eines Dokuments mit anderen Knoten aus der Sicht des Einzeldokuments herauszuarbeiten« angesprochen. HTML bietet, wie ich in geschildert habe, die Möglichkeit, diesen Kontext explizit semantisch und formal angemessen auszuzeichnen - und zwar individuell aus der Fischaugenperspektive. Jedes Dokument enthält dadurch Verweise zum individuellen Kontext (und ist damit autonom, was später eine Rolle spielen wird).

                            Soweit gehen wir konform -- wenn man davon absieht, wie mangelhaft diese Methoden bisher eingesetzt werden können, wenn man keinen Einfluss auf den User Agent hat.

                            Demgegenüber steht nun die Vorgehensweise, auf diese Auszeichnung ganz oder weitesgehend zu verzichten und den individuelle Kontext nur noch implizit durch die Position des Titels des jeweiligen Dokuments bzw. Position des Links zum jeweiligen Dokument in der Listenhierarchie der Sitemap zu erkennen ist. Anstatt jedem Dokument diese Informationen mitzugeben, wird nur noch ein Meta-Dokument geboten, dass alle Zusammenhänge aus der Vogelperspektive beschreibt.

                            Wieso? Je nach gebotenem Ausschnitt können auch mehrere Perspektiven innerhalb eines Dokumentes liegen. Dies schließt zwar eine hohe Redundanz ein, aber die ist bei der anderen Methode ja auch nur auf mehrere Dokumente verteilt.

                            Von typisierten Verweisen, die die Einordnung eines Dokuments in den jeweiligen Kontext vornehmen, ist dabei keine Spur mehr, auch wird keine Unterscheidung von direktem und entfernterem Kontext gemacht.

                            Wieso? Ich muss doch nicht vom schlechtesten Beispiel auf die Allgemeinheit schließen, denn natürlich kann ich typisierte Verweise und den Kontext über Klassen oder logische Auszeichnung innerhalb der Sitemap herstellen und per CSS auszeichnen. -- Ich mag Sitemaps eigentlich nicht sonderlich und verteidige sie nur ungern, aber ich befürchte einfach, dass deine Darstellung die Sachverhalte ein wenig verkürzt.

                            Selbst wenn jedes an sich mit anderen nicht vernetzte Dokument ein eigenes Frameset mit einer eigenen angepassten Sitemap erhält, in der das jeweillige Dokument irgendwie markiert ist (wie oben etwa durch strong) und der spezielle Kontext hervorgehoben ist, kann darin nie diejenige Semantik untergebracht werden, die das lokale, individuelle Auszeichnen des Dokumentkontexts ermöglicht. Das hatte ich schon in anklingen lassen und Tim hat es in schön auf den Punkt gebracht.

                            Das es sich dabei um einen Behelf handelt, ist uns doch allen bewusst. Aber deswegen muss ich nicht ganz darauf verzichten oder darauf verzichten, die Methode zu verfeinern -- zumal die bessere Variante bisher leider kaum Unterstützung bei den User Agents findet.

                            Der praktische Nachteil davon, dass das Dokument nur durch Drittdokumente in seinen Kontext eingeordnet wird und nicht durch Metadaten in Form von link-Verknüpfungen (oder pragmatisch: breadcrumb trails, kleinere Sitemapausschnitte wie oben gezeigt), ist die fehlende Navigierbarkeit, wenn das Dokument außerhalb des Framezusammenhangs steht. Aber das ist ein generelles Problem von Frames, da verweise ich auf meine Postings im Archiv, welche die Notwendigkeit hervorheben, dass ein Dokument in dieser Weise autonom sein muss bzw. sollte, um unter verschiedenen Bedingungen benutzbar zu sein.

                            Keine Frage, aber die Idee mit den Frames war ja auch aus dem Vorwurf geboren, eine Sitemap oder sonstige Navigation nicht in die Seite einbinden zu dürfen. Die dadurch geschaffene Redundanz sehe ich sicher als kleineres Übel gegenüber Frames an. Wie ich zu Frames stehe, habe ich ja bereits innerhalb dieses Threads sowie im Vorfeld deutlich zu verstehen gegeben.

                            Es gibt sogar Suchmaschinen, die darauf basieren und diese Knoten visuell darstellen.

                            Wie hat man sich diese vorzustellen, als eine Art dynamisches Menü? Woher bekommt sie die Information über die Struktur und den jeweiligen Kontext, oder soll sie die Verbindungen gar nicht visualisieren? Sie müsste ja irgendwo die Daten hernehmen, etwa aus einem globalen RDF-Dokument.

                            Frage mich bitte nicht nach der zu Grunde liegenden Technik. Ich weiß nur, dass es sich wohl um ein Java-Applet handeln muss, dass unterschiedlich weit entfernte und unterschiedlich große miteinander vernetzte Knoten um den zentralen Suchbegriff darstellt und den Fokus beim Klick auf einen dieser Knoten auf diesen verlagert und weitere Knoten um diesen herum aufbaut.

                            Der Aufbau einer Navigation hat sich nach der Präsentation zu richten, so dass ein Kontext immer gegeben ist.

                            Ansonsten plädierst du dafür, die Präsentation bei der Auszeichnung zunächst zu ignorieren und die Auszeichnung an sich zu betrachten, wieso stellst du hier die Präsentation über alles und fragst nicht nach Semantik?

                            Nur kurz zur Begriffsklärung: Unter "Präsentation" verstehe ich "eine Präsentation", also eine bestimmte Anzahl zusammenhängender Dokumente. Was du als "die Präsentation" aufgefasst hast, bemühe ich mich, als "Darstellung" zu bezeichnen.

                            So findet man auf vielen Seiten eine entsprechend abgespeckte Version der Navigation mit einem zusätzlichen Verweis auf die Sitemap, die als Inhaltsverzeichnis ja per se einen Bezug zum Inhalt des Dokumentes hat.

                            Abgesehen davon, dass auch dies im Sinne des Ursprungsposting unsemantisch ist (krchch) und die link-Elemente die Navigation formalisieren könnten und damit das Problem der besagten »Interferenzen« lösen würden, halte ich es für einen alltagstauglichen/praktikablen Schritt, wenn die besonders relevanten Beziehungen herausgearbeitet werden. Davon, fast alle Navigationsbewegungen über reine Meta-Dokumente wie Sitemaps laufen zu lassen (Benutzer geht immer wieder zur Sitemap, zu einem Dokument, zur Sitemap, zur einem weiterem Dokument usw.), halte ich wiederum wenig.

                            Da sind wir uns einig.

                            Und eine übegreifende Navigation erweitert meines Erachtens lediglich diesen Kontext.

                            Sie verwischt den ursprünglichen Kontext m.E. vollkommen. Das Netzwerk konstituiert sich nicht in seinen Bestandteilen und deren Beziehungen mit Subjekten, Prädikaten (rel) und Objekten (href) bzw. umgekehrten Beziehungen, sondern nur in einem zentralen Metadokument.

                            Daher hatte ich von einem "zusätzlichen Verweis" gesprochen, der zum einen nicht die Meta-Angaben ersetzen soll und zum anderen ein ja auf ein in sich stimmiges Inhaltsverzeichnis als Gesamtdokument verweist, das in sich geschlossen funktioniert. MfG, at

              2. Hallo Cyx,

                Und für das Ausgangsposting des Thread bleibe ich bei dem konkreten
                Vorschlag sich Frames oder ggf. Iframes zu bedienen, um Interfrenzen zu
                vermeiden. Wär doch was nach dem XML-Hype Frames zu entdecken!

                Frames sind m.E. genau dasselbe, nur in ein anderes Dokument gezwängt. Die
                Aussage des Ausgangsposting war doch gerade, sich von der in den <body>
                gezwängten Navigationsstruktur loszusagen, dies zugunsten einer eventuell
                dem Dokument noch innewohnenden, aber nicht im Dokumentinhalt verwirklichten
                Navigation. Den letztendlich sind Navigationslinks nichts anderes als
                Metadaten.

                Tim

                1. Hallo Tim,

                  Und für das Ausgangsposting des Thread bleibe ich bei dem konkreten
                  Vorschlag sich Frames oder ggf. Iframes zu bedienen, um Interfrenzen zu
                  vermeiden. Wär doch was nach dem XML-Hype Frames zu entdecken!

                  Frames sind m.E. genau dasselbe, nur in ein anderes Dokument gezwängt. Die
                  Aussage des Ausgangsposting war doch gerade, sich von der in den <body>
                  gezwängten Navigationsstruktur loszusagen, dies zugunsten einer eventuell
                  dem Dokument noch innewohnenden, aber nicht im Dokumentinhalt verwirklichten
                  Navigation. Den letztendlich sind Navigationslinks nichts anderes als
                  Metadaten.

                  ein separates Dokument mit einem anderen Inhalt und z.B. dem <title> Sitemap hat ja Navigationslinks als stimmigen Inhalt.

                  Grüsse

                  Cyx23