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

[Randall Leeds]

I was fairly certain that browsers collapsed leading and trailing white
space inside block elements and not in inline elements. That's what I was
referring to.

Whitespace around a tag I don't think is collapsed.

Maybe I'm missing the point? Some concrete examples would help. Can you
point me to a test and a browser version and ask again?
On Sep 9, 2014 12:56 PM, "Bill Hunt" <bill at krues8dr.com> wrote:

>
> 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/20140910/7d066aba/attachment-0004.html>