goog.editor.range
Namespacegoog.editor.range.Point
ClassOne endpoint of a range, represented as a Node and and offset. … more
.expand(range, opt_stopNode)
Given a range, expand the range to include outer tags if the full contents of those tags are entirely selected. This essentially changes the dom position, but not the visible position of the range. Ex.
range
{goog.dom.AbstractRange
}
opt_stopNode
{Node
=}
goog.dom.AbstractRange
}
.getDeepEndPoint(range, atStart)
Get the deepest point in the DOM that's equivalent to the endpoint of the given range.
range
{goog.dom.AbstractRange
}
atStart
{boolean
}
goog.editor.range.Point
}
.intersectsTag(range, tagName)
Returns whether the given range intersects with any instance of the given tag.
range
{goog.dom.AbstractRange
}
tagName
{goog.dom.TagName
}
boolean
}
.isEditable(range)
Checks if a range is completely inside an editable region.
range
{goog.dom.AbstractRange
}
boolean
}
.narrow(range, el)
Given a range and an element, create a narrower range that is limited to the boundaries of the element. If the range starts (or ends) outside the element, the narrowed range's start point (or end point) will be the leftmost (or rightmost) leaf of the element.
range
{goog.dom.AbstractRange
}
el
{Element
}
goog.dom.AbstractRange
}
.normalize(range)
Given a range in the current DOM, create a factory for a range that represents the same selection in a normalized DOM. The factory function should be invoked after the DOM is normalized. All browsers do a bad job preserving ranges across DOM normalization. The issue is best described in this 5-year-old bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=191864 For most applications, this isn't a problem. The browsers do a good job handling un-normalized text, so there's usually no reason to normalize. The exception to this rule is the rich text editing commands execCommand and queryCommandValue, which will fail often if there are un-normalized text nodes. The factory function creates new ranges so that we can normalize the DOM without problems. It must be created before any normalization happens, and invoked after normalization happens.
range
{goog.dom.AbstractRange
}
function
(): goog.dom.AbstractRange
}
.normalizeNode(node)
Normalizes the given node.
node
{Node
}
.placeCursorNextTo(node, toLeft)
Position the cursor immediately to the left or right of "node". In Firefox, the selection parent is outside of "node", so the cursor can effectively be moved to the end of a link node, without being considered inside of it. Note: This does not always work in WebKit. In particular, if you try to place a cursor to the right of a link, typing still puts you in the link. Bug: http://bugs.webkit.org/show_bug.cgi?id=17697
node
{Node
}
toLeft
{boolean
}
goog.dom.AbstractRange
}
.rangePreservingNormalize(node, range)
Normalizes the node, preserving a range of the document. May also normalize things outside the node, if it is more efficient to do so.
node
{Node
}
range
{goog.dom.AbstractRange
?}
goog.dom.AbstractRange
?}
.saveUsingNormalizedCarets(range)
Saves the range by inserting carets into the HTML. Unlike the regular saveUsingCarets, this SavedRange normalizes text nodes. Browsers have other bugs where they don't handle split text nodes in contentEditable regions right.
range
{goog.dom.AbstractRange
}
goog.dom.SavedCaretRange
}
.selectNodeStart(node)
Cause the window's selection to be the start of this node.
node
{Node
}
.selectionPreservingNormalize(node)
Normalizes the node, preserving the selection of the document. May also normalize things outside the node, if it is more efficient to do so.
node
{Node
}