The New Editor and Browser Support

If you have not already, I encourage you to read through the Editor Technical Overview and check out the great work so far in the initial Gutenberg prototype. Progress on the new editor can also be followed on the GitHub project.

While the technical overview focuses on what obstacles are faced before forming opinions on the correct way to solve them, it does not focus on the actual technology requirements of the deliverables. As contributors start to create a new and improved editor experience, these technical requirements should be clearly defined and agreed upon so that decisions and progress can be made.

Accessibility, for example, is one technical requirement. All new features must pass WCAG 2.0 AA.

Browser support is another technical requirement. A few lengthy discussions have occurred within #core on Slack and within an issue on Gutenberg’s GitHub. The discussions weigh the pros and cons of dropping support for older browsers in order to use features only supported in newer browsers to improve the editor. It is a tough decision to make because the editing experience will become less useful for a small percentage of users.

This post will attempt to summarize the discussions that have taken place so far and provide some data in an effort to elicit more discussion so a stance on this requirement can be determined.

Who Uses Older Browsers and Why?

Many users are still unable to choose which browser they use. Many companies and institutions have specific browser and version restrictions based on their own unique software, technical, and security requirements.

Here are some factors that contribute to older browser versions still existing:

  • IE8 is the highest version a Windows XP user can install.
  • IE9 is the highest version a Windows Vista user can install.
  • Windows 7 users are forced to update to IE11.

To determine how many people are still using these browsers, 3 data sources were considered. The following numbers are from StatCounter’s GlobalStats:

  • IE8: 0.41%
  • IE9: 0.26%
  • IE10: 0.26%
  • IE11: 3.79%

WordPress.com numbers are nearly identical to these. W3Counter also shows similar numbers with IE8, IE9, & IE10 slightly higher (but with less precision as no numbers are available).

While these percentages are negligible in some contexts, it is important to remember how many people use WordPress. When these statistics are considered in the context of WordPress, they represent tens (if not hundreds) of thousands of people that could potentially be left behind if support for any of these browser versions is dropped.

Current Established Core Browser Support Policies

According to the design handbook, the current stance in Core for browsers is as follows:

  • Full support back to IE11, partial back to IE8.
  • Firefox, Chrome, Safari: Current – 1.
  • iOS Safari: Current – 1.
  • Android browser: Current major.
  • Chrome/Android: Current.
  • Everything else: Bugs fixed as reported.

Older browsers must continue to be functional, even if the experience does not match that of newer browsers.

Calypso only supports IE11 & Edge, dropping support for older versions.

Microsoft has even dropped support for IE8, 9, and 10 very early in 2016. This means that no bug patches or security updates will be released for any of those versions. Because of this, users should be encouraged to upgrade their browsers whenever possible.

Dropping support

In order to drop support for a browser, there needs to be a specific substantial benefit. Not dropping support for anyone, if possible, is desired.

The argument has been made that since this is an overhaul of a core feature essential to WordPress, it could be the perfect time to raise the minimum browser requirements.

Proposed Fallbacks

If a decision is reached to remove support for any of the browser versions mentioned, a proper fallback must be provided so users being forced to use an outdated browser can continue to enjoy using WordPress.

All potential options will be evaluated with the WordPress project’s core philosophies in mind. Please review them and consider them while brainstorming and discussing.

The following are some potential fallbacks that have been suggested in discussions.

Include two versions of TinyMCE in Core

This approach would be seamless for the user. It would, however, magnify the burden on Core’s editor component by requiring two versions of the library to be maintained. It would also ship code that a large percentage of the user base may not use. Every extra file shipped in core also has potential to reduce auto update reliability.

Move the current implementation of TinyMCE into a plugin.

This approach would allow site administrators to enable the current editor experience if their user base contains a large number of people using older browser versions. From a user perspective, this would be a very poor and frustrating experience, especially if the user is not allowed to install plugins, or does not have enough technical knowledge.

Use a simple textarea.

This is the current approach in the editor for users with JavaScript disabled. However, this may alienate some non-technical users who, for example, may not know that <em> is used for italics. A basic HTML knowledge would be required to effectively use this fallback.

Further Discussion

Do you have additional suggestions for an approach or fallback? Feelings on where the line should be drawn in the sand? Thoughts on why we should continue to maintain support for older browsers? Please mention them below.

#browser-support, #editor