Non-invasive way of making highlights - maybe with an overlay?

[csillag]

Currently, we are making highlights by wrapping SPANs around text elements.
This can cause problems, if the page has some active code, which tries to work with the same text elements later.

For example, take this example:

• There is a P element, with the following text: "This page has been seen by 10 people."
• We create an annotation around "has been", thereby cutting the original text element into three parts, and replacing the middle one with a SPAN, containing the text.
• Then the page would like to replace the original content with this: "This page has been seen by 11 people."
• Since the page assumes that the P element has only one child, the text element, it will probably simply use firstChild to find the element, and overwrite in it's value. Which, in our case, will result in this: "This page has been seen by 11 people.has been seen by 10 people."

There can be many similar unintended consequences.

Ideally, it would be great to add highlights without disturbing the original DOM any more than necessary.

Here is a way we could do in, in theory:

• Add a div, which would be positioned to cover exactly the same area as the root element
• Use this div as a layer above the original content
• Instead of working with the "real" content of the DOM, draw our highlights over this new layer, laid over the original content.

From the user's point of view, this would be indistinguishable from what we have now. However, we could totally (well, almost totally) abstain from touching the DOM! That also means we could stop slicing and dicing the text nodes, which has been proven to be a huge pain point, at least for me.

What do you think?

btw, I think PDF.js is doing something similar for selection: they have a canvas for actually drawing the content of the PDF, and different DIV laid over the canvas, which is only used for selection.

[nickstenning]

This is something that I've discussed in the past. In particular, the canvas approach was the one taken by the Textus project. I'd be really excited to see this.

The Textus code that does this is here. If you're going to start working on this I'd strongly suggest checking it out.

[csillag]

I don't intend to start working on this right away; I am just mentioning
this here for the record.

Btw, I have done a bunch of interesting things related to highlights
(and anchoring in general), which I hope to explain to you ASAP.
(Probably tomorrow.)

[csillag]

[...] the canvas approach was the one taken by the Textus project. [...]
The Textus code that does this is here.

Yes, that's exactly what I had in mind.

[mitar]

Interesting. This is what we have in PeerLibrary. We use DOM elements and we render below the content, not above. So that users can still select text normally.

[mitar]

(But we have easier time because we control all content and PDF text layer so we can have such layers.)

[csillag]

Sounds nice. Is your implementation tightly coupled to your code, or is it more of a generic, library-like thing?

[mitar]

For this initial stages of trying out things and see if it really improves something it will be somewhere in the code. But I would be glad to abstract it out if we see that it really works better and if you would be interested.

Same goes for our text-selection improvements for PDF.js. Currently it is coupled with our viewer, but we could send it upstream at some point as well.

[mitar]

(We are all for code sharing and reusing. Just have to be told what other people find interesting.)

[csillag]

I find your non-invasive highlight implementation very interesting. And since I have already refactored highlights into separate classes living in separate plugins (hopefully to be merged into Annotator 2.0 soon), your work could (in theory) be used as a drop-in replacement for the current implementation, with zero or very little changes outside the relevant plugins.

[mitar]

You are talking about this plugin? Because yes, this is where I was looking at maybe implementing an alternative way of doing highlights.

[csillag]

Yes, that's the one. Highlights are implementing this interface. For another example, see this highlight in the (WIP) image anchoring plugin.

[csillag]

The interface definition is not really exhaustive, because there are a bunch of things highlights are supposed to do, but are not mentioned in the interface. (Like calling the onAnchorMouseover, onAnchorMouseout, onAnchorMousedown, onAnchorClick methods.)

[tilgovi]

I think we should investigate the Shadow DOM. If it's possible to get coordinates of shadowed nodes (for things like the heatmap), it'd be great if we could (somewhat) invisibly change the DOM this way.

[csillag]

• Textus (recommended by @nickstenning) has a working implementation for this.
• Also @mitar 's stuff has something very similar.

We can check out ShadowDOM, too, but I would prefer investigating the two already existing implementations first.
(And I believe that @mitar might already working on that... right?)