<ul> versa <dl>
0 0 0 
Matthias Apsel
0 0 
molily
1 molily
2 
Gunnar Bittersmann
0 0 0 <ul> versa <dl>. Ist <a> das Problem?
0 Matthias Apsel
0 0
<ul> versa <dl>
Hello,
ich möchte eine Übersicht über eine Fotogalerie erstellen, wobei jedes dargestellte Element einen Hyperlink auf die jeweilige Galerie darstellt.
1. Entwicklungsstufe war es nur eine textuelle <ul><li> liste... Kein Problem
2. Entwicklungsstufe: anstelle des textlichen Inhaltes des Links sollte ein
Bild erscheinen <a><img></a>
3. nun soll das Bild aber auch eine Unterschrift bekommen
4. und wenn es ganz wild wird, soll rechts neben dem Bild noch ein Beschreibungstext
erscheinen.
Wie bekomme ich das am saubersten hin?
Dieser Versuch hier ist jedenfalls ungeeignet und das zugehörige CSS war inzwischen so verbastelt, dass ich es gelöscht habe ;-O
<ul class="vertical-linklist">
<li><a href="/gallery/?cmd=show&gal=101"><dl class="imgLeft">
<dt><img src="/gallery/101.gal/100.jpg" alt="Übersicht" title="Übersicht" style="<!--STYLE-->"></dt>
<dd>Bilder für Biker</dd>
</dl></a></li>
<li><a href="/gallery/?cmd=show&gal=110"><dl class="imgLeft">
<dt><img src="/gallery/110.gal/120100.jpg" alt="Gelände" title="Gelände" style="<!--STYLE-->"></dt>
<dd>Das Freigelände - Morgenstimmung</dd>
</dl></a></li>
<li><a href="/gallery/?cmd=show&gal=120"><dl class="imgLeft">
<dt><img src="/gallery/120.gal/120120.jpg" alt="Häuser" title="Häuser" style="<!--STYLE-->"></dt>
<dd>Pläne der Häuser</dd>
</dl></a></li>
<li><a href="/gallery/?cmd=show&gal=130"><dl class="imgLeft">
<dt><img src="/gallery/130.gal/104.jpg" alt="Partytime" title="Partytime" style="<!--STYLE-->"></dt>
<dd>Party-Stimmung im Bkockhaus</dd>
</dl></a></li>
</ul>
Ist <dl> nun eigentlich eine Alternative für <ul>, oder brauche ich beide? Jedenfalls darf man es laut SelfHTML innerhalb <li> benutzten...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
die ul- und dl-Elemente haben semantisch unterschiedliche Bedeutungen.
Für Bilder und zugehörigen Text sind figure und figcaption die korrekten Elemente.
Gruss
MrMurphy
-
Hello,
die ul- und dl-Elemente haben semantisch unterschiedliche Bedeutungen.
Ja, danke. Das ist mir irgendwie nebulös auch schon so vorgekommen *tztz*
Gunnar hat auch schon wieder viel neuen Stoff für mich in den Thread geworfen. Da muss ich erstmal wieder lesen...
Für Bilder und zugehörigen Text sind figure und figcaption die korrekten Elemente.
Meine urprüngliche (implizite) Frage, ob die Schachtelung von <ul> und <dl> überhaupt sinnvoll ist, ist damit leider noch nicht erschöpfend beantwortet.
Welche von beiden Auszeichnungen wäre denn für die vorgesehene Anwendung (Bild, Unterschrift, Beschreibungstext, weiterführender Link ausgehend vom der gesamten Elementegruppe), das Ganze in Wiederholung (also Liste) der richtige?
Alternativ würde man ja einfach eine Tabelle benutzen und die gesamte <tr> als Link benutzten, wie auch immer :-))
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Om nah hoo pez nyeetz, Tom!
Meine urprüngliche (implizite) Frage, ob die Schachtelung von <ul> und <dl> überhaupt sinnvoll ist, ist damit leider noch nicht erschöpfend beantwortet.
Ich würde Gunnars Konstruktion in eine ungeordnete Liste stecken.
Matthias
-
Om nah hoo pez nyeetz, Matthias und Tom!
Meine urprüngliche (implizite) Frage, ob die Schachtelung von <ul> und <dl> überhaupt sinnvoll ist, ist damit leider noch nicht erschöpfend beantwortet.
Um deine Frage dann mal explizit zu beantworten:
Ich halte im vorliegenden Fall die Verwendung einer <dl> für "falsch". Ebenso die einer <ul>. Insofern stellt sich die Frage nach der Schachtelung ja nicht mehr, aber die wäre imho ebenso falsch!Ich würde Gunnars Konstruktion in eine ungeordnete Liste stecken.
Warum?
Irgendwie neigt jeder dazu, alles was mehr als genau einmal vorkommt in eine "Liste" stecken zu wollen.Jedes Bild "symbolisiert" jeweils eine eigene Fotogalerie und ggf. enthält die Bildunterschrift dann noch den Namen der Galerie sowie einen beschreibenden Text.
Das bedeutet, dass jeder dieser "Blöcke"
- für sich alleine stehen kann (ohne dass der Sinn & Zweck verloren geht)
- er keinerlei "Beziehung" zu etwaigen anderen Blöcken hat
Daraus ergibt sich für mich, dass eine "Zusammenfassung/ Gruppierung" hier aus semantischer Sicht nicht angebracht ist.
Der hier vorliegende Fall ist für mich einer, wo "weniger mehr ist".
Und selbst wenn man es unter dem Layout Gesichtspunkt betrachtet, sehe ich keine Notwendigkeit, hier noch zusätzlich irgendeine "Liste" zu verwenden.
Gruß Gunther
-
Hallo,
Irgendwie neigt jeder dazu, alles was mehr als genau einmal vorkommt in eine "Liste" stecken zu wollen.
Listen sind erst einmal nichts anderes als (meist) geordnete Mengen von gleichartigen Informationen.
Jedes Bild "symbolisiert" jeweils eine eigene Fotogalerie und ggf. enthält die Bildunterschrift dann noch den Namen der Galerie sowie einen beschreibenden Text.
Das bedeutet, dass jeder dieser "Blöcke"
- für sich alleine stehen kann (ohne dass der Sinn & Zweck verloren geht)
- er keinerlei "Beziehung" zu etwaigen anderen Blöcken hat
Daraus ergibt sich für mich, dass eine "Zusammenfassung/ Gruppierung" hier aus semantischer Sicht nicht angebracht ist.
Dem kann ich nicht folgen. Ein anderes Beispiel:
<nav> <ul> <li><a href="http://forum.de.selfhtml.org">Forum</a></li> <li><a href="http://de.selfhtml.org">Doku</a></li> <li><a href="http://wiki.selfhtml.org">Wiki</a></li> <li><a href="http://blog.selfhtml.org">Blog</a></li> </ul> </nav>Dies ist eine Liste von Links.
- Jeder Link kann für sich alleine stehen, ohne dass der Sinn verloren geht.
- Ein einzelner Link hat keine notwendige »Beziehung« zu den anderen Links. Es gibt auch keine bedeutungsvolle Ordnung im Sinne von Reihenfolge.
Trotzdem haben die Links etwas gemeinsam. Es sind gleichförmige Kurz-Links zu Teilen von SELFHTML. Deshalb gruppiere ich sie in eine Liste.
Wenn ich also eine Liste mit Links zu Bildergalerien habe – so können diese natürlich alleine stehen. Aber was haben sie gemeinsam?
Inhaltlich: Es sind z.B. alle Fotografien, die ich letztes Jahr geschossen habe, gruppiert in Alben nach Orten/Anlässen. Es ist in aller Regel keine willkürliche Zusammenstellung mit französischen Felszeichnungen, chinesischen Ming-Vasen, Fotos von süßen Hundebabys sowie Marlboro-Werbeplakaten.
Strukturell: Es sind alles gleichförmige Links mit gleichförmigen Cover-Bildern, einem kurzen Titel und einer optionalen Beschreibung. Die Markup-Struktur wiederholt sich also immer wieder (siehe Gunnars Beispiel). Sinn der Sache ist, einen kurzen, eventuell chronologischen Überblick zu geben.
Es ist nützlich, diese Auflistung auch als Liste auszuzeichnen. Mit dem ul/ol markiere ich, dass hier eine Auflisung gleichartiger Informationen kommt. Mit li zeichne ich Anfang und Ende eines Eintrags aus. Das bietet nicht nur CSS-Angriffspunkte und eine klare Datenstruktur, die z.B. mit DOM Scripting eindeutig verarbeitet werden kann. Es erlaubt User-Agents auch eine komfortable Navigation zwischen den Einträgen. Ein Screenreader kann z.B. ausgeben: »Liste mit 10 Einträgen«.
Ausgehend von Gunnars Beispiel mit a, figure und figcaption: Welche Auszeichnung würdest du auf der Makro-Ebene benutzen? Direkt a-Elemente aneinander reihen? Oder sie in p-Elemente schachteln?
Mathias
-
@@molily:
nuqneH
geordnete Mengen
Was ist das für ein Lärm? Oh, der Cantor dreht sich im Grab um.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Was ist das für ein Lärm?
Dito.
Oh, der Cantor dreht sich im Grab um.
Ich spreche hier nicht in mathematisch-logisch korrekten Termini, wie du dir denken kannst.
Mathias
-
@@molily:
nuqneH
Ich spreche hier nicht in mathematisch-logisch korrekten Termini, wie du dir denken kannst.
Ich spreche hier nicht in smileyfreien Termini, wie du dir denken kannst.
Auch wenn Smileys machmal implizit sind. Explizite oder gar „SCNR“ würden doch aber manchem Posting den Witz nehmen.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)-
Om nah hoo pez nyeetz, Gunnar Bittersmann & molily!
Ich spreche hier nicht in mathematisch-logisch korrekten Termini, wie du dir denken kannst.
Ich spreche hier nicht in smileyfreien Termini, wie du dir denken kannst.
Auch wenn Smileys machmal implizit sind. Explizite oder gar „SCNR“ würden doch aber manchem Posting den Witz nehmen.Zumal auch noch der Adressat eine Rolle spielt. Ich habe das durchaus als schmunzel-würdig empfunden, was, wenn der Adressat ein unbekannter Poster gewesen wäre, nicht der Fall wäre.
Matthias
-
-
-
-
Hallo,
Irgendwie neigt jeder dazu, alles was mehr als genau einmal vorkommt in eine "Liste" stecken zu wollen.
Listen sind erst einmal nichts anderes als (meist) geordnete Mengen von gleichartigen Informationen.
Das sehe ich anders, und zwar in dem Punkt, dass es eben nicht um "gleichartig", sondern vielmehr um "zusammengehörend" geht.
Jedes Bild "symbolisiert" jeweils eine eigene Fotogalerie und ggf. enthält die Bildunterschrift dann noch den Namen der Galerie sowie einen beschreibenden Text.
Das bedeutet, dass jeder dieser "Blöcke"
- für sich alleine stehen kann (ohne dass der Sinn & Zweck verloren geht)
- er keinerlei "Beziehung" zu etwaigen anderen Blöcken hat
Daraus ergibt sich für mich, dass eine "Zusammenfassung/ Gruppierung" hier aus semantischer Sicht nicht angebracht ist.
Dem kann ich nicht folgen. Ein anderes Beispiel:
<nav>
<ul>
<li><a href="http://forum.de.selfhtml.org">Forum</a></li>
<li><a href="http://de.selfhtml.org">Doku</a></li>
<li><a href="http://wiki.selfhtml.org">Wiki</a></li>
<li><a href="http://blog.selfhtml.org">Blog</a></li>
</ul>
</nav>Genau auf dieses Beispiel habe ich gewartet, bzw. damit gerechnet, dass es kommt. ;-) Mal davon abgesehen, dass es imho eine bis heute andauernde Unzulänglichkeit von HTML ist, dass es kein "vernünftiges/ brauchbares" Element dafür gibt (Stichwort <menu>), ist die Verwendung einer ungeordneten Liste für diesen Zweck also eher eine "historisch gewachsene Behelfslösung", als eine semantisch korrekte Auszeichnung. > Dies ist eine Liste von Links. > > - Jeder Link kann für sich alleine stehen, ohne dass der Sinn verloren geht. > - Ein einzelner Link hat keine notwendige »Beziehung« zu den anderen Links. Es gibt auch keine bedeutungsvolle Ordnung im Sinne von Reihenfolge. > > Trotzdem haben die Links etwas gemeinsam. Es sind gleichförmige Kurz-Links zu Teilen von SELFHTML. Deshalb gruppiere ich sie in eine Liste. Das kannst du ja auch gerne machen. Deshalb muss es aber semantisch gesehen noch lange nicht "die (einzig) richtige" Variante sein. Denn nach dieser Argumentation könntest/ müsstest die ja bspw. auch die Artikelübersicht auf der Blog Startseite (<http://blog.selfhtml.org/>) in eine Liste packen! Da jeder dieser Links zu einem "eigenständigen" Teil von SELFHTML verlinkt, sie also keine hierarchische Reihe bilden, wäre die Anordnung der Links ohne Listenelement innerhalb des Nav Elements aus meiner Sicht genauso möglich. > Wenn ich also eine Liste mit Links zu Bildergalerien habe – so können diese natürlich alleine stehen. Aber was haben sie gemeinsam? > > Inhaltlich: Es sind z.B. alle Fotografien, die ich letztes Jahr geschossen habe, gruppiert in Alben nach Orten/Anlässen. Es ist in aller Regel keine willkürliche Zusammenstellung mit französischen Felszeichnungen, chinesischen Ming-Vasen, Fotos von süßen Hundebabys sowie Marlboro-Werbeplakaten. > > Strukturell: Es sind alles gleichförmige Links mit gleichförmigen Cover-Bildern, einem kurzen Titel und einer optionalen Beschreibung. Die Markup-Struktur wiederholt sich also immer wieder (siehe Gunnars Beispiel). Sinn der Sache ist, einen kurzen, eventuell chronologischen Überblick zu geben. Kleine Anmerkung: Bei einer "chronologischen" Reihenfolge wäre eine ungeordnete Liste aber eh verkehrt, da die Spec eindeutig aussagt:"The ul element represents a list of items, where the order of the items is not important" (Quelle: <http://www.w3.org/TR/2010/WD-html5-20100624/grouping-content.html#the-ul-element>) > Es ist nützlich, diese Auflistung auch als Liste auszuzeichnen. Mit dem ul/ol markiere ich, dass hier eine Auflisung gleichartiger Informationen kommt. Mit li zeichne ich Anfang und Ende eines Eintrags aus. Das bietet nicht nur CSS-Angriffspunkte und eine klare Datenstruktur, die z.B. mit DOM Scripting eindeutig verarbeitet werden kann. Es erlaubt User-Agents auch eine komfortable Navigation zwischen den Einträgen. Ein Screenreader kann z.B. ausgeben: »Liste mit 10 Einträgen«. Die Argumente mit dem "CSS-Angriffspunkt" und dem "DOM Scripting" greifen ja nicht wirklich. Beides ist in jedem anderen Fall genauso möglich (und selbst wenn nicht, gäbe es dafür die "inhaltslosen" Elemente <div> und <span>). Auch der Punkt mit der "komfortablen Navigation" ist weder ein Grund, noch ein Argument für die Verwendung einer Liste! Denn über Links ließ sich schon immer sehr komfortabel bspw. per Tastatur navigieren. Und auch der letzte Punkt, assoziative Techniken betreffend, ist kein Argument. Hier gibt es durchaus andere Möglichkeiten (Stichwort: "visually hidden"). Wenn ich keinen Punkt übersehen habe, dann waren das alle. Und keiner rechtfertigt aus meiner Sicht die Verwendung einer Liste. > Ausgehend von [Gunnars Beispiel](https://forum.selfhtml.org/?t=216350&m=1483274) mit a, figure und figcaption: Welche Auszeichnung würdest du auf der Makro-Ebene benutzen? Direkt a-Elemente aneinander reihen? Oder sie in p-Elemente schachteln? Das kommt wie immer "darauf an". Wenn ich Tom richtig verstanden habe in seinem Ausgangsposting, dann ist diese Galerie-Übersicht quasi der Hauptinhalt (der einzige Inhalt?) dieser Seite. Dann wäre bspw. auch die Verwendung von <section> für jede Fotogalerie denkbar (ggf. jeweils mit <header> und <footer>. Und wenn z.B. auch noch Meta-Daten zu der jeweiligen Galerie mit hinzukommen sollen, dann kann dafür wiederum eine <dl> durchaus semnatisch korrekt und angebracht sein. Denn mal von der Präsentation abgesehen, könnte man nach deiner Ansicht/ Argumentation ja auch gleich eine Tabelle (für jede Galerie eine Zeile) nehmen. Natürlich ist es bei mehrfachem Vorliegen "gleichartiger" "Objekte/Elemente" immer schwierig \_gegen\_die Verwendung einer (ungeordneten) Liste zu argumentieren, weil es leicht ist, Begründungen dafür zu finden, warum eine Liste angebracht sei. Und dennoch halte ich oftmals die Verwendung einer solchen Liste zumindest für "überflüssig" und semantisch eher für falsch, da dadurch eine "Verbindung" zwischen "Objekten/Elementen" hergestellt wird, die tatsächlich gar nicht gegeben ist. Im konkreten Fall kommt es also maßgeblich darauf an, als für wie "einzelständig" man die Galerien ansieht? Und ich sehe die halt als vollkommen unabhängig voneinander an, und somit auch von der Semantik her keinerlei Notwendigkeit, diese in irgendeiner Form als "zusammengehörig" zu kennzeichnen. Gruß Gunther-
Hallo,
Mal davon abgesehen, dass es imho eine bis heute andauernde Unzulänglichkeit von HTML ist, dass es kein "vernünftiges/ brauchbares" Element dafür gibt (Stichwort <menu>),
Inwiefern wäre ein menu-Element besser?
ist die Verwendung einer ungeordneten Liste für diesen Zweck also eher eine "historisch gewachsene Behelfslösung", als eine semantisch korrekte Auszeichnung.
Aha. Was ist daran nicht korekt?
Das kannst du ja auch gerne machen. Deshalb muss es aber semantisch gesehen noch lange nicht "die (einzig) richtige" Variante sein.
Ja. Man darf gerne Gegenargumente formulieren.
Denn nach dieser Argumentation könntest/ müsstest die ja bspw. auch die Artikelübersicht auf der Blog Startseite (http://blog.selfhtml.org/) in eine Liste packen!
Ich habe damit gerechnet, dass dieser Einwand kommt. ;) Und habe deshalb https://forum.selfhtml.org/?t=216350&m=1483355 geschrieben.
Um das zusammenzufassen: Ja, man könnte es in eine Liste packen – man muss und sollte es aber nicht, da ein Dokument auf der obersten Ebene aus Sections besteht, welche per definitionem gleichförmig sind und in einer Abfolge stehen. Die korrekte Auszeichnung auf dieser Ebene sind also Sectioning-Elemente. Im Falle von blog.selfhtml.org: aufeinander folgende article-Elemente.
Da jeder dieser Links zu einem "eigenständigen" Teil von SELFHTML verlinkt, sie also keine hierarchische Reihe bilden,
Was ist eine »hierarchische Reihe«? Eine ungeordnete Liste erfordert keine Hierarchie.
wäre die Anordnung der Links ohne Listenelement innerhalb des Nav Elements aus meiner Sicht genauso möglich.
So etwa?
<nav> <a>…</a> <a>…</a> <a>…</a> </nav>Wo sind dann deiner Meinung nach Listen überhaupt noch angebracht? ;)
Kleine Anmerkung: Bei einer "chronologischen" Reihenfolge wäre eine ungeordnete Liste aber eh verkehrt
Ja. Ich wollte nichts gegenteiliges behaupten.
Die Argumente mit dem "CSS-Angriffspunkt" und dem "DOM Scripting" greifen ja nicht wirklich. Beides ist in jedem anderen Fall genauso möglich (und selbst wenn nicht, gäbe es dafür die "inhaltslosen" Elemente <div> und <span>).
Ja, ich kann auch andere, schlechter passende, nahezu aussagelose Elemente zur Auszeichnung verwenden. Aber wieso sollte ich das tun? ;)
Auch der Punkt mit der "komfortablen Navigation" ist weder ein Grund, noch ein Argument für die Verwendung einer Liste! Denn über Links ließ sich schon immer sehr komfortabel bspw. per Tastatur navigieren.
Erst einmal ging es um komplexe Listeneinträge bestehend aus Bild, Bildunterschrift, Beschreibung *und* Link.
Ferner meinte ich mit Navigation nicht nur die Navigation zwischen den Einträgen. Es geht darum, den ganzen Block zu kennzeichnen, damit zwischen Blöcken navigiert werden kann. Wenn ein Screenreader-Nutzer »Liste mit 10 Einträgen« liest, so kann er in diese Liste hineinspringen (weiterlesen) oder sie überspringen.
Klar, das erübrigt sich, wenn die Liste der gesamte <main>-Inhalt ist. Dann wären Sections angebracht.
Und auch der letzte Punkt, assoziative Techniken betreffend, ist kein Argument. Hier gibt es durchaus andere Möglichkeiten (Stichwort: "visually hidden").
Ich verstehe nicht, was du damit meinst. Wahrscheinlich meinst du assistive Techniken. Aber was soll ich nun für Screenreader verstecken? Die Information »Liste mit 10 Einträgen« bekomme ich nicht durch Verstecken.
Wenn ich Tom richtig verstanden habe in seinem Ausgangsposting, dann ist diese Galerie-Übersicht quasi der Hauptinhalt (der einzige Inhalt?) dieser Seite.
Dann wäre bspw. auch die Verwendung von <section> für jede Fotogalerie denkbar (ggf. jeweils mit <header> und <footer>.
Das kann ich nachvollziehen, ja. Unter diesen Umständen würde ich auch keine Liste, sondern Sections verwenden, und halte das für die bessere Lösung. (Wie gesagt, um den Teil abzudecken, hatte ich noch das andere Posting geschrieben.)
Und dennoch halte ich oftmals die Verwendung einer solchen Liste zumindest für "überflüssig" und semantisch eher für falsch, da dadurch eine "Verbindung" zwischen "Objekten/Elementen" hergestellt wird, die tatsächlich gar nicht gegeben ist.
Im konkreten Fall kommt es also maßgeblich darauf an, als für wie "einzelständig" man die Galerien ansieht?
Die Verbindung – oder Gemeinsamkeit, wie ich es lieber bezeichne – ist entweder lose oder sehr stark. Wenn man sich z.B. Flickr anschaut, so gibt es tausende Möglichkeiten, warum Bilder in *einer* Liste erscheinen. Was haben die schon miteinander zu tun? Sie könnten teilweise nicht verschiedener sein. Doch meistens ist es eine Auswahl unter einem bestimmten Aspekt, und dieser Aspekt steht meistens in der Überschrift direkt über der Liste. Mein Beispiel mit Hundebabys und Ming-Vasen lässt sich einfach umkehren. Wenn die Überschrift wäre »Potpourri an Bildern, die ich sehenswert finde«, so gibt es durchaus einen inhaltlichen Grund, warum die Bilder in einer Liste stehen.
Insofern finde ich die strukturellen Gründe gewichtiger: Es gibt eine Aneinanderreihung von gleichartigen Elementen (Fotos, Fotoalben…), und sie gehören zusammen in einen Block, um sie von den Elementen vorher und nachher abzugrenzen. Eine entsprechende Auszeichnung bringt die besagten Vorteile.
Mathias
-
Hallo,
Mal davon abgesehen, dass es imho eine bis heute andauernde Unzulänglichkeit von HTML ist, dass es kein "vernünftiges/ brauchbares" Element dafür gibt (Stichwort <menu>),
Inwiefern wäre ein menu-Element besser?
Es wäre insofern besser, als dass es von der Semantik her eine "präzisere" Auszeichnung erlauben würde (zusammen mit <menuitem>, wobei dann immer noch entsprechende Attribute fehlen, die die "Beziehung" der Links untereinander repräsentieren würden).
Denn auch das in HTML5 neu eingeführte Nav Element sorgt nicht für die notwendige Klarheit/ Eindeutigkeit.
ist die Verwendung einer ungeordneten Liste für diesen Zweck also eher eine "historisch gewachsene Behelfslösung", als eine semantisch korrekte Auszeichnung.
Aha. Was ist daran nicht korekt?
Es verleiht den Elementen nicht die semantische Bedeutung, die sie eigentlich haben sollten/ müssten.
Das kannst du ja auch gerne machen. Deshalb muss es aber semantisch gesehen noch lange nicht "die (einzig) richtige" Variante sein.
Ja. Man darf gerne Gegenargumente formulieren.
Ich bemühe mich ja gerade ...! ;-)
Denn nach dieser Argumentation könntest/ müsstest die ja bspw. auch die Artikelübersicht auf der Blog Startseite (http://blog.selfhtml.org/) in eine Liste packen!
Ich habe damit gerechnet, dass dieser Einwand kommt. ;) Und habe deshalb geschrieben.
Um das zusammenzufassen: Ja, man könnte es in eine Liste packen – man muss und sollte es aber nicht, da ein Dokument auf der obersten Ebene aus Sections besteht, welche per definitionem gleichförmig sind und in einer Abfolge stehen. Die korrekte Auszeichnung auf dieser Ebene sind also Sectioning-Elemente. Im Falle von blog.selfhtml.org: aufeinander folgende article-Elemente.
Sehr schön ..., dann sind wir ja im Prinzip einer Meinung. Den Beitrag hatte ich noch nicht gelesen, bevor ich meinen verfasst hatte.
Da jeder dieser Links zu einem "eigenständigen" Teil von SELFHTML verlinkt, sie also keine hierarchische Reihe bilden,
Was ist eine »hierarchische Reihe«?
Zugegeben, schlecht formuliert. Gemeint war so etwas wie ein "Breadcrumb Trail", wo also quasi jeder nachfolgende Punkt/ Link den vorhergehenden beinhaltet und sozusagen jeweils eine Ebene tiefer reicht.
Eine ungeordnete Liste erfordert keine Hierarchie.
Eine alleine kann keine Hierarchie "abbilden", verschachtelte schon.
wäre die Anordnung der Links ohne Listenelement innerhalb des Nav Elements aus meiner Sicht genauso möglich.
So etwa?
<nav> > <a>…</a> > <a>…</a> > <a>…</a> > </nav>Ja, warum denn deiner Meinung nach nicht? Die Semantik kommt, genau wie die "Gruppierung" von dem Nav Element, welches man ggf. noch mit einem role Attribut (role="navigation") ergänzen kann.
Das geht natürlich so lange, wie die Links alle auf "einer Ebene" liegen, also es keine Links gibt, die hierachisch unter einem anderen Link liegen.
Aus diesem Grund, und weil vor HTML5 A Elemente keine Blocklevel Elemente beinhalten durften, ist imho mangels passenderer Alternativen die Auszeichnung mittels UL entstanden. Davon mal abgesehen, wäre wohl in den allermeisten Fällen eine OL "richtiger", da es sehr wohl auf die Reihenfolge ankommt.
Wo sind dann deiner Meinung nach Listen überhaupt noch angebracht? ;)
Überall da, wo es sich um "Aufzählungen/ Auflistungen" handelt. Also z.B. bei einer Pro und Kontra Liste, Eigenschaften einer Sache/ eines Produkts etc.
Natürlich kann man auch, so wie du, argumentieren, dass ein Menü auch eine "Auflistung" von Links ist und sieht sich aufgrund der millionenfachen Umsetzung als solche auch leicht darin bestätigt. Aber nochmal, ich halte das für "falsch" und sehe eine derartige Umsetzung nur aufgrund mangelnder (passenderer/ richtigerer) Alternativen gegeben.
Die Argumente mit dem "CSS-Angriffspunkt" und dem "DOM Scripting" greifen ja nicht wirklich. Beides ist in jedem anderen Fall genauso möglich (und selbst wenn nicht, gäbe es dafür die "inhaltslosen" Elemente <div> und <span>).
Ja, ich kann auch andere, schlechter passende, nahezu aussagelose Elemente zur Auszeichnung verwenden. Aber wieso sollte ich das tun? ;)
Nicht nur "nahezu", sondern per Definition "inhaltslos"! Tun sollte man das immer dann, wenn aus Gründen der Präsentation (CSS) oder des Scriptings "angebracht" ist. Denn aus diesen Gründen eine Liste im HTML zu verwenden, verändert ja die Semantik. Und genau das ist in diesen Fällen ja nicht angebracht.
Auch der Punkt mit der "komfortablen Navigation" ist weder ein Grund, noch ein Argument für die Verwendung einer Liste! Denn über Links ließ sich schon immer sehr komfortabel bspw. per Tastatur navigieren.
Erst einmal ging es um komplexe Listeneinträge bestehend aus Bild, Bildunterschrift, Beschreibung und Link.
Ferner meinte ich mit Navigation nicht nur die Navigation zwischen den Einträgen. Es geht darum, den ganzen Block zu kennzeichnen, damit zwischen Blöcken navigiert werden kann. Wenn ein Screenreader-Nutzer »Liste mit 10 Einträgen« liest, so kann er in diese Liste hineinspringen (weiterlesen) oder sie überspringen.
Dann muss man sich aber zu allererst einmal die Frage stellen, ob die Semantik gegenüber einer "komfortablen Navigation" für Screenreader (oder andere Ausgabemedien) nachrangig ist, oder nicht?
Der einzige wirkliche Vorteil scheint mir hier zu sein, dass der Screenreader (wenn ich deine Aussage richtig interpretiere) hier gleich die Anzahl der Listeneinträge ansagt. Das ließe sich ja auch leicht anders bewerkstelligen. Und Skip Links kann man auch sehr leicht integrieren. Und per "tabindex" kann man ein "komfortables" Navigieren innerhalb des Blocks ermöglichen.
Das hat aber alles nichts mit der Semantik zu tun. Denn die ergibt sich rein aus dem Inhalt und nicht daraus, wie ggf. durch selbigen navigiert werden kann.
Klar, das erübrigt sich, wenn die Liste der gesamte <main>-Inhalt ist. Dann wären Sections angebracht.
Gut, dann sind wir uns ja einig (wie auch in deinem anderen Beitrag geschrieben).
Und auch der letzte Punkt, assoziative Techniken betreffend, ist kein Argument. Hier gibt es durchaus andere Möglichkeiten (Stichwort: "visually hidden").
Ich verstehe nicht, was du damit meinst. Wahrscheinlich meinst du assistive Techniken.
Haha ..., war wohl schon (zu) spät. Aber schön, dass du mich trotzdem verstanden hast. ;-)
Aber was soll ich nun für Screenreader verstecken? Die Information »Liste mit 10 Einträgen« bekomme ich nicht durch Verstecken.
Siehe oben!
Wenn ich Tom richtig verstanden habe in seinem Ausgangsposting, dann ist diese Galerie-Übersicht quasi der Hauptinhalt (der einzige Inhalt?) dieser Seite.
Dann wäre bspw. auch die Verwendung von <section> für jede Fotogalerie denkbar (ggf. jeweils mit <header> und <footer>.
Das kann ich nachvollziehen, ja. Unter diesen Umständen würde ich auch keine Liste, sondern Sections verwenden, und halte das für die bessere Lösung. (Wie gesagt, um den Teil abzudecken, hatte ich noch das geschrieben.)
Wie bereits gesagt, sind wir uns darin einig. Umgekehrt würde ich eine (ungeordnete) Liste verwenden, wenn bspw. auf einer Seite als "ein Punkt unter vielen" aufgeführt wird: Unser Fotoarchiv umfasst (u.a.) die folgenden Galerien:
- Galerie X
- Galerie Y
- Galerie Z
Und dennoch halte ich oftmals die Verwendung einer solchen Liste zumindest für "überflüssig" und semantisch eher für falsch, da dadurch eine "Verbindung" zwischen "Objekten/Elementen" hergestellt wird, die tatsächlich gar nicht gegeben ist.
Im konkreten Fall kommt es also maßgeblich darauf an, als für wie "einzelständig" man die Galerien ansieht?
Die Verbindung – oder Gemeinsamkeit, wie ich es lieber bezeichne – ist entweder lose oder sehr stark. Wenn man sich z.B. Flickr anschaut, so gibt es tausende Möglichkeiten, warum Bilder in einer Liste erscheinen. Was haben die schon miteinander zu tun? Sie könnten teilweise nicht verschiedener sein. Doch meistens ist es eine Auswahl unter einem bestimmten Aspekt, und dieser Aspekt steht meistens in der Überschrift direkt über der Liste. Mein Beispiel mit lässt sich einfach umkehren. Wenn die Überschrift wäre »Potpourri an Bildern, die ich sehenswert finde«, so gibt es durchaus einen inhaltlichen Grund, warum die Bilder in einer Liste stehen.
Das ist ja das "Problem" ...! :-P Es lassen sich immer sehr leicht Gründe/ Argumente dafür finden, warum man "Dinge" in eine Liste packt. Und sehr oft ist das ja auch durchaus "korrekt".
Nur leiden manche Autoren imho schon fast an einem "Listenwahn", und erkennen eben nicht mehr, wann eine Liste ggf. _nicht_angebracht ist.
Und in dem vorliegenden Fall (davon ausgehend, dass die Fotogalerie Übersicht der Hauptinhalt der Seite ist), ist sie eben imho nicht angebracht (und bei Navigationen eigentlich auch nicht - s.o.)!
Insofern finde ich die strukturellen Gründe gewichtiger: Es gibt eine Aneinanderreihung von gleichartigen Elementen (Fotos, Fotoalben…), und sie gehören zusammen in einen Block, um sie von den Elementen vorher und nachher abzugrenzen. Eine entsprechende Auszeichnung bringt die besagten Vorteile.
Ich bin mir nicht ganz sicher, ob diese Aussage richtig verstehe. Aber prinzipiell besteht ja ein Unterschied zwischen "Elemente gruppieren" (durch das Umschließen, um sie so als "Block" zu kennzeichnen) und "Listenelementen" (die dadurch bereits "gruppiert" sind, weil sie eben Teil einer Liste sind). Daraus aber abzuleiten, dass pauschal alle Elemente, die "zusammengefasst/ gruppiert" werden können, deshalb auch immer Listenelemente sind (und deshalb die Gruppierung in Form einer Liste erfolgt), halte ich für falsch.
Klassiker: "Alle Chinesen sind Menschen, aber nicht alle Menschen sind Chinesen (jedenfalls noch nicht)!"
Es kommt bei Fragen der Semantik ja immer auf die Intention an, und da gibt es meist sehr feine Unterschiede.
Ist die Übersicht über die existierenden Fotogalerien der Hauptinhalt der entsprechenden Seite, oder möchte ich nur einen "Überblick/ Ausblick" auf vorhandene Galerien geben, oder gebe ich die Galerien als "Treffer" einer Suchanfrage wieder, oder gruppiere ich sie anhand anderer Kriterien, oder oder oder ...?
Und zumindest viele dieser Fälle rechtfertigen jeweils eine andere Auszeichnung im HTML. Denn eine Liste eignet sich erstmal nicht dafür, Inhalte thematisch zu gruppieren, da bspw. eine ul/ ol nur li Elemente als Kindelemente haben darf und auch keinen "sectioning content" darstellt. Das heißt die "Gruppierung" müsste eh schon auf einer darüberliegenden Ebene stattfinden. Und dann stellt sich doch oftmals die Frage, ob eine weitere Zusammenfassung in Form einer Liste überhaupt noch erforderlich, bzw. semantisch korrekt ist?
In Gunnars Beispielcode sorgen ja z.B. die A Elemente für eine entsprechende Gruppierung zu einzelnen Blöcken. Und es würde imho semantisch nicht "besser", wenn man diese zusätzlich noch in li Elemente stecken würde. Wozu? Und angenommen diese Blöcke stecken in einem section Element mit entsprechender "section heading", was würde das rein semantisch gesehen bringen/ bedeuten?
Imho ist das genau wie bei dem Beispiel mit der Navigation nur "doppelt gemoppelt".
Gruß Gunther
-
-
-
Hallo,
eine Tabelle wäre semantisch nicht korrekt.
Das dl-Element mit den zugehörigen dt- und dd-Elementen wäre in deinem Fall auch semantisch korrekt. Zumal du ja zwei Texte (bzw. bis zu zwei Texte) zu jedem Bild erstellen willst. Das geht mit dem figure-Element nicht, da immer nur ein figcaption-Element zulässig ist.
Wobei für den zweiten Text eventuell auch ein Slider sinnvoll wäre. Aber dazu müsste ich genau wissen, wie du dir das vorstellst und ob du mit sinnvollen Abweichungen leben kannst.
Gruss
MrMurphy
-
Hallo,
eine Tabelle wäre semantisch nicht korrekt.
Wieso nicht?
<table> <caption>Meine Bildergalerien</caption> <thead> <tr> <th scope="row">Titel</th> <th scope="row">Album-Deckblatt</th> </tr> </thead> <tbody> <tr> <th><a href="/galerien/biker">Bilder für Biker</a></th> <th><a href="/galerien/biker/harley"><img src="…" alt="Harley Davidson"></a></th> </tr> … </tbody> </table>Wäre von der Struktur her durchaus möglich, finde ich. Allerdings ist es eher untypisch, solche Inhalte in Tabellen anzuordnen.
Mathias
-
-
Hallo,
Meine urprüngliche (implizite) Frage, ob die Schachtelung von <ul> und <dl> überhaupt sinnvoll ist, ist damit leider noch nicht erschöpfend beantwortet.
Welche von beiden Auszeichnungen wäre denn für die vorgesehene Anwendung (Bild, Unterschrift, Beschreibungstext, weiterführender Link ausgehend vom der gesamten Elementegruppe), das Ganze in Wiederholung (also Liste) der richtige?
Ich finde, eine Liste ist die korrekte Datenstruktur, aber das ist vielleicht aus Programmierer-Sicht gesehen.
Fragen wir uns einmal: Was für Möglichkeiten bietet HTML denn?
Auf oberster Ebene gibt es Sections. body ist die Wurzel, ein Sectioning Root. Darunter notiert man üblicherweise header, main, footer. Innerhalb von main oder direkt unter body werden weitere Sections notiert. Sectioning-Elemente sind das generische section und die spezifischeren nav, aside sowie article.
Die Elemente h1-h6 liefern die Überschriften für die Sections. Sie können auch selbst implizite Sections erzeugen, sofern kein explizites Sectioning-Element verwendet wird.
Sections sind üblicherweise geordnet. Das liegt an der Linearität von Texten. Ein Dokument ist also schon eine verschachtelte Liste von Sections. Der HTML5-Outline-Algorithmus erlaubt es, tatsächlich eine Liste mit Überschriften aus dem Dokument zu generieren.
Innerhalb von Sections gibt es recht wenige Elemente, um den Inhalt zu gruppieren: p, ol, ul, dl, figure, blockquote, pre, div. (main gehört auch zu den gruppierenden Elementen, habe ich aber oben schon angesprochen, da es eine besondere, dokumentweite Bedeutung hat.)
Wenn ich von Gunnars Vorschlag ausgehe, nutzen wir hiervon bereits figure-Elemente. Und zwar eine ganze Reihe davon, direkt aufeinander folgend, gleichförmig, eventuell geordnet. Ich behaupte, dass sich auf dieser Ebene ol oder ul hervorragend zur Gruppierung solcher figure-Elemente eignen. Was sonst? p zeichnet Textabsätze aus. blockquote und pre kommen nicht infrage. div ist sehr unspezifisch und aussageschwach. dl wäre prinzipiell möglich, passt aber nicht, wenn figcaption verwendet wird.
Wir könnten die zusätzliche Gruppierung natürlich auch weglassen, wie Gunther vorschlägt. Das ist möglich und nicht unlogisch. Ich halte sie aber strukturell und praktisch für angebracht.
Ich nehme hier eine hierarchische Ordnung eines Dokuments an: Sections, darin Grouping-Elemente, darin Text-Level-Elemente. Die HTML5-Spezifikation legt dies in der Beschreibung der Element nahe, aber es ist *kein* syntaktisches Erfordernis, Dokumente so aufzubauen. HTML5 ist hier (im Gegensatz zu HTML 4.01 Strict) sehr frei. Es gibt sehr offene Inhaltskategorien wie Flow Content, die zur Definition der möglichen Verschachtelung benutzt werden.
Innerhalb einer Section können sowohl gruppierende als auch Text-Level-Elemente verwendet werden.
<section><p><strong>Foo</strong></p></section>ist möglich, aber auch<section><strong>Foo</strong></section>. Der Inhalt von a-Elementen ist nicht streng Phrasing Content, es kann unter Umständen auch Flow Content umschließen (grob zusammengefasst).<a><figure></figure></a>ist also genauso möglich wie<figure><a></a></figure>. Der Logik nach würde ich a unterhalb von figure einsetzen, aber wie gesagt ist HTML5 hier offen.Mathias
-
-
-
@@Tom:
nuqneH
- nun soll das Bild aber auch eine Unterschrift bekommen
<figure> <a><img/></a> <figcaption>Unterschrift</figcaption> </figure>oder noch besser alles verlinkt
<a> <figure> <img/> <figcaption>Unterschrift</figcaption> </figure> </a>- und wenn es ganz wild wird, soll rechts neben dem Bild noch ein Beschreibungstext
erscheinen.
Gehört die Unterschrift zu Bild und Beschreibung? Dann
<a> <figure> <img/> <div>Beschreibung</div> <figcaption>Unterschrift</figcaption> </figure> </a>Wenn nicht, dann
<a> <figure> <img/> <figcaption>Unterschrift</figcaption> </figure> <div>Beschreibung</div> </a>Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer) -
Hello,
ich möchte eine Übersicht über eine Fotogalerie erstellen, wobei jedes dargestellte Element einen Hyperlink auf die jeweilige Galerie darstellt.
-
Entwicklungsstufe war es nur eine textuelle <ul><li> liste... Kein Problem
-
Entwicklungsstufe: anstelle des textlichen Inhaltes des Links sollte ein
Bild erscheinen <a><img></a> -
nun soll das Bild aber auch eine Unterschrift bekommen
-
und wenn es ganz wild wird, soll rechts neben dem Bild noch ein Beschreibungstext
erscheinen.
Wie bekomme ich das am saubersten hin?
Meine derzeitige Lösung für Bilder. Das Thüringer Bilderverzeichnis hat eine Paginator-Funktion, es wird automatisch eine neue Linkliste erstellt, wenn Du auf den vorletzten oder letzten Link in der Liste klickst. HTML5-gefällig ist das noch nicht, wird aber ;)
Horst
-
Meine Herren!
Meine derzeitige Lösung für Bilder. HTML5-gefällig ist das noch nicht, wird aber ;)
Du sagst es ja selber. Deine semantische Auszeichnung ist so ausdrucksstark wie ein Kieselstein und deshalb nicht gerade ein Musterbeispiel, das auf positive Weise zur Lösungsfindung beitragen könnte. Dem TO geht es doch vor allem, um die passende Auszeichnung.
--
“All right, then, I'll go to hell.”-
hi,
Meine derzeitige Lösung für Bilder. HTML5-gefällig ist das noch nicht, wird aber ;)
Du sagst es ja selber. Deine semantische Auszeichnung ist so ausdrucksstark wie ein Kieselstein
Ein bischen detaillierter könnte Deine Kritik schon sein. Also gut, ich frage mal direkt:
Ist dl/dt/dd als deprecated eingestuft? Wenn ja, welche Alternativen gibt es für HTML5?
Bitte mal um Hinweise (nur dl betreffend).
Horst Dankwart-
Meine Herren!
Du sagst es ja selber. Deine semantische Auszeichnung ist so ausdrucksstark wie ein Kieselstein
Ein bischen detaillierter könnte Deine Kritik schon sein. Also gut, ich frage mal direkt:
Da muss ich dir recht geben. Entschuldige, das war destruktiv.
Ich meine damit die inflationäre Verwendung von Containern, wo keine benötigt werden. Zum Beispiel p-Tags um ein einzelnes Bild zu umschließen. Oder wahllos eingestreute Elemente, die nur der Präsentation dienen (div.left) und, wie du selber schon gesagt hast, die Abstinenz von strukturierenden HTML5 Elementen. nav-Element um die Navigation und ein figure-Element um den Zusammenhang zwischen Bild und Bildbeschreibung herzustellen. Gunnar hat hat das ja schon exemplarisch veranschaulicht.
Ist dl/dt/dd als deprecated eingestuft? Wenn ja, welche Alternativen gibt es für HTML5?
Nein, nur die Semantik hat sich geändert. Während in HTML4 eine dl dazu gedacht war lexikalische Definitionslisten zu erstellen, ist die Bedeutung in HTML5 umfassender und kann zum Beispiel auch genutzt werden um eine Legende zu erstellen oder ein Datenblatt zu einer Hardware-Komponente.
--
“All right, then, I'll go to hell.”-
hi,
Ich meine damit die inflationäre Verwendung von Containern, wo keine benötigt werden. Zum Beispiel p-Tags um ein einzelnes Bild zu umschließen. Oder wahllos eingestreute Elemente, die nur der Präsentation dienen (div.left) und, wie du selber schon gesagt hast, die Abstinenz von strukturierenden HTML5 Elementen. nav-Element um die Navigation und ein figure-Element um den Zusammenhang zwischen Bild und Bildbeschreibung herzustellen. Gunnar hat hat das ja schon exemplarisch veranschaulicht.
Ja, ok, das betrifft dann die Seiten mit dem Bildern drinnen, liegt schon auf meinem Tisch, Danke auch an Gunnar u.a. Hier muss ich nur das Template anfassen.
Viele Grüße,
Dankwart Horst--
$Zauberwort_mit_tt = $polite ? 'Bitte' : 'Mach schon, aber flott';
-
Hallo,
Du sagst es ja selber. Deine semantische Auszeichnung ist so ausdrucksstark wie ein Kieselstein
Ein bischen detaillierter könnte Deine Kritik schon sein. Also gut, ich frage mal direkt:
Da muss ich dir recht geben. Entschuldige, das war destruktiv.
Das finde ich nicht! Der hotti versucht nur mal wieder Traffic für seine Seite zu generieren und Werbung für sein ominöses Framework zu machen. Dabei interessiert ihn nicht im geringsten, dass sein Posting absolut nichts mit der Frage zu tun hat. Nicht mal im entferntesten. Da könnte man auf jede x-beliebige Seite verlinken, auf der ein Bild dargestellt ist.
Viele Grüße
Siri
-
-
-
-
-
Meiner Meinung nach wäre folgends möglich (nahe an Toms Original):
<ul>
<li>
<dl>
<dt>
<a>
<figure>
<img>
<figcaption>
Unterschrift des Bildes
</figcaption>
</figure>
</a>
</dt>
<dd>
Beschreibung dessen, was man in dt sieht
</dd>
</dl>
</li><li> (usw...) </li></ul>
Ich fände das aber zu umständlich
Wenn es sich tatsächlich schon um Text und Bild mit Untersachrift handelt, würde ich das ganze eher so aufbauen
<article>
<a>
<figure>
<img>
<figcaption>
Unterschrift des Bildes
</figcaption>
</figure>
</a>
<p>Beschreibung</p>
</article>Denn für mich sind das im Grunde kleine Artikel, die füpr sich selber stehen können und dürfen und vielleicht sogar sollen...
Marc, der sein Passwort vergessen hat
-
Sorry, habe die Auszeichnung vergessen. Hier nochmal:
Meiner Meinung nach wäre folgends möglich (nahe an Toms Original):
<ul> <li> <dl> <dt> <a> <figure> <img> <figcaption> Unterschrift des Bildes </figcaption> </figure> </a> </dt> <dd> Beschreibung dessen, was man in dt sieht </dd> </dl> </li> <li> (usw...) </li> </ul>Ich fände das aber zu umständlich
Wenn es sich tatsächlich schon um Text und Bild mit Untersachrift handelt, würde ich das ganze eher so aufbauen
<article> <a> <figure> <img> <figcaption> Unterschrift des Bildes </figcaption> </figure> </a> <p>Beschreibung</p> </article>Denn für mich sind das im Grunde kleine Artikel, die für sich selber stehen können und dürfen und vielleicht sogar sollen...
Marc, der sein Passwort vergessen hat
-
Hello Poster,
vielen Dank für die vielen Anregungen.
Ich habe es jetzt so generiern lassen:
<div id="main"> <div id="content"> <h2>Fotoalbum der Bikers Lodge Harz</h2> <a href="/gallery/?cmd=show&gal=101"><dl class="imgLeft"> <dt><img src="/gallery/101.gal/100.jpg" alt="Übersicht" title="Die Galerie für Biker enthält Bilder zu Unterstellmöglichkeiten für die Bikes, wilden Kurven in der Umgebung, möglichen Aktivitäten u. v. m." style="<!--STYLE-->"></dt> <dd>Bilder für Biker</dd> <dd style="font-size:90%; font-weight:normal;">Die Galerie für Biker enthält Bilder zu Unterstellmöglichkeiten für die Bikes, wilden Kurven in der Umgebung, möglichen Aktivitäten u. v. m.</dd> </dl></a> <a href="/gallery/?cmd=show&gal=110"><dl class="imgLeft"> <dt><img src="/gallery/110.gal/120100.jpg" alt="Gelände" title="Das Freigelände der Odertaler Sägemühle" style="<!--STYLE-->"></dt> <dd>Das Freigelände - Morgenstimmung</dd> <dd style="font-size:90%; font-weight:normal;">Das Freigelände der Odertaler Sägemühle</dd> </dl></a> <a href="/gallery/?cmd=show&gal=120"><dl class="imgLeft"> <dt><img src="/gallery/120.gal/2014_Satelliten-Foto.jpg" alt="Häuser" title="Die Häuser, Ferienwohnungen und Übernachtungsmöglichkeiten in der Odertaler Sägemühle, hier aus dem Weltall betrachtet" style="<!--STYLE-->"></dt> <dd>Pläne der Häuser</dd> <dd style="font-size:90%; font-weight:normal;">Die Häuser, Ferienwohnungen und Übernachtungsmöglichkeiten in der Odertaler Sägemühle, hier aus dem Weltall betrachtet</dd> </dl></a> <a href="/gallery/?cmd=show&gal=130"><dl class="imgLeft"> <dt><img src="/gallery/130.gal/104.jpg" alt="Partytime" title="Hier kannst Du wilde Parties feiern!" style="<!--STYLE-->"></dt> <dd>Party-Stimmung in der Sägemühle</dd> <dd style="font-size:90%; font-weight:normal;">Hier kannst Du wilde Parties feiern!</dd> </dl></a> </div> </div>So funktioniert das ganz gut bisher. Life zu sehen unter
http://bikers-lodge.lan/gallery/Das Angenehme ist, dass jetzt auch der IE 8.x nicht mehr rumzickt.
Das CSS ist sicherlich noch überarbeitungswürdig, funktionert aber erst einmal.
Wie man sieht, sind auch noch nicht erstzte Platzhalter enthalten. Das ist Absicht, um die Validität nach http://validator.w3.org auch für diese Fälle zu testen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello Tom,
Ich habe es jetzt so generiern lassen:
<div id="main">
<div id="content">
<h2>Fotoalbum der Bikers Lodge Harz</h2><a href="/gallery/?cmd=show&gal=101"><dl class="imgLeft">
<dt><img src="/gallery/101.gal/100.jpg" alt="Übersicht" title="Die Galerie für Biker enthält Bilder zu Unterstellmöglichkeiten für die Bikes, wilden Kurven in der Umgebung, möglichen Aktivitäten u. v. m." style="<!--STYLE-->"></dt>
<dd>Bilder für Biker</dd><dd style="font-size:90%; font-weight:normal;">Die Galerie für Biker enthält Bilder zu Unterstellmöglichkeiten für die Bikes, wilden Kurven in der Umgebung, möglichen Aktivitäten u. v. m.</dd>
</dl></a>
<a href="/gallery/?cmd=show&gal=110"><dl class="imgLeft">
<dt><img src="/gallery/110.gal/120100.jpg" alt="Gelände" title="Das Freigelände der Odertaler Sägemühle" style="<!--STYLE-->"></dt>
<dd>Das Freigelände - Morgenstimmung</dd>
<dd style="font-size:90%; font-weight:normal;">Das Freigelände der Odertaler Sägemühle</dd>
</dl></a>
<a href="/gallery/?cmd=show&gal=120"><dl class="imgLeft">
<dt><img src="/gallery/120.gal/2014_Satelliten-Foto.jpg" alt="Häuser" title="Die Häuser, Ferienwohnungen und Übernachtungsmöglichkeiten in der Odertaler Sägemühle, hier aus dem Weltall betrachtet" style="<!--STYLE-->"></dt>
<dd>Pläne der Häuser</dd><dd style="font-size:90%; font-weight:normal;">Die Häuser, Ferienwohnungen und Übernachtungsmöglichkeiten in der Odertaler Sägemühle, hier aus dem Weltall betrachtet</dd>
</dl></a>
<a href="/gallery/?cmd=show&gal=130"><dl class="imgLeft">
<dt><img src="/gallery/130.gal/104.jpg" alt="Partytime" title="Hier kannst Du wilde Parties feiern!" style="<!--STYLE-->"></dt>
<dd>Party-Stimmung in der Sägemühle</dd>
<dd style="font-size:90%; font-weight:normal;">Hier kannst Du wilde Parties feiern!</dd>
</dl></a></div>
</div>Kein HTML5? Warum nicht? Davon abgesehen halte ich deine Verwendung einer dl hier so ziemlich für die schlechteste Wahl. > So funktioniert das ganz gut bisher. Life zu sehen unter > <http://bikers-lodge.lan/gallery/> Der Server unter ... kann nicht gefunden werden. > Das Angenehme ist, dass jetzt auch der IE 8.x nicht mehr rumzickt. Wie und warum "zickt" der ansonsten rum? > Wie man sieht, sind auch noch nicht erstzte Platzhalter enthalten. Das ist Absicht, um die Validität nach <http://validator.w3.org> auch für diese Fälle zu testen. Validität alleine ist erstmal nur eine Grundvoraussetzung, die aber ansonsten nichts weiter aussagt. Gruß Gunther-
Hello,
So funktioniert das ganz gut bisher. Life zu sehen unter
http://bikers-lodge.com/gallery/Der Server unter ... kann nicht gefunden werden.
Sorry, da ist natürlich die öffentliche Variante notwendig. Aber bei der Kotrollansicht merkt man diesen Fehler nicht, da der lokale DNS den Request ja ordnungsgemäß bedienen kann ;-.))
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
So funktioniert das ganz gut bisher. Life zu sehen unter
http://bikers-lodge.com/gallery/na ja ... document type does not allow element "DL" here *grins*
Gruß Gunther
-
Hello Gunther,
So funktioniert das ganz gut bisher. Life zu sehen unter
http://bikers-lodge.com/gallery/na ja ... document type does not allow element "DL" here *grins*
Danke für den Test. Das ist ja langsam wirklich nervtötend...
Ich werde weiter basteln.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
Hello Gunther,
So funktioniert das ganz gut bisher. Life zu sehen unter
http://bikers-lodge.com/gallery/na ja ... document type does not allow element "DL" here *grins*
Danke für den Test. Das ist ja langsam wirklich nervtötend...
Ich werde weiter basteln.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo
hast du die Seite bereits geändert? Ich bekommen nur Fehlermeldungen, das 4 DIVs nicht erlaubt sind, was ja auch bei dem Quelltext korrekt ist.
Gruss
MrMurphy
-
-
-
-
-
-
-
-
-
Hello,
das Problem ist leider noch nicht vom Tisch.
Es liegt wohl daran, dass ein <a>-Element kein DIV oder DL enthalten darf.Da muss ich wohl das gesamte Konstrukt umbauen und den Hyperlink nach innen legen.. :-O
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Om nah hoo pez nyeetz, Tom!
Da muss ich wohl das gesamte Konstrukt umbauen und den Hyperlink nach innen legen.. :-O
Ja. Oder du änderst deinen Doctype
<!doctype html>Dadurch sollten sich keinerlei Änderungen an der Darstellung ergeben.
Matthias
-
Hello Matthias
Da muss ich wohl das gesamte Konstrukt umbauen und den Hyperlink nach innen legen.. :-O
Ja. Oder du änderst deinen Doctype
<!doctype html>
Ist ja interessant. Dann interessiert die Schachtelung innerhalb des <a> tatsächlich nicht mehr, aber die ganzen anderen Probleme kommen spontan hoch, die mir die Vorausarbeitende mit ihrem Dream-Weaver geschaffen hat.: Design-Auszeichnungen in HTML statt in CSS. Das muss ich auch nmoch alles durcharbeiten \*puh\* Ich baue die Galerie-Vorschau jetzt lieber nochmal um, solange noch Zeit ist. <DL> und seine Brüder kann ich dann anschließend aber benutzten. Liebe Grüße aus dem schönen Oberharz Tom vom Berg  -- ☻\_ /▌ / \ Nur selber lernen macht schlau <http://restaurant-zur-kleinen-kapelle.de> -
Om nah hoo pez nyeetz, Tom und Matthias!
Da muss ich wohl das gesamte Konstrukt umbauen und den Hyperlink nach innen legen.. :-O
Ja. Oder du änderst deinen Doctype
<!doctype html>
> > Dadurch sollten sich keinerlei Änderungen an der Darstellung ergeben. HTML5 zu verwenden ist i.d.R. aber mehr, als nur den Doctype zu ändern! Stichworte sind u.a.: "Section" und "Outline" Und aus meiner Diskussion mit Mathias (molily), sollte eigentlich auch klar hervorgehen, welches in diesem Fall hier (wo die Galerie-Übersicht der Hauptinhalt der Seite ist) die beste Variante ist. Die mit der <dl> (außer für evt. Meta-Angaben) ist es jedenfalls nicht. ;-) Gruß Gunther-
Om nah hoo pez nyeetz, Gunther!
HTML5 zu verwenden ist i.d.R. aber mehr, als nur den Doctype zu ändern!
Mit Sicherheit. Aber da Tom Wert auf ein valides Dokument legt und div als Nachfahre von a in HTML < 5 nicht geht, …
Die mit der <dl> (außer für evt. Meta-Angaben) ist es jedenfalls nicht. ;-)
Auch da stimme ich dir zu.
Matthias
-
Hello,
HTML5 zu verwenden ist i.d.R. aber mehr, als nur den Doctype zu ändern!
Mit Sicherheit. Aber da Tom Wert auf ein valides Dokument legt und div als Nachfahre von a in HTML < 5 nicht geht, …
Ich werde mir den Thread nochmal aufmerksam durchlesen und Gunthers und Andreas' Anmerkungen verfolgen.
So ein "trivialer Fehler" schlägt leider ziemlich weit durch. Liegt vielleicht auch daran, dass HTML + CSS + JS & Co in Wirklichkeit nur riesengroße Bastelkisten sind und keine echte innere Konsistenz aufweisen.
Ich habe daher auch angefangen, meine kleine Template-Engine an dieser Stelle nochmal vollständig zu renovieren (bzw. leider lange verworfene alte Ideen nochmal einfließen zu lassen), solange noch Zeit ist - ich sie also noch nicht multipliziert eingesetzt habe für 30 -40 Seiten.
Das sieht so aus, als würde das ganze Kontrukt dadurch nachher für den "Chief-Content-Manager" (der nur noch HTML und CSS anfassen darf) sehr viel transparenter und strukturierter werden. Also ist es der Mühe wert.
Der Anwender hat mit dem ganzen Quark dann ja gar nichts mehr zu tun, sondern wählt nur noch Elemente aus, lädt (Bild-)dateien hoch und füllt Formulare aus.
Und spätestens der Seiten-Besucher/Nutzer darf keinerlei Manipulationsmöglichkeiten mehr finden :-O
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
