La coloration de code étaient plus lisible avant

Bonjour,

La v27 arrive avec un nouveau zmarkdown. Et je viens de remarquer que les codes sont moins lisibles de mon point de vue que ce que l’on avait avant.

Un exemple pour le même code :

Je n’arrive pas a expliquer pourquoi, mais je lis plus facilement le code tel qu’il apparaissait avant. Le gras doit y être pour quelque chose. Et j’ai l’impression aussi que les contrastes entre les couleurs étaient plus optimales avant.

Je trouve aussi étrange que la coloration soit différente suivant que l’on soit dans une liste à puces ou non.

Exemple :

a = 0

• a = 0
  

J’ajoute que le choix du « coloriage » me semble particulièrement louche. Cf l’exemple de firm1, l’intégralité des paramètres de la méthode (ligne 28) est coloriée du même orange pétant, parenthèses comprises. Personne ne fait ça, ça n’a pas de sens !

Alors, avant on utilisait Pygments avec le style par défaut qui fonctionnait pas mal. Aujourd’hui on utilise highlight.js avec le style Tomorrow.

Y’a plus qu’à choisir un style plus pertinent (dans le lien précédent) et à faire la PR qui va bien, sachant que la modification se fait soit ici, soit là, soit dans les deux liens – je ne sais pas pourquoi cette dépendance est appellée aux deux endroits (ping @Sandhose pour l’info).

PS : ça ne règle pas le problème des couleurs qui partent en couille quand le code est dans une puce.

PPS : il n’y a pas l’air d’avoir par défaut de règle hightlight.js qui reprenne le code couleur par défaut de Pygments.

Le style Idea semble être celui qui se rapproche le plus de Pygments.

Il a aussi l’avantage d’être connu de pas mal de monde, puisque c’est le style clair par défaut des produits Jetbrains (IntelliJ, PyCharm, PhpStorn… et je crois qu’Android Studio a conservé le thème).

Y’a plus qu’à choisir un style plus pertinent (dans le lien précédent) et à faire la PR qui va bien, sachant que la modification se fait soit ici, soit là, soit dans les deux liens – je ne sais pas pourquoi cette dépendance est appellée aux deux endroits (ping @Sandhose pour l’info).

C’est parce qu’on sort deux feuilles de styles. Une pour le site, une avec juste le style nécessaire au contenus (qui est entre-autre utilisé dans les EPUBs)

Du coup, question naïve : ne devrait-on pas avoir main.scss qui importe zmd.scss ?

Ça pourrait. Mais c’était plus simple de faire ça pour contrôler un peu les imports (typiquement, on veut pas de normalize.css dans les EPUBs, mais son ordre d’import est important), et pour pouvoir émettre un zmd.css qui injecte le style du zmarkdown que sous un scope .zmarkdown. Au vu du peu d’imports dans zmd.scss, j’ai considéré que c’était acceptable comme compromis

MR lancée.

Coucou, je profite de ce sujet car je trouve la coloration syntaxique actuelle lisible mais pas spécialement belle.

Du coup, voilà mon userContent

@-moz-document domain("zestedesavoir.com") {
  .hljs-code-div {
    background-color: #222 !important;
    color: #FFF !important;
  }

  .hljs {
    background-color: #222 !important;
    color: #FFF !important;
  }
  .hljs-selector-tag {
    color: #AB0 !important;
  }
  .hljs-keyword {
    color: #C33 !important;
  }
  .hljs-number {
    color: #E15!important;
  }
  .hljs-title {
    color: #FA4 !important;
  }
  .hljs-function {

    /*
     * color: #B4C !important;
     */

    color: #B7F !important;
  }
  .hljs-string {
    color: #9B9 !important;
  }
  .hljs-attribute {
    color: #44F !important;
  }
  .hljs-literal {
    color: #44F !important;
  }
  .hljs-section {
    color: #FFA !important;
  }
  .hljs-selector-class {
    color: #AFA !important;
  }

  span.upvote {
    display: none !important;
  }
}