28182 sujets

CSS et mise en forme, CSS3

CSS : Menu navigation et CSS conditionnel

Bonjour.

Dans un Menu de navigation principal n'affichant que de simples bouton/liens vers les différentes sections du site,
il est souhaitable pour la bonne orientation du visiteur que le bouton de la section choisie change d'aspect lors du survol (a:hover) puis lorsque l'on clique dessus (a:active),
mais aussi qu'il reste mis en évidence une fois rendu dans la section de destination.

Avec un script cela peut être obtenu via une classe "active" dynamiquement attribuée au bouton correspondant à la section visitée.

Pour un site statique (sans script) utilisant uniquement HTML/CSS
la solution qui me vient immédiatement est d'attribuer au <body> une classe
correspondant à chaque section et d'écrire dans le fichier CSS autant de séries de règles pour chaque section du site.

Maintenant que vous avez compris (j'espère avoir été clair) le but recherché,

je vous demande si avec les nouveautés en termes de règles conditionnelles introduites récemment au CSS (https://drafts.csswg.org/css-conditional-3/) (@media, @supports,etc),
s'il y a un moyen propre de fournir une série de règles génériques pour les éléments (de menu = <a> dans mon cas)
et de les altérées conditionnellement en fin de fichier CSS ?

p.ex en fonction d'une classe ou id placé comme précédemment sur <body>
ou par un autre mécanisme prévu pour cela ???

Merci pour vos avis.
Modifié par dezix (16 Sep 2019 - 13:40)
Merci pour cette solution,
mais ce que je recherche avant tout,
est de ne pas exécuter de scripts
et plus encore côté client.

Je sais que c'est à contre-courant des usages les plus communs,
mais comme l'usage de scripts côté client est trop souvent abusif,
je m'y refuse par principe => NoScript !

C'est la raison de ce sujet.
Administrateur
Bonjour,

un générateur de site statique te permet de servir des pages HTML/CSS et d'avoir une certaine variété dans le code généré (je ne sais pas de combien de pages on parle : 8, 30, 300+ ?), ce qui évite le bidouillage CSS.
À vrai dire, pas tellement du bidouillage mais plutôt une solution insuffisante du point de vue de l'accessibilité : https://disic.github.io/guide-integrateur/2-navigation.html#encoursdeconsultation (voir les démos)

Si tu veux cibler un lien particulier en fonction d'une classe sur un parent, il faut quelque chose de particulier sur ce lien : classe, attribut data-*, etc. Ouais du coup pas besoin de classe sur l'ancêtre
Ce n'est pas possible sans script car tu n'as aucun moyen de faire la distinction entres les différents liens de ton menu.

C'est bien de faire attention aux scripts abusifs d'ailleurs en effet ça se fait plutôt généralement côté serveur ce genre de choses. Mais tu te prives de toute génération dynamique avec ce type de contraintes.
@Felipe
Merci pour le lien vers le Guide de l'Intégrateur

Au niveau des générateurs de sites statiques,
as-tu d'expérience quelque-chose qui correspondrait,
à me suggérer ?

Mon contenu (plusieurs centaines de pages avec des images) est rédigé avec l'éditeur de texte Zim qui permet très simplement de structurer la hiérarchie des pages et de créer des liens internes ou externes (j'en utilise beaucoup).
Zim permet d'exporter le contenu (.txt) en HTML, Markdown ou RST (sphinx)
c'est donc un outil très pratique, pilier de mon mode de travail.

J'ai déjà fait un tour vers Hugo, Jekill et quelques autres
mais ça m'a paru assez ardu d'emploi,
je n'ai donc pas insisté... peut-être à tord.

J'ai testé aussi MKDocs ... problème avec les liens je crois

Bref, après moult essais j'en suis arrivé à la conclusion que :
1. Le statique au statique (HTML)
2. Usage de CMS spécialisés et minimalistes si nécessaire ( p.ex: FluxBB pour un forum)


@bacasable
Je sais bien que ça tourne un peu à l'idée fixe,
mais je me suis fixé l'objectif suivant :

Rendre mon projet 100% accessible en mode Texte pour les navigateurs dans un terminal

Dans mon esprit cela implique une réelle ergonomie et lisibilité dans le terminal.

Je n'ai pas d'expérience/retour pour les utilisateurs d'agents utilisateurs spéciaux (braille ou autre),
alors je parts du postulat suivant :

"Si le site est très accessible en mode texte
alors il devrait aussi l'être en général."

Si ce postulat est faux, merci de me le dire

Donc pour parvenir à ce résultat,
la manière la plus simple/fiable m'a paru être d'éliminer tout type de CMS
qui souvent appliquent leur propre code pas toujours facile à contrôler
pour qui ne domine les arcanes de ces usines à gaz.

J'ai fait des tests avec GetSimple qui comme sont nom l'indique est assez simple au niveau des modèles et du fonctionnement général,
mais auquel il manque un système d'importation d'un site statique pré-conçu.
Modifié par dezix (17 Sep 2019 - 13:27)
Ton postulat n'est pas totalement faux a savoir qu'un site qui fonctionne sans javascript sera probablement plus accessible.

Mais il faut savoir que :

- contourner javascript par différents hack css peu contrairement à ce qu'on pense dégrader l’expérience utilisateur
- javascript peut au contraire renforcer l'accessibilité. Sans javascript tu ne peux pas manipuler les attributs aria pour masquer/afficher un élément par exemple.

Il faut dans tout les cas d'abord réfléchir au cas par cas à chaque situation. Ici en l’occurrence l'activation ou non de javascript ne dégrade rien pour ce genre de chose. Et faire cela côté serveur n'aura réellement aucune incidence avec l'avantage de fonctionner sans js.
Meilleure solution
@Jean-Pierre-Bruneau

Je ne mets absolument pas en doute la validité de la solution proposée,
surtout que n'y connais rien en JS (voie si je suis honnête Smiley cligne )

Mais sur ton second conseil, d'afficher le code de la page,
je ne parviens pas à saisir la leçon (je demande à apprendre).

J'ai écrit ma page d'accueil à la main uniquement en html(5) validé par W3C et respectant la syntaxe stricte du XML.

Comment le navigateur pourrait-il me montrer autre chose que le code que j'ai écrit ?

Maintenant si tu me dis d'examiner le code d'une page prise au hasard sur la toile,
alors oui je risque à 80% d'y trouver ce que tu me dis : une page vide au sens du html.

Et c'est exactement cela que je ne veux pas.
Je veux du code qui fonctionne avec un navigateur qui ne supporte pas JS (ça existe),
c'est comme faire du blé sans roundup ... c'est possible !

Là ce n'est plus une question technique, mais éthique ou philosophique.

Si je suis passé à côté de quelque-chose => éclaire ma lanterne
dezix a écrit :
@Jean-Pierre-Bruneau

Maintenant si tu me dis d'examiner le code d'une page prise au hasard sur la toile,
alors oui je risque à 80% d'y trouver ce que tu me dis : une page vide au sens du html.



Non, sauf erreur JP Bruneau parle de la page d'accueil du navigateur : si tu fais la manip, tu constateras que le navigateur lui-même fait un large appel aux scripts et que cela ne gêne en rien ses performances et son accessibilité. Ergo pourquoi s'en priver par principe ?
Bon courage pour ton projet. Smiley biggrin
oldmerou a écrit :


Non, sauf erreur JP Bruneau parle de la page d'accueil du navigateur : si tu fais la manip, tu constateras que le navigateur lui-même fait un large appel aux scripts et que cela ne gêne en rien ses performances et son accessibilité. Ergo pourquoi s'en priver par principe ?
Bon courage pour ton projet. Smiley biggrin


D'abord cela dépend du navigateur.

J'ai fait le test avec Firefox,
effectivement il y a des fonctions dont je n'ai aucune utilité.

S'il y a déjà ce qu'il faut dans l'interface (préférences, marques-pages, historique, etc)
Je choisis pour ma page d'accueil mon moteur préféré : https://duckduckgo.com

Je ne lui demande qu'un champ de saisie pour la recherche
et un lien vers le mode d'emploi (https://help.duckduckgo.com/)
qui malheureusement n'est pas accessible sans script.
Ce n'est pas grave, j'ai un marque-page pour y accéder.

Performances,
j'utilise souvent des navigateurs légers tels que Surf, Netsurf, Dillo,
Lynx qui sont autrement plus rapides que Firefox ou Chromium.
Et il serait bien malheureux, qu'ils rament pour ouvrir un fichier local.

Sans vouloir offenser personne, je crois que le web est "accro" aux gadgets.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On s'éloigne, de la question initiale pour laquelle la réponse semble : NON

L'avenir me dira si je parviens à un résultat satisfaisant ou non.

Merci pour vos conseils et encouragements.
Sujet clos
Aller à