Spoiler dans un spoiler

Bonsoir !

Comme vous le savez sûrement, le support de l’export des contenu en PDFs passe par l’utilisation de LaTeX. Pour ce qui est des spoilers, la gestion est un peu particulière, parce que LaTeX ne gère pas spécialement bien le fait de sauver une portion de code pour l’utiliser plus tard, mais disons que ça fonctionne. Par contre, un spoiler dans un spoiler, c’est un peu trop pour lui (et croyez moi, j’ai retourné le problème dans tout les sens).

J’ai donc suggéré que pour les PDFs les spoilers dans les spoilers soient rendu comme le texte qu’il contiennent (ou éventuellement avec un élément graphique qui indique que c’était un spoiler dans un spoiler), mais pas comme des spoilers séparé.

@cepus souhaiterai savoir si, pour les (potentiels) auteurs, ça risque de poser problème. À moins que vous n’ayez quelque chose à dire, il suffit de mettre un pouce rouge si c’est un problème pour vous (vous pouvez développer, notez), un pouce vert si ça n’en est pas un.

Merci

Perso, je n’arrive pas à imaginer un seul cas d’utilisation réaliste pour un spoiler-ception.

Ou alors juste pour embêter les devs.

Tu as quelques exemples ? Est-ce que simplement aplatir le spoiler enfant dans son parent a un résultat toujours compréhensible ?

Bref je préfère la 2nd solution.

Edit : Je pense que le sondage est truqué. Est-ce que vous pensez que ça peut poser problème, c’est pas pareil que "est-ce que c’est un problème pour vous". À ce tarif, pour moi rien n’est jamais un problème : je suis pas auteur.

Mettre des exercices dans un spoiler (parce que c’est trop long sinon), et la correction sous l’exercice, dans un spolier dans le spolier. C’est facilement contournable (correction sous l’exercice), pas forcément approprié, mais ça peut être imaginé par un auteur.

Attention, ce n’est pas le cas à ma connaissance, et on peut demander à un auteur de faire autrement. Ce n'est pas une bonne raison de s’embêter à implémenter ça. Mais c’est un usage légitime d’un double spolier. Pas forcement pertinent, mais légitime.

Ce qu’on peut aussi faire, en plus de ce qui est proposé côté latex, c’est refuser les spoiler imbriqués côté Markdown.

@artragis me corrigera si je me plante mais côté backend zds on remonte les erreurs qu’on envoie depuis le parseur.

Hum, je fais que proposer.

Mais un spoiler en PDF, ce serait pas une portion de texte (sens large) retourné simplement ?

Un spoiler dans un spoiler serait une portion de texte retourné dans une portion de texte retourné … Ouais …

PS: L’idée vient des magazines avec des réponses juste en dessous des questions ou les réponses sont inversées par rapport au question (et du coup il faut retourner le magazine pour lire la réponse).

Ça voudrait dire que pour lire un pdf il faut soit l’imprimer, soit être au courant que la plupart des liseuses de pdf permettent de retourner les pages.

Pour le coup ca me semble pas terrible.

@artragis me corrigera si je me plante mais côté backend zds on remonte les erreurs qu’on envoie depuis le parseur.

il faut quej e vérifie, mais la dernière expérience de blackline avec les gridtable me fait douter de ça.

La liseuse se tourne hein ^^"
Après pour les PDFs j’avoue …

Je parlais plus généralement du soft sur n’importe quel écran en fait.

Après, sans mentir, c’est une fonctionnalité très très courante. Je ne connais pas de lecteur de PDF incapable de le faire. (Firefox, Chrome, IE, Evince, Acrobat Reader, mupdf, xpdf, de tête j’en connais pas plus).

Si l’écran est au format portable, tu peux tourner l’écran …

Qu’elle soit implémentée dans tous les lecteurs, je n’en doute pas. Ce que je remets en question, c’est le fait que n’importe quelle personne susceptible de lire les cours de ZdS en PDF sache que la fonctionnalité existe, pense à l’utiliser, et le fasse sans que ça implique trop d’action de sa part ni perdre le fil.

Ce qui est trivial pour nous ne l’est pas forcément pour tout le monde.

Puis, on parle pas de 3 mots ou d’une phrase à l’envers, on parle de choses qui peuvent prendre plus d’une page (typiquement, un code solution à un exercice, pour ne citer que ça). Donc c’est tout de suite autre chose.

Quelle expérience ?

quand blackline avait eu un bug sur les gridtables qui faisait planter zmd et qu’il n’avait eu aucun avertissement à ce propos.

Il me semble qu’on donne un avertissement sur l’aperçu mais pas sur le post. (je vais tester en mettant une mauvaise balise math tiens)

à l’aperçu j’obtiens :

Erreur du serveur Markdown: KaTeX parse error: Expected 'EOF’, got '\' at position 10: a | b |c \̲\̲ \hline d | e |…

et quand je poste :

Erreur du serveur Markdown: KaTeX parse error: Expected 'EOF’, got '\' at position 10: a | b |c \̲\̲ \hline d | e |…

mais en haut de page ce qui n’est pas très visible.

Ah oui ça ! En fait il y a une différence entre retourner une erreur et crasher. Un crash c’est pas prévisible, quand ça se produit il est trop tard. À l’inverse, renvoyer une erreur c’est qu’on a prévu le coup et soit capturé une erreur soit généré une erreur, erreur qu’on envoie ensuite à la personne qui pourra en faire quelque chose.

C’est aussi ce mécanisme qu’il faudra utiliser pour de l’aide contextuelle.

Je pense que ce serait bien d’améliorer la situation actuelle quand on a une erreur comme ce que tu montres. Après je peux lancer une erreur pour les spoilers.

J’ai eu un problème KaTeX avec un tableau moi ?

hein?

C’est quoi gridtable ?

Personellement j’aime bien l’idée de retourner le contenu d’un spoiler mais je ne saurais pas comment gérer ça en LaTeX si le contenu est à cheval sur plusieurs pages.

Sinon, par curiosité, c’est quoi la compilation LaTeX actuelle des spoilers (je parie sur \begin{spoiler}...\end{spoiler} avec un environnement bien choisi…), et aujourd’hui ça fait quoi pour l’utilisateur ?

Il me semble qu’actuellement, le contenu de spoilers est mis en annexe ? Dans le cas contraire, j’en profite pour soumettre l’idée \o/.