Syntax highlighters typically wrap tokens in <span> elements and use CSS for colorization. The CSS Custom Highlight API aims to streamline this process, reducing DOM clutter.
See the spec here and learn more through this article by Bram.us. Also, check out an implementation example on CodePen:
Could this API be an alternative to highlight.js for syntax highlighting?
How are you proposing to wire up a tiddler text field with a pre element?
That’s interesting. But it seems to be very early in browser support. Which also seems to be still buggy.
On the other hand, it seems like, that we could use the parse-tree, which should have most of the start / end positions for TW wikitext. BUT – TW uses an IFRAME text editor, to be able to keep text selections alive, when clicking the toolbar buttons.
So as always. The devil is in the details. – It will not be easy.
I wonder how this relates to codemirror?
I do not know CM6 well enough, but CM5 a completely different concept.
CodeMirror’s syntax highlighting feature is primarily implemented using Lezer. Lezer is a syntax parsing library that can parse text and identify the syntax structures within it. It then marks different syntax elements in a semantic way and highlights them using CSS styles. Lezer’s advantage lies in its ability to efficiently handle various types of syntax and its ease of extension and customization, enabling CodeMirror to support syntax highlighting for multiple languages.
I lack the technical skills to implement this approach but I thought that if applicable it might benefit TiddlyWiki users, particularly with the CodeMirror plugin’s tendency to add many elements to the DOM, sometimes affecting custom styling (for example the sizing of text areas). I posted this in hope that someone with the necessary expertise will be inspired to delve into this 
Basically, this…
<pre contenteditable>{{my-tiddler}}</pre>
presents the content of my-tiddler for editing. The next step is to either…
I bet there’s a set of problems waiting for me if I tried that. 
Not least of which, no draft mechanism. And would the text ref reread the rewritten content giving a nightmare race condition?
I don’t have time for that kinda thing, sadly.
I am interested, but I do not know enough about the new API to see a clear picture, how we can implement TW wikitext syntax into the TW editor. Some experiments and much more reading will be needed.
The codepen examples are impressive, but we need to get it going with our own editors, which are based on textareas, which is not supported by the API atm.
For me personally, it’s too early. My primary browser is FireFox, which does not support the mechanism yet. Also from the blog post you linked, there still are some severe problems. See the section about The downsides …
The TW parse-tree is also still missing some start / end “markers” that we’ll probably need to implement the highlight logic. There is a pending PR which will make the situation better, but I’m ot sure if there will be enough info to get “good quality” highlighting.
I think it would be interesting, since it seems there will be much less code involved as with the current CM5 or CM6 plugins, which account for close to 1MByte for CM6
Ah yes I failed to see that as @pmario said, the API does not support textarea and input (yet) - I tought that this could work on any selectable text. Yes, as of now this won’t be easy to use it for tiddlywiki, I can see how complicated this can get
The limited styling options is a bummer Not having pointer event on the highlighted text is less of an issue, as code mirror do not provide custom tooltip either (or at least not the default version), and while not ideal the (temporary) loss of color highlight on highlighting a text could be acceptable (for me) if this approach would result in improved performances compared to codemirror.
Note that firefox DOES support the API, but only on nightly for now :
Therefore the odds that this will get better support soon (?) are pretty good, or at least I hope so.
In any case, even if it’s not ready yet (I agree, firefox not supporting it is definitively a deal breaker), I think it’s worth keeping an eye on this tech That being said, if it’s tiny enough this could be a nice progressive enhancement for tiddlywiki to enable syntax highlighting on stylesheet preview for example, chromium and webkit based users benefiting first, then firefox users once the feature is fully implemented.
PS: Once this api become better supported, it will probably be usefull for the dynannotate plugin too, here’s a demo for a custom search highlighter: Custom Highlights demo (codepen.io)
According to this post, it’s behind the pref dom.customHighlightAPI.enabled.
https://groups.google.com/a/mozilla.org/g/dev-platform/c/fE37aJ_YdA8/m/Sfv0ggpLBQAJ
Odd, but I can’t find mention of it here: https://html-now.github.io/ or here: Mozilla Specification Positions
