nicht angemeldet
Gunnar Bittersmann
Der Martin
Gernot Back
Der Dicki
Gunnar Bittersmann
Tim Tepaße
Gunnar Bittersmann
molily
Gunnar Bittersmann
molily
Hi,
Wie würdet Ihr die Brotkrümel-Navigation (home → foo → bar →) auszeichenen?
Als Liste?
MudGuard<ol>
<li><a href="http://example.net/" rev="top">home</a></li>
<li><a href="http://example.net/foo/" rev="chapter">foo</a></li>
<li><a href="http://example.net/foo/bar/" rev="section up">bar</a></li>
</ol>
Oder findet Ihr, dass das nicht passt?
Live long and prosper,
Gunnar
Hallo Gunnar.
Wie würdet Ihr die Brotkrümel-Navigation (home → foo → bar →) auszeichenen?
Da eines der Unterpunkt des vorher gegangenen ist, als verschachtelte Liste, obgleich diese mit jeweils nur einem Listenpunkt etwas merkwürdig anmutet:
<ol>
<li><a href="http://example.net/" rev="top">home</a>
<ol>
<li><a href="http://example.net/foo/" rev="chapter">foo</a>
<ol>
<li><a href="http://example.net/foo/bar/" rev="section up">bar</a></li>
</ol>
</li>
</ol>
</li>
</ol>
Einen schönen Dienstag noch.
Gruß, Ashura
Hi,
Oder findet Ihr, dass das nicht passt?
IMHO perfekt. Ashuras Vorschlag halte ich für unangemessen, da es sich in der Tat um genau eine Liste der vorherigen (bzw. übergeordneten) Punkte handelt.
Cheatah
Hallo Cheatah.
IMHO perfekt. Ashuras Vorschlag halte ich für unangemessen, da es sich in der Tat um genau eine Liste der vorherigen (bzw. übergeordneten) Punkte handelt.
Und warum meinst du, dass hier eine verschachtelte Liste nicht geeignet ist?
Folgender Aufbau schreit ja geradezu danach:
Home
↳ Kapitel
↳ Sektion
↳ Untersektion
IMHO würde eine einfache Liste der Hierarchie nicht gerecht werden.
Einen schönen Dienstag noch.
Gruß, Ashura
Hi,
Und warum meinst du, dass hier eine verschachtelte Liste nicht geeignet ist?
weil es sich um _eine_ Liste handelt, nämlich die der Hauptpunkte.
Folgender Aufbau schreit ja geradezu danach:
Home
↳ Kapitel
↳ Sektion
↳ Untersektion
Nö. Die Breadcrumb-Navigation repräsentiert keine komplette Hierarchie, sondern nur die von einem Element ausgehenden Hauptpunkte. Es ist irrelevant, ob die selben Daten in einem anderen Kontext eine andere Struktur bilden können - hier werden nur die Navigationspunkte aufgelistet, die zu einem bestimmten Element führen. Mit anderen Worten:
IMHO würde eine einfache Liste der Hierarchie nicht gerecht werden.
Es existiert keine Hierarchie.
Cheatah
Hallo Cheatah.
IMHO würde eine einfache Liste der Hierarchie nicht gerecht werden.
Es existiert keine Hierarchie.
Ich verstehe deinen Einwand und akzeptiere ihn.
Doch ich denke auch, dass es von Gunnar's vorhandener Struktur abhängt, inwiefern dieser Trackback „dargestellt“ wird.
Einen schönen Dienstag noch.
Gruß, Ashura
Hi,
Doch ich denke auch, dass es von Gunnar's vorhandener Struktur abhängt, inwiefern dieser Trackback „dargestellt“ wird.
da hast Du allerdings auch Recht. Mir drängte sich anhand der Fragestellung eine Vermutung auf, die ich dann einfach als Tatsache vorausgesetzt habe.
Cheatah
Hi Cheatah,
Ashuras Vorschlag halte ich für unangemessen, da es sich in der Tat um genau eine Liste der vorherigen (bzw. übergeordneten) Punkte handelt.
Das sehe ich anders. Du wirst mir doch zustimmen, dass man die Gesamt-Navi als System von verschachtelten Listen auszeichnen könnte (sollte). Voraussetzung ist natürlich, dass die Navigation mehrstufig ist, aber wenn sie das nicht ist, sind ja auch die Breadcrumbs witzlos.
Und beim Breadcrumb Trail handelt es sich imho um einen ausgewählten Pfad aus dieser Listen- oder Baumstruktur. Deshalb finde ich es sinnvoll, diese Struktur, auch wenn sie nur auf einen Eintrag pro Ebene reduziert ist, grundsätzlich beizubehalten.
Im Interesse eines _übersichtlichen_ Markups wurde ich mich aber deiner Ansicht anschließen und nur aus rein pragmatischen Grunden wohl auch eine einfache Liste vorziehen.
So long,
Martin
Hi,
Das sehe ich anders. Du wirst mir doch zustimmen, dass man die Gesamt-Navi als System von verschachtelten Listen auszeichnen könnte (sollte).
ja, nur halte ich es nicht für zielführend, etwas anderes zu betrachten als das, was man gerade auszeichnen möchte.
Und beim Breadcrumb Trail handelt es sich imho um einen ausgewählten Pfad aus dieser Listen- oder Baumstruktur.
Eben. Um einen Pfad, nicht um den Baum. Das Ziel(!) der Breadcrumb-Navigation ist eine Informationsreduzierung, die zwangsläufig keine Rückführung mehr in die vorherige Struktur erlaubt. Oder würdest Du tatsächlich die gesamte Navigation mit <ol> auszeichnen?
Deshalb finde ich es sinnvoll, diese Struktur, auch wenn sie nur auf einen Eintrag pro Ebene reduziert ist, grundsätzlich beizubehalten.
Demnach wäre <ol> unangebracht. In einer Breadcrumb-Navigation ist es aber das ideale Element: Es wird eine Liste aufgeführt, deren Punkte nur in einer speziellen Reihenfolge Sinn machen.
Im Interesse eines _übersichtlichen_ Markups wurde ich mich aber deiner Ansicht anschließen und nur aus rein pragmatischen Grunden wohl auch eine einfache Liste vorziehen.
Nein, ein flaches <ol> ist hier tatsächlich dogmatisch, nicht pragmatisch.
Cheatah
Und beim Breadcrumb Trail handelt es sich imho um einen ausgewählten Pfad aus dieser Listen- oder Baumstruktur. Deshalb finde ich es sinnvoll, diese Struktur, auch wenn sie nur auf einen Eintrag pro Ebene reduziert ist, grundsätzlich beizubehalten.
IMHO handelt es sich um eine Liste von Brotkrümeln, die in einer bestimmten Reihenfolge fallengelassen wurden ;-) - SCNR
IMHO handelt es sich um eine Liste von Brotkrümeln, die in einer bestimmten Reihenfolge fallengelassen wurden ;-) - SCNR
… und von den Vögel in wahlloser Reihenfolge aufgepickt wurden ;-) - SCNR2
Hallo haensel,
IMHO handelt es sich um eine Liste von Brotkrümeln, die in einer bestimmten Reihenfolge fallengelassen wurden ;-) - SCNR
Du sollst Gretel nicht hänseln!
Gruß Gernot
Moin!
Wie würdet Ihr die Brotkrümel-Navigation (home → foo → bar →) auszeichenen?
<div id="breadcrumb"><a href="http://example.net/" rev="top">home</a> → <a href="http://example.net/foo/" rev="chapter">foo</a> → <a href="http://example.net/foo/bar/" rev="section up">bar</a></div>
- Sven Rautenberg
Hallihallo!
<... rev="top" ...>
Wenn ich da mal nachhaken dürfte:
Auf der Seite http://de.selfhtml.org/html/verweise/typisierte.htm#beziehung
habe ich mal nachgesehen, und jetzt stellen sich mir plötzlich wieder mehr Fragen als vorher:
1. Ist rev="top" erlaubt? Falls ja: auf der o.g. Selfseite fehlt es...
2. Sehe ich das richtig, daß das Attribut _rel_ Verweise auszeichnet, mit denen man "weiter in das Projekt reinkommt", und _rev_ diejenigen Verweise auszeichnet, mit denen man wieder "hochkommt" (mal in einer Baumstruktur gedacht)?
3. Falls (2) mit "ja" beantwortet: Macht gemäß http://de.selfhtml.org/html/kopfdaten/beziehungen.htm#quellen das Attribut rel="top" überhaupt Sinn, oder dürfte es nur rev="top" geben?
Ich finde die Geschichte mit den logischen Beziehungen ja klasse, und ich benutze sie auch gerne und konsequent, aber im Moment verwirren sie mich...
Viele liebe Grüße,
Der Dicki
Hi,
- Ist rev="top" erlaubt? Falls ja: auf der o.g. Selfseite fehlt es...
dort steht aber <link rel="top" title="SELFHTML" href="../../index.htm"> - was hier mMn auch deshalb sinnvoller ist, weil es von der Startseite keinen Verweis auf diese Unterseite gibt.
- Sehe ich das richtig, daß das Attribut _rel_ Verweise auszeichnet, mit denen man "weiter in das Projekt reinkommt", und _rev_ diejenigen Verweise auszeichnet, mit denen man wieder "hochkommt" (mal in einer Baumstruktur gedacht)?
nein. Es ist recht selten, daß link rev wirklich angebracht ist, weil zwei Dateien sich gegenseitig referenzieren. Außerdem ist link rev u.U. nicht in dem Maße nutzbar, wie link rel. In der LinkToolbar für Firefox funktioniert z.B. link rev="prev" nur i.V. mit link rev="next" - wenn man das mit link rel="next" kombiniert, ist es nicht mehr nutzbar. Aber für eine guided tout paßt link rev ohnehin nicht sonderlich.
freundliche Grüße
Ingo
Hallihallo!
Hmm,
Die beiden völlig verschiedenen Antworten einmal zugrundegelegt, scheint das link-Element mit seinen Attributen "rel" und "rev" also nicht nur mir (zumindest ein kleines) Problem zu sein.
Was ich jedoch aus dieser Diskussion gelernt habe:
1. Ich verzichte auf "rev", weil es eh keinen wirklichen Nutzen zu bringen scheint (oder merkt Google sich sowas?)
2. Ich muß wohl alle Attribute "top" ändern in "start" :(
BTW: Der W3C- Validator hat das Attribut "top" nie bemängelt.
Herzlichen Dank für die Antworten und viele liebe Grüße,
Der Dicki
Hi,
Die beiden völlig verschiedenen Antworten einmal zugrundegelegt, scheint das link-Element mit seinen Attributen "rel" und "rev" also nicht nur mir »» BTW: Der W3C- Validator hat das Attribut "top" nie bemängelt.
Die Attribute rel und rev sind vom Typ CDATA. top ist eine gültige CDATA-Zeichenfolge.
Der Validator KANN also rev="top" gar nicht bemängeln, da es keinen Mangel darstellt.
Evtl. an anderer Stelle existente, in der DTD nicht ausdrückbare, Einschränkungen für die zulässigen Attributwerte kann der Validator nicht überprüfen.
cu,
Andreas
Evtl. an anderer Stelle existente, in der DTD nicht ausdrückbare, Einschränkungen für die zulässigen Attributwerte kann der Validator nicht überprüfen.
Ja, Andreas,
Weshalb auch <td style="width: 500;"> [steffen] valides HTML ist. ;-)
YY
Live long and prosper,
Gunnar
Hi,
Ja, Andreas,
Weshalb auch<td style="width: 500;">[steffen] valides HTML ist. ;-)
Habe ich gegenteiliges behauptet?
cu,
Andreas
Hi MudGuard,
Habe ich gegenteiliges behauptet?
Nein. Wieso? Hat ich das behauptet? ;-)
Live long and prosper,
Gunnar
Hi Der,
(Na sowas, noch ein „Der“. ;-))
- Ist rev="top" erlaubt?
Ja. „Autoren könnten den Wunsch haben, zusätzliche Linktypen, die nicht in dieser Spezifikation beschrieben sind, zu definieren. Wenn dem so ist, sollten sie ein Profile benutzen (siehe Abschnitt 7), um die für die Definition des Linktyps verwendeten Konventionen anzuführen.“ [HTML401 §6.12]
Falls ja: auf der o.g. Selfseite fehlt es...
Ich hatte das "top" aus [SELFHTML: Logische Beziehungen]. Das scheint dort ein Fehler zu sein, "Top" taucht weder in [HTML401 §6.12] noch in [XHTML-MODULARIZATION] auf; dafür aber "Start", wie es auch in [SELFHTML: Typisierte Verweise] steht. Gleichmal in den BugTracker damit.
- Sehe ich das richtig, daß das Attribut _rel_ Verweise auszeichnet, mit denen man "weiter in das Projekt reinkommt", und _rev_ diejenigen Verweise auszeichnet, mit denen man wieder "hochkommt" (mal in einer Baumstruktur gedacht)?
Würd ich so sehen.
- Falls (2) mit "ja" beantwortet: Macht gemäß http://de.selfhtml.org/html/kopfdaten/beziehungen.htm#quellen das Attribut rel="top" überhaupt Sinn, oder dürfte es nur rev="top" geben?
rel="start" kann sich ja auf die Startseite einer anderen Website beziehen.
Live long and prosper,
Gunnar
Hi,
- Ist rev="top" erlaubt?
Ja. [...]
merken wir uns das mal...
Ich hatte das "top" aus [SELFHTML: Logische Beziehungen]. Das scheint dort ein Fehler zu sein,
nanu?
Gerade hattest Du nicht nur das Gegenteil gesagt, sondern das sogar mit einem Link belegt. Wenn man diesem weiter folgt ("In der DTD weist %LinkTypes auf eine durch Leerzeichen getrennte Liste von Linktypen.") bzw. gleich in der DTD vergleicht, findet man:
rel %LinkTypes; #IMPLIED -- forward link types --
rev %LinkTypes; #IMPLIED -- reverse link types --
<!ENTITY % LinkTypes "CDATA">
<!-- space-separated list of link types -->
Ich sehe hier in der Tat wie Mudguard keine solche Einschränkungen.
Die Auflistung der Attributwerte erhebt soweit ich sehe auch keinen Anspruch auf Vollständigkeit.
"Top" taucht weder in [HTML401 §6.12] noch in [XHTML-MODULARIZATION] auf; dafür aber "Start", wie es auch in [SELFHTML: Typisierte Verweise] steht. Gleichmal in den BugTracker damit.
Das hättest Du Dir sparen können. In Selfhtml steht:
"Folgende logische Bezüge können Sie angeben:" bzw.:
"Anerkannte Attributwerte sind:",
und das ist völlig korrekt. "Anerkannt" meint nicht "vom W3C explizit genannt", sondern "von Browsern umgesetzt" und damit nutzbar. Und das ist "top" tatsächlich. Hier im Forum z.B. wird mir für
<link rel="top" href="http://forum.de.selfhtml.org/my/" title="SELFHTML Forum" />
sowohl in der LinkToolbar für Firefox, als auch im Opera und Mozilla eine Schaltfläche angeboten; sie wird zwar mal als "Startseite", als "Anfang" oder "-^" bezeichnet, aber erfüllt ihren Zweck.
Es wäre daher falsch, diesen Wert in Selfhtml nicht zu nennen (und wie ich jetzt weiß, erhälst Du gleich Post vom Bugtracker ;-)
- Sehe ich das richtig, daß das Attribut _rel_ Verweise auszeichnet, mit denen man "weiter in das Projekt reinkommt", und _rev_ diejenigen Verweise auszeichnet, mit denen man wieder "hochkommt" (mal in einer Baumstruktur gedacht)?
Würd ich so sehen.
wie ich an anderer Stelle bereits angeführt habe, sehe ich das anders - und Selfhtml übrigens auch: http://de.selfhtml.org/html/kopfdaten/beziehungen.htm#rueck.
Und da wie gesagt für eine guided tour rel und rev gemixt Probleme ergeben kann, würde ich auf rev grundsätzlich verzichten.
rel ist ja auch grundsätzlich nie verkehrt. rel="prev" definiert das vorhergehende Dokument genauso wie rel="top" das oberste Dokument bezeichnen kann.
rel="start" kann sich ja auf die Startseite einer anderen Website beziehen.
genau wie rel="top", welches aber auch auf die Startseite oberhalb einer (quasi) verschachtelten Guided Tour hinweisen kann, für die "up" nicht ausreicht.
Und da hier praktische Erwägungen eine sehr große Rolle spielen:
Opera wertet rel="start" höher als rel="top", während Mozilla und die LinkToolbar beides gleichsetzt, also wie bei CSS dem Attribut Vorrang gibt, welches als letztes notiert wird.
freundliche Grüße
Ingo
Hi Ingo,
nanu?
Gerade hattest Du nicht nur das Gegenteil gesagt, sondern das sogar mit einem Link belegt.
Nana.
Wo auch – wie von mir zitiert und von dir unterschlagen – steht: „Wenn dem so ist, sollten sie ein Profile benutzen […], um die für die Definition des Linktyps verwendeten Konventionen anzuführen.“ Von einem solchen ist in SELFHTML nichts gesagt.
Wenn man diesem weiter folgt […] bzw. gleich in der DTD vergleicht, […]
Ich sehe hier in der Tat wie Mudguard keine solche Einschränkungen.
Andreas sagte auch: „Evtl. an anderer Stelle existente, in der DTD nicht ausdrückbare, Einschränkungen für die zulässigen Attributwerte kann der Validator nicht überprüfen.“
Für mich liest sich die Spec so, dass man die vorgegebenen Werte verwenden sollte oder wenn man eigene verwendet, diese deklarieren sollte. (Und ja, SOLLTE heißt nicht MUSS.)
"Anerkannt" meint nicht "vom W3C explizit genannt", sondern "von Browsern umgesetzt" und damit nutzbar.
Mit dem Argument könnte ja auch ein HTML-Wanna-be wie marquee in SELFHTML aufgeführt werden. Oh, wird ja auch. ;-)
Es wäre daher falsch, diesen Wert in Selfhtml nicht zu nennen (und wie ich jetzt weiß, erhälst Du gleich Post vom Bugtracker ;-)
Es ist aber IMHO falsch, dass [SELFHTML: Logische Beziehungen] und [SELFHTML: Typisierte Verweise] da nicht konsistent sind. Dann sollte auf beiden Seiten "start" und "top" erwähnt werden. Und wie ich jetzt weiß, erhält der Bugtracker nochmal Post von mir ;-)
Live long and prosper,
Gunnar
Hi,
Für mich liest sich die Spec so, dass man die vorgegebenen Werte verwenden sollte oder wenn man eigene verwendet, diese deklarieren sollte. (Und ja, SOLLTE heißt nicht MUSS.)
und das ist der springende Punkt, besonders wenn sich eine Interpretation bereits bei den UserAgents durchgesetzt hat.
Es ist aber IMHO falsch, dass [SELFHTML: Logische Beziehungen] und [SELFHTML: Typisierte Verweise] da nicht konsistent sind. Dann sollte auf beiden Seiten "start" und "top" erwähnt werden. Und wie ich jetzt weiß, erhält der Bugtracker nochmal Post von mir ;-)
hehe, da magst Du recht haben und das liegt wohl daran, daß die Erklärung zum link-Element erweitert wurde. Allerdings ist eine völlige Deckungsgleichheit auch nicht sinnvoll - rel="stylesheet" z.B. sollte nur beim link-Element erwähnt werden.
freundliche Grüße
Ingo
Wie würdet Ihr die Brotkrümel-Navigation (home → foo → bar →) auszeichenen?
Als Liste?
nein.
Oder findet Ihr, dass das nicht passt?
ja.
Gruß, Andreas
Hallo Gunnar,
Wie würdet Ihr die Brotkrümel-Navigation (home → foo → bar →) auszeichenen? Als Liste?
Nein. Wenn Du im Archiv recherchierst, habe ich mich in den letzten Jahren öfters gegen den Listenwahnsinn (aufgekommen seit dem Taming Lists Artikel bei A List Apart) ausgesprochen, so z.B. in diversen Diskussionen mit at. Warum? Im wesentlichen ist das eine pragmatische Einstellung, die sich auf die Frage „Welche Vorteile und welche Nachteile habe ich durch diese Form recht stringenter Auszeichnung“ zurückführen läßt.
Für horizontale Menüs und insbesondere für Breadcrump Trails finde ich diese Art der Auszeichnung, in der Extremvariante von Ashura, einfach überkandidelt. Ich gebe gerne zu, dass sie strukturell vielleicht korrekter ist, als die einfache Lösung von Sven, wobei man da auch streiten kann.
Nachteile sind für mich vor allem die Darstellung in aktuellen Browsern, wenn die Formatierungsmöglichkeiten von CSS nicht vorhanden sind. Das sind zum Beispiel Textbrowser, in denen Listen immer mit einem Listenzeichen dargestellt werden, aber auch Screenreader, die meiner Erinnerung nach Listen als solche vorlesen. Dazu kommen noch kaputte Browser wie Netscape 4 oder IE-Versionen; es ist ja neuerdings Mode, CSS vor denen komplett zu verstecken.
Otto Normalnutzer hat dann anstatt einer Lösung, die auch im worst case skaliert, les- und verstehbar ist („graceful degradation“), eine für ihn möglicherweise verwirrende Textstruktur, das Abstraktionsvermögen von Liste bzw. verschachtelter Liste zu Brotkrümelpfad hat nicht jeder, ich würde sogar bestreiten, dass es ausser in informatik-affinen Kreisen wirklich verbreitet ist. Dagegen wird die reine Textlösung wohl noch von den meisten verstanden.
Und Vorteile? Außer sich im sonnigen Gefühl baden zu können, „richtig“ strukturiert zu haben, eigentlich keines. Aus CSS-Sicht kann man eine Lösung, wie Sven sie vorgeschlagen hat, ebenso formatieren wie die Listenlösung, sogar noch einfach, da man auf das immer noch etwas schwierige Verändern des Box-Modells oder Float verzichten kann. Jedes Element ist durch einen Selektor erreichbar:
<p id="breadcrumptrail"><a href="http://example.net/">home</a><span class="divider"> → </span><a href="http://example.net/foo/">foo</a><span class="divider"> → </span><a href="http://example.net/foo/bar/" rev="section up">bar</a></p>
Eventuell sollte man sogar noch überlegen, die Unicode-Pfeile durch ASCII-Art zu ersetzen, ich bin immer wieder überrascht, wie viele Zeichen, die ich selbstverständlich verwende, unter anderen Systemen nicht angezeigt werden – ein Armutszeugnis für das Jahr 2005.
Langfristig fände ich es natürlich auch toller, entsprechende Strukturen zu haben, z.B. das NL-Element in XHTML 2, wenn es denn im aktuellen WD noch existiert. Aber ich träume ja auch noch von einem Browser, der den CSS Media Typ tty versteht. Man wird sehen. Derzeit halte ich strukturell korrekte Auszeichnung für unnötig – oder kennt jemand UAs, die sich wirklich für die tiefgehende Struktur der Webseite interessieren, also nicht nur Überschriften und Links wie z.B. GoogleBot?
Tim
Eventuell sollte man sogar noch überlegen, die Unicode-Pfeile durch ASCII-Art zu ersetzen,
Hi Tim,
Mit dem gleichen Argument könnte man auch noch den Verzicht auf Umlaute und die Beschränkung auf ASCII fordern. ;-)
ein Armutszeugnis für das Jahr 2005.
Yep.
Die Auszeichnung als Liste hätte die Folge, dass man den Trenner gar nicht im HTML hat, sondern im CSS. Oops, gab’s da nicht Browser, die das nicht können? Gibt’s die immer noch? ;-/
Langfristig fände ich es natürlich auch toller, entsprechende Strukturen zu haben, z.B. das NL-Element in XHTML 2,
Ja.
Für die Brotkrümel sollten eigentlich auch die vorhandenen ausreichen: die link-Elemente im head. Dann müsste man das alles nicht doppelt angeben.
Nur dumm, dass die Brotkrümel dann ganz zum Anfang auf der Seite stehen müssten (ich denke, durch eine Positionierung woandershin handelt man sich haufenweise Probleme ein). Und oops, gab’s da nicht … (s.o.)
Live long and prosper,
Gunnar
z.B. das NL-Element in XHTML 2,
Ja.
Äh, nein: XHTML ist case-sensitiv. ;-)
Live long and prosper,
Gunnar
Hi,
Für die Brotkrümel sollten eigentlich auch die vorhandenen ausreichen: die link-Elemente im head. Dann müsste man das alles nicht doppelt angeben.
Dagegen hab ich mal eine Lösung: Ein JavaScript liest die entsprechenden link-Elemente aus dem head und baut sie als Breadcrumb-Navigation ins Dokument ein. (MudGuards Script aus </archiv/2005/7/t111494/> hat mir dabei einige Denkarbeit erspart. ;-))
Ohne JavaScript erscheinen die Brotkrümel durch CSS an den Beginn der Seite gesetzt, jedenfalls in Browsern[tm].
http://gunnarbittersmann.de/2005/breadcrumbs-20050721.html
Dass Nutzer des IE ohne JavaScript sowie Nutzer, die JavaScript und CSS deaktiviert haben bzw. mein Stylesheet ersetzen, keine Breadcrumb-Navigation zu sehen bekommen, macht die Verwendung doch etwas problematisch.
Was denkt Ihr?
Live long and prosper,
Gunnar
Hi,
Wie mir MudGuard gerade in https://forum.selfhtml.org/?t=111849&m=705511 weißmachte, darf noscript kein Kind von head sein.
Da fällt mir grad nichts zu ein. Außer doch öfter mal den Validator zu bemühen. ;-)
Live long and prosper,
Gunnar
Da fällt mir grad nichts zu ein.
Ähm, jetzt doch. War noch’n bisschen früh vorhin. ;-)
style ganz normal im head, Änderung im JavaScript. Berichtigung unter http://gunnarbittersmann.de/2005/breadcrumbs-20050722.html
Live long and prosper,
Gunnar
PS. Übrigens bekommt man einen noscript-Bereich doch in den head:
<head>
…
<object>
<noscript>
…
</noscript>
</object>
</head>
Was sagen wir denn dazu, Mr. DTD? ;-)
Allerdings dürfen in noscript weder style- noch meta-Elemente auftauchen.
Hallotrio,
Wie würdet Ihr die Brotkrümel-Navigation (home → foo → bar →) auszeichenen?
home -> foo -> bar
Als Liste?
Wo ist das denn eine Liste? Nehmen wir mal saemtliche Formatierung raus (i.e CSS ausgeschaltet), was bleibt dann? Das hier:
Daraus kann ich nur mit viel Muehe eine Brotkruemel-Navigations-"Hierarchie" oder Abfolge erkennen die doch eine Brotkruemel-Navigation auszeichnet.
Da sind saemtliche Elemente der Liste in gewissem Sinne gleichwertig. Es ist eine Aufzaehlung, aus der ich aber nicht automatisch erkenne dass dies in genau der Abfolge "abzuarbeiten" ist.
Vielleicht fuer die Techies und Semantik-Struktur-Fetischisten hier, aber nicht fuer den "Normalbuerger" der wenn er Pech hat ueber so etwas stolpert.
Oft werden "geordnete Listen" einfach nur benutzt um darzustellen wieviele Elemente eine Liste hat, die Elemente sind nicht notwendigerweise unterschiedlich "wertvoll" oder nur in der Ordnung vorstellbar.
Ob das nun richtig oder falsch ist, ist hier irrelevant, wichtig ist wie sie tatsaechlich benutzt werden und was das fuer Auswirkungen hat.
Oder findet Ihr, dass das nicht passt?
Viel schlimmer, ich halte es fuer potentiell irrefuehrend.
Live long and prosper,
Hi Armin,
home -> foo -> bar
Iiiigitt! ;-)
Dann schon lieber home <img src="http://example.net/rarr" alt="->"> foo <img src="http://example.net/rarr" alt="->"> bar
Wo ist das denn eine Liste?
Ist IMHO schon eine, wie auch [Cheatah] und [haensel] ;-) zustimmten.
Nehmen wir mal saemtliche Formatierung raus (i.e CSS ausgeschaltet), was bleibt dann? Das hier:
- home
- foo
- bar
Das Argument gegen die Auszeichnung als Liste ist aber nicht von der Hand zu weisen.
Live long and prosper,
Gunnar
Huhu,
Dann schon lieber
home <img src="http://example.net/rarr" alt="->"> foo <img src="http://example.net/rarr" alt="->"> bar
Von mir aus. Vor allem weil das wie schon von Herrn Tepasse angemerkt auch die Systeme/Browser anzeigen koennen die den Font mit den Pfeilen nicht vorraetig haben.
Bleiben natuerlich Screenreader und aehnliches, keine Ahnung wie die mit dem ganzen umgehen, egal welche Methode angewandt wird.
Das Argument gegen die Auszeichnung als Liste ist aber nicht von der Hand zu weisen.
Dann bin ich ja beruhigt ;-)
Live long and prosper,
Hi,
Bleiben natuerlich Screenreader und aehnliches, keine Ahnung wie die mit dem ganzen umgehen, egal welche Methode angewandt wird.
nunja, ob die nun "Link:foo Minus GrößerAls, ..." oder "Link:foo Bild:GrößerAls, ..." vorlesen - beides fände ich unschöner als "Liste: 1.: Link: foo, ..." ;-)
freundliche Grüße
Ingo
Hallo,
Bleiben natuerlich Screenreader und aehnliches, keine Ahnung wie die mit dem ganzen umgehen, egal welche Methode angewandt wird.
nunja, ob die nun "Link:foo Minus GrößerAls, ..." oder "Link:foo Bild:GrößerAls, ..." vorlesen - beides fände ich unschöner als "Liste: 1.: Link: foo, ..." ;-)
Deswegen ist für Screenreaderbenutzer <img alt="Unterrubrik:"> oder ähnliches um Längen sinnvoller als eine ol-Liste, →, -> oder <img alt="->">.
Mathias
home → foo → bar →
home -> foo -> bar
home <img src="http://example.net/rarr" alt="->"> foo <img src="http://example.net/rarr" alt="->"> bar
Von mir aus. Vor allem weil das wie schon von Herrn Tepasse angemerkt auch die Systeme/Browser anzeigen koennen die den Font mit den Pfeilen nicht vorraetig haben.
Nochmal überlegt: Na und? Dann erscheint halt statt → ein Rechteck oder ein ? als Trenner; sieht auch nicht blöder aus als -> und erfüllt auch die Funktion, dass home, foo und bar nicht aneinander kleben.
Live long and prosper,
Gunnar
Hallo,
home → foo → bar →
home -> foo -> bar
home <img src="http://example.net/rarr" alt="->"> foo <img src="http://example.net/rarr" alt="->"> bar
Von mir aus. Vor allem weil das wie schon von Herrn Tepasse angemerkt auch die Systeme/Browser anzeigen koennen die den Font mit den Pfeilen nicht vorraetig haben.Nochmal überlegt: Na und? Dann erscheint halt statt → ein Rechteck oder ein ? als Trenner; sieht auch nicht blöder aus als -> und erfüllt auch die Funktion, dass home, foo und bar nicht aneinander kleben.
Nix »na und«. Die Funktion ist eben, zu kommunizieren, dass es sich bei dem folgenden Link um eine Unterrubrik handelt.
Und nein, ein Rechteck (was Screenreader m.W. dann nicht vorlesen) oder gar ein Fragezeichen erfüllen diese Funktion nicht.
Ein Blinder kann die Funktion aus > oder -> noch am ehesten schließen, weil er dies als ASCII-Pfeil erkennt und die Bedeutung in diesem Kontext versteht (»darunter liegt: ...«).
→ und Co. hatte ich mal mit JAWS getestet, wenn ich mich richtig erinnere, ignoriert er das Zeichen standardmäßig.
Mathias