Frage zum Wiki-Artikel „Listen“

[Q, ob nun aus der 007 oder Scharddreg-Phantasy-Welt]

Wieso gibt es nicht „längst“ einen „responsiven“ Ersatz für die alten HTML-Listen? Immerhin verbinden die alle Inhalte mit der Darstellung. Und das zwingend, so daß auch jeder Versuch, sie mittels CSS zu (hier, listenbezüglich) „entblocken“, an vielen Ecken und Enden im Detail scheitert?

Beispiel?

„Ich packe in meinen Koffer: einen Hund, eine Katze, einen Föhn, ein …“, „…!”

<ul>
<header>Ich packe inh meinen Koffer</header>
<li>einen Hund</li>
<li>eine Katze</li>
<li>einen Föhn</li>
<li>ein …</li>
<li>…!</li>
</ul>

Den Inhalt in verschiedene Darstellungsformen zu zwingen (hier wäre es erst einmal eine Inline-Liste) und dann mit diversen anderen CSS-Features zu „verzieren“ (insb. ::before und ::after) scheitert. Und zwar, hier im Beispiel, daran, daß so beigefügte Darstellungselemente immer wieder als nicht dem Element zugehörig betrachtet werden, welchem sie von der topologischen Struktur her zugeordnet wären. Sprich: das ::before und/oder ::after-Element wird (oftmals ohne jegliche Not!) umgebrochen und damit vom Element getrennt.

Einen Teil(!) dieser Effekte kann man gerade noch vermeiden, wenn man Whitespace(!) zwischen den Grenzen der Entities (also zwischen einem „>“ und dem folgenden „<“) weg nimmt. Aber schon das Tauschen dieser Whitespaces gegen HTML-Kommentare funktioniert nicht „einwandfrei“. Es dauert nur etwas länger, bis man über das nächste sich daraus ergebende Problem stoplert.

Ergebnis: eine div-Wüste, welche Elemente gegen ihre Eltern isoliert und damit versucht, diese bzw. deren Eigenschaften in die Knie zu zwingen. Oder schlicht Resignation, die intrinsische Frage, wieso man es nicht lieber gleich bei HTML 0.9 beläßt!

[Matthias Scharwies]

Servus!

Wieso gibt es nicht „längst“ einen „responsiven“ Ersatz für die alten HTML-Listen?

Listen sind responsiv, d.h. sie passen sich auch ohne CSS an den Viewport an.

Immerhin verbinden die alle Inhalte mit der Darstellung.

Nein.

Den Inhalt in verschiedene Darstellungsformen zu zwingen (hier wäre es erst einmal eine Inline-Liste)

ul  {
  list-style: none; 
  padding: 0; 
  margin: 0; 
}

ul li {
  display: inline;
}

und dann mit diversen anderen CSS-Features zu „verzieren“ (insb. ::before und ::after) scheitert.

Liegt das an den Listen oder am CSS? Bring mal ein Live-Beispiel!

Ergebnis: eine div-Wüste,

Listen oder divs?

Oder schlicht Resignation, die intrinsische Frage, wieso man es nicht lieber gleich bei HTML 0.9 beläßt!

Fremdwörter kannst du! Respekt! Neue Rechtschreibung kommt noch!

Herzliche Grüße und ein schönes Wochenende!

Matthias Scharwies

[Q, ob nun aus der 007 oder Scharddreg-Phantasy-Welt]

„einen Hund, eine Katze, einen Föhn, ein …“ ist also keine Liste sondern ein Block!

Blöderweise müßte das Element dann aber <ub>, <ob> oder <db> heißen.

Mal „dem Duden“ mitteilen: das Beispiel ist kein korrektes Deutsch, es DARF NUR SO geschrieben werden:

einen Hund

eine Katze

einen Föhn

ein …

[Auge]

Hallo

„einen Hund, eine Katze, einen Föhn, ein …“ ist also keine Liste sondern ein Block!

Das ist schlicht eine Aufzählung. Die wird, wenn innerhalb eines Satzes notiert, wie du es zeigst, oder eben als Liste und dann (üblicherweise) untereinander als Listenpunkte. In dem Tutorial geht es nicht um Satzbau sondern um Listen. So what?

Tschö, Auge

