[Résolu]Le premier li visible

Bonjour !

C'est peut-être simple mais j'avoue que je ne vois pas...

Je me suis fait une page de liens qui sont séparés par des 'border-top', le premier lien de chaque catégorie ne reçoit pas le 'border-top'.

Jusqu'ici, c'est simple.

Seulement voilà dans la 'version basique', certains 'li' sont cachés...

Si le premier 'li' est invisible, c'est quand même lui qui est ciblé et ce n'est pas le premier 'li' visible qui s'abstient du border-top...

D'où un trait embêtant au début...

http://codepen.io/Zelena/pen/XKrPwq

Des idées ?

Modifié par Zelena (26 May 2016 - 20:24)

Salut,

Bon, étant donné qu'il n'y a pas de sélecteur :visible ou :hidden, donc c'est pour moi impossible en CSS, mais dans ton cas précis, je te propose de truander le système :

.invisible:first-child+li,
.invisible:first-child+.invisible+li,
.invisible:first-child+.invisible+.invisible+li,
.invisible:first-child+.invisible+.invisible+.invisible+li { border-top: none; }

Oui je sais, c'est dégueulasse

Et si le nombre de lignes n'est pas fixe ?

Oui, je commence à me dire que c'est impossible en CSS et que la seule solution est en Javascript...

Cela dit, j'apprécie l'effort.

Bon alors, ne me demande pas trop pourquoi (trop pour mon cerveau ce soir), mais...

li{
  border-top : none;
}
li:not([class*="invisible"]) + li{
  border-top : none;
}
li:not([class*="invisible"]) + li +li {
  border-top : cyan 1px solid !important;
}
ul > li:not([class*="invisible"]) + *, 
ul > li:not([class*="invisible"]) ~ * ~ li[class*="invisible"] ~ * {
  border-top : cyan 1px solid !important;
}

... semble fonctionner !

Dérivée d'une solution vue sur stackoverflow
Modifié par SolidSnake (26 May 2016 - 19:32)

Ça a l'air de marcher, oui...

Sacré morceau de CSS... j'aimerais comprendre mais ce soir, aucune chance (je suis du matin).

Résolu, donc...

Merci infiniment.

Zelena a écrit :
Bonjour !
C'est peut-être simple mais j'avoue que je ne vois pas...
Je me suis fait une page de liens qui sont séparés par des 'border-top', le premier lien de chaque catégorie ne reçoit pas le 'border-top'.
Jusqu'ici, c'est simple.
Seulement voilà dans la 'version basique', certains 'li' sont cachés...
Si le premier 'li' est invisible, c'est quand même lui qui est ciblé et ce n'est pas le premier 'li' visible qui s'abstient du border-top...
D'où un trait embêtant au début...
http://codepen.io/Zelena/pen/XKrPwq
Des idées ?

Si j'ai bien compris le problème :
- création de LI avec attribut @class à "visible" ou "invisible"
- possibilité d'insérer un filet de séparation mais pas au-dessus du premier élément visible
Pourquoi ne pas jouer sur la balise HR au lieu de styler la bordure en CSS ?

<ul>
      <li class="invisible">Premier élément</li>
        <hr class="invisible"/>
      <li>Deuxième élément</li>
        <hr/>
      <li>Troisième élément</li>
        <hr/>
      <li class="visible">Quatrième élément</li>
        <hr/>
      <li>Cinquième élément</li>
</ul>

ul
{
width : 15rem;
list-style-type : none;
}
ul>hr
{
height:2px;
background-color:black;
}
.invisible
{
display : none;
}

Un traitement "manuel" mais, a priori, cela devrait fonctionner et tu as la main sur les séparations que tu veux activer ou non, espacer en hauteur, épaissir

@Zelena et @SolidSnake : Hou là là ! que vois-je ?

Je vous propose plus light :

ul {
  width: 15rem;
  list-style-type: none;
}
li + li {
  border-top: Cyan 1px solid;
}
.invisible {
  display: none;
}
.invisible:first-child + li {
  border: none;
}

Le CodePen ici : List items

@sepecat : des balises hr dans une liste c'est pas terrible sémantiquement.

Olivier C a écrit :
@sepecat : des balises hr dans une liste c'est pas terrible sémantiquement.

Ben, à mon avis, on est justement en plein dans la sémantique de la balise en question.
Sauf erreur, le rôle d'un HR est bien de servir de séparateur, ou alors il faut que je revoie dare dare les spécifications

sepecat a écrit :
Sauf erreur, le rôle d'un HR est bien de servir de séparateur, ou alors il faut que je revoie dare dare les spécifications

Effectivement, car si le <hr> sert bien de séparateur, il ne peut être mis en élément enfant direct d'une liste. Mais même si le cas avait été possible, séparer chaque items d'une liste n'aurait été que de peu d'intérêt puisque ces items, de par leur conception, sont repérés comme étants séparés.
Modifié par Olivier C (27 May 2016 - 10:02)

