[annotator-dev] Cross-browser support, cont'd.

[Randall Leeds]

On Sep 8, 2014 1:29 PM, "Bill Hunt" <bill at krues8dr.com> wrote:
>
> Hi everyone,
>
> I've been continuing to work on adding support for older browsers,
focusing on IE back to 8 at the moment.  Right now I've got *most* of the
test suite running successfully - using a handful of shims - but I've had
to circle back to working on the xpath-range plugin to get the Highlighter
tests to pass.
>
> Quick history:
>
> Original IE ticket from 2012:
> https://github.com/openannotation/annotator/issues/173
>
> Current issue:
> https://github.com/openannotation/annotator/issues/428
>
> Thread on Range implementation from June of this year:
> https://lists.okfn.org/pipermail/annotator-dev/2014-June/000944.html
>
> xpath-range issues on the topic:
> https://github.com/openannotation/xpath-range/issues/3
> https://github.com/openannotation/xpath-range/issues/4
> https://github.com/openannotation/xpath-range/issues/5
>
> The short version is, using Rangy as an interface (not just a shim) is
providing most of the behavior we need for support.  There are a few
outstanding major issues, such as #5:
>
> IE8 (and several other browsers) produce rather inconsistent results when
you're reading the contents of DOM nodes that have newlines in/between them
- some include this extra whitespace, others don't. As a result, it's kind
of hard to test predictably the way that we're currently doing it.  I don't
know that stripping whitespace in the test helper is necessarily the best
way to handle this. We will need to alert users of the inconsistency of
course.
>

It would seem to me that if whatever we're using for ranges and selections
isn't providing consistent results it's an issue with that library, or with
a browser.

We should report these where it makes sense and special case the tests. If
the differences are well understood we can work around them or submit
patches ourselves.

It might also be the case that we're doing something less than ideal in
annotator. For instance, we may want to split ranges at element boundaries
and store multiple ranges for a selection. That might eliminate
inter-element whitespace collapsing issues. With regard to trimming
whitespace at the front or back of a single element's text, the W3C has
spec'd this and I think it works out to depend on whether something is an
inline or block element. We could probably make fixes/workarounds.

> I'd really appreciate any insight or feedback that anyone has on this -
please feel free to jump in on any of those tickets.   I also don't know
what kind of impact fuzzy anchoring may have on this, if any.
>
> Cheers,
> -Bill
>
> Bill Hunt
> Senior Developer
> OpenGov Foundation
> http://opengovfoundation.org/
>
> _______________________________________________
> annotator-dev mailing list
> annotator-dev at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/annotator-dev
> Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20140908/fb0c3b2b/attachment-0004.html>