Gutenberg: Confirm browser support

[androb]

Very soon the TinyMCE team are going to have to decide whether to implement our new "Alloy UI" in time for Gutenberg or to stick with the current TinyMCE UI.

Alloy is dependent on flexbox and IE11+

According to the DevChat summary this is still a topic of debate:
https://make.wordpress.org/core/2017/02/17/dev-chat-summary-february-15th-4-7-3-week-3/

The TinyMCE team would like to put a big vote for moving browser support to IE 11+. Flexbox would be a very useful addition.

[aduth]

@androb Is the Alloy UI in any way related to what you'd previously referred to as TinyMCE's upcoming "headless" options? Given the current mockups, it seems like the amount of UI we'd expect to be shown to the user to be quite minimal. In my mind, they seem to be best served by an extension of TinyMCE's Inlite theme or a new theme with a similar feature set.

So far as browser support goes, as had been mentioned in the referenced Slack conversation, ideally we can at least provide graceful fallbacks for older browsers. Specifically for flexbox, we could consider a polyfill like flexibility to add backwards compatibility to older versions of Internet Explorer. If we want to use new JavaScript features, we'd likely want to look at a combination of either/both es5-shim and Babel.

[androb]

@aduth it is a related project yes.

Browser-requirements might drive our decision here to stick with current TinyMCE UI or make a dash to the finish line for Alloy.

The Alloy UI is a next version Textbox.io's UX (see https://textbox.io) that we are porting to TinyMCE. It's inline theme is worth checking out as an example:
https://jsfiddle.net/textboxio/1mq3wxqh/

There are some benefits to Alloy such as edge magnets, resize behavior and mobile behaviors.

I am not clear whether we have looked at a polyfill to help with backwards compatibility. Will see if I can get some more of our team to chime in here :)

[androb]

This was Ella’s statement: https://wordpress.slack.com/archives/core-editor/p1481103876000037

We try to support as many as possible, even IE7/8, if it’s not too much work to do it. We have not officially dropped IE7/8 support yet either. :) A lot of newer features only work in IE9+ though, so I can see us adding new features for IE11 in the future, and falling back to the current state (or something equally usable) for other users.

Could the new editing experience target IE11+ and fall back to TinyMCE 4 on older browsers?

[androb]

And this is a relevant link, although not clear how official this is:
https://make.wordpress.org/design/handbook/browser-support/

[ellatrix]

@androb When you talk about dropping support for IE < 11, do you mean in terms of UI or TinyMCE entirely? I don't think we're prepared to drop support in core. When I'm saying it's okay to drop support, I mean that for _new features_.

It is still in the best interest of WordPress core to keep the existing TinyMCE UI, or to keep everything as backward compatible as possible. We know that this is sometimes not _entirely_ possible, and we are prepared for this, as we were once prepared to move to TinyMCE 4.x.

For this editor project we are mostly looking to create our own UI, ideally on top of a lightweight, headless version of TinyMCE that fixes contenteditable across browsers and gives us a good API to work with it. This is what's most important for us, and we're looking forward to see such a headless version, and improved contenteditable tools and normalisation.

If we decide to merge this project with WordPress core, it will also need to be as backward compatible as possible and support the browsers that we currently support for basic existing features. Additional features could reasonably have limited browser support if really necessary.

[jasmussen]

A little more discussion in slack: https://wordpress.slack.com/archives/core-editor/p1487581929004693

[androb]

@iseulde I think we would like to look at it for the whole of TinyMCE, ideally. We are looking to major upgrades to everything this year :)

From Spocke on our internal engineering Slack. Hopefully he can add more comments (I can't at-mention him until he joins!):

Flexbox is just a one part of the problem. IE 8 doesn't even have the same selection model so we are currently feature filling that in tiny. The event model is different, style api is different, attributes api is different, innerHTML is different I can go on and on. Supporting IE 8 has been a major pain for us for years. It has basically none of the apis you expect even the DOM trees are broken they can have circular references or nodes that you can't touch with out getting exceptions. Partially why we had to write our own html parser/serializer. The browser dom couldn't be trusted. We pretty much need to drop it now in the 4.6.0 since the test frameworks bedrock/agar won't work on IE 8. This has been part of the effort to convert the tests.

[ellatrix]

Yeah, I'm aware of the crazy issues with IE < 9. I would really love to drop it, but I can't speak for the whole WordPress core team. Dropping 9 and 10 as well isn't that much of a stretch as IE 8 and XP were a bottle neck of sorts, but not sure how others feel about this. In general, if it's not too bad to support, we'd encourage supporting it still.

Let's try to chat Wednesday about this during the weekly core chat. It would be great if some people could join! :)

[spocke]

Our current thinking meaning we haven't made a decision yet is to officially drop support for IE 8-10 in the upcoming 4.6.0 release and have 4.5.x in some form of LTS that probably means that we would have to back port any fixes that Wordpress needs to the 4.5.x branch. So as long as WP supports IE 8 we would have to maintain the 4.5.x branch. That would also mean that two editor versions would have to be shipped with WP in the future one for the new block based editor and the other one for current editing ui for legacy support.

Why we want to drop support so soon is that we are currently trying to modernize tinymce and doing that in incrementally so 4.6.0 would probably work on IE 8 for a while but we are unsure how long since the libraries and things we are moving to will only be tested on modern browsers. So officially we would want to say we dropped support since it's no longer tested.

[aduth]

I'm not entirely familiar with what support is lacking, but is there an option to shim/polyfill APIs for older IE, such that TinyMCE code can target modern APIs while still providing a functional fallback? Or are the APIs/behavior different enough that it can't possible be polyfilled?

e.g.

• https://github.com/luwes/selection-polyfill
• https://afarkas.github.io/webshim/demos/
• https://github.com/2is10/selectionchange-polyfill

[Afraithe]

I can add this to the discussion as well for those who want to understand more about the type of effort is required to keep old IE working properly.

https://www.ephox.com/blog/a-quick-guide-to-browser-selection-models/

Would love to hear some user/dev stories of why it is needed to keep IE support at the current level. What kind of company situation would allow for their employees to run unsupported and insecure browsers?

It goes way deeper than just the UI and Flexbox by the way, even our testing tools will soon no longer support IE8, we can do more comprehensive automated testing with more modern tools.

[aduth]

Would love to hear some user/dev stories of why it is needed to keep IE support at the current level. What kind of company situation would allow for their employees to run unsupported and insecure browsers?

For what it's worth, I doubt anyone would argue in favor of being justified in continuing to use older versions of Internet Explorer. Rather, arguments in favor of keeping support are based mainly on observations of non-negligible usage analytics.

I'm also not personally arguing one way or the other. Ideally we could find some compromise where at least it's not a totally unusable editing experience in unsupportable browsers (even if that means degraded to the point of using a barebones texarea).

Thanks too for the blog post link. I think the points made therein could serve as strong evidence in potentially dropping support.

[androb]

I was able to pull up some stats from cdn.tinymce.com regarding browser usage.

Of the 25.6M unique visitors we had in the past two weeks 93,957 were from IE8-10… or 0.366% in total.

https://cloudup.com/caZ8koOnSNp

[jasmussen]

This seems to confirm it. WordPress 4.8 to end support for 8, 9, 10. https://make.wordpress.org/core/2017/04/23/target-browser-coverage/

Closing as resolved.