affichage incorrect des rubriques restreintes #3640

Closed
opened 7 years ago by peetdu · 5 comments
peetdu commented 7 years ago

À la création d'un auteur, (administrateur), la restriction à des rubriques produit un affichage curieux (voir copie d'écran).

remarques

Pierretux me signale que c'est la même chose si l'auteur à le statut de rédacteur.

À la création d'un auteur, (administrateur), la restriction à des rubriques produit un affichage curieux (voir copie d'écran). remarques - Le bug n'est pas présent sur SPIP 3.0.x - le HTML produit par ce composant est le même dans SPIP 3.0 et 3.1 - ce serait donc un pb de CSS (probablement https://core.spip.net/projects/spip/repository/entry/spip/prive/themes/spip/forms.css.html#74) Pierretux me signale que c'est la même chose si l'auteur à le statut de rédacteur.

Le problème est aussi en modification.

Je serait pour rajouter un margin-#ENV{left}:0; ici
https://core.spip.net/projects/spip/repository/entry/spip/prive/themes/spip/forms.css.html#L245

.formulaire_editer_auteur .editer.editer_statut .rubriques_restreintes label {margin-#ENV{left}:0}

Le problème est aussi en modification. Je serait pour rajouter un margin-#ENV{left}:0; ici https://core.spip.net/projects/spip/repository/entry/spip/prive/themes/spip/forms.css.html#L245 .formulaire_editer_auteur .editer.editer_statut .rubriques_restreintes label {margin-#ENV{left}:0}
b_b commented 7 years ago
Owner

J'ai envoyé un patch mais ce n'est pas satisfaisant, la règle css de source:spip/prive/themes/spip/forms.css.html#L74 impacte encore, en appliquant une largeur en dur au label.

En comparant avec SPIP 3.0, on voit que la règle précédente est plus haut dans la css compactée, par rapport aux styles du picker, cf :

source:spip/prive//themes/spip/picker.css.html#L67

Du coup, plutôt que d'ajouter une couche supplémentaire, je me dis qu'il vaudrait chercher pourquoi l'ordre d'insertion de ces deux css a changé. En attendant j'ai annulé r22717 par r22718.

Trouvé, c'est l'ajout de .editer dans dans source:spip/prive/themes/spip/forms.css.html#L74 qui rend la règle plus forte que celle du picker.

Première option, affiner le sélecteur de source:spip/prive/themes/spip/forms.css.html#L74 comme ceci :

 .formulaire_spip .editer > label, .formulaire_spip .editer.gauche > label

Mais ça risque d'avoir des effets de bord. Deuxième option, ajouter la règle suivante dans source:spip/prive/themes/spip/forms.css.html#L246 :

.formulaire_editer_auteur .editer.editer_statut .rubriques_restreintes label { float: none; width: auto; margin-#ENV{left}: 0; }

D'autres avis ?

J'ai envoyé un patch mais ce n'est pas satisfaisant, la règle css de source:spip/prive/themes/spip/forms.css.html#L74 impacte encore, en appliquant une largeur en dur au label. En comparant avec SPIP 3.0, on voit que la règle précédente est plus haut dans la css compactée, par rapport aux styles du picker, cf : source:spip/prive//themes/spip/picker.css.html#L67 Du coup, plutôt que d'ajouter une couche supplémentaire, je me dis qu'il vaudrait chercher pourquoi l'ordre d'insertion de ces deux css a changé. En attendant j'ai annulé r22717 par r22718. Trouvé, c'est l'ajout de .editer dans dans source:spip/prive/themes/spip/forms.css.html#L74 qui rend la règle plus forte que celle du picker. Première option, affiner le sélecteur de source:spip/prive/themes/spip/forms.css.html#L74 comme ceci : <pre> .formulaire_spip .editer > label, .formulaire_spip .editer.gauche > label </pre> Mais ça risque d'avoir des effets de bord. Deuxième option, ajouter la règle suivante dans source:spip/prive/themes/spip/forms.css.html#L246 : <pre> .formulaire_editer_auteur .editer.editer_statut .rubriques_restreintes label { float: none; width: auto; margin-#ENV{left}: 0; } </pre> D'autres avis ?
Poster

Il me semble que effectivement, la deuxième solution présente comme tu dis l'avantage d'éviter les effets de bord.
J'ai testé en ajoutant 7 rubriques (sur Chrome, Firefox, Safari, Opéra, et Edge 13) et sur tous ça marche au poil.
Voir copie écran.

la deuxième option et donc valide (for me at last)

Il me semble que effectivement, la deuxième solution présente comme tu dis l'avantage d'éviter les effets de bord. J'ai testé en ajoutant 7 rubriques (sur Chrome, Firefox, Safari, Opéra, et Edge 13) et sur tous ça marche au poil. Voir copie écran. la deuxième option et donc valide (for me at last)
Poster

la deuxième option est donc valide

la deuxième option *est* donc valide
b_b commented 7 years ago
Owner

Appliqué dans le trunk par r22783 et reporté en 3.1 par r22784, on ferme :)
Statut changé à Fermé

Appliqué dans le trunk par r22783 et reporté en 3.1 par r22784, on ferme :) **Statut changé à Fermé**
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.