On Thu, Oct 26, 2017 at 12:44 AM helt < [email protected]> wrote:
> Hi Randall, > > after reading your email twice and skimming over the W3C stuff and > planning wiki page, I am a strong advocate of getting the selector.js > done first :) I don't even need the w3c data structures as I have my > own... > The selector implementation is about identifying (selecting) segments of the document. It is independent of the Range implementation. > I agree, the Range API is more complex than I had imagined and > implementations of it seem to differ across browsers. So before > extending my own hacky code to robustify selection, I looked at your > project as a possible alternative. Whether any w3c (or whatever) Data > Model standard is (correctly) implemented or not is not of relevance to > me right now, as the web app I have written does definitely not adhere > to any. If this is your first big milestone, I will be happy to > contribute a package that uses reactjs to highlight stuff. > Range has definitely implemented inconsistently. Newer browsers might be more consistent, but I suspect there are still some difficulties. A comprehensive replacement that tries to be consistent is Rangy [1]. In my experience, that's only really necessary for older browsers (IE < 10) that implement Range very poorly or not at all. For the purpose of getting consistent Range for selections of text, you might find that a simpler library, range-normalize, is helpful [2]. I have a version of it that has no external dependencies and, I believe, a simpler algorithm [3]. I may merge that into annotator. [1] https://github.com/timdown/rangy [2] https://github.com/webmodules/range-normalize [3] https://github.com/webmodules/range-normalize/pull/2
