We’ve been wondering what’s the general state of the HTML XBlock? In this talk:
it was mentioned that all the XModules will be replaced by XBlocks. So presumably the HTML XModule will be replaced by this XBlock by OpenCraft? Looking at that XBlock, we find it very useful and in addition, we see an opportunity there for it to be the basis for some other, helpful features. One being the ability to edit content in Markdown, as we now have a need for that functionality. We’ve already created a PR suggesting to add this feature:
and we’d love to get some thoughts on that! Anyone else looking to have an XBlock with Markdown editing? Would you like this solution or would you prefer a separate XBlock for just that?
Yes, and that has been happening. In fact, @usman converted the HTML XModule to an XBlock about five months after my talk, on August 1, 2019 (see HtmlModule to HtmlBlock pull request). This didn’t involve any user-visible changes, it was simply reducing technical debt in the platform by moving away from the old XModule code to the newer XBlock code.
That xblock-html works well enough, but we realized that we were going to need to support a lot of other types of XBlock in addition to HTML, and there are too many places in each XBlock’s settings where user input can be converted to HTML, presenting an XSS risk.
So in the end we stopped development of xblock-html and took a different approach, that of rendering every XBlock in a sandboxed <iframe> and not worrying about sanitizing the HTML/JS of individual XBlock fields.
Wow, nice! And thanks for that PR, it looks great. I’ll look into getting it reviewed and merged.
I’m not sure if or to what extent we’re actually using xblock-html at the moment, but if people in the community find it useful (especially with markdown) it certainly makes sense for people to use it, and it can be installed alongside the “normal” HTML XBlock no problem. Perhaps in the future there can even be an option to make it the default for new “Text” components in Studio, though I don’t know if that makes sense for Open edX as a whole.
there really isn’t much of a reason to use the xblock-html ?
The only reason would be if you want some increased security, if you have course authors you don’t trust. But generally no there is no reason to use it instead of the built-in HTML block.
So if one has a course that includes content built with the xblock-html , exports it and subsequently imports it into an instance that does not enable it, what happens? And what about the reverse case?
It won’t import successfully; those HTML components will just show up as “unknown component” until/unless you install the xblock-html onto that instance.
The reverse case is fine, the standard HTML block always works and is universally compatible with all Open edX instances and versions as far as I know.
Basically the system treats them as totally separate xblock types. The built-in HTML block is of type html and the xblock-html that we made as an experiment is of type html5, so they’re always separate.
Thanks for the info @braden, this has been very helpful! With this in mind, I believe it will actually make more sense for us to start maintaining our fork as a separate XBlock for only Markdown editing and publish it as Markdown XBlock on PyPI.
Adding a link to our Markdown XBlock here, in case anyone is interested of the outcome of this dicussion:
This is based on the HTML XBlock by OpenCraft as mentioned above. We replaced the text and raw HTML editors with just one, a Markdown editor. We will be using and maintaining this, so for anyone giving it a try, feel free to ping me for any issues you might have regards to that!