How much more efficient? Here are some timings – the scripting time in Chrome incurred on ten keystrokes in a document containing notes, averaged over three attempts:
No. of notes in doc
Before (ms)
After (ms)
10
111
69
100
212
105
1000
2010
337
There are still issues with the cursor that may be related to issues with either Prosemirror or browsers – see this issue for details.
Implementation details
There are a few changes to the rendering and styling of note ears here. The note ear spans now contain a single space character to give the span some content, which seems to improve caret behaviour in browsers as they move around note ears.
I'm still unsure as to why this is the case. It may be to do with the fact that zero-width spans have no dimensions, which seems to cause caret positioning bugs.
To prevent the caret appearing in the center of the span, which now contains content, padding is conditionally applied to either the left or the right of the note ear depending on the intended position of the caret, to ensure it is placed correctly.
It's possible that this space character could be replaced with a zero-width space, which would remove the need for some of these changes, and perhaps be a little more obvious semantically
Todo:
[ ] Investigate possibility of zero width span within span elements
Adds a key to our widget decorations re: the spec, to avoid redrawing them every transaction.
This makes our RTE more efficient, and may prevent a Chrome cursor bug that's triggered when inserting spans.
How much more efficient? Here are some timings – the scripting time in Chrome incurred on ten keystrokes in a document containing notes, averaged over three attempts:
There are still issues with the cursor that may be related to issues with either Prosemirror or browsers – see this issue for details.
Implementation details
There are a few changes to the rendering and styling of note ears here. The note ear spans now contain a single space character to give the span some content, which seems to improve caret behaviour in browsers as they move around note ears.
I'm still unsure as to why this is the case. It may be to do with the fact that zero-width spans have no dimensions, which seems to cause caret positioning bugs.
To prevent the caret appearing in the center of the span, which now contains content, padding is conditionally applied to either the left or the right of the note ear depending on the intended position of the caret, to ensure it is placed correctly.
It's possible that this space character could be replaced with a zero-width space, which would remove the need for some of these changes, and perhaps be a little more obvious semantically
Todo: