TL;DR

No support means no support, javascript can break in IE6/7 and no special measures are in place in core to avoid breakage if JS is using unsupported functionalities in IE6/7.

Original Report

New IE8 features will break the JS on IE7/6. The features have a very big positive impact on performance, we would benefit a lot from them. I'm asking how committed we are with IE8 in D8.

First

Can the javascript crash under IE7/6, potentially preventing every other JS from running on the page?

Second

How painful we want to make IE6/7 support for contrib. In order of PITA: to support IE6/7 contrib would have to:

  1. Replace files: Replace all problematic core js files with compatible version.
  2. Preprocess files: Preprocess the js file and do a search/replace (It'll be possible to do, it's just changing the function name with $).
  3. Replace functions: Replace a few core JS functions to replace them with compatible alternatives.

I need both answers to continue with the Core clean-up of JS files.

Original report

Drupal 8 will support only IE8+, this is great news. The real world may have to support IE6/7 for a while longer though.

IE8 allows us to use very nice things like querySelectorAll, localStorage, console.log, JSON. A number of these new things can speed up js so much it needs to be plotted on a logarithmic scale (true story). I very much intend to use them as much as possible.

Using that means that the page completely fails in IE6/7. Since the front-end might depend on some core code and said front-end might need to be IE6/7 compatible, how are we going to handle that? It's not the same as requiring a minimum PHP version.

On the code side we can wrap all functionalities in a function call that can be overridden by contrib. Honestly I'd prefer if we let contrib deal with that (backport module?) and override the whole js file to make it compatible for dumb browsers.

It's critical because in China for example they are still using IE6 an it still has a big market share. Even a few market share % correspond to a lot of people over there, we can't just ignore that.

Since D8 is still a while away maybe this can be postponed for later, but not too much, I, at least, will get to refactoring core JS pretty soon I'll need to know how we handle this.

Comments

Support for IE6 and 7 has been dropped and this has already been extensively discussed:
#308865: Drop IE6 support in Drupal core
#1217788: Drop IE7 support in Drupal core

So of course you are allowed to completely break IE6 and 7 as we do not support them. Doing anything else would mean that we partly support them, which we do not do. Even doing some special wrapping of functions sounds like a compromise to me, but you could rightfully argue that we should give contrib some extensibility so that others can support any crap they want.

Read both issues, it's still not clear what we should be doing for javascript.

It all comes down to how painful we want to make IE6/7 support for contrib. To support IE6/7 contrib will have to:

1) Replace all problematic core js files with compatible version.
2) Preprocess the js file and do a search/replace (depending on a few things the actual preprocessing could be done in PHP or JS).
3) Replace a few core JS functions to replace them with comptible alternatives.

I just thought of the preprocess thing and it could actually be the best solution. Since we'll have pluggable preprocessing of JS and CSS at some point making a compatibility filter could work. Core JS files will be clean enough to regxp the heck out of them too.

