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