Selection API
Home Page: http://w3c.github.io/selection-api/
License: Other
Selection API Specification defines APIs for selection, which allows users and authors to select a portion of a document or specify a point of interest for copy, paste, and other editing operations.
Completely unspec'ed. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=10583.
Define select and selection change events.
See b2c535a
We need to clarify when selectstart and selectionchange events are fired in relation to other keyboard and mouse events in the user agent that supports changing selection in the default event handlers of these events.
We should also clarify whether selectionchange happens before the next animation frame request or not.
The current spec doesn't explain what needs to happen for input and textarea elements when the selection inside them changes. Those selections are not associated with the Selection object for a Document, so we need to handle them somehow.
I think a nice way to extend the current spec to cover this case would be to dispatch selectstart and selectionchange to the input or textarea element itself when the selection inside them changes. The reason why the selectionchange event needs to be dispatched to the element and not the Document is that the web page would otherwise be unable to detect which selection has changed.
The spec doesn't define any onfoo event handlers, but IIRC at least some implementations already have them.
Need to spec which interfaces should have onselectstart and onselectionchange.
We need to define the concept of visually equivalency used in the definition of Selection.containsNode.
In both WebKit and Blink, the arguments of some functions are optional. That includes some nonsensical cases like "void addRange([Default=Undefined] optional Range range);" but also some arguments that have sensible defaults:
collapse's offset argument (0)
extend's offset argument (0)
containsNode's allowPartialContainment argument (false)
setBaseAndExtent also has all optional arguments, but that makes less sense.
Consider making at least the first three cases optional, as it does not seem worthwhile investigating the Web compat impact of making them non-optional.
The steps for collapse() and setBaseAndExtent include checks for negative numbers, which cannot be true. (These are signed in WebKit/Blink, I guess the steps were just copied.)
At the moment, CSS-generated text is not selectable in most (all?) user agents. It is also possible to make text unselectable via CSS styles. The Selection API should address this somehow.
Possibilities that spring to mind include:
Copied from w3c/editing#10
For instance, a Range that represents what the selection would be after a Selection event?
From: Piotrek Koszuliński, CKEditor JavaScript Lead Developer
Forked from w3c/editing#39.
To summarize:
If the range object is directly mutated by the user script, should the selectionchange event be fired? This isn't clear in the documentation.
var s = document.getSelection();
var r = document.createRange();
r.selectNode(node1);
s.addRange(r); // selectionchange event should be queued
// -- some time passes --
r.selectNode(node2); // Should another selectionchange event be queued?Could you please implement selection.containsNode(), as I need to use it or to use something like it for my GoogleTrans gadget, which is on en.wikipedia.org.
This gadget is loaded by 23,000 ids on the English wikipedia.
I have something called selection translation.
You
When you do these three things, then a popup happens with the Google translation of the selected text.
In order to know whether the cursor is in the selected text object I use, among other things, the selection.containsNode()
A small clip of the code is below:
/*
if(userSelection.containsNode(children[i],false))
SCselection[i] = true;
else
*/
if(!SCbIsIE11 && userSelection.containsNode(children[i],true))
{
SCselectionarray[i] = new Array();
SCselectionstart[i] = -1;
SCselectionend[i] = -1;
SCAreWordsInSelection(userSelection,SCselectionarray[i],
children[i],i);
SCselection[i] = false;
}
else
{
SCselectionarray[i] = new Array();
SCselection[i] = false;
SCselectionstart[i] = -1;
SCselectionend[i] = -1;
}
I want to tell you that I never could get userSelection.containsNode(children[i], false) to work. Firefox (and later IE9 and IE10) only worked for userSelection.containsNode(children[i], true)
However, both IE9 and IE10 supported this call. Would you please support the call for IE11, as least in the
userSelection.containsNode(children[i], true) mode. It is very helpful to me.
Otherwise, I cannot support knowing whether the cursor is over the current selection.
Gecko implemented Document.onselectionchange and GlobalEventHandlers.onselectstart. [1]
Edge does it too (but both on Document [2])
Blink does it too (on both Document too [3])
These event handlers properties should be added to the spec.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=571294
[2] https://dev.modern.ie/platform/documentation/apireference/interfaces/document/
[3] https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/Document.idl
For block-direction caret movements, we need to expose a property that specifies where the caret movement had started vertically.
It's implemented by WebKit and Blink and does the same thing as collapse(), oddly enough.
Usage is low, but so is the effort to support it:
https://www.chromestatus.com/metrics/feature/timeline/popularity/327
Quoting @johanneswilm from w3c/editing#73:
beforeselectionchange has been mentioned a few times. This event should be in the Selection API. If the caret movements intentions are to be moved there, it's important that the beforeselectionchange event contains the user intention (such as: "caret up").
Alternatively the beforeselectionchange event can just have a from-range and a to-range that doesn't need to specify what user intention caused the selection change, and we keep the intended caret movement events the beforeinput.
The spec currently say:
it must return a reference to (not a copy of) the context object's range.
and in its following note, it says it's currently not interoperable. Are there any reasons or good use cases to make this a "must" when implementations are not interoperable?
Most specs have a dedicated section, for important interfaces, so that they can be linked easily:
https://dom.spec.whatwg.org/#interface-document
http://dev.w3.org/csswg/cssom/#the-stylesheet-interface
This would be nice for the Selection API spec as well, at first glance I thought the Selection interface wasn't actually in the spec. Maybe just rename "Definition" to "The Selection Interface" or something.
We need to ensure we can only add ranges that are in the document associated with the selection.
"Once a selection is associated with a given range, it must continue to be associated with that same range until this specification requires otherwise."
This paragraph above is vague. It needs to be replaced by detailed conformance requirements saying exactly what to do for particular keystrokes, like we have for backspace/delete/etc.
Should we check for object equality or just equality of boundary points in selection.removeRange()?
Different browsers currently have different issues with this. The only stub element that they all seem to be able to navigate around are IMGs. Others, such as SVGs or Canvas-elements are only handled correctly in some browsers and not in others. Also, carets should be able to be displayed before, after and in-between non-editable elements and non-editable elements with editable islands.
See also https://bugzilla.mozilla.org/show_bug.cgi?id=873883
And discussion starting in w3c/editing#58 (comment)
Some apps have concurrent editing support. Since the Selection object represents the current user's selection, we need a parallel way to represent another user's selections.
This would make them much more easily Accessible. Today, browsers can announce changes to the selection object, but they have no easy way to track changes from other users to other areas of the document. A selection-like object for this purpose is one way to do this.
This request comes from the IndieUI WG. It is likely a V2 feature, or possibly needs it's own spec. But I want to make sure it's tracked.
Should cover click/mouse for place caret and expand selection in contentEditable='typing' and non-editable contnet
Selection.type appears to be supported in Chrome and used on CKEditor. We should define it. It supports at least "None", "Caret", and "Range" as values.
Should addRange(), removeAllRanges(), and removeRange() reset direction?
Would someone please explain why "Specification" is included in the title? Without a compelling reason to include it, please delete it.
I'm currently implementing selection events for gecko, and I noticed that the selectstart event documentation currently appears to imply that every time that a user changes the selection, a selectstart event should be fired. This is because of the combination of:
When the user agent is about to associate a new range newRange to the selection in response to a user initiated action, the user agent must fire ([DOM4]) an event with the name selectstart [...]
and
If the user makes any modification to a selection, the user agent must create a new range with suitable start and end of the range ([DOM4]) and associate the selection with this new range (not modify the existing range) [...]
This behavior definitely doesn't agree with chrome's implementation (resizing a selection in a textbox with the arrow keys in chrome, for example, doesn't fire selectstart events).
My best guess at the intention of this is that the selectstart event is intended to fire whenever a selection goes from being empty or collapsed to being non-collapsed. This is what I am currently implementing in Bug 571294. The spec should be updated to clarify what the intent is.
Should this spec codify if the range return by selection.getRangeAt(0) is changed, (e.g. insert a node into the range), the selection should change accordingly or not?
Currently, browsers behave differently on this one. Webkit and blink make selection to contain a new range. Gecko changes the selection. I personally think Gecko's behavior is the correct one.
The method must make the context object empty by disassociating its range if the context object's range is range.Otherwise, it must do nothing.One more point, what is range, in Selection.removeAllRanges() when we are saying if the context object's range is range`.
Forked from w3c/editing#39.
To summarize:
In order for editors to move the selections temporary, do some work in other regions, then restore the selections back, we need a new APIs.
This APIs not only save all public properties of selections but also internal states as well, so that the selections can really be restored.
There are some details we need to take care of, such as IME uncommitted strings. Usually IME uncommitted strings are committed when the selections are changed. But since IME uncommitted strings are part of the internal selection states, and since we want to restore it later, UA should cancel them on save (or save then move the selection.) Not sure whether this should be spec'ed, just an informative note, or not needed in the spec though.
We need to define how selection behaves with respect to user-select CSS property. We also need to ensure use cases listed at w3c/editing#58 (comment) are satisfied.
It's implemented by WebKit, Blink and Gecko, but not IE.
It has rather low usage:
https://www.chromestatus.com/metrics/feature/timeline/popularity/405
setBaseAndExtent as implemented in WebKit/Blink are related to these. Is the plan to drop the attributes but keep the function? Use counter data from Chrome:
https://www.chromestatus.com/metrics/feature/timeline/popularity/400
https://www.chromestatus.com/metrics/feature/timeline/popularity/401
https://www.chromestatus.com/metrics/feature/timeline/popularity/402
https://www.chromestatus.com/metrics/feature/timeline/popularity/403
https://www.chromestatus.com/metrics/feature/timeline/popularity/406
Based on this dropping the attribute looks doable, but is WebKit going to?
From MS Office Team:
The Unicode BiDi Algorithm (explained here: http://www.unicode.org/reports/tr9/tr9-31.html) is used by Text Rendering engines to properly display LTR and RTL text together in the same paragraph. In short, each character has a classification (mostly L and R, plus a bunch of neutral types), and the sequence of character classifications is used to determine which runs are displayed as LTR or RTL.
Mostly what I think we would need is the ability to query, for a given character, whether its direction is LTR or RTL after the Unicode BiDi Algorithm has been applied. I don’t know where the best place to put this API would be, perhaps the Range object? Something like this:
Range.getBiDiTextDir() : int
Return value is an enum in the range (LTR, RTL, MIXED), where MIXED is returned when the Range contains both LTR and RTL characters. (The caller would need to try again with a smaller range to get something useful in this case. MIXED would never be returned for a single character.)
I have no idea if this is the best API design but I’m just hoping to get across what would be useful to us.
For context, the reason this is important to us is that while HTML has the concept of “neutral text direction” (whenever the CSS property direction: ltr or direction: rtl is NOT specified), some editors like Word do not. Every run is either marked as LTR or RTL. If we can’t correctly detect the text as it’s being typed, then we may save it incorrectly into the document, and Word will display text direction differently than what the user saw as they were typing in the browser. There are also some performance optimizations we could make around text selection if we knew where in a paragraph the text changed direction, but this is less of a compelling reason than content fidelity.
Like the issue #32, we need a mechanism by which to specify whether the caret appears before or after a link break. Alternatively, we could make the attribute we're adding in the issue #32 writable but having to call setPosition / collapse and set a property separately in order to place a caret isn't great.
Should we replace the range rather than mutating it in Selection.deleteFromDocument()? This is currently the only Selection method that actually mutates an existing range in place.
The selection Api so far doesn't talk about changing the selection when moving the caret.
This will only apply when cE=typing and cE=true are specified, so it may have to go into another document.
If it's not specified anywhere, and browsers choose to implement it different, we won't be sure so we will need to continue to interrupt each key stroke event to check whether the caret may be at the border of an element before letting it do its default action. Then it may be easier to use a hidden textarea for input instead of cE=typing.
Two issues come to mind:
Caret at the end of an inline element
<p>Hello <i>Austri|a</i></p> ( | = caret)
If the user hits the right-key and then enters a "!", where should that end?
<p>Hello <i>Austria</i>!|</p> or <p>Hello <i>Austria!|</i></p> ?
And what is the intermediate step? To the user, these two situations will look the same:
<p>Hello <i>Austria</i>|</p> and <p>Hello <i>Austria|</i></p>
so it seems it would be reasonable that they will behave the same as well.
It should be ensured that the movement of the caret is the same in all browsers.
There are some well-known issues with that now, mostly related to the caret "jumping" another character when moving across inline void elements, foreign elements (SVGs) or elements that are specified as being noneditable or the caret not being able to go certain places (such as before one of the before mentioned elements when these are at the start of a block element). In all these cases, I believe it should be specified that these elements should be treated like single characters in relation to caret movement.
Passing null should cause it to behave like removeAllRanges. This is the behavior of WebKit and Blink, and an attempt to align with the spec in Blink failed with many reports of breakage:
https://code.google.com/p/chromium/issues/detail?id=395318
See use cases listed at w3c/editing#58 (comment)
It seems to me that this spec needs to include the following IDL changes for the event handlers that it adds, something like:
partial interface GlobalEventHandlers {
attribute EventHandler onselectstart;
attribute EventHandler onselectionchange;
};
If a caret is at the end of a line that wraps, it's hard to tell where it is on the screen (end of line or beginning of the next line). This is important for being able to control the selection (beforeSelectionChange).
-From MS Office Team
It has non-trivial usage, so unless it is useless or harmful may it should be spec'd:
https://www.chromestatus.com/metrics/feature/timeline/popularity/404
We need to define what it means to say editing hosts can't have selection.
If given a range, can we return if the character there is combined or simple? This helps with knowing how to correctly control selection movement.
-From MS Office Team
We need an API to return one, or two in the case of bidi, rects for the current caret position.
That's what it does in WebKit/Blink, and it has quite high usage:
https://www.chromestatus.com/metrics/feature/timeline/popularity/407
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.