Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8)

I'm all for that.

Question is how to not run js on IE8. There is some weird conditional comments we can use but do we want to use that? it looks like that:

<!--[if !lte IE 8]><!-->

    All the JS scripts in here.

<!--<![endif]-->

Looked it up, it's called Downlevel-revealed Conditional Comments.

There are ways to make it happen, we need to see which one would be the best.

(edit) changed if to lte.

my mistake, it should be lte, reroll.

In #1077878: Add HTML5shiv to core, the consensus was that requiring JavaScript for IE8 and lower was reasonable in order to get the HTML5shiv (and subsequently HTML5) into core.

This would be at least a slight backtrack from that: does this need to be reframed as "Make IE8 behave as no-js, but make an exception only for the HTML5shiv"? Otherwise, it seems IE8 support is moot without styling support for HTML5 elements.

Mark is correct. Since Drupal 8 uses HTML5 and we want IE8 to be styled/usable, we have to continue to use the HTML5shiv. But I'm fine with that being an exception to our IE8 js rule.

As for "downlevel-revealed Conditional Comments”… *sigh* I can't think of a better way to do this. But I would prefer if we did think of a better way to do this.

Over in #1787012-12: [policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support), webchick pointed out we'd need contrib to be able to turn IE8 support back on. So I'd like to point out a thorny issue we currently have with JS in D7: telling the difference between a JS added with explicit intentions and JS added that gets the default settings.

For example, we'd like to be able to tell the difference between a JS that explicitly needs to be added to the HEAD of the document and a JS that doesn't care and just used the default setting (which is also to place it in the HEAD). It would be awesome to move all the JS that "doesn't care" where it goes in the footer and leave all the JS that "wants to be in HEAD" in the HEAD of the document, but its currently impossible to tell the difference between the two. See #784626: Default all JS to the footer, allow asset libraries to force their JS to the header

Now…Within the context of this issue, we could make a default setting that says all JS goes in a downlevel-revealed conditional comment for IE8. But for contrib, the problem will again be determining which JS explicitly doesn't want to be sent to IE8.

Intentionally break websites for IE8 users? That seems much more harmful than just #1787012: [policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support).

Just adding a tracker tag...

ow that's pretty much this issue #1252178: Add Modernizr to core with the version issue you opened earlier.

As far as core is concerned, pretty much all feature detection will end at if (document.addEventListener) for core scripts.

We can have a decent amount of polyfills in IE to do stuff and make it somehow work. The immediate issue about events handlers is memory leaks. IE8 is just not good at that stuff and leaks from everywhere. Manual cleanup needs to be done on page unload and that sort of stuff. We don't want to go there (I don't at least :p). You also have the focus/blur event thing to take care of if you want to delegate that.

Events are the main reason we use jQuery, the rest is all right. We might still want to go with something like https://github.com/fat/bean and provide an "adapter" from bean methods to jQuery in contrib or something. They take care of cleaning up objects in IE. And well, it's 4kb.

The other thing we might want to do is some tools to make the DOM less painful to use (straight DOM is fine with me but other might complain). But still a couple of kb at most. There can be a lot to it. Hopefully I'll have data/patches to look at some code soon.

Also: https://twitter.com/ppk/status/249100988693241856

Bumping to major. This is blocking js refactoring/optimization so it'd be good to get it done.

Besides events, it would be great to have a blueprint in core something along the lines of the jquery ui widget factory (but with less bloat and only single entry and exit points).

Like enforcing a standard method of init and destroy. Currently it is up to the patch author what its called (create, init, start).

One of the big plusses of jQuery UI widget factory is that it prevents memory leaks in IE (definitely in IE8, maybe they still exist in IE9): if you have a reference to a DOM node in a prototyped instance, and when the DOM node is deleted, it will remain in memory. I think they are using an internal jQuery function for that.

Time flies. What's the status on this? I'm still for not catering to IE8.

We can add a intermediate API for biding events that will fallback to jQuery or whatever contrib wants to use. And I say we use this API https://github.com/fat/bean which is actually the same as jQuery's for events.

Repeat the process for other features IE8 doesn't support. that way it's possible for contrib to switch the implementation without having to rewrite everything.

IMO,

No JS support + Single Column layout === Entirely drop IE8.

Any non-drupal developer will make fun with Drupal again:
http://ma.tt/2013/03/the-redhat-of-drupal/

Totally agree with #19.

I agree with #18. Not supporting JS in IE8 is the same as not supporting it at all.

Here's the two options, assuming one route involves a degree of wtf:

1. Getting laughed at for dropping IE8 in (late) 2013, with most usage of the new release not going to pick up into 2014, and with Drupal 7 supporting IE8 until 2015/6

2. Getting laughed out for still supporting IE8 in 2018 (i.e. when Drupal 10 comes out) while making all mobile browsers slow for the five years beforehand on hundreds of thousands of sites.

I'd go for #1.

Just to clarify, jQuery 2.0 is not a mobile performance magic bullet. Far from it.

I think the best option is to not support IE8 at all. As a themer, it would be nice not to have to worry about IE 8 someday in consideration of projects and costs. Playing devils advocate for a moment, the most compelling argument to keep some support would be those companies that are still tied into Windows XP and therefore cannot go beyond IE8 and that could be an issue. But Windows XP is now 12 years old so ancient in computer years.

Of note would be Google's stopping support for IE8 in November of 2012, the month Windows 8 arrived.

The best option for a themer or for a client? ;-) I think we want to support IE8, but we are sort of resource and we want to focus on other things.

That said, Drupal is not Google. Drupal is not in the position of having a market share like Gmail or Google Apps. The target clients of Drupal and Google Apps/Gmail/Basecamp etc. are not the same. Drupal websites are for the general clients, which IE8 takes account of about 10% market share (it has dropped 4% in the last 12 months, but seems flat now). About Gmail/Basecamp/Google Apps users, I don't think many of them use IE8 (or IE at all).