Status:Active» Closed (won't fix)

Use Drupal 7 if you must support IE6/7. It's a fine Drupal.

Priority:Critical» Major
Status:Closed (won't fix)» Active

There's a difference between JS errors (breaking all JS on the page) and not supporting older browsers that don't support certain features.

Let's discuss this some more. Doesn't have to be critical though.

What I can tell you for sure is that things will crash and break everything on the page in unsupported browsers.

I won't do or support any fancy workaround to avoid failure and silently fail like nothing is wrong in old browsers. Some workarounds to help contrib could still be possible.

Issue summary:View changes

issue summary

Title:Strategy for dealing with IE6/7[Policy, no patch] Strategy for dealing with IE6/7
Assigned:Unassigned» Dries
Status:Active» Needs review

Dries decided to support IE8 and above. How committed are we to this?

I've updated the issue summary to reflect the current state of things.

I'm all for letting JS break in IE6/7. But I need answers to continue with the current JS clean-up.

Title:[Policy, no patch] Strategy for dealing with IE6/7[Policy, no patch] Strategy for dealing with javascript in IE6/7

Hopefully better title.

...I'm not sure. It seems that IE6 + IE7 combined still have a 15%-20% of IE users. OTOH, IE market share as a total has dropped so low that this percentage drops to only a 3%-4% among all browsers (with IE8/9 holding a 15%).

We generally have pages to work without js so a limited experience isn't terrible. I don't know how to quantify it but i'd strive for things like fieldset collapse to work as far back as it reasonable but not work to hard otherwise.

I guess what I'm trying to say is, I run a site with heavily corporate/non-technical user traffic. We're only getting ~15% IE7 traffic and a negligible IE6 traffic(we're dropping support) and its dropping off at a very steady pace. I seriously don't expect to support IE7 by the time D8 comes out so I generally agree with chx that its OK to care very little about 6 and 7. Break 6 all you want really. I would also be epic-ly frustrated though if my predictions are wrong and I have to replace all frontend JS just because we didn't want to us $() in a couple places though.

When the issues #308865: Drop IE6 support in Drupal core and #1217788: Drop IE7 support in Drupal core committed to no IE6/IE7 support in Drupal 8 they didn't seem to be restricting themselves to just CSS. The IE7 patch, for example, deleted IE7 specific code from .js files. That implied to me that that the 'no IE6/IE7' decision is general and Drupal 8 is not concerned with breakage in those browsers. Contrib authors should take that into account as well. Why continue to let IE6/IE7 hold Drupal javascript back? People can, and will, continue to run Drupal 7 long after Drupal 8 is out. I think the decision has been made so close this issue, forget IE6/IE7, and go forward.

ps. Is there a formal 'no IE6/IE7' announcement somewhere?

@dcrocks nod_ is asking the greyer question. Removing specific code so things don't work correctly is different from breaking javascript in the browser. He's asking how far that support question extends.

Also, there should be a change notice for those issues but I'm having trouble finding it.

I should note, @klonos was noting IE7 is 15% or IE traffic and I was saying 15% of my total traffic. I realise now that could be confusing.

What I can tell you for sure is that things will crash and break everything on the page in unsupported browsers.

That's a large part of why we don't support them anymore. Things tend to break when IE6 and 7 get involved.

We've already dropped IE6 and 7 support. If you want support for those browsers, use D7. Why does this need further discussion?

Part of the problem here is that we have no official change notification indicating that we dropped support for IE 6 and 7 and what exactly this means. There is no official announcement. I've reopened #1217788: Drop IE7 support in Drupal core to address this.

Sure, but that doesn't change the fact that pretty much everyone who's been active in core development in the past six months is aware of this (much celebrated) change. I mean, the original issue report acknowledged that Drupal 8 is IE8+.

I was made aware that my last comment could come off as a little aggressive, so let me clarify:

  • The discussion to drop IE6 and IE7 support was a very long, arduous one.
  • I'm concerned that reopening such a discussion is going to be wasteful to contributors' time
  • Right now, we have decided that IE6 and IE7 are unsupported, as in, we don't care about them anymore. At all. If you believe this to be an error, I would ask that you please open an issue describing why we need to care about them. It doesn't seem like that's what this issue is really about.
  • It seems that this issue is trying to get clarification about what, specifically, "unsupported" means. IMO, that means that we can pretend that they don't exist, but I'm sure that there are other opinions that differ
  • The fact that we don't have a change notification stating that we don't support IE6 and/or IE7 anymore is a HUGE problem that needs to be remedied. I think that by having that change notification in place, we'll be able to more effectively answer the question of "How do we deal with legacy browsers in a sane manner?"
  • Lastly, sorry about the unneeded aggression. That was not my intent. I only want to ensure that we're using contributors' time efficiently

This entire issue becomes moot if we manage to execute each Drupal behavior in a protected scope so that errors don't bubble up and break all JS on a page.

Given that error handling, JS authors can independently decide on their own whether a particular behavior is crucial for delivering the web application (and thus should use backwards-compatible jQuery methods) or whether a behavior only adds fanciness and can happily break on older browsers.

Unfortunately, errors in jQuery scopes/events do bubble up (whereas native events do not).

@nod_ mentioned the idea of wrapping the attach/detach calls in try/catch, which would sound like a sane approach to me. Let's investigate that in a separate issue.

Unassigning @Dries, because I don't think there's remotely enough debate and disagreement here, so an escalation would only lead to a premature decision.

Could we do something as simple as wrapping all of our script statements in conditional comments to exclude IE < 8? If we know it's going to break, the we just treat IE < 8 as a no-js browser. It will work, just sans-JS. We try to make all pages work, if not well, sans-JS already so you'd get the same experience as if you turned off JS by hand. Too bad, so sad.

Then we can safely write JS on the assumption that it won't run on IE < 8, and don't need to deal with those error conditions.

#21 sounds like an insanely simple, "duh why didn't I think of that" stopgap measure.

To clarify, are you saying that we wouldn't even load the Javascript files on IE8 and below?

I'm not following #21 doesn't that mean no JS for anyone except in IE8 and IE9? What we'd need is the opposite of what conditional comments do here.

Am I missing something?

I think it just means that there'd be no javascript for IE6 and IE7. IE8+ and other browsers would still get JS.

I understand this, my question is how? I don't understand how conditional comments would allow us to do that.

(edit) To me it's always been conditional "inclusion" comments, not conditional "exclusion" comments.

<!--[if !(IE 6)&!(IE 7)]> 
<!-- <script> tags here -->
<![endif]--> 

See http://www.impressivewebs.com/conditional-comments/ for good examples.

Ok I understand, I didn't know about this fancy use of conditional comments. The example you're giving is not the right one, but the proper syntax we should be using is in the linked article.

This is fine for core but what about contrib? this would be inserted via the 'browser' options of drupal_add_js so that contrib can alter it? If that's the case i'm fine with it. Better than having a JS error.

While conditional comments can be nested, I wonder about the complexity being required on the PHP side, when module/theme developers want to add/use actual conditional comments.

That is, because the actual/additional conditional comments of module/theme authors might target specific versions within the wrapping constraint of skipping older IEs.

In general, I like @Crell's idea for its simplicity, but OTOH, I'm not fully convinced yet... partly, because I think we need to cater for unsupported code in Drupal behaviors throwing errors anyway. But then again, both could be approached at the same time.

The approach suggested by Crell seems good to me, but time consuming regarding testing and categorizing CSS that breaks IE6/IE7. This also mean that we will generate more JS groups for aggregation and may make this less efficient. But, it is still a good compromise for avoiding ugly errors on non essential JS for those browsers.

The best approach of all anyway is to ensure the site works without JS, it's a pre-requisite for being accessible anyway, as long as we keep that, JS compat for old IE is not a problem (the users may experience IE telling them they have errors on the page, but they still be able to fully browse and use the site).

There is also weighting to do between administration pages JS and frontend pages JS: we could safely make some administrative features not being accessible without IE, it make sense, some other webapplications surely does that. While the site admin needs JS, the end users don't. But I'm not fond of this solution because some clients require the administration pages to be accessible as well.

Issue summary:View changes

order

Status:Needs review» Reviewed & tested by the community

After further talks on IRC with webchick and cweagans and the recent directions given by Dries in another post about IE8 #1465948-26: [meta] Drop some IE8 coddling from Drupal core it was made clear that no support means no support and that javascript can break in IE6/7.

While #21 would be the most gentleman way of handling it, it is not necessary for D8. I'm leaving RTBC to check if there are any objections, and will change to fixed in 2 weeks (it'll stay in the open for 4 weeks at least).

Change notif updated and issue summary updated.

"IE 7, what's that?" is also a perfectly viable answer. :-) I support this.

No objections. I'd like to add that there is a fundamental difference between site management functionality and content consumption.

Content consumption should be possible on any device out there. That's the core principle of content first design. We should strive to avoid dependence on JavaScript on content consumption pages.

Site management is a specialized set of tasks. It's ok to require a higher level of browser support for these tasks and to let the experience degrade less well. People who want to build sites will be willing to overcome more hurdles - even if in this case the hurdle is simply installing a modern browser.

So personally, I'd like to see us be elastic in serving content and precise in producing it.

About IE6 and IE7, today we still provide services for big companies that still have a lot of outdated devices, and which require their tools to work on it. I'm all about the new and fancy, but we should try to keep some level of no javascript compat for most features of core.

Well, no, that's the whole point of this issue.

Also see: #1465948-33: [meta] Drop some IE8 coddling from Drupal core

Oh right... I was saying compat with no js quite widely, because it's also a requirement for accessibility. EDIT: But for pure JS, I couldn't agree more too, so my comment was indeed irrevelant in here.

Status:Reviewed & tested by the community» Closed (won't fix)

So back to won't fix then. Official policy: we don't care about IE6 or IE7.

Issue summary:View changes

agreement reached