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

[Bill Hunt]

Bill Hunt
krues8dr.com
Ph: 20-BILL-HUNT
       202 455 4868

On Sep 8, 2014, at 4:46 PM, Randall Leeds <tilgovi at hypothes.is> wrote:

> 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.
> 

Well, the W3C states that all whitespace is kept in the DOM, but goes on to say, "Note that some DOM implementations, which do not consider whitespace in element content to be meaningful for the XML languages they support, discard these whitespace nodes before exposing the DOM to their users."  ( http://www.w3.org/DOM/faq.html#emptytext )   So it's not entirely unusual.  Mozilla also canonically provides a chunk of code for stripping these nodes (https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOM )   So my gut here says that we shouldn't rely on how whitespace nodes are handled for determining content.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20140909/ef38c191/attachment-0004.html>