Skip to Content
Technical Articles

Web API – The Selection interface

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:

Step 1 - 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:

Step 2 - 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.

Step 3 - Only the screen areas which are not set to user-select: none are selected

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:

Step 4 - The alert window contain only 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 Advanced Scenario - The user selection highlighting in 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 Advanced Scenario - The user selection highlighting in 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 Advanced Scenario - The user selection highlighting in 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) Advanced Scenario - The user selection highlighting in 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 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.

 

Be the first to leave a comment
You must be Logged on to comment or reply to a post.