[Q, ob nun aus der 007 oder Scharddreg-Phantasy-Welt]

Dann bedarf https://de.wikipedia.org/wiki/Liste wohl (auch) einer Korrektur?

[Auge]

Hallo

Dann bedarf https://de.wikipedia.org/wiki/Liste wohl (auch) einer Korrektur?

Warum?

„Eine Liste ist eine „schriftliche Zusammenstellung, Aufstellung … unter einem bestimmten Gesichtspunkt aufgeführter Personen oder Sachen“.[1] Die Darstellung erfolgt in einer einheitlichen, sich für die jeweiligen Einzelinhalte wiederholenden Form, beispielsweise als gleichartige Zeilen …“

Passt doch und erzeugt keinen Widerspruch zur Aufzählung innerhalb eines Satzes, die den gleichen Zweck erfüllt, aber eine andere Form einer Aufzählung ist!?

Tschö, Auge

[Q, ob nun aus der 007 oder Scharddreg-Phantasy-Welt]

Rächtschroibungk? Welche Version? Gar eine, die jende des kleinen roten Panda länst überholt hat?

Oder: dieser neumodische Kram, der steht doch in Reih und Glied mit, beispielsweise, dieser „Wissenschaftssendung“ letztens. Astronomie, das Universum usw. war die Thematik. Und plakativ, sowohl als Ton als auch als eingeblendeter Text: „das Scharze Loch … wiegt …“. — Nicht nur in der „Anstalt“ gibt es „Nefton“-Probleme.

[Rolf B]

Hallo Qnix,

schönen Gruß ans Kontinuum, sowie an Jean-Luc und Kathy!

<ul>
<header>Ich packe inh meinen Koffer</header>
<li>einen Hund</li>
<li>eine Katze</li>
<li>einen Föhn</li>
<li>ein …</li>
<li>…!</li>
</ul>

ist falsch, <header> als Kind von <ul> ist unzulässig. Eine Listen-Überschrift muss außerhalb der Liste stehen. Einfach als <p>, oder als passendes <h…> Element. <ul> darf enthalten:

• <li> Elemente
• <script> Elemente
• <template> Elemente

Erstaunlich, dass der Browser vor dem header nicht gleich erstmal das ul zumacht. Was wo enthalten sein darf, sagen Dir die Referenzseiten zu den Elementen im Selfwiki, oder Mozilla, oder die HTML Spezifikation. Die w3schools verraten Dir sowas allerdings nicht.

Aber das sollte Dir die List-Items nicht verhageln.

Einen Teil(!) dieser Effekte kann man gerade noch vermeiden, wenn man Whitespace(!) zwischen den Grenzen der Entities (also zwischen einem „>“ und dem folgenden „<“) weg nimmt.

Dass ::before-Inhalt, li-Inhalt und ::after-Inhalt umgebrochen werden, liegt daran, dass der Inhalt des li als Fließtext aufgefasst wird. Deshalb bleibt auch der Whitespace als eine Leerstelle erhalten. Hier kann es helfen, das li-Element mit display:inline-flex zu formatieren (was aber auch gleich das Listenverhalten entfernt) und flex-flow: row wrap; zu setzen. li Elemente haben ab Werk ein display:list-item, wenn dessen Entfernung stört, musst Du den li-Inhalt in ein span oder div packen und dem die passenden Styles geben. Muss aber alles nicht klappen, es hängt sehr davon ab, was Du da tust.

Tauschen von Whitespace gegen Kommentare ist eine weitere Möglichkeit, das kann man aber auch so machen. Schön ist allerdings anders:

<span>Hallo</span
><span>Welt</span>

(Kann ich jetzt nicht mit ~~~ formatieren weil der HTML-Formatter vom Forum darüber austickt)

Um Dir wirklich eine Lösung empfehlen zu können, müssten wir wissen, was genau Du erreichen willst.

Rolf

[Q, ob nun aus der 007 oder Scharddreg-Phantasy-Welt]

Na, wenn das so ist: einfach mal die da informieren:

• https://developer.mozilla.org/de/docs/Web/HTML/Element/header „Erlaubte Eltern Jedes Element, das fließende Inhalte akzeptiert.“

• https://developer.mozilla.org/de/docs/Web/HTML/Content_categories#flow_content „Die Flusselemente sind: … <dl> … <ol> … <ul>“

