Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
FlorianVogt
Product and Topic Expert
Product and Topic Expert
0 Kudos
716
This blog post is about the Selection interface, which is available in all modern browsers (e.g. Chrome, Firefox or Safari). This interface enables developers, among other things, to identify the screen areas which are currently selected by the user and to trigger user selections via code. Because the Selection interface is still in an experimental state, this blog post will be continuously updated to reflect the current situation.

The Introduction


Coding state-of-the-art enterprise-ready web applications requires a lot of different functionalities, e.g. performance, accessibility, and more. One important aspect is keyboard support. For many users of enterprise software the keyboard is still the main input device, so an application developer has to keep that in mind while building her applications.

Background


This blog post frequently uses the css attribute user-select. More information on it is available at Mozilla.

The Scenario


In this blog post I'd like to share with you my experience with the Selection interface, and more precisely how you can trigger a selection, how you can determine the currently selected text, and how different browsers act.

Step 1 - Create an HTML page


Firstly, I had to create a new HTML file and add some content:
<html>
<body>
<span id="rootText">This is selectable text No.1</span>
<div>This is selectable text No.2</div>
<div>This is a non-selectable text</div>
</body>
</html>


Let's open this HTML file in a modern browser and perform a Select All with CTRL+A on the keyboard.
All text on the screen is selected:




JSFiddle: https://jsfiddle.net/flovogt/o5jugf6L/

 

Step 2 - Mark the content as selectable and not selectable


Secondly, I've marked some areas with special CSS classes. All areas with class notSelect will be selectable. The areas with class notAllowSelect will be blocked from selection.
<html>
<body>
<span id="rootText">This is selectable text No.1</span>
<div class="allowSelect">This is selectable text No.2</div>
<div class="notAllowSelect">This is a non-selectable text</div>
</body>
</html>

Before I refreshed the HTML I had to add two CSS classes.
.notAllowSelect {
-webkit-user-select: none; /* Chrome/Safari/Opera/Chromium-based Edge */
-moz-user-select: none; /* Firefox */
-ms-user-select: none; /* Internet Explorer/EdgeHTML-based Edge */
user-select: none; /* Non-prefixed version */
}

.allowSelect {
-webkit-user-select: text; /* Chrome/Safari/Opera/Chromium-based Edge */
-moz-user-select: text; /* Firefox */
-ms-user-select: text; /* Internet Explorer/EdgeHTML-based Edge */
user-select: text; /* Non-prefixed version */
}

Now, let's refresh the page and perform a Select All with CTRL+A on the keyboard. Only the screen areas which are not set to user-select: none are selected:


JSFiddle: https://jsfiddle.net/flovogt/bd7gk0L6/

 

Step 3: Performing a 'Select all' without manual user input


There might be scenarios where it's not possible to perform a Select All with the keyboard, e.g. in automated test scenarios where there is no access to a keyboard. For these scenarios, the Selection interface provides an API called selectAllChildren. This method performs a selection on all child nodes of the given DOM element.

Let's enhance my sample with a small piece of JavaScript code to perform the Select All without any user interaction:
document.body.onload = function(){
document.getSelection().selectAllChildren(document.body);
}

Refreshing the page leads to the same result as described in Step 2, i.e. only the screen areas which are not set to user-select: none are selected. However, no manual user interaction was necessary.



JSFiddle: https://jsfiddle.net/flovogt/Lbeupdht/

 

Step 4: Get the currently selected text


After selecting text via code, the next step is to get the current selection via code. And again, the Selection interface provides an API for our scenario, more precisely the toString method. Let's add a button to the page, which will inform us about the currently selected text:
<html>
<body>
<span id="rootText">This is selectable text No.1</span>
<div class="allowSelect">This is selectable text No.2</div>
<div class="notAllowSelect">This is a non-selectable text</div>
<button onclick="getCurrentSelection()" class="notAllowSelect">
Get Current Selection
</button>
</body>
</html>

 

I also had to code a JavaScript function which will react on the button click:
function getCurrentSelection(){
alert(document.getSelection().toString());
}

Let's refresh the page and see what happens. When the page is loaded, the selection is performed. With the click on the button a new alert window is displayed that contains the currently selected text:


JSFiddle: https://jsfiddle.net/flovogt/wtho63sj/

 

Preliminary Conclusion


With the css attribute user-select and the Selection interface, it is possible to handle and simulate user selection.

So far so good, every modern browser provides this behaviour. Nice! However, as I wrote before, the Selection interface is still in an experimental state. That's the reason why using it in a productive environment is not recommended. Next, I'd like to show you an advanced scenario where the behaviour and result is completely browser-specific.

Advanced Scenario - Different neighbours, different selection


Let's add a new area to the sample above and mark it as non-selectable.
<html>
<body>
<span id="rootText">This is selectable text No.1</span>
<div class="notAllowSelect">This is non-selectable text No.1</div>
<div class="allowSelect">This is selectable text No.2</div>
<div class="notAllowSelect">This is non-selectable text No.2</div>
<button onclick="getCurrentSelection()" class="notAllowSelect">
Get Current Selection
</button>
</body>
</html>

JSFiddle: https://jsfiddle.net/flovogt/xqp7jd9g/

 

The following table shows the behaviour and the result in the different browsers:

 

































Browser Result of user selection - highlighting Result of user selection - copy & paste manually Result of the toString() method
Chrome
This is selectable text No.1
This is selectable text No.2


This is selectable text No.1
This is non-selectable text No.1
This is selectable text No.2

Firefox
 This is selectable text No.1
This is selectable text No.2


This is selectable text No.1
This is selectable text No.2

Safari
This is selectable text No.1
This is non-selectable text No.1
This is selectable text No.2


This is selectable text No.1
This is non-selectable text No.1
This is selectable text No.2

Edge (EdgeHTML)
This is selectable text No.1
This is non-selectable text No.1
This is selectable text No.2
This is non-selectable text No.2
Get Current Selection


This is selectable text No.1

This is non-selectable text No.1

This is selectable text No.2

This is non-selectable text No.2

Get Current Selection


Temporary / Final Conclusion


As of now, the selection interface can be useful in basic scenarios. In the future, advanced scenarios should also become possible, as soon as the different browsers improve their Selection interface, and the specification is clearer.

 

Author








Profil picture of Florian Vogtflorian.vogt#about is a UI5 Core developer, javascript advocate and cultivates a vineyard in the black forest. He is currently working on the UI5 Core to raise it to the next level.

 
Labels in this area