Doléances sur le Zmarkdown de la V27

a marqué ce sujet comme résolu.

Pour le coup c’est le mode pédantique qui est bizarre de mon point de vue, parce qu’il agit sur des points sans rapport (fonctionnels) les uns avec les autres.

De mon point de vue le fait que bla_bla bla bla_bla affiche « blabla bla blabla » et non « bla_bla bla bla_bla » est un problème.

PS : concernant ceci :

Unordered lists with different markers (*, -, +)

Sans ce mode pédantique, est-ce que ça implique que :

  • On peut créer des listes avec tous les marqueurs mais pas les mélanger,
  • Ou bien que certains marqueurs ne produiront plus du tout de listes ?

Si c’est la première réponse, pour moi on peut se contenter de désactiver le mode pedantic, qui renvoie à un comportement qui me semble plus logique : la fonctionnalité « créer des listes avec des marqueurs différents dans la même liste » me semble moins intéressante qu’avoir un comportement cohérent de la mise en italique.

+3 -0

Bon, à titre consultatif j’aimerais bien vos votes.

Question 1

La liste où un élément commence par 4 espaces (·), ce qui déclenche généralement un block de code (cf ····bar) en markdown :

*·foo
*····bar

doit donner :

<ul>
<li>foo</li>
<li>
<pre><code>bar
</code></pre>
</li>
</ul>

(parce que le contenu du 2e item est ····bar)

et non :

<ul>
<li>foo</li>
<li>bar</li>
</ul>

(où les espaces sont mangés).

Question 2

Le markdown foo_bar_baz doit donner foo_bar_baz, et non foobarbaz.

Question 3

Le markdown

* a
- b
* c

doit donner 3 listes l’une après l’autre et non une liste de 3 éléments.

Comment voter

  • Comptez +1 par réponse positive à une affirmation ci-dessus, -1 par réponse négative.
  • Faites le total
  • Si le total est positif, mettez un pouce en l’air sur ce message.
  • Si le total est négatif, mettez un pouce pas en l’air sur ce message.

[edit] 9 à 0, je fais ça. Pouvez arrêter de voter. La PR pour faire ça était prête depuis 3 semaines donc ça va aller vite.

+7 -0

je ne savais même pas qu’on pouvait faire des sous-liste en faisait *····item je pensais naïvement que c’était l’inverse (····- item)

artragis

Non non, on ne peut pas. C’est bien l’inverse, oui.

+0 -0

C’est déployé (notez que le style sera corrigé un jour : https://github.com/zestedesavoir/zds-site/issues/5004 ).

Evidemment ça corrige au passage ceci :

Bug avec les liens qui sont mis en italique :

https://developer.mozilla.org/fr/Apps/Game_engines_and_libraries

https://developer.mozilla.org/fr/Apps/Game_engines_and_libraries

@A-312

Prochain fix ce sera probablement la coloration latex et console d’artragis.

+3 -0

Pour ceux qui passent par ici et qui connaissent les bases d’html et css, y’a un moyen fantastique de savoir d’où vient cet espace : demander au navigateur.

Exemple : https://imgur.com/VkBtSWV:)

+0 -0

Je crois que les devs manquent sérieusement de gens pour s’occuper du frontend, tu peux leur proposer ton aide ?

C’est un peu hors sujet ici, ça ne concerne pas zmarkdown. zmarkdown n’a d’ailleurs pas de feuille de style.

+0 -0

Salut,

J’ai découvert récemment la possibilité de faire des cases à cocher, comme ça :

  • case 1
  • case 2

Malheureusement, le rendu est bof, à cause de la présence de la puce de la liste avant la case et le mauvais alignement. Cette issue est à rapporter sur quel dépôt ? zmarkdown ou zds-site (ou autre) ?

+0 -0

Il y a un problème de parsing du lien Wikipedia ci-dessus dans le message de l’avion : la parenthèse fermante n’est pas prise en compte. Après, est-ce un bug ou un comportement voulu pour les liens mis entre parenthèses ?

+0 -0

Il y a un problème de parsing du lien Wikipedia ci-dessus dans le message de l’avion : la parenthèse fermante n’est pas prise en compte. Après, est-ce un bug ou un comportement voulu pour les liens mis entre parenthèses ?

amael

Je pense que c’est un bug dans l’implémentation de la spec gfm dans l’upstream : d’après https://github.github.com/gfm/#extended-autolink-path-validation ça devrait passer.

@A-312 ça me semble une fausse bonne idée, c’est généralement moche et ça n’a pas de sémantique. Mieux vaut utiliser l’élément HTML.

+2 -0

Je trouvais que ça avait un certain charme et que ça s’intègre mieux ✔ à être a côté d’un texte. Plutôt que d’ajouter des éléments bruts.

c’est généralement moche et ça n’a pas de sémantique. Mieux vaut utiliser l’élément HTML.

Plus moche que maintenant ? On se tape un fond disabled. Je pourrais comprendre si c’était un formulaire mais là, ce n’est pas logique car c’est une checkbox statique. On peut faire difficilement pire. Mon idée est 100% CSS.

Si on veut suivre la sémantique HTML correctement, il faudrait que le texte à côté soit dans un <span> et non au même niveau que la checkbox. Ceci permettrait de mettre un vertical-align:middle; au deux éléments et de corriger le problème. De plus si tu regardes attentivement le css ::after de la checkbox cochée, il est déjà modifié par une image.

Pour ces cases à cocher, il faudrait quand même ne pas afficher la puce de liste et aligner la checkbox. Ça serait plus joli.

amael

L’une des raisons pour suivre mon idée de départ.

@cepus Tu proposes de bonne idée, il m’arrive aussi certaine fois de ne pas proposer des choses délirantes quand ça parle de front. Pour vous montrer que je n’ai pas l’habitude de vous proposer des trucs trop moche : https://jsfiddle.net/ndmf7zx8/ Ce n’est pas tiré d’un de mes projets de jeu d’avion x)

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte