Spin-off from #1787012: [policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support). In the event Dries decides against abandoning IE8 entirely, what about simply making IE8 degrade to the same experience as users who disable JavaScript? That would allow us to optimize our JS as discussed in that issue without worrying about triggering error conditions in IE8.

Members fund testing for the Drupal project. Drupal Association Learn more


nod_’s picture

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.


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.

effulgentsia’s picture

860 bytes

I don't know if conditional comments is the technique we want to use, but if it is, here's one way to do that.

nod_’s picture

862 bytes

my mistake, it should be lte, reroll.

Mark Trapp’s picture

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.

JohnAlbin’s picture

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.

RobLoach’s picture

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).

tsvenson’s picture

Issue tags: +legacy

Just adding a tracker tag...

effulgentsia’s picture

Intentionally break websites for IE8 users? That seems much more harmful than just #1787012: [meta] Fully drop IE8 support from D8 core.

No, if we do #1787012: [policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support) without this issue, what that will mean is that nod_ and the other JS people will (correctly) start optimizing some JavaScript to not use jQuery, but rather standards-based direct DOM access which we know will trigger errors on IE8. And an official policy of not supporting IE8 means there will be no reason to reject those patches. This issue, on the other hand, is about deciding to not run JS at all on IE8 (with some exceptions, like html5shiv), so that IE8 users see a functioning website sans JS (e.g., all "vertical tabs" fieldsets visible rather than converted to vertical tabs) rather than a website with broken JS (e.g., vertical tabs that aren't clickable so no way to access anything but the first one).

effulgentsia’s picture

365 bytes

Just brainstorming here... Is there a compelling benefit to this being a global decision rather than a per-library one? For example, for any core library that wants to benefit from JS features not available in IE8, can that library simply add some feature detection, like in this patch?

nod_’s picture

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.

effulgentsia’s picture

Unless I'm missing something, adding if (document.addEventListener) on a library by library basis to vertical-tabs.js and anything else that can benefit from removing a jQuery dependency seems like a great idea to me. What do others think?

effulgentsia’s picture

Is addEventListener() really the only missing thing in IE8 that we need to optimize our JS? If so, would that mean contrib could add it and make everything magically work again on IE8? A 1 minute Google search turned up https://gist.github.com/2415137. I don't know if that's any good or not, but just pointing to it as a way of probing the problem space.

nod_’s picture

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.

effulgentsia’s picture

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)

Yep. I'm not suggesting we add an addEventListener() polyfill to core, but wondering about the possibility of it being an option in contrib. What I want to avoid is where we only feature detect document.addEventListener, and if we detect that, then we assume a modern browser and freely call other functions that break in IE8, cause that then would cause breakage on a site that added an addEventListener polyfill to IE8. So, if we're relying on multiple features missing from IE8, I'd want our if statement including all of them.

Wim Leers’s picture

catch’s picture

Priority: Normal » Major

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

Kiphaas7’s picture

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.

nod_’s picture

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.

droplet’s picture


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

Any non-drupal developer will make fun with Drupal again:

jbrown’s picture

Totally agree with #19.

quicksketch’s picture

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

catch’s picture

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.

LewisNyman’s picture

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

Danny Englander’s picture

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.

jcisio’s picture

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?

cweagans’s picture

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.

webchick’s picture

"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.

cweagans’s picture

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.

RobLoach’s picture

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.

catch’s picture

@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.

David_Rothstein’s picture

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.

effulgentsia’s picture

I think the issue title and summary are no longer reflective of what is actually needed to optimize for mobile. @nod_: What's your latest thinking on this? Is event handling (#18) still the main issue? What are the other ones that you know of? Per #31, which libraries (e.g., states, ajax, etc.) would be affected? And per #27, what specifically would a contrib module need to implement for those libraries to be functional again on IE8 (for example, would states, ajax, etc. each need to be re-implemented, or would only an event API need to be implemented)?

effulgentsia’s picture

nod_’s picture

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.

effulgentsia’s picture

Status: Active » Postponed

The issue title on #1787012: [policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support) has been changed, such that this issue is now a duplicate of that one. Or perhaps, that issue is about answering the policy question, and then this issue can be used for implementation. Based on the latter possibility, postponing this issue on that one.

nod_’s picture

Status: Postponed » Fixed

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.

Automatically closed -- issue fixed for 2 weeks with no activity.