Unwanted interactions between highlights and document structure

[benel]

For unknown reasons, LaSuli generates a very deep structure of spans (10 levels) on the creation of an highlight (screenshots will be sent by e-mail).

This could be the cause of two different bugs:

• one on the page layout (some rows are too much indented),
• the other on the display of fragments (the highlighted text is only a part of the the text used in the name).

[benel]

The "spans of spans" could be related to reloads but I'm still not sure about the exact procedure to reproduce it.

I'm not truly sure either that it is the explanation for the two bugs mentioned earlier.

[chao]

Yes I have aware of this bug. The thing is after the document ishighlighted, I can not revert the highlights (unhighlight) correctly (remove the tag <span>). So when you switch between the different viewpoints without reload the document, the document will be highlighted several times, each time produce a SPAN tag.

This is actually a bug, I'm still trying to find a solution.

[benel]

OK, I'll delay the first IF14 lab till next friday.

[chao]

Bad news!

I made a mistake, I never know Mozilla also counts the whitespaces in the original HTML text document into DOM.

see: https://developer.mozilla.org/en/Whitespace_in_the_DOM

So that every coordinate in our database is not correct! Since they included invisible whitespaces!

And after we updated the Cassandre output layout, the whitespaces are changed too. That's why the injected spans are placed wrong place.

[chao]

Help needed...

I don't know how to ignore those invisible whitespace in treewalker.

[benel]

I have no idea... Isn't it possible to trim the PCDATA before calculating positions? Or are the positions given to you by an existing API you have no control on?

[chao]

If we use treewalker to traverse the example in https://developer.mozilla.org/en/Whitespace_in_the_DOM, we will get DOM tree like this:

<textnode>\n2s</textnode> <H1>Header</H1> <textnode>\n2s</textnode> <P> <textnode>\n4S</textnode> <textnode>Paragraph</textnode> <textnode>\n2S</textnode> </P> <textnode>\n</textnode>

By giving the coordinate [0,6], we will expect the whole word "Header" highlighted. However, there are 3 invisible characters "\nss" before the tag <h1>, so that only "Hea" will be highlighted in this case.

So that the coordinates are not correct!

And I cannot simply trim the spaces, since some spaces are visible in some cases:

<font>example</font>1s<font>here</font>

transform to DOM tree-> <FONT> <textnode>example</textnode> </FONT> <textnode>1s</textnode> <FONT> <textnode>here</textnode> </FONT>

In this example the whitespace between "example" and "here" is visible!

('s' stands for whitespace)

[benel]

I'm not sure I understand. Do these whitespaces affect:

• the highlights creation,
• the highlights rendering,
• or both (but in a different way).

[chao]

It is not a problem if the original HTML source code remains the same. Since we counted the invisible spaces when we create the highlights. and we also count the invisible spaces for rendering highlights.

That's why I haven't noticed this bug.

The problem is: the author changes the HTML source code after the highlights creation, e.g. add some spaces or new lines between the tags (which won't effect the web page render result), the highlights rendering will be totally wrong.

[benel]

Yes I knew that.

It is really a problem if any change to Cassandre pages structure makes all the markings obsolete. We can afford to loose the existing highlights, but I would prefer that we adopt as soon as possible a method that would reduce the effects of future page structure changes.

My question was: "Are the coordinates of the UI selection (i.e. before highlights creation) impacted by whitespaces?". If it were, that would be nearly impossible to fix. If it's not, and the problem is only in the rendering process, there's still some hope :)

[chao]

Yes, UI selection coordination is also depended on the whitespace. I'm still trying to find a way to avoid such affect.

[chao]

I have tried a day to learn which white spaces can be ignore, which one should be kept during the tree traversing. But after I checked HTML4 specification (http://www.w3.org/TR/html4/struct/text.html#h-9.1), I found out it's too difficult to distinguish the insignificant white space and significant white space in JavaScript.

So that for now I have to put down this issue and start to work on issue #14. But I will keep thinking ...

[benel]

Mmm, puzzling...

[benel]

The indentation bug can be seen also on the old Cassandre table layout. So this is really a LaSuli bug (independent from Cassandre recent updates) and this is a new bug probably due to a recent update in LaSuli.

What was the rationale of the refactoring of the way the text is highlighted?

[benel]

I wonder if you understood what I meant by "indentation bug"... I didn't mean in the source code but in the layout displayed by Firefox.

Display this text while LaSuli is opened. You'll need your Hypertopic account.

[benel]

This issue is too general. More specific issues will be reported.