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.
Probably not.
When we were starting the LabXchange project, we realized that in order to allow user-generated content in XBlocks on the site, we were going to have to provide some very strict HTML sanitization/sandboxing. So we whipped up xblock-html as an experiment; it uses bleach to restrict authors to a safe subset of HTML and by default also prevents any use of JavaScript.
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.
@usman converted the HTML XModule to an XBlock about five months after my talk, on August 1, 2019
Ah, ok. So for HTML content there really isn’t much of a reason to use the xblock-html?
it can be installed alongside the “normal” HTML XBlock no problem
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?
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!
One issue I’ve experienced, though I don’t know if this is the right place to list it, is that I can’t use Markdown blocks in Libraries (and thus I always have to fall back to raw HTML). Is this expected?
Yes. Libraries only support a limited set of XBlocks. You’ll have to modify the code to allow others.
I used to maintain a patch that did just this, but haven’t kept it up to date. A quick investigation seems to indicate the good folks at City Network have, though. (At least up until Maple.) See the last two commits in this branch.
Note that your mileage may vary with any individual block. There’s a reason why the choice was limited in the first place.
Lastly, as I usually do when libraries come up, I suggest keeping an eye on the work being done on Libraries v2. One of the major improvements over Libraries v1 is precisely allowing any block type to be included.
Given that v1 libraries don’t work for public classes, and I assume the answer will be “we’re not going to support that because v2 is coming soon!”, how can I submit something so that this gets tracked and fixed for v2 libraries?
That sums it up, yes. For most intents and purposes, you can consider v1 libraries to be in maintenance mode.
However, I wouldn’t say they’re coming soon. Yes, I know: I’ve said as much many times in the past, and have been bitten accordingly by multiple delays. There is significant work being done, but I’m no longer clear on when it will be in a generally usable state.
For general suggestions (i.e. not just libraries v2), the current recommended way is to submit ideas to the roadmap.
If you want to draw the attention of people that are actually coordinating the current work, I would suggest commenting on the project page in the wiki.
Would you like this solution or would you prefer a separate XBlock for just that?