[spip-dev] CSS Neodist

Salut,

petite question du vendredi : pourquoi y a t'il des !important sur le http://zone.spip.org/trac/spip-zone/browser/squelettes/neo-dist/css/links.css?rev=85530#L20

Ce n'est pas très pratique car, pour les surcharger, il faut rajouter des !important dans sa feuille de style. Jusque là, rien de compliqué. Mais le souci, c'est que les fonds sur lesquels sont ces liens ne sont pas les forcément mêmes et il faut donc les surcharger autant de fois qu'on a de fond...
(je ne sais pas si je suis très clair)

Il ya peut-être une raison (ou une autre manière de faire sa CSS) mais je ne vois pas...

             jean marie

je ne sais non plus ... cela vient de la tinytypo originale.
il faudrait demander à tetue.

peut-être pour être sur que les liens sont biens visibles en accessibilité ? (navigation par tab par ex;)
mais il est vrai que le !important est particuliement gênant à surcharger par la suite

Il y a un ticket TinyTypo sur ce sujet, et une discussion (et des explications) :
https://github.com/tetue/tinytypo/issues/4

Pour faire court, ça sert à signaler le focus de façon visible et constante, ce qui règle le problème d'accessibilité pointé en WCAG 2.4.7 :
http://www.braillenet.org/accessibilite/comprendre-wcag20/V3/navigation-mechanisms-focus-visible.html

Plus précisément, signaler le focus par le outline seul ne suffit pas et il est conseillé de le renforcer :
http://romy.tetue.net/signaler-le-focus-ameliore-la-navigation
http://archives.rezo.net/archives/accesstech.mbox/LSPUIIFTLB5GMUJEYS3K4Q5NTSKCEJTY/

Techniquement, la spécificité CSS des liens impose ce !important, afin de garantir la constance d'affichage du signalement du focus (sinon ça casse à la première surcharge, cf. commentaires du ticket sus-cité).

Pragmatiquement, c'est surchargeable par a:focus { background: inherit !important; }

Et je suis preneuse de tous vos retours, détaillés et chipoteurs, en contexte (avec code et page tabulable), afin d'améliorer ça autant que possible.

À votre service :slight_smile:

Hello,

J'ai aussi jeté un œil au code et voici qq remarques sur les « conflit spip / tinytypo » neutralisés en début de la feuille spip.css (je ne sais pas si c'est ici qu'il faut signaler ça, sinon sur quel ticketing ?)

ul, ol {list-style:none;margin-left:0; }
- Faut pas faire ça, c'est mal :slight_smile: parce que ça déstyle les listes (non spip) que l'on souhaiterait mettre dans les skel.
- Logiquement, ul.spip et ol.spip ne devraient pas être définis, puisque déjà stylés par la base.
- Si besoin d'une liste non stylée, pour un menu de nav par exemple, utiliser la class .list-none
- Mais je comprends qu'on puisse laisser comme ça, pour transition, si l'idée était de ne pas modifier le HTML dans cette version.

s, strike,del, .del { opacity:1;}
- Simple curiosité : pourquoi ?

- Corrigé : https://github.com/tetue/tinytypo/commit/ac02691dc180d5015f20cedac6a80066db9cd7e3

hr.spip {clear:both;}
- Pourquoi forcer le both sur les hr ? Ça peut être très gênant, par exemple dans un texte, où y'a des images, le hr va se mettre sous l'image, générant un grand blanc dans le texte.

@media print {
  a.spip_out:after,
  a.spip_url:after { content: " (" attr(href) ")"; }
}
- Plus besoin de ces lignes, puisque c'est défini dans Tiny Typo :slight_smile:

-- tetue

hello tetue

merci pour les retours.
pour l'instant par email cela me convient mais on peut ticketer si besoin

Hello,

J'ai aussi jeté un œil au code et voici qq remarques sur les « conflit spip / tinytypo » neutralisés en début de la feuille spip.css (je ne sais pas si c'est ici qu'il faut signaler ça, sinon sur quel ticketing ?)

ul, ol {list-style:none;margin-left:0; }
- Faut pas faire ça, c'est mal :slight_smile: parce que ça déstyle les listes (non spip) que l'on souhaiterait mettre dans les skel.
- Logiquement, ul.spip et ol.spip ne devraient pas être définis, puisque déjà stylés par la base.
- Si besoin d'une liste non stylée, pour un menu de nav par exemple, utiliser la class .list-none
- Mais je comprends qu'on puisse laisser comme ça, pour transition, si l'idée était de ne pas modifier le HTML dans cette version.

j'ai ajouté ces lignes pour toucher au minimum le html
si tout le monde est d'accord pour modifier le html sur ces points,
on peut faire le changement avec les .list-none

n'hésite pas à commit directement

s, strike,del, .del { opacity:1;}
- Simple curiosité : pourquoi ?

je ne suis pas convaincu par tinytypo par ces lignes

del,
.del {
   opacity: .5;
   text-decoration: line-through;
}

je comprends l'intention (mettre en recul des contenus non pertinents)
mais pour moi, changer l'opacity est pertinent sur une surface (un fond ou une image) mais pas sur une couleur de police,

graphiquement on voit juste un changement de couleur (le noir passe gris)
et obtient le contraire de l'effet est renforcé. on voit le barré plus qu'avant

a:link {transition:none !important;}
- Corrigé : La transition sur les liens, c'est bien, pour accompagner le geste de… · tetue/tinytypo@ac02691 · GitHub

super.

hr.spip {clear:both;}
- Pourquoi forcer le both sur les hr ? Ça peut être très gênant, par exemple dans un texte, où y'a des images, le hr va se mettre sous l'image, générant un grand blanc dans le texte.

oui mais les rédacteurs de base n'ont aucun moyen d'avoir un raccourci pour "réinitialiser" les alignements (qu'ils ont souvent du mal à comprendre)

la règle permet cela simplement

voir par ex. sur
http://neodist.grml.eu/spip.php?article6

mais bon c'est un point à discuter

@media print {
  a.spip_out:after,
  a.spip_url:after { content: " (" attr(href) ")"; }
}
- Plus besoin de ces lignes, puisque c'est défini dans Tiny Typo :slight_smile:

fait (j'ai ajouté le spip_url qui n'est pas forcement en external)

ul, ol {list-style:none;margin-left:0; }
- Faut pas faire ça, c'est mal :slight_smile: parce que ça déstyle les listes (non spip) que l'on souhaiterait mettre dans les skel.
- Logiquement, ul.spip et ol.spip ne devraient pas être définis, puisque déjà stylés par la base.
- Si besoin d'une liste non stylée, pour un menu de nav par exemple, utiliser la class .list-none
- Mais je comprends qu'on puisse laisser comme ça, pour transition, si l'idée était de ne pas modifier le HTML dans cette version.

j'ai ajouté ces lignes pour toucher au minimum le html
si tout le monde est d'accord pour modifier le html sur ces points,
on peut faire le changement avec les .list-none

n'hésite pas à commit directement

Je peux plus commit !
Mais comme je disais, on peut laisser ainsi pour transition.

s, strike,del, .del { opacity:1;}
- Simple curiosité : pourquoi ?

je ne suis pas convaincu par tinytypo par ces lignes

del,
.del {
opacity: .5;
text-decoration: line-through;
}

je comprends l'intention (mettre en recul des contenus non pertinents)
mais pour moi, changer l'opacity est pertinent sur une surface (un fond ou une image) mais pas sur une couleur de police,

graphiquement on voit juste un changement de couleur (le noir passe gris)
et obtient le contraire de l'effet est renforcé. on voit le barré plus qu'avant

C'est intéressant comme retour, merci !

hr.spip {clear:both;}
- Pourquoi forcer le both sur les hr ? Ça peut être très gênant, par exemple dans un texte, où y'a des images, le hr va se mettre sous l'image, générant un grand blanc dans le texte.

oui mais les rédacteurs de base n'ont aucun moyen d'avoir un raccourci pour "réinitialiser" les alignements (qu'ils ont souvent du mal à comprendre)

la règle permet cela simplement

voir par ex. sur
Domain Details Page

mais bon c'est un point à discuter

Oui, c'est une mauvaise idée de détourner un élément de son sens pour cela.
Surtout que c'est le rôle du br.clear (ou le hr.clear), pour lesquels il n'existe pas de raccourcis, je sais bien.

Je laisserais l'initiative de ce détournement aux webmestres, plutôt que de la proposer par défaut, dans l'idée que ce n'est pas une pratique exemplaire.

@media print {
  a.spip_out:after,
  a.spip_url:after { content: " (" attr(href) ")"; }
}
- Plus besoin de ces lignes, puisque c'est défini dans Tiny Typo :slight_smile:

fait (j'ai ajouté le spip_url qui n'est pas forcement en external)
Connexion · GitLab

exact !

-- tetue

tu as raison. je l'ai retiré.
il faudrait à terme avoir un racocurci simple pour annuler les flottants.

j'ai aussi essayé de normaliser un peu les commentaires notamment:
- essayer de préférer le français (pour éviter le français / anglais qui sent bon le copier / coller)
- avoir des entêtes et des pieds de fichiers identiques dans un optique de normalisation