Selektoren in verschachtelten Listen

[michat]

Hi

in einer ul li ul li Liste versuche ich Abstände zu definieren, die sich nur auf ul li, nicht aber auf ul li ul li auswirken sollen ... was so einfach jedoch nicht funktioniert eben weil ul li auch die li Elemente auf der zweiten Ebene selektiert (hier wäre soetwas wie eine Pseudoklasse ":stage", ":level" wünschenswert).
Es wird vermutlich klappen wenn ich zunächt die gewünschte Formatierung für (und mittels dieses Selektors) ul li  definiere und anschließend die unerwünschten für ul li ul li  überschreibe.

Alternativ könnte ich auch eine normale Klasse mit den gewünschten Eigenschaften definieren, die ich dann den Elementen der ersten Ebene zuweise.

Oder ginge das doch noch einfacher?

bye

MH

[Matthias Apsel]

Om nah hoo pez nyeetz, michat!

Oder ginge das doch noch einfacher?

>

Matthias

[Der Martin]

Hallo,

Oder ginge das doch noch einfacher?
>

dieser Vorschlag setzt aber etwas voraus, das du vergessen hast zu erwähnen - nämlich dass z.B. die oberste Ebene durch ein besonderes Merkmal, etwa eine ID des obersten ul-Elements, erkennbar ist. Denn sonst träfe der Selektor ul>li auch auf die untergeordneten Listen zu, und Micha hätte nichts gewonnen.

Ciao,
 Martin

[Matthias Apsel]

Om nah hoo pez nyeetz, Der Martin!

dieser Vorschlag setzt aber etwas voraus, das du vergessen hast zu erwähnen - nämlich dass z.B. die oberste Ebene durch ein besonderes Merkmal, [...], erkennbar ist.

korrekt

etwa eine ID des obersten ul-Elements

oder eben die Tatsache, dass dieses ul-Element das oberste ist, selektiert etwa per nav > ul.

Matthias

[Gregorius]

Hallo

wie siehts aus mit ul:first-child li ? Sollte doch gehen?

Noch einfacher, super Ansatz!

[Matthias Apsel]

Om nah hoo pez nyeetz, Gregorius!

wie siehts aus mit ul:first-child li ? Sollte doch gehen?

Du verkennst, dass die ul nicht zwingend ein erstes Kind ihres Elternelements sein muss.

<nav>  
  <h2>  
  <ul>

Hier würde die Pseudoklasse first-of-type zutreffend sein. Also genau wie mein Vorschlag nav > ul mangels Kenntnis des HTML nur Spekulation.

Matthias

[michaa aka michat]

Hi

... Also genau wie mein Vorschlag nav > ul mangels Kenntnis des HTML nur Spekulation.

Erstmal danke für den Hinweis mit dem ">" Kombinator.

Das war ein kurzes Wechselbad der Gefühle auf Grund meiner Schnelleinschätzungen:

"Kombinator"

Klasse, so klappt das

"ul>li"

Neeeee, so kann das nicht klappen, das hatte ich in ähnlicher Form schon

nav>ul

Och nöööö. Ich hab heut' den halben Nachmittag damit verbracht das nav Element zu eliminieren. Weil ja ul auch ein Blockelement ist und man sich ein umschließendes nav somit eigentlich sparen kann. Sagt jetzt nicht dass das nav Element schön macht oder sonst zu was besonderes wichtigem nutze ist.

Gut dass ich glaube ;-) mit dem nächsthöheren Element, der umgebenden Box, das selbe erreichen zu können. Grad noch 'mal gut gegangen. Ma schaun ...

ubox>ul li sollte tun was ich erreichen will

Gruß

Michael

[Kai345]

[latex]Mae  govannen![/latex]

nav>ul

Och nöööö. Ich hab heut' den halben Nachmittag damit verbracht das nav Element zu eliminieren. Weil ja ul auch ein Blockelement ist und man sich ein umschließendes nav somit eigentlich sparen kann. Sagt jetzt nicht dass das nav Element schön macht oder sonst zu was besonderes wichtigem nutze ist.

Ja, das ist (mal wieder) die übliche Idiotie von HTML5.

Jahrelang wurde gegen unsinniges Markup wie

<div id="nav"><ul>.....</ul></div>

gekämpft und nun wird einfach div durch nav ersetzt, statt das nav-Element direkt so zu gestalten, daß man damit und einem entsprechenden Kind-Element damit verschachtelte Strukturen aufbauen kann und eine inliegende ul nicht benötigt.

So ist es nichts anderes als ein etwas semantischer benanntes <div id="nav">

Stur lächeln und winken, Männer!
Kai

[Gregorius]

ist halt nur wegen dem IE, aber du hast recht…

[Matthias Apsel]

Om nah hoo pez nyeetz, Kai345!

Jahrelang wurde gegen unsinniges Markup wie
<div id="nav"><ul>.....</ul></div>
gekämpft

unsinnig (<div id="nav"><ul>.....</ul></div>)

vs.

sinnvoll (<div id="nav"><h2>...</h2><ul>.....</ul></div>)

Matthias

[michaa aka michat]

Hi

sinnvoll (<div id="nav"><h2>...</h2><ul>.....</ul></div>)

Offen gestanden hat mir Kai aus der Seele gesprochen. Und im Grunde eigentlich auch dir. Denn genau das was du mit dem eingeschlossenen <h2>...</h2> zu erreichen suchst hat mich heute die meiste Zeit gekostet: Man braucht vielleicht nicht zwingend eine Überschrift im Menü, aber - dein Beispiel ist ja die abstrakte Vorlage dafür - ein dementsprechender Wunsch kann doch bestehen.

Und da bin ich heute verzweifelt mit dem Versuch einerseits das <div id="navigation"> loszuwerden aber andererseits dem ul eine Überschriftfunktion abzuringen.

<ul>Überschrift
<li>seite 1
<ul>
<li>punkt 1<li>
<li>punkt 2<li>
...

Semantisch ist deine abstrakte Vorlage durchaus nachvollziehbar, eine Überchrift ist eine Überschrift ist eine Überschrift. Aber wenn man dasn schon ein nav-Element einführt wäre es schon naheliegend gewesen dies mit genau dieser fehlenden Eigenschaft auszustatten.
Ich hab's am Anfang gar nicht begriffen, dass ich keine div-Suppe erstellen soll. Langsam ist's dann gedämmert, dass div nur das allgemeinste Blockelement neben anderen, vordefinierten Blockelementen ist. Aber dass wir jetzt die Eigenschaftslosigkeit des neuen nav-Elements, was ggf. erst das h2 notwendig macht, für sinnvoll erachten sollen geht mir nicht ein.

[Matthias Apsel]

Om nah hoo pez nyeetz, michaa aka michat!

<ul>Überschrift
<li>seite 1
<ul>
<li>punkt 1<li>
<li>punkt 2<li>

ist ungültiges HTML.

was ggf. erst das h2 notwendig macht, für sinnvoll erachten sollen geht mir nicht ein.

s.o. Die h2 wird nicht notwendig gemacht. Sie ist innerhalb einer Liste nicht erlaubt.

Matthias

[michat]

Hi

<ul>Überschrift
<li>seite 1
<ul>
<li>punkt 1<li>
<li>punkt 2<li>

ist ungültiges HTML.

ja eben!

bye

MH

[Kai345]

[latex]Mae  govannen![/latex]

unsinnig (<div id="nav"><ul>.....</ul></div>)

vs.

sinnvoll (<div id="nav"><h2>...</h2><ul>.....</ul></div>)

Für entsprechende Interpretation von sinnvoll. Wie schon im anderen Beitrag angedeutet, hätte _ich_ es für sinnvoll gehalten, das nav-Element entsprechend auszustatten. Was spräche gegen ein nav-Element, daß bspw. zwei (oder drei) verschiedene Kind-Elemente haben kann, je eines für Überschrift, Navigationspunkte (und Sub-Navigation). Ist doch ein neues Element, man hätte daher keinerlei Rückwärtskompatibilität beachten müssen.

Stur lächeln und winken, Männer!
Kai

[Matthias Apsel]

Om nah hoo pez nyeetz, Kai345!

Was spräche gegen ein nav-Element, daß bspw. zwei (oder drei) verschiedene Kind-Elemente haben kann, je eines für Überschrift, Navigationspunkte (und Sub-Navigation).

Was spricht gegen ein nav-Element, das beliebige andere Elemente enthalten darf? Obwohl mir zugegebenermaßen auch nicht so viele Varianten einfallen, die sinnvoll sein könnten. Etwa ein kleiner Footer in der Navigation. "Zu Risiken und Nebenwirkungen lesen sie bitte die <a href=  ..."

Ich finde eine solche Freiheit viel besser, als auf bestimmte Elemente angewiesen zu sein.

Interessant und sinnvoll hätte ich ein lh-Element (list heading) gefunden oder auch das gruppierende di-Element.

Matthias

[Gunnar Bittersmann]

@@Matthias Apsel:

nuqneH

Interessant und sinnvoll hätte ich ein lh-Element (list heading) gefunden

Go figure (no pun intended):

<figure>  
  <figcaption>list heading</<figcaption>  
  <ul> … </ul>  
</figure>

oder auch das gruppierende di-Element.

Das unbedingt.

Qapla'

[Kai345]

[latex]Mae  govannen![/latex]

Om nah hoo pez nyeetz, Kai345!

Was spräche gegen ein nav-Element, daß bspw. zwei (oder drei) verschiedene Kind-Elemente haben kann, je eines für Überschrift, Navigationspunkte (und Sub-Navigation).

Was spricht gegen ein nav-Element, das beliebige andere Elemente enthalten darf?

Einerseits nichts.  Allerdings dürfte in gefühlten 90% der Fälle eben <nav><ul>…</ul></nav> dabei herauskommen. Und schon hat man wieder die Problematik* von UL zu beachten. Hier hätte man mit einer flexiblen STrukturvorgabe, die nicht unbedingt zwingend sein müßte, zwei Probleme erledigen können. Einerseits nav als Container für *-Elemente, andererseits wahlweise eine Strukturvorgabe, die verschachtelte Navigationen (mit Überschriften  in jedem Level) einfach möglich macht:

<nav>
  <nh>Die Navigation</nh>
  <ni>foo</ni>
  <ni>bar</ni>
</nav>

<nav>
  <nh>Die Navigation</nh>
  <ni>foo</ni>
  <ni>bar</ni>
  <nav>
    <nh>Die Sub-Navigation</nh>
    <ni>baz</ni>
    <ni>qux</ni>
    <p>Hinweis: lorem ipsum</p>
  </nav>
</nav>

Stur lächeln und winken, Männer!
Kai

* nur LI als Kind möglich, Verschachtelung in weiterer UL nur als Kind von LI erlaubt. Spätestens bei Sub-Überschriften in einem tieferen Level muß man wieder die „altbewährten“ unflexiblen Strukturen verwenden.

[Gunnar Bittersmann]

@@Kai345:

nuqneH

Ja, das ist (mal wieder) die übliche Idiotie von HTML5.

Das ist Unsinn. (Nicht das nav-Element, sondern deine Einschätzung.)

So ist es nichts anderes als ein etwas semantischer benanntes <div id="nav">

Na und ob es was anderes ist!

Hier entlang.

Qapla'

[Matthias Apsel]

Om nah hoo pez nyeetz, michaa aka michat!

Och nöööö. Ich hab heut' den halben Nachmittag damit verbracht das nav Element zu eliminieren. Weil ja ul auch ein Blockelement ist und man sich ein umschließendes nav somit eigentlich sparen kann. Sagt jetzt nicht dass das nav Element schön macht oder sonst zu was besonderes wichtigem nutze ist.

Es hat vor allem eine semantische Bedeutung, weil sich eben die Navagion zusammenfassen lässt. Etwa

<nav>  
  <h2>Überblick</h2>  
  <ul>  
    <li>...  
    ...  
  </ul>  
  ggf. noch weitere Elemente  
</nav>

ubox>ul li sollte tun was ich erreichen will

Nein. Denn du selektierst wieder _alle_ li-Elemente innerhalb einer besonderen ul. (Eine, die direkter Nachfahre eines fiktiven Elements ubox ist.)

Matthias

[michat]

Hi

ubox>ul li sollte tun was ich erreichen will

Nein. Denn du selektierst wieder _alle_ li-Elemente innerhalb einer besonderen ul. (Eine, die direkter Nachfahre eines fiktiven Elements ubox ist.)

Agrrr.

#ubox > ul > li

müsste es wohl tun.

bye

MH

[Gunnar Bittersmann]

@@michaa aka michat:

nuqneH

Och nöööö. Ich hab heut' den halben Nachmittag damit verbracht das nav Element zu eliminieren.

Dann kannst du den Vormittag dazu nutzen, es wieder zu deeliminieren.

Sagt jetzt nicht dass das nav Element schön macht oder sonst zu was besonderes wichtigem nutze ist.

Natürlich ist es das!

“User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip and/or provide on request.” [HTML5]

(Und wenn nicht das nav-Element verwendet wird, dann bitte das WAI-ARIA-Attribut @role="navigation".)

Qapla'

[michat]

Hi

Dann kannst du den Vormittag dazu nutzen, es wieder zu deeliminieren.
... [HTML5]

[schnauf]püüüühhhhhh[/schnauf]

Ich bin hier mit meiner Steite mit Mühe auf dem Stand von xhtml und verwende bislang keine html5-Elemente (ich will mich dem bestimmt nicht verschießen, aber ich arbeite eben im Bestand).

Hast du nen Link zu ner Seite auf der ich mir einen *Überblick* verschaffen kann, was an Browserkompatibilität in die Fritten geht wenn ich nun für die betreffende Website einen entsprechenden Doctype für html5 festlege und zusätzlich zum xhtml Bestand mindestens das nav-Element verwende.
Was ist von einer xhtml-Seite noch brauchbar für IE ab 7 (besser noch 6, aber dafür hab ich dann doch nur noch Mitleid soweit Zusatzaufwand das Überspringen recht niedriger Hürden berdeutet), Webkitbrowser (Chromium, Safari), mittelgut abgehangene Geckos, Opera ab 10? Brauche ich dann nur Würgarounds für das nav-Element (so es diese überhaupt gibt) oder erwartet mich ein komplettes Land der Tränen?

Danke für deine Infos und Links bisher.

bye

MH

[Kai345]

[latex]Mae  govannen![/latex]

Hast du nen Link zu ner Seite auf der ich mir einen *Überblick* verschaffen kann, was an Browserkompatibilität in die Fritten geht wenn ich nun für die betreffende Website einen entsprechenden Doctype für html5 festlege und zusätzlich zum xhtml Bestand mindestens das nav-Element verwende.

Man ist - für IE8 und kleiner auf Javascript angewiesen, damit diese Browser die neuen Elemente erkennen und man sie stylen kann. Ohne das ist Essig mit HTML5 und alten IE.

Dann kann man noch nachhelfen, was die Erkennung von Features angeht, das ist aber auch bei nicht-HTML5 durchaus nützlich. Allerdings - beides erfordert halt aktives Javascript, ein simples Fallback sollte also sein (d.h. daß dann alles lesbar ist und nicht durch nicht erkannte Elemente hellgrauer text auf weißem Hintergrund steht. Mehr Aufwand sollten uralte Browser wie IE6/7 aber nicht unbedingt wert sein.

Was ältere Versionen anderer Browser angeht, würde ich zuerst mal bei caniuse.com vorbeischauen.

Was ist von einer xhtml-Seite noch brauchbar für IE ab 7 (besser noch 6, aber dafür hab ich dann doch nur noch Mitleid soweit Zusatzaufwand das Überspringen recht niedriger Hürden berdeutet)

IE6 ist seitens der Firma Microsoft für tot erklärt worden, wenn du nicht gerade eine Site baust, die bestimmte große Firmen anspricht, kann man auf IE6-Support meines Erachtens komplett verzichten. Und die Hürde ist nicht wirklich niedrig, je nach dem, was mit rein soll, insbesondere bei Javascript.

Stur lächeln und winken, Männer!
Kai

[michat]

Hi

Man ist - für IE8 und kleiner auf Javascript angewiesen, damit diese Browser die neuen Elemente erkennen und man sie stylen kann. Ohne das ist Essig mit HTML5 und alten IE.

Da ich von JS sowenig Ahnung habe wie der Wolf vom Eierlegen stellt das für mich ne gewaltige Hürde da. Dass meine Seite derzeit auf JS nicht angewiesen ist betrachte ich als Feature. Allerdings sehe ich schon, dass die Zukunft nicht darin liegen kann auf das Aussterben des IE 8 zu warten.

Dann kann man noch nachhelfen, was die Erkennung von Features angeht,

Eines ist mir bei der Verwendung dieses Modernizrs nicht klar: Wie gelangt der dynamisch erzeugte neue/zusätzliche Sourcecode in meine Quellen? Ich meine dauerhaft. Muß ich da für jede einzele meiner Seiten den neuen Quellcode im Browser suchen und per Hand in meine Quellen kopieren? Ich kapiers nicht (und bezweifle, dass ich dies für die gegenwärtige Seite in Angriff nehme).

Was ältere Versionen anderer Browser angeht, würde ich zuerst mal bei caniuse.com vorbeischauen.

Danke dafür. Hatte ich zwischenzeitlich ergoogelt.

bye

MH

[Der Martin]

Hallo,

Da ich von JS sowenig Ahnung habe wie der Wolf vom Eierlegen ...

na das ist doch mal ein netter Vergleich! Muss ich mir merken. :-)

Ciao,
 Martin

[michaa aka michat]

Hi

Man ist - für IE8 und kleiner auf Javascript angewiesen, damit diese Browser die neuen Elemente erkennen und man sie stylen kann. Ohne das ist Essig mit HTML5 und alten IE.

Moment, verstehe ich das richtig: Alles was ich zu tun habe um IE 6/7 mit html5 Würgarounds zu versorgen ist den auf der verlinkten Wikipediseite angegeben Codeschnippsel in den/die Seitenheader zu kopieren und die library auf meinen webserver hochzuladen?

Gruß

Michael

[Matthias Apsel]

Om nah hoo pez nyeetz, michaa aka michat!

Moment, verstehe ich das richtig: Alles was ich zu tun habe um IE 6/7 mit html5 Würgarounds zu versorgen ist den auf der verlinkten Wikipediseite angegeben Codeschnippsel in den/die Seitenheader zu kopieren und die library auf meinen webserver hochzuladen?

Ja.

Auch wenn ich das anders formulieren würde: Du möchtest die Browser nicht mit Workarounds versorgen, sondern html5 shiv ist ein workaround (und keine Bibliothek), der die HTML-5-Elemente bei den Browsern bekannt macht.

Matthias

[Kai345]

[latex]Mae  govannen![/latex]

Moment, verstehe ich das richtig: Alles was ich zu tun habe um IE 6/7 mit html5 Würgarounds zu versorgen

…und IE8; der kann's auch noch nicht.

Stur lächeln und winken, Männer!
Kai

[michat]

Hi

(Und wenn nicht das nav-Element verwendet wird, dann bitte das WAI-ARIA-Attribut @role="navigation".)

Eigentlich hatte ich mich nun schon fast entschieden, nach überschlägiger Abwägung der Pros und Cons, dieses WAI-ARIA-Attribut zu verwenden.

Ich müßte vermutlich den bestehenden Doctyp

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

zu

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN"
  "http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">

oder

<!DOCTYPE html>

ändern und könnte einfach das Attribut an entsprechender Stelle einfügen.

Irritiert bin ich von der Frage ob das dann tatsächlich noch valider Code ist und vielmehr noch hiervon:

“ It is not appropriate to use these document types for live content. These are made available only for download, to support local use in development, evaluation, and validation tools. Using these versions directly from the W3C server could cause automatic blockage, preventing them from loading.”

Zitata von hier: http://www.w3.org/TR/wai-aria/appendices#xhtml_dtd

Im Moment lasse ich erstmal alles wie es ist.

Gruß und Danke für eure Mühen.

MH

[michat]

Hi

also, dieses Dokumenten verstehe ich so, dass ich das role-Attribut mit XHTML verwenden kann, und dies im IE ab einschl. IE8 aufwärts verstanden wird.

Nachteil: Seite validiert nicht als XHTML.

Abhilfe: <!DOCTYPE html>

oder

DTD für XHTML erweitern (was für mich aber auch erstmal ne neue und große Baustelle wäre)

Spricht irgendetwas gegen <!DOCTYPE html> statt XHTML 1.0 (strict)

Funktionieren damit IE hacks wie dieser:

*+html li { list-style: disc; }

bye

MH

[Gunnar Bittersmann]

@@michat:

nuqneH

Spricht irgendetwas gegen <!DOCTYPE html> statt XHTML 1.0 (strict)

Nein. (Außer dass der Validator dann nicht gemäß XML-Syntaxregeln prüft.)

Funktionieren damit IE hacks wie dieser:
      *+html li { list-style: disc; }

Dem Renderer ist es völlig egal, in welcher HTML-Version das Dokument geschrieben wurde.

Den Renderer interessiert lediglich, ob Quirks- oder Standardmodus; nicht aber, durch welche DOCTYPE-Angabe dieser hervorgerufen wurde.

Dem HTML-Parser ist die HTML-Version auch völlig egal. Es gibt nur einen HTML-Parser im Browser, welchen alle HTML-Dokumente unabhängig von der HTML-Version durchlaufen.

Qapla'

[Gunnar Bittersmann]

@@michat:

nuqneH

(Und wenn nicht das nav-Element verwendet wird, dann bitte das WAI-ARIA-Attribut @role="navigation".)

Eigentlich hatte ich mich nun schon fast entschieden, nach überschlägiger Abwägung der Pros und Cons, dieses WAI-ARIA-Attribut zu verwenden.

Wie ich letztens schon sagte, ist die Verwendung der richtigen Elemente (hier also nav) dem @role-Attribut vorzuziehen.

Ich müßte vermutlich den bestehenden Doctyp
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
zu
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN" "http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">
oder
<!DOCTYPE html>
ändern

Eher letzters. Und dann kannst du auch das nav-Element verwenden.

Qapla'

[Gunnar Bittersmann]

@@Gregorius:

nuqneH

wie siehts aus mit ul:first-child li ? Sollte doch gehen?
Noch einfacher, super Ansatz!

Nur leider falsch.

Qapla'

[Gregorius]

Nur leider falsch.

also müsste es in etwas so heißen?
zB: #nav ul:first-child > li {}

[Matthias Apsel]

Om nah hoo pez nyeetz, Gregorius!

also müsste es in etwas so heißen?
zB: #nav ul:first-child > li {}

trifft auf

<div id="nav">  
  <h2>  
  <ul>  
    <li>Dieses Listenelemt</li>

nicht zu.

Matthias

[Gregorius]

Und wie siehst mit dem aus: #nav :first-child li {}

[michaa aka michat]

Und wie siehst mit dem aus: #nav :first-child li {}

<wasauchimmer> :first-child <wasauchimmerer>

wählt immer nur das *erste* Vorkommen des Folgeelements aus. Nie jedoch *alle* Vorkommen des Folgeelements auf der zweiten Hierarchieebene.

[Gregorius]

das greift bei mir

[Matthias Apsel]

Om nah hoo pez nyeetz, Gregorius!

Und wie siehst mit dem aus: #nav :first-child li {}

Das ist noch schlimmer. #nav :first-child wählt schon mal _alle_ (in beliebiger Tiefe) Elemente, die erstes Kind eines beliebigen anderen Elements sind. li (Leerzeichen!), _alle_ li-Elemente, die in beliebiger Tiefe folgen.

Matthias

[Gregorius]

Und wie siehst mit dem aus: nav :first-child ul li {}

Hier das Beispiel

[Matthias Apsel]

Om nah hoo pez nyeetz, Gregorius!

Und wie siehst mit dem aus: nav :first-child ul li {}

Hier das Beispiel

versagt, wenn du eine weitere untergeordnete Liste einfügst.

Matthias

[Gregorius]

Ja dann halt so

[Matthias Apsel]

Om nah hoo pez nyeetz, Gregorius!

Ja dann halt so

Dann sind wir aber wieder da, wo wir am Anfang waren: Etwas für alle Listenelemente definieren

nav li {foo:bar}

und für die nachfolgenden überschreiben

nav li li {foo:quz}

Auf das Überschreiben möchte man gern verzichten. Passend für dein Beispiel

nav > ul > li

Beide dieser Wege sind gangbar, aber die Ausgangsfrage war halt, das Überschreiben zu vermeiden.

Matthias

[Gregorius]

klar wenn die Tiefe nicht definiert ist, wird das wohl ohne class||id nichts werden…

[Der Martin]

Hallo,

also müsste es in etwas so heißen?
zB: #nav ul:first-child > li {}

nein, du bist einem Missverständnis aufgesessen. Es geht hier nicht um den ersten Eintrag in einer Liste, oder die erste Liste in einem Container, sondern um die Hierarchie von Listeneinträgen, also quasi die Verschachtelungstiefe. Die Pseudoklasse :first-child selektiert ja nur das erste Element _einer_ Hierarchieebene.

Btw: Dein Beispiel selektiert alle Listeneinträge innerhalb einer unsortierten Liste, die ihrerseits das erste Kindelement in einem Container mit der ID "nav" ist.

Ciao,
 Martin

[MudGuard]

Hi,

in einer ul li ul li Liste versuche ich Abstände zu definieren, die sich nur auf ul li, nicht aber auf ul li ul li auswirken sollen ...

:not(li) > ul > li

(Browserunterstützung darfst Du selbst ermitteln)

cu,
Andreas

[Matthias Apsel]

Om nah hoo pez nyeetz, MudGuard!

:not(li) > ul > li

Mit der Verneinung ist das so eine Sache: Kommt jetzt später nach vielen vielen Jahren auf einer beliebigen Inhaltsseite eine Liste hinzu, ...

Matthias