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 sitesite (versus network, blog). 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., 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 releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. cycles. Then, use a simple textarea similar to the one in core now for users with JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. 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 APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. though, setting benchmarks for future decisions can be very difficult.

PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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 accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/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 makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). 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