substance / surface

A building block for web-based text editors

Home Page:http://sandbox.substance.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Overlapping annotations

michael opened this issue · comments

So here's the thing.. surface should allow all possible variations of overlapping annotations etc.

So we should let the user control the behavior of overlapping annotations..

Toggling annotations

Let me describe the Composer usecase:

em/strong are explicit.. and can't overlap

So in my implementation if someone wants to do an em, but it partly overlaps with an existing strong element we want to split up that strong annotation into two and put the em in between.

  0SSSSSS0000
+ 0000EE00000

Result:

0SSSEESS0000

To implement this (outside of surface of course, we need to provide the right information so the user can do the thing that is right for his usecase.

Get overllapping annotations in a given range (but only for em, and str annotations) others can overlap... such as comments.

surface.annotations([4,6], ["em", "str"])

So we get back the str annotation and split it up into two.

  1. Update the existing annotation (new range [1, 4])
  2. Create a second strong annotation (range [6,8]

And then.. savely insert the new em annotation in between.

This means we need an insert/update/delete API for annotations. We should just implement it. The toggle mechanism can't be generalized and should be handled from outside.

Displaying overlapping annotations

surface.hide(["annotation:1"], ["annotation:5"]);
surface.show(["annotation:1"]);
surface.get("annotation:5").hidden; // true or false

Say we have overlapping comments, say 10 for the exact same range.. not a problem. BUT: the client needs to visually deal with it.. So we should introduce a hide/show mechanism. The user can then implement strategies like... show all latest annotations in case of an overlap.. or trigger a second view.. which shows all annotations matching a particular selection.

So I guess what we need is an API for show/hide and a hidden property to check if a particular annotation is visible. By default we just show everything.. but the user might pass in a hidden flag to not have those annotations rendered on the surface.

@oliver---- What do you think?

This scenario makes sense, but then would the second part of an annotation become a new annotation by itself? or when you refer to the first chunk, we consider it extends to the end of the second one? Also when hiding/toggling a split annotation...

Mhh good point. I think it'd be fine to have a new annotation for that. The other thing to consider is storing multiple ranges per annotation. However I think this is a lot of work that needs to go into tweaking.. so it should be handled on the application side. We'll figure it out as we go. For surface it's just fine if it accepts overlapping annotations of any kind. To ensure rules the application should do the dirty work.

Regarding showing and hiding.. maybe we should shift that to the application level as well. So any annotation get's shown on the surface. To hide it, your app removes it from the surface, to show it.. it re-adds it.