[Auge]

Hallo

Na, wenn das so ist: einfach mal die da informieren:

• https://developer.mozilla.org/de/docs/Web/HTML/Element/header „Erlaubte Eltern Jedes Element, das fließende Inhalte akzeptiert.“

Gegenprobe auf der MDN-Seite für ul (und identisch bei ol): „Erlaubter Inhalt: Null oder mehr <li>, <script> und <template> Elemente.“. Mehr is nich.

Tschö, Auge

[Rolf B]

Hallo Q,

„Die Flusselemente sind: … <dl> … <ol> … <ul>“

Du hast "Flusselement" und "Element mit Flussinhalt" verwechselt. Also die „Außen-“ und „Innen-“seite des Elements.

Rolf

[Q, ob nun aus der 007 oder Scharddreg-Phantasy-Welt]

Hab’ ich das verwechselt? Oder habe ich nur, gerade von der Header-Seite ausgehend, auf den Link mit „fließende Inhalte“ geklickt?

[Rolf B]

Hallo Q,

hast Du. Und dann hast Du fließenden Inhalt mit Flusselementen verwechselt.

Flusselemente sind fließender Inhalt. Das heißt nicht, dass sie fließenden Inhalt enthalten dürfen.

Beispiel: <p>. Ist ein Flusselement, darf aber nur „phrasing content“ enthalten. Beispiel: <ul>. Ist ein Flusselement, hat aber gar keine Kategorie als Inhalt. Statt dessen sind die erlaubten Inhalte explizit aufgezählt: <li>, <script> und <template>.

Wer lesen kann, ist klar im Vorteil. Wer das, was er liest, dann auch noch versteht, gewinnt das Rennen. Ich warne übrigens vor der "deutschen" MDN. Der deutsche Inhalt hat schon lange kein Betreuungsteam mehr und sie erstellen das jetzt durch einen Automatischen Idioten („AI“).

Rolf

[Q, ob nun aus der 007 oder Scharddreg-Phantasy-Welt]

Ach so, da war ja noch eine Frage. Und das gleich auch als Antwort: „warum gibt’s kein responsives …“. Oder: Listen, die nicht Blockwarte sein wollen.

[Rolf B]

Hallo Q, ob nun aus der 007 oder Scharddreg-Phantasy-Welt,

Wieso gibt es nicht „längst“ einen „responsiven“ Ersatz für die alten HTML-Listen? Immerhin verbinden die alle Inhalte mit der Darstellung.

Diese Verbindung gab es im Netscape Navigator 2 oder so. Danach hat man die Navigator-Darstellung reverse-engineered und CSS draus gemacht. Dieses kannst Du komplett überschreiben.

Was Du nicht ändern kannst, ist die Semantik der HTML-Elemente und ihre Inhaltsmodelle. Die sind vorgegeben. Weshalb caption in ul verboten ist. Sowas verrät Dir im Zweifelsfall ein HTML Validatortool wie dieses. Wobei deine Kühnheit ihn schon ordentlich verwirrt…

<ul>
<caption>Hallo</caption>
<li>Eins</li>
<li>Zwei</li>
<li>Viertelvordrei</li>
</ul>

Rolf

[Q, ob nun aus der 007 oder Scharddreg-Phantasy-Welt]

Nun, es gibt, und zwar auch „innerhalb MDN“, Diskrepanzen zu dieser Frage. Immerhin: man kann sich fragen, was früher da war (Feuerzangenbowle?) — und was dann möglicherweise keine Rücksicht auf später Hinzugekommenes nimmt.

Aber egal: streicht man den <header>, so ändert sich doch nichts an der Frage nach responsivem Ersatz.

[Rolf B]

Hallo Q,

so ändert sich doch nichts an der Frage nach responsivem Ersatz.

Die stellst Du Dir alleine und wir haben Dir gesagt: Listen sind bereits responsiv.

Eine inline-Liste erzeugt man entweder mit display:flex auf dem ul/ol Element oder durch display:inline auf ul/ol und li. Die Listenpunkte kommen durch das display:inline auf den li automatisch weg, weil li per Default ein display:list-item hat und die Marker nur für List-Items erzeugt werden.

Etwas knifflig ist es allerdings, ul in ein p Element zu packen, weil ul eben flow content und kein phrasing content ist. Die Browser zicken da rum und beenden das p vor dem ul. Aber gut, das kann man umgehen. Schön ist zwar anders…

<div role="paragraph">
Ich packe mein Raumschiff und nehme mit:
<ul class="inline">
<li>einen Jean-Luc</li>
<li>eine Kathy</li>
<li>einen Continuum-Hopper</li></ul>. 
Sonst noch Fragen?
</div>

div[role=paragraph] { margin: 1em 0; }
ul.inline {
  padding: 0;
  display: inline;
  li { display: inline; 
    &::after { content: ", "; }
    &:nth-last-of-type(2)::after { content: " und "; }
    &:last-of-type::after { content: ""; }
  }
}

Ob sich das für einen Screenreader schön anhört, ist eine weitere Frage…

Rolf

[Gunnar Bittersmann]

@@Rolf B

<li>einen Continuum-Hopper</li></ul>. 
Sonst noch Fragen?

Ja, da hab ich eine. Hat der Continuum-Hopper, den du da mitnimmst, die Initialen WC?

Jolan tru

[Rolf B]

Hallo Gunnar,

hihi, ich hab's sogar verstanden. Bin ich nicht ein Wunderkind? Aber... Continuum, nicht Time!

Rolf

[Gunnar Bittersmann]

@@Q, ob nun aus der 007 oder Scharddreg-Phantasy-Welt

Den Inhalt in verschiedene Darstellungsformen zu zwingen (hier wäre es erst einmal eine Inline-Liste) und dann mit diversen anderen CSS-Features zu „verzieren“ (insb. ::before und ::after) scheitert.

Tut es das?

Und zwar, hier im Beispiel, daran, daß so beigefügte Darstellungselemente immer wieder als nicht dem Element zugehörig betrachtet werden, welchem sie von der topologischen Struktur her zugeordnet wären. Sprich: das ::before und/oder ::after-Element wird (oftmals ohne jegliche Not!) umgebrochen und damit vom Element getrennt.

Kann ich auf den lower decks nicht nachvollziehen. Auf den upper decks auch nicht.

Kwakoni Yiquan

[Q, ob nun aus der 007 oder Scharddreg-Phantasy-Welt]

Tut es. Immer wieder einmal. Wenn man den Kram dazu zu zwingen versucht, eine Liste als Liste darzustellen, wie sie Leute verfassen, die „mal eben“ etwas „nicht technisch organisiert“ auflisten wollen. Also etwas in ähnlicher Qualität wie das „ich packe“ Beispiel:

Wenn die <li>s mittels ::after z.B. durch Kommata getrennt, vor dem letzten <li> mit einem „und“ verbunden und letztendlich einem „.“ beendet werden sollen, dann finden sich diese (gut, beim „und“ macht es nichts) Anhängsel schnell abgetrennt am Anfang der nächsten Zeile. — Gibt’s dafür einen analogen Ausdruck zum „Plenken“?

Das jedenfalls auch dann, (gerade dann?) wenn <li> ein display: inline block verordnet bekommt/bekam (mit inline klappt es gleich doppelt nicht). Und: da ist jetzt noch nicht mal darauf geschielt, daß eine solche, eine wahre Liste (ohne Darstellungs-Diktat), ja auch ein Inline-Element (gar als Liste von Listen?) sein könnte. Wenn also <dl>/<ul>/<ol> das Blockwart-Dasein ganz aufgeben müß(t)en — display: contents.

[Gunnar Bittersmann]

@@Q, ob nun aus der 007 oder Scharddreg-Phantasy-Welt

Tut es. Immer wieder einmal.

Lass sehen!

Wenn die <li>s mittels ::after z.B. durch Kommata getrennt, vor dem letzten <li> mit einem „und“ verbunden und letztendlich einem „.“ beendet werden sollen, dann finden sich diese (gut, beim „und“ macht es nichts) Anhängsel schnell abgetrennt am Anfang der nächsten Zeile.

Ich hatte ein Beispiel erstellt, wo genau das nicht passiert. Wenn du jetzt das Gegenteil behauptest, dann zeige das an einem Beispiel anstatt rumzuschwafeln.

Jolan tru