Continued Discussion on Browser Support

There will be an additional dev chat this week to further discuss the fallback strategy to be used if support is dropped for older browsers. This chat will take place on March 15, 2017 at 12:00 EDT.

While only a small percentage of WordPress users still utilize older, obsolete browsers, it amounts to hundred of thousands, if not millions of people when applied to the WordPress userbase. With the new editor being worked on, there will come a time where a decision must be made whether or not to drop support for these older browsers to allow more modern functionality to be developed. More details can be found in my previous post outlining the discussion so far.

If a decision to drop support for these browsers is reached, there must be a fallback approach determined so that these users do not lose the ability to edit their WordPress site. After continuing the discussion from my previous post outlining proposed fallbacks in the most recent dev chat, here is a modified list of discussed fallbacks with some new, and some improved ideas.

Gradual Approach

@jbpaul17 suggested using a blend of the previously proposed fallbacks. Start by including two versions of TinyMCE in core, and record data to measure exactly how much the old editor is utilized over the course of X number of months, or X number of release cycles. Then, use a simple textarea similar to the one in core now for users with JavaScript disabled. Moving from one step to the next would only happen when an agreed upon benchmark is reached.

This approach hinges on actually having the ability to collect this data (see #38418). As learned with the REST API though, setting benchmarks for future decisions can be very difficult.

Plugin Approach with Auto Install/Install Suggestion

As suggested by @samuelsidler, if the plugin approach is taken and the old version of TinyMCE is not included in WordPress core when the new editor lands, there could be an auto-install approach. After much discussion, it was agreed that auto-installing a plugin would not work because there are too many points of failure. However, a large message encouraging a user to upgrade their browser or install the plugin could be a feasible option.

Plugin Route First, Adding Back If Necessary

@jnylen0 suggested that the plugin route could be taken first, adding the old version of TinyMCE back into core only if a benchmark is reached to indicate sufficient demand. This too would need some way to measure demand for the old editor.

Simple Text Editor with Some Enhancements

@afercia noted that a simple textarea or the current “text mode” will very likely still be required for accessibility reasons. I suggested using this option while making a list of features that would need to be added to that field in order to make this an acceptable fallback for older browsers.

If you have thoughts on any of these, please share them below. Otherwise, hope to see you in Slack!

#browser-support, #editor

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% 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