Why just not have a "best-effort", not full, support for IE8?

If we drop IE8, we can use jQuery 2. As lewis mentioned, that's not a magic bullet, but I think it's worth it.

Also, it's not unreasonable to support a "jquery_downgrade" or some such module in contrib to take care of Javascript issues on older browsers. The rest is mostly an issue of themeing. I'd guess that sites that use Bartik aren't going to care much if IE8 is supported, and if they do, they can happily use Bartik in D7.

"The rest is mostly an issue of themeing."

Can someone explain, very specifically, how someone in contrib could "re-add" JS support in core for IE8 if core doesn't support it natively? It seems to me that'd probably require re-implementing a huge portion of core's JS files, as well as CSS files, and overriding tons of theme templates to re-add missing selectors and the like, but maybe I'm mistaken.

It would mean reimplementing a large portion of javascript included with core. It would function very similar to how jquery_update works, which is just by removing the scripts that core adds and replacing them with scripts included with jquery_update.

For CSS, yeah...that's a bit more of a problem. In theory, the stylesheets could be swapped out by contrib, but I don't think somebody is going to be reimplementing IE8 support for bartik. That is, sites that are using the default themes probably are not going to be the ones that care about IE8 support.

In short, it's doable, but it'd be a PITA.

Of course, we can always take the approach of telling sites that want IE8 support to use D7. That would be much easier.

The Drupal browser requirements state support for Internet Explorer 8 and above. Are there any plans to change that target for Drupal 8?

Can someone explain, very specifically, how someone in contrib could "re-add" JS support in core for IE8 if core doesn't support it natively?

hook_js_alter, hook_css_alter() or hook_library_info_alter allow changing the way JavaScript and CSS is added to the page. One could make an IE8 module, or something along those lines, which adds support for Internet Explorer 8. drupal.org/project/ie_support , etc.

@RobLoach - if we make a decision here then we'll change that page.

Note we already agreed some time ago that'll we'll ship the latest release of jQuery with core wherever possible (including upgrading after release so we don't end up running an unsupported release for several years) and have a 'pinned' module in contrib for those who need to stay with previous version. That pinned module could potentially start with 1.9.

@jessebeach made a good point on the other issue - if you're an admin on a Drupal site you can change your browser in 99.9% of cases (the 0.1% can stay on Drupal 7 or argue with their IT departments). Site visitors barely get any js executed as it is so removing JS for those will barely be noticed.

I think the big question would be around JavaScript APIs (#states, Ajax, etc). Even though a fresh Drupal core installation doesn't really use those on pages seen by end users, many sites certainly do.

Few things before I start:

• difference with IE8 and IE9 features.
• At the time this whole thing started (March/April last year) the jQuery team didn't think dropping IE8 support was a good idea. Then in June they announced their plan for jQuery 1.9 and 2. The stable version of jQuery 2 got out last week, much was up in the air before that.

1. Event handling is still a concern. What's new is jQuery 2 and their custom builds that are starting to get pretty sweet. Us using jQuery 2 and finishing the whole JS clean-up will address that concern. By then we'll know what we use jQuery for, and where (hopefully core will work on an 'unofficial' — not shipped — stripped down jQuery build that removes some modules we're not using).

   It'll still be possible to use whatever else library to replace jQuery implementation, with #1342198: Use .on and .off instead of .bind, .unbind and .delegate all event-related things will be used and called consistently. It's the same idea as #18 but the other way around. This is not so important now that jQuery 2 is out there.

2. The real perf benefit we can get all around is not using sizzle anymore. If you have toolbar enabled and profile any page, the 1st thing to show up is Sizzle, then modernizr (used to be jQuery in the list but since their 1.8/1.9 release it's much better). Not taking into account the time it take to initialize all the different js files, once everything is loaded and compiled: it is Sizzle that takes up most of JS time on the page.

   Sizzle can be replaced most of the time in core by native querySelectorAll calls. Native is faster, look at jsperf.com, there are lots of test cases all over the place: http://jsperf.com/search?q=sizzle

   But qSA only works with selectors the browser understands, see the first link for an overview, all the CSS3 goodness is not available on IE8. If we try to write native selectors we'll run into IE8 and sizzle will end up being required, meaning that contrib will not even try to be careful use it and nobody will be able to get out of it even if they want to.

3. After that you have DOM manipulation, adding, removing elements and all, for that there is just not enough time and/or manpower to do much about it anymore, that has to be jQuery at this point.

So core would benefit from it, more importantly contrib will be free from it. On a real website it's not in core JS that slowdowns happens, it's that third party whatever script loading fancy fonts that kills perf.

I got into core JS because I wanted to fix contrib JS. This would have a much bigger impact than JSHint or the JS clean-up. And since time is just running out we can't do much about #2 right now.

Contrib will have trouble with JS, not because of core or because of us not supporting IE8 but because of API changes between jQuery 1.X and 1.9/2.0 once they get past that they'll probably just leave it there and if it works with 2.0, it'll work with 1.9 but it won't get in the way of people trying new things in contrib and who don't care about IE8. Remember the mobile traffic projections? no IE8 on mobile phones.

We ran out of time for core, IE8 support? just load jQuery 1.9 from somewhere (jquery_downgrade?). Done.

I created the IE8 module in contrib. I'll make sure it works, at least for core and major contrib modules.

If an IE8 module exists, I'd say it's fair that JS crashes on a D8 core install with IE8. And anyway we can't break things to much if we want to support an IE8 module in contrib, it'll all work out. I don't think we need to do anything about this issue. The discussion was a really good thing though.