Allow plugins to use a sane set of HTML (<img> and/or <svg> in particular)

[loilo]

As far as I can tell from trying it out plugins are restricted to use a really small subset of HTML (strong, em, ...). It would be really nice to be able to use stuff like tags.

My concrete use case was that I tried to improve the basic math module by molding the input into nice LaTeX SVG output with MathJax. This seems not to be possible at the moment.

Are there reasons heavier than the potential benefit to keep those elements away from plugins?

[appetizermonster]

@Loilo I agree with you. In the first time, I just couldn't think about that cases. and do you have any suggestion for another tags except (<img> <svg>)?

[loilo]

Woops, accidentally closed this issue while typing an answer. :)

---

I think not concerning those use cases from the beginning is probably a pretty natural part of development. :)

So let me bring my thoughts on some of this topic to the table:

Would the usage of HTML be useful?

I definitely think so. There are probably plenty of things one could do with additional tags and I certainly can't event think of all of them right now.

Which tags would be useful?

Well, I guess <img> and <svg> are the obvious ones. Since we already got a kind of <ul> tag by just adding more responses, those are the ones providing the most value on their own.

That said, the most other tags wouldn't be too useful without the abilty to style them.

That opens an even wider field of questions regarding the usage of CSS

Other tags (apart from <img> and <svg> which are kind of a styling thing on their own) probably wouldn't be too useful without the ability to style them.

If we'd want to go further, we'd need a sensible interface for bringing our own styles. Scoped CSS would probably be the optimal solution but sadly that's not supported in Chromium. A polyfill would be an option.

Another passable path would probably be to use PostCSS on the first loading of a plugin to prefix all developer-defined rules with a unique class or ID selector so the not-native CSS would be kept under control. Technically that's probably also a polyfill for scoped CSS anyway.

So for now I think it would be fine to stick with <img> and <svg>. Other options would probably take some time to be sanely planned in detail.

Other thoughts more or less loosley related to using HTML:

• Although we don't have access to the DOM via the plugins API (which is probably a good idea) it would be nice to be able to dynamically change the contents of a response for whatever reason. One possibility would be to allow to not only pass strings to the title property of the response options but also to pass a DOM node. It would allow developers to change the contents of a response on the fly.
  • A problem with that would clearly be that this was an indirect access to the whole app's DOM which is probably a terrible idea.
  • This issue could be bypassed by using <webview> tags for the title information but that might actually be too much of a crazy thing. I kind of lack the experience in Electron to tell if that would be a good idea at all.
• Since I've already written about styling above: It would be nice to not restrict the height of a response. That would allow for more crazy things like an image search or anything else that would need a little more space. Just something to think about if we're already at it. :)

[appetizermonster]

@Loilo wow, Good article, I think that it's reasonable to implement <img> and <svg> at first. and Some other kind of window for displaying html like Spotlight would be needed