molily: Zu Navigationsleisten und deren Umsetzung

Beitrag lesen

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.

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