Workaround for bogus HTML documents (h:#409) by csillag · Pull Request #207 · openannotation/annotator

and others added 30 commits

July 4, 2012 17:16
Rather than using the presence of a `ranges` property on an annotation
to determine whether it is new or updated, track that information via
one-shot closures subscribed to the editor events. The proper
subscriber registers via the callbacks for adder and annotation edit
clicks where it is known for certain if the annotation is new or
updated.
… target/selector, instead of range)
- Went from using ranges to using targets, which have selectors.
- Added support for generating "xpath range", "position" and "context quote" selectors. (Some of them contain some fake data.)
- Don't publish event after trying to load annotations, when nothing is found
- When trying to find anchor based on the XPath range selector, verify the quote, if available
- Added fuzzy matching strategy
…ator into fuzzy-anchoring
 - Renamed some range-related things for more consistency
 - Added support for handling img title and alt tags

Annotator:
 - Renamed some range-related things for more consistency
…owser differences.)

 - Add support for showing visual diff of the changed quotes. (Currently only works inside of h.)
Updated to follow API change on dom-text-matcher.
- Moved the init code of the dom-text-* libraries into a separate method, making it possible to omit these libraries when not needed.
- Removed some dead code
- Cosmetic changes
Conflicts:
	src/annotator.coffee
In case our highlights were removed from the DOM somehow, don't
remove them again.
…osition in the one-phase fuzzy strategy.

@csillag

… when something was cut.

@csillag

… names of the constants. (Better readability)

 - Added detailed debug information to SerializedRange.normalize
 - When normalizing a SerializedRange, and looking for the start, don't choose the last position of the previous text element, but the first position of the current one. This avoid adding whitespace by accident.

@csillag

@csillag

@csillag

@csillag

…gn in them."

This reverts commit 0d1ef70, which was unsufficient to solve the problem.
Stronger measures have been introduced since this first weak attempt.