Je viens de voir le petit bouton « Imprimer », sympa et pratique ! ça rejoint ceci : Publipostage : Custom widget pour enregistrer facilement les PDFs
En effet, c’est exactement le même principe !
Est-ce que tu pourrais détailler stp pourquoi vous devez utiliser du code dans le widget markdown, et ce qui bloque ?
À la base, c’était pour faire pareil que sur le modèle de Vincent : utiliser une vue Markdown pour avoir un aperçu HTML (en principe, la vue HTML dédiée aurait dû suffire, mais elle était buguée à l’époque).
Mais dans notre cas, les choses sont un peu différentes : on a mis le CSS dans une case à part, du coup la vue Markdown n’affiche plus un aperçu fidèle du rendu final (ce qui a priori ne me dérange pas trop, car de mon point de vue, c’est l’aperçu avant impression qui doit faire foi). De fait, elle sert plutôt à éditer le contenu de la case qui contient le code HTML, et donc de masquer la colonne « code HTML » qui, lorsqu’elle est affichée, augmente considérablement la hauteur des lignes du tableau et rend son usage inconfortable. Pour ça, le bouton « Edit » de la vue est parfait, mais une fois dedans, le risque est que l’utilisateurice se mette à utiliser les boutons de mise en forme (gras, italique, etc) et à injecter du Markdown alors qu’il n’en faut pas ici.
On envisage de faire une vue custom « éditeur de texte brut », sans boutons de mise en forme (peut-être basée sur browserpad ?) qui permettrait d’éditer le HTML et le CSS sans ambiguïté, et qui viendrait donc remplacer les vues Markdown.