@bramus Slick! but if there's no markup it's not really...

@bramus Slick! but if there's no markup it's not really a semantic document anymore, right? not standalone anyway.
To me, “overloading” the DOM with meaningful elements to denote information about a piece of text is the least concerning thing when it comes to creating elements these days.
Also, was there consideration from ECMA about using `Range`? seems like that might be more useful as a non-browser primitive.

Like 15 February at 23:58 | Wall-to-wall | Open on indieweb.social

2 comments

Bramus

@tbeseda The way these highlighters typically work is by wrapping things in spans with a bunch of classes. These spans with classes add no semantics at all.

Also, sometimes - e.g. on large files with many tokens - they can cause performance issues because of the larger DOM tree.

Don't have info on how this API came to be, so don't know if and when TC-39 was consulted.

16 February at 0:04 | Open on front-end.social

tbeseda

@bramus good point about performance.
I have written a couple highlighters and one tried to be semantic about the added elements. A lot of work for minimal pay off.
I’m not opposed to the new feature, just wish there was a way without the script.
Cool to see the progress.

16 February at 0:09 | Open on indieweb.social

Go Up