Suivi — Feuilles de style (CSS) Feuille de style CSS 3 avec theme clair et sombre automatique

#3188 Posté par  (site web personnel) . État de l’entrée : ouverte. Licence CC By‑SA.
Étiquettes : aucune
2
23
mar.
2024

Bonjour,

Voici une feuille de style pour le site linuxfr que j'ai commencé à coder. C'est une démonstration de ce que l'on peut faire en utilisant CSS3, notamment le basculement automatique clair/sombre.

Dans quelle mesure ces idées peuvent-elles être prises en compte pour une nouvelle feuille de style de linuxfr ?

Est-ce que SCSS est obligatoire ?

Merci.
André

  • # Captures d'écran

    Posté par  (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 24 mars 2024 à 10:44.

    Bureau

    Theme clair

    Theme clair

    Theme sombre

    Theme sombre

    Telephone

    Theme clair

    Clair Sombre
    Theme clair Theme sombre

  • # Collaboration et remarques

    Posté par  (site web personnel) . Évalué à 3 (+0/-0).

    Plutôt que de créer une foultitude de tickets, une discussion serait productrice, je pense.

    Dans la plupart des cas, il semble qu'il y ait un manque d'appréciation du fonctionnement des feuilles de style, dans le code HTML généré.

    Toutefois, il y a un problème qui revient régulièrement, sur un déséquilibre de balises qui empêche de créer des feuilles de styles efficaces.

    Par exemple :

    <div id="toolbar"><span id="toolbar_items">Nouveaux commentaires :
  <span id="toolbar_current_item">0</span> /
  <span id="toolbar_nb_items">0</span>
  <a href="#" accesskey="<" class="prev">&lt;</a> |
  <a href="#" accesskey=">" class="next">&gt;</a>
</span><span id="toolbar_alt_items">Commentaires par ordre chronologique :
  <span id="toolbar_current_alt_item">0</span> /
  <span id="toolbar_nb_alt_items">0</span>
  <a href="#" accesskey="[" class="prev">[</a> |
  <a href="#" accesskey="]" class="next">]</a>
</span><span id="toolbar_threshold">Seuil :
  <a href="#" class="change">1</a>
</span></div>
    • Il y a donc des éléments qui ne sont pas dans une balise, et d'autres qui le sont. Du coup, il est impossible d'appliquer un style sur les éléments extérieurs, sans affecter les éléments intérieurs.
    • On utilise des caractères ASCII pour faire des boutons (en 2024, on peut utiliser des emojis, AMHA)

    • [^] # Re: Collaboration et remarques

      Posté par  (site web personnel, Mastodon) . Évalué à 3 (+0/-0).

      Hello,

      Merci pour les idées pour améliorer le CSS.

      D'abord, le code de LinuxFr est assez ancien (vers 2010) et assez vieux pour avoir eu besoin d'outils pour être compatible avec Internet Explorer et ne pas avoir les facilités de CSS3 (d'où l'utilisation de Sass et CoffeeScript).

      Nous avons entamé récemment la mise à jour du framework Ruby On Rails et côté Ruby, on a déjà pas mal de travail et on n'aura pas le temps de s'occuper de la CSS tout de suite. Tu peux regarder la discussion sur Github sous la PR "rails7".

      Comme il y a très peu de bénévoles sur le code, nous allons très certainement supprimer l'option de personnalisation des CSS via le site LinuxFr. J'avais expliqué mon point de vue ici: https://linuxfr.org/suivi/css-contribuees-utilisation-et-mise-a-jour#comment-1945690

      Par rapport à Sass, la gem que nous utilisons pour gérer ça est dépréciée et il faudrait que l'on trouve une nouvelle solution. Pour les variables, nous pourrions utiliser CSS3, mais pour la fonction qui permet facilement d'imbriquer les règles, c'est encore utile (c'est trop récent dans CSS3).

      Il y a donc des éléments qui ne sont pas dans une balise, et d'autres qui le sont. Du coup, il est impossible d'appliquer un style sur les éléments extérieurs, sans affecter les éléments intérieurs.

      Il y a les règles :not() en CSS qui peuvent aider, non ?

      On utilise des caractères ASCII pour faire des boutons (en 2024, on peut utiliser des emojis, AMHA)

      Les caractères ASCII utilisent la fonte définie par LinuxFr (si l'utilisateur laisse télécharger la fonte), ils ont l'avantage donc que le rendu ne dépend pas trop du navigateur.

      En effet, la solution propre serait d'utiliser SVG pour faire de vraies icônes pour les boutons. Le rendu des emoji dépend trop du navigateur qui l'affiche et donc le style ne serait pas maîtrisé (entre Firefox/Linux, Firefox/Windows, Android et iOS, je crois que chaque application fait un rendu différent).

      Nous pourrions utiliser une police spéciale pour gérer les emoji, mais la réalité est que l'utilisation de polices d'écritures pour faire un rendu d'icônes est obsolète et qu'il vaut mieux utiliser SVG (selon les explications de fontawesome eux-mêmes).

      Enfin, si jamais ça pourrait t'intéresser, mjourdan nous avait fait une nouvelle proposition de design que nous n'avons pas encore pu implémenter.

      J'avais ouvert le suivi ici pour en discuter: https://linuxfr.org/suivi/implementer-le-nouveau-design-de-linuxfr et mjourdan avait fait un répertoire Github avec son mockup: https://github.com/mjourdan/linuxfr-design

      • [^] # Re: Collaboration et remarques

        Posté par  (site web personnel) . Évalué à 2 (+0/-0).

        D'abord, le code de LinuxFr est assez ancien (vers 2010) et assez vieux pour avoir eu besoin d'outils pour être compatible avec Internet Explorer et ne pas avoir les facilités de CSS3 (d'où l'utilisation de Sass et CoffeeScript).

        Ok, ça se défend, je m'y attendais, de toute façon.

        Comme il y a très peu de bénévoles sur le code, nous allons très certainement supprimer l'option de personnalisation des CSS via le site LinuxFr. J'avais expliqué mon point de vue ici: https://linuxfr.org/suivi/css-contribuees-utilisation-et-mise-a-jour#comment-1945690

        Franchement, je suis d'accord. Autant avoir une feuille de style qui tiens la route, avec clair et sombre, aussi. Cependant, si c'est bien implémenté, vous pouvez avoir plusieurs styles, avec un minimum d'effort, en respectant un principe : séparer la disposition des éléments (layout) de leur rendu (style). Si vous respectez cela, ça permet de changer l'un sans changer l'autre, et du coup :

        • De faire une feuille de style pour une tablette ou un téléphone, sans avoir à écrire une nouvelle feuille de style.
        • De "jouer" avec la disposition des éléments, sans avoir à réécrire les styles.
        • De faire un nouveau style visuel, sans avoir à se retaper les difficultés de la disposition des éléments.

        Vous pouvez, par exemple, faire une feuille de style en fonction des événements ou des vacances en cours (Pâques, Noël, etc.)

        Par rapport à Sass, la gem que nous utilisons pour gérer ça est dépréciée et il faudrait que l'on trouve une nouvelle solution. Pour les variables, nous pourrions utiliser CSS3, mais pour la fonction qui permet facilement d'imbriquer les règles, c'est encore utile (c'est trop récent dans CSS3).

        Oui, je sais, et je suis à peu près d'accord. Si on vise un minimum de compatibilité, il vaut mieux ne pas utiliser les imbrications, et utiliser un préprocesseur SCSS ou autre, avec une option pour générer les imbrications quand ce sera supporté.

        Les caractères ASCII utilisent la fonte définie par LinuxFr (si l'utilisateur laisse télécharger la fonte), ils ont l'avantage donc que le rendu ne dépend pas trop du navigateur.
        En effet, la solution propre serait d'utiliser SVG pour faire de vraies icônes pour les boutons. Le rendu des emoji dépend trop du navigateur qui l'affiche et donc le style ne serait pas maîtrisé (entre Firefox/Linux, Firefox/Windows, Android et iOS, je crois que chaque application fait un rendu différent).
        Nous pourrions utiliser une police spéciale pour gérer les emoji, mais la réalité est que l'utilisation de polices d'écritures pour faire un rendu d'icônes est obsolète et qu'il vaut mieux utiliser SVG (selon les explications de fontawesome eux-mêmes).

        Que les émojis soient rendus différemment d'un système à l'autre, pour moi, ce n'est pas un problème, au contraire, surtout si leur style est plus accordé avec l'OS. Le but des émojis, ce n'est pas seulement pour faire joli, c'est aussi faciliter le scan visuel de la page par le cerveau.

        Enfin, si jamais ça pourrait t'intéresser, mjourdan nous avait fait une nouvelle proposition de design que nous n'avons pas encore pu implémenter.

        Avec le temps libre que j'ai, sans doute pas. Comme expliqué dans mon journal, je fais ça pour rafraîchir mes connaissances sur CSS. Entre deux exercices en Rust, Ansible ou Terraform. Cependant, si je reçois de l'aide sur mes projets open-source, peut-être que ça libèrerait du temps pour ça.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.