Tag Archives: browser support

Adam Silverstein 4:22 pm on September 20, 2023
Tags: browser support, ,   

Seeking proposals for Interop 2024

TL;DR

Once again it’s time to submit your proposals, as Interop 2024 is happening! WordPress developers, please contribute your proposals for 2024 as on GitHub or as a comment on this post.

What is Interop?

Developing for the web’s diverse browsers has historically been complicated by gaps in browser capabilities that developers had to work around. Interop is a multi-year, multi-browser effort to address that. 

Interop aims to improve interoperability across the three major web browser engines (Chromium, WebKit and Gecko) in important areas as identified by web developers. Interop provides a benchmark – agreed on by representatives of three major browsers and developed through a process of public nomination – and a scoring mechanism.  The overall goal is to make developers’ lives better by enabling a widely compatible “Baseline” of web platform features.

The scale of WordPress and the wide variety of use cases we support puts WordPress developers in a unique position to contribute to and benefit from this effort. In the past, WordPress has helped identify and adopt important features like `srcset` and native lazy loading, and Interop gives us an opportunity to contribute feedback directly to browser developers. 

The Interop 2023 work has already made great progress including on suggestions WordPress developers made on last year’s post like color-mix, inert, import-maps and some contentEditable areas. Now, the effort has begun to identify issues for Interop 2024. 

What browser interoperability issues continue to present problems for WordPress developers? You can make suggestions to the Interop 2024 project directly by opening a GitHub issue or leave a detailed comment below.

Suggestions can include features that have inconsistent behaviors across browsers or features that aren’t available in all browsers. When formulating proposals, keep in mind that the goal of the project is to improve interoperability between browsers rather than identify new features.

What potential features in WordPress are blocked by cross-browser compatibility issues? Help make browsers better by submitting issues!

#browser-support, #developer-experience, #standards

Adam Silverstein 5:48 pm on October 10, 2022
Tags: browser support, ,   

Seeking proposals for Interop 2023

TL;DR

Proposals for Interop 2023 focus areas are open and can be submitted as a GitHub issue until October 15, 2022.

What is Interop?

Interop is an effort to improve interoperability across the three major web browser engines (Chromium, WebKit and Gecko) in important areas as identified by web developers. This work provides a benchmark – agreed on by representatives of three major browsers and developed through a process of public nomination – and identifies focus areas to be scored according to their pass rate on selected relevant tests.  

The scale of WordPress and the wide variety of use cases we support puts WordPress developers in a unique position to contribute to and benefit from this effort. In the past, WordPress has helped identify and adopt important features like `srcset` and native lazy loading, and Interop gives us an opportunity to contribute feedback directly to browser developers. 

The Interop 2022 work has already made great progress and the effort has begun to identify issues for Interop 2023. What browser interoperability issues continue to present problems for WordPress developers? You can make suggestions to the Interop 2023 project directly by opening a GitHub issue.

Suggestions can include features that have inconsistent behaviors across browsers or features that aren’t available in all browsers. When formulating proposals, keep in mind that the goal of the project is about improving interoperability between browsers rather than identifying new features.

What potential features in WordPress are blocked by cross-browser compatibility issues? We can help make browsers better by submitting these issues!

#browser-support, #developer-experience, #standards

Héctor Prieto 7:14 pm on March 25, 2021
Tags: , browser support,   

Discussion summary: Dropping support for IE11

As a follow-up to the very active discussion around the proposal to drop support for IE11, there is a majority agreement to move forward with dropping support. The next steps are to figure out a timeline and what it means for projects/teams to drop the support.

Regarding timeline, there are two upcoming milestones where support could be dropped: 5.8 and 5.9. The argument for dropping in 5.8 is to realize the change and improvement quicker, while others are inclined to wait until 5.9 to provide a longer window between the official announcement and the effective date.

The decision when will be left to the release team for WordPress 5.8; this team is not formed yet as it depends on the April go/no-go Full Site Editing merge.

This post was written in collaboration with @mkaz, @annezazu, and @youknowriad.

#accessibility, #browser-support, #performance

Héctor Prieto 10:50 am on March 4, 2021
Tags: , browser support,   

Discussion: Dropping support for IE11

After digging into data and reviewing previous decisions around browser support, this is a proposal to define a policy to stop supporting Internet Explorer 11 (IE11) now that usage has cumulatively fallen below ~1% across three metrics. 

Current state of IE11

As of February 25th 2021, IE11 usage has cumulatively fallen below ~1% according to three sources of metrics:

  • 0.71% from StatCounter’s GlobalStats.
  • 1.2% from W3 Counter.
  • 0.46% from WordPress.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/.

For comparison, the numbers above are very close to the data used to make a decision in 2017 to drop support for IE versions 8, 9, and 10. It’s important to keep in mind that when viewing these statistics in the context of WordPress, these percentages represent tens (if not hundreds) of thousands of users that could potentially be left behind if support for IE11 is dropped. 

In August 2020 Microsoft themselves announced that Microsoft 365 and Teams apps would stop supporting IE in the upcoming months. However, given that IE11 is a component bundled with Windows10, according to the IE Lifecycle it will still receive security updates as long as the Windows version it was shipped with continues to receive support. 

In terms of the current WordPress user experience, a flag was added to not recommend IE in BrowseHappy about 13 months ago, so by now, most WordPress users should be aware. Tied to this, the experience overall is not optimal in IE11 with a high cost of maintenance for developers.

Proposed Policy

The proposed policy for WordPress is to end Internet Explorer 11 support. This was discussed most recently in the February 24th Core Editor Chat and briefly during February 23rd JavaScript office hours in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. More context and discussion have been shared over time in this original Trac issue that seeks to determine clear guidelines around what absolutely can’t be broken in order to help identify development and testing needs. 

Benefits

Dropping support would result in smaller scripts, lower maintenance burden, and decrease build times. For instance, a recent exploration by @youknowriad demonstrated that not transpiling the scripts to IE11 immediately resulted in a net reduction of nearly 84kB in the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 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/. built files, representing a 7,78% total decrease in size; these scripts have seen a size contraction up to 60%, with an average reduction of 24%. This is a result of heavily relying on transpilers, further explained by Jason Miller, Web DevRel at Google. Moreover, dropping support would ultimately make WordPress’ currently included polyfill script obsolete, decreasing the enqueued scripts size up to 102kB more.

The smaller downloads would positively impact all users, especially those on slower networks, or computing devices. We expect a result of dropping IE11 support to improve performance for the vast majority of users. 

Potential Concerns/Blockers

TLDR: The concerns are for those who are unable to upgrade, like financial institutions and education sectors, and those who rely on IE11 for screen readers. 

There are major institutions like banking, government, and education that are unable to control when they can upgrade sometimes due to legal requirements, depending on the country. This further underscores the need to determine a policy that takes into consideration both a data-informed approach and the impacted user bases while weighing the potential benefits for the wider web. 

According to a September 2019 WebAIM survey, IE11 is still used as a browser among screen readers with 11.5% share. This is an older survey and IE11’s global share was 2.9% at the time the survey was done according to the sources linked above. It takes time for screen reader software to support newer browsers and the latest versions of popular screen reader NVDA have continued improving and adding support for the Edge browser. As a result, this post embraces an assumption that IE usage among screen reader users has declined since the survey as the software improves and overall usage of IE11 has declined. Please let us know if this assumption is or if there is better data available to refer to.

Keep in mind that there are ways to patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. gaps in functionality that’s determined critical to maintain for a time. This post does not seek to go into technical implementation details though.

Share your feedback about this proposed policy change to drop support by March 18th

This is a tough decision to make and we want to solicit feedback from as many voices across the community it may impact. Please note, this post is not meant to go over any technical fallbacks at this time but to purely discuss the policy of dropping support. 

Once we’ve gathered feedback, the next step will be to consolidate and decide the policy. The actual technical implementation of the policy is most practical to pursue across the numerous WordPress projects. 

Thank you to @mkaz, @annezazu, @youknowriad, @desrosj for help writing and reviewing this post. 

#accessibility, #browser-support, #performance
Jonathan Desrosiers 1:38 pm on March 13, 2017
Tags: browser support,   

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

Jonathan Desrosiers 10:03 pm on February 28, 2017
Tags: browser support,   

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.

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), 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.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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.
  • iOSiOS The operating system used on iPhones and iPads. 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. 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 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.

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 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. However, this may alienate some non-technical users who, for example, may not know that <em> is used for italics. A basic HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. 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