Produits Entr'ouvert » Intégrations graphiques Publik

Pour appliquer les mêmes styles partout il faudrait que le HTML généré pour les checkbox et radio soit le même que celui produit par wcs: <label><input type="checkbox" ...><span></span></label>.
Je fais un ticket gadjo dans ce sens.

Je n'aime pas la multiplication des selecteurs. Cela complique la création de thème, rend infernal l'évolution du core et demande de patcher tous les thèmes.
Ne pourrait-on pas garder les mêmes class ?

Les noms des class sont celles des widgets utilisés pour le rendu des champs. Ils sont différents dans wcs (RadiobuttonsWidget, CheckboxWidget, CheckboxsWidget,...) des autres applis qui utilisent les classes django qui ont un autre nom.

Pour revenir à la duplication des selecteurs dans les variants, on doit pouvoir sûrement s'en passer car il s'agit de la personnalisation de la couleur, taille, bordure des éléments ::before et ::after. On pourrait gérer cela avec des variables.

Je fais un ticket.

Serghei Mihai a écrit :

Pour revenir à la duplication des selecteurs dans les variants, on doit pouvoir sûrement s'en passer car il s'agit de la personnalisation de la couleur, taille, bordure des éléments ::before et ::after. On pourrait gérer cela avec des variables.

Cela existe déjà: $widget-custom-radio-checkbox-border-color, $widget-custom-radio-checkbox-marker-color. Il manquerait une variable pour gérer la taille du widget (comme à la Dordogne par exemple).

Les noms des class sont celles des widgets utilisés pour le rendu des champs

Ok, je comprends donc qu'il n'y a aucun moyen d'avoir un selecteur commun. Passons.

On pourrait gérer cela avec des variables

De ce que je vois, il y egalement des paddings, la possibilité de différencier la couleur du contour de celle du fond, des valeurs de border-radius,
et la modification de la taille qui se fait à coup de width, height et qui demande du coup de repositionner les élements à coup de top parfois left et calc().
(Bref, réécrire tout cela devient necessaire).
Enfin même si on multiplie les variables de personnalisation, il arrivera toujours un moment où on aura besoin de personnaliser aussi via CSS.

Pour cleaner la personalisation dans les variants
Il y a toujours les @extend Sass à la rescousse :

.custom-radio-checkbox {
  // ici tout le code actuel
}

@if $widget-custom-radio-checkbox == true {
.django-radio-select,
.django-checkbox-input,
.RadiobuttonsWidget,
.CheckboxWidget,
.CheckboxesWidget {
  @extend .custom-radio-checkbox;
}
}

Et s'il y a besoin de personnaliser via CSS dans un thème :

.custom-radio-checkbox {
  // CSS de personnalisation
}

Pour moi c'est déjà plus propre, plus simple, plus mieux.

Thomas Jund a écrit :

Ok, je comprends donc qu'il n'y a aucun moyen d'avoir un selecteur commun. Passons.

On peut sûrement y arriver, mais cela implique beaucoup plus de modifications de code dans wcs et gadjo que dans publik-base-theme.

Pour moi c'est déjà plus propre, plus simple, plus mieux.

Je suis d'accord.

%custom-radio-checkbox-widget {
-     @extend %custom-radio-checkbox-widget;

Tu n'as pas besoin de faire un @extend, c'est implicite, comme pour une class CSS

Je préfère aussi l'utilisation d'une class CSS, utilisable dans les templates, plutôt que du %truc specifique Sass.

Ou bien je ne saisis pas ton idée?

Je propose de remplacer les

- %custom-radio-checkbox-widget {
+ .custom-radio-checkbox-widget {

et

@extend %custom-radio-checkbox-widget;
@extend .custom-radio-checkbox-widget;

+ de CSS natif et - de SASS specifique.

Sérieusement pas à pousser à deux jours de la mise à jour.

My bad, ce patch corrigeait le raté sur l'alignement des cases à cocher sur le thème GLC. Et au lieu de poser de code pourri dans son _custom.css qu'il allait falloir virer de toute façon j'ai opté pour envoyer celui-ci.

J'ai fait le tour des recettes, notamment celles avec les widgets customisés, et ça a l'air ok.

J'ai fait le tour des recettes, notamment celles avec les widgets customisés, et ça a l'air ok.

De fait pas et ça vient peut-être surtout des modifications gadjo mais comme tout ça arrive tard je suis obligé d'y aller sans finesse et je vire tout plutôt qu'essayer de voir quel bout de quel patch pourrait être laissé.

Frédéric Péters a écrit :

Et j'ai reverté les bouts gadjo qui allaient avec.

Une différence visible immédiatement (une fois que j'ai vu ce commit arriver c'est ce que je suis allé voir) c'est le "civilité" de Strasbourg, cf captures.

Pour revenir là-dessus. Je pense que la différence de rendu est due au fait qu'après le patch de #54642 les boutons radio ne sont plus placés dans des listes (pas de padding à gauche).
Il faudrait ajouter du padding pour le nouveau markup pour respecter le rendu.

Le propos c'est que oui différence de markup différence de rendu j'en ai pointé un exemple il peut y en avoir d'autres il faut le plus rapidement possible faire correctement le tour.