Open kciy opened 1 year ago
Unless we're careful about sanitising the resulting report (confusing for users), or using a separate domain for user generated content like this (completely unimplemented, with a long timeline), it potentially increases the attack surface considerably. Everyone would need to be careful when opening a workflow report from someone else.
If it's possible to enumerate which features? there's probably more interest in adding support for those useful subset, rather than allowing any html and the associated attacks possible with that.
That's true, I see your point.
I would like to have:
<details><summary>...</details>
)I guess we can close the issue since I agree not just allowing any HTML.
those are great suggestions! I'd love a details/summary box as well, and a table of contents, especially for larger reports, would be really nice.
hopefully the updated scratch book works nicely with reports? side by side is exactly the use case for that
That sounds good, how can we proceed from here? And what do you mean by scratch book?
It's what seems to be now called the window manager, which allows you to open multiple dataset views at once.
and, yes, all really good ideas @kciy :)
Ahaa, thanks!!
I think we want to keep track of these ideas, so maybe keep it open and change the title?
Using workflow reports makes sense with markdown to have headings and lists, but it could easily extended to allowing HTML as well. This would allow for custom elements, overview tables and more.
It could also help in some things mentioned in #11426
The markdown parser which is used (npm markdown-it) per default disables HTML usage.
Any opinions on this?