Is there a reason why the Sublime API supports only a subset of the HTML5 tags (as minihtml) ? Performance reasons ?
Why minihtml and not HTML5?
I guess ST does not want to embed an entire browser rendering engine or something like that.
If you really want to know those implementation details (which is not important for non-staff), you can @ wbond then. Will Bond shed some light on that?
Here’s a link to an article by Tristan Hume (@trishume), Disassembling Sublime Text, that explores the internals of Sublime Text custom rendering engine:
Hume’s analysis reveals an elaborate engine built on top of various third party components known for high performance and scalability (eg. Skia). The article is two years old, so things might have changed slightly, but it gives the overall idea.
Here’s @wbond reply to that article (with some correction), on this forum:
Would be nice to have dummy simple HTMLCanvas element support. Then with help of zebkit.org it would be possible to build almost any desirable UI
Using zebkit would require embedding a full-blown JavaScript engine, likely with JIT compilation capability to make it fast enough for rendering UI elements. I highly doubt that this will ever happen, sorry.
Yes, I completely understand it. zebkit cannot be used as is and (from my point of view) brining JS engine to Sublime doesn’t make any practical sense. The idea is it would be nice if sublime could provide something similar to dummy HTMLCanvas (python canvas) what could be used by plug-ins developers for building custom visualizations and (if it could support basic input events) for creation of custom UI. Backing to zebkit lib, it is actually abstract enough to be ported to Python canvas-like API (at least earlier zebkit father has been applied to J2SE, J2ME, Java SWT and .NET platforms).