Hello,

Un petit essai sur base du codepen d'Olivier...

Bonjour !

J'ai essayé d'arriver à un code plus simple que celui de Solid Snake...

Et j'ai été 'battue' par Yordi...

OlivierC, votre code ne fonctionne pas si les deux premiers li sont invisibles...
(j'ai fait des listes avec à peu près toutes les permutations possibles..)

Merci à tous.

Olivier C a écrit :

Effectivement, car si le &lt;hr&gt; sert bien de séparateur, il ne peut être mis en élément enfant direct d'une liste. Mais même si le cas avait été possible, séparer chaque items d'une liste n'aurait été que de peu d'intérêt puisque ces items, de par leur conception, sont repérés comme étants séparés.

N'ayant pas vérifié sur le moment (réponse depuis un Smartphone), j'ai effectivement placé le HR directement sous le UL, au lieu de le placer dans le LI.
Cette dernière consteuction est parfaitement autorisée par les spécifications HTML5 (cf. flows éléments autorisés sous LI).
Le séparateur HR étant... Un séparateur, il est tout à fait cohérent de l'employer comme tel au sein d'un élément de liste, que ce soit pour délimiter ledit élément par rapport au suivant, ou bien pour séparer visuellement deux blocs au sein d'un même élément.
Le fait que visuellement les éléments LI soient la.plupart du temps espacés à l'affichage, nativement ou par CSS, ne rend pas de facto interdite ou non conforme la balise HR.

Bien vu Yordi ! C'est ce que j'aime bien sur ce forum : on contribue mais on reçoit aussi pas mal en retour...

sepecat a écrit :
Le fait que visuellement les éléments LI soient la.plupart du temps espacés à l'affichage, nativement ou par CSS, ne rend pas de facto interdite ou non conforme la balise HR.

Je ne sais pas trop... chez moi ça ne passe pas à la validation du code.

Les <ul> ne peuvent contenir directement que des <li>, plus précisément "Zero or more li and script-supporting elements." :
https://www.w3.org/TR/html5/grouping-content.html#the-ul-element

Raphael a écrit :
Les &lt;ul&gt; ne peuvent contenir directement que des &lt;li&gt;, plus précisément "Zero or more li and script-supporting elements." :
https://www.w3.org/TR/html5/grouping-content.html#the-ul-element

Tout à fait exact (cf. Mon précédent commentaire).
C'est d'ailleurs un contrôle de cohérence inscrit dans mon générateur HTML, lequel interdit ce genre de construction.

@sepecat, perso, je m'en tiendrais au li seul enfant possible aux ol et li. Ensuite je ne voit pas l'interêt d’insérer un <hr/>, autant inserer une class supplémentaire à l’élément ou au suivant dans ce cas.

@zelena, finalement résolue ou pas ?

si non, j'en viens avec d'autre sélecteurs qui semble fonctionné au premier abord : http://codepen.io/gc-nomade/pen/gMOYgr (basé sur le poids des selecteur)

		ul {
		  width: 15rem;
		  list-style-type: none;
		}
		
		li.visible ~ li,
		li:not(:first-child),
		.invisible ~ li:not(.invisible) + li {
		  border-top: cyan 1px solid;
		}
		
		.invisible ~ li {/* appliqué si l'une des conditions[i] (sélecteurs)[/i] précédentes ne sont pas applicables */
		  border-top: none;
		}
		
		.invisible {
		  display: none;
}

gcyrillus a écrit :
@sepecat, perso, je m'en tiendrais au li seul enfant possible aux ol et li. Ensuite je ne voit pas l'interêt d’insérer un &lt;hr/&gt;, autant inserer une class supplémentaire à l’élément ou au suivant dans ce cas.]

En fait, la question ne porte pas sur la cohérence Ul / LI mais sur LI / HR...
Dans la mesure où cette cominaison de balises semble conforme aux spécifications W3C, je ne vous rien qui m'empêche de l'utiliser.
Je l'ai déjà fait dans certains de mes développements, ne serait-ce que parce-qu'elle s'avère plus souple pour dimensionner le séparateur en largeur.
Tout le monde ne veut pas forcément avoir un délimiteur aussi large que le texte qu'il encadre et dans ce cas de figure jouer sur la bordure de l'élément en CSS peut vite devenir énervant.
Avec ton HR inséré dans le LI, c'est un jeu d'enfant.
Ceci dit, à chacun de voir...

gcyrillus a écrit :

@zelena, finalement résolue ou pas ?

Si, si, résolu... La méthode de Yordi fonctionne et elle est simple à retenir.

Que 'hr' soit sémantique, je le conçois mais cela demande de faire attention à un élément en plus... et plus les liens sont déjà dans des containers séparés, les 'li'...

sepecat a écrit :

Avec ton HR inséré dans le LI, c'est un jeu d'enfant.

Intéressant...