jQuery 2.0, Google Apps, Basecamp and other web applications have dropped support for IE8. This issue discusses whether or not Drupal 8 should too.

Cons

  • As a point of reference, IE8 is right now where IE6 was in about June 2010 and we made the decision around this time in D7's cycle to support IE6. It took another 2 years (until about June 2012) for IE6 to become a non-issue. 2 years from now is April 2015, and that's well within D8's life cycle. (@webchick in IRC && #42)
  • IE's current marketshare of 10% is not a trivial percentage. That's one in every ten people. (#62)
  • It's also a percentage likely to be much higher among content authors, who are also less likely to have control over their operating system/browser environment (#62).
  • Those left on IE8 are likely to be governments & conservative companies (#3)
  • Will we be losing users, contracts and site builds because of an IE8 requirement (#5)
  • Can PC users install other browsers (#8)
  • It’s going to be a lot harder for sites to add IE8 support than remove it (#44)
  • What about content authors? (#54, #55, #62)
  • Getting laughed at for dropping IE8 in (late) 2013 #1787146-22: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8)

Pros

Other comments

A work in progress update to Drupal's Browser Requirements documentation

Websites built using just Drupal 8 core (i.e. with no additional, contributed modules) are compatible with, and fully functional, in all browsers that support CSS3 selectors and modern JavaScript (ECMAScript 5).
Here is an incomplete list of browsers that are known to work well with Drupal 8 core and support all of its features:
- Internet Explorer 9 and later
- Firefox 5 and later
- Opera 12 and later
- Safari 5.1 and later
- Google Chrome
Even among the above browsers, the level of standards compliance varies, and so there may be minor variations in site appearance.
On browsers that do not support CSS3 selectors or ECMAScript 5, such as Internet Explorer 8, as well as on browsers where the user has disabled JavaScript, the appearance or functionality will be very different. For example:
- What is normally displayed in multiple columns might appear in a single column.
- Alignment, spacing, fonts, colors, and other visual cues might be missing or appear incorrectly.
- Productivity enhancing features such as drag and drop item reordering, WYSIWYG editing, contextual links, and hiding of form elements until they're needed, might not function.
However, all content can still be accessed and site operations can still be completed.

Comments

Issue tags:+JavaScript, +mobile

As far as javascript is concerned this would be great. Tagging.

Issue tags:+legacy

Just read @nod_'s comment to my post where he explains that by dropping support for IE8 the need for jQuery will be much less, as most of what it is used for is IEx stuff. This would also result in that pages will load much faster.

The more I have dug up the last couple of days about this, the more I start to wonder why IE8 wasn't dropped at the same time as IE7 go the axe?!

I also posted a follow up today where I have looked into the decline for IE8. It has lost a whopping 17% the last 18 months since it had it peak, going from just over 30% to 13%.

Now with Google's announcement, the Windows 8 release in a couple of months and Microsoft ending the extended support for XP April 8th 2014 that decline is going to continue. By the time Drupal 8 has been out and enough important contrib modules will be available, IE8 should be quite dead...

With all these very good reasons for dropping it, are there any reason at all that really can justify keeping it?

Issue tags:-legacy

Most of us would like IE8 to be history for Drupal 8. We must not forget that the percentage of IE8 users will fall after Google drops it and Drupal 8 is due to be released in one year!

The biggest con I see is that there's still pretty large percentage of Windows XP users (governments, conservative companies, etc) that wont be able to upgrade to IE9.
So we don't have only IE8 on the table to gamble with, but also some poor users stuck on Windows XP.

My vote still goes to: Drop IE8!

I'm of the opinion that, if you want IE8 support, you should use Drupal 7. It is a very good Drupal. If you want the latest and greatest, you need to actually use the latest and greatest, and that certainly does not mean IE8 (or any Internet Explorer release, for that matter).

+1 from me.

We need to stop thinking of ourselves and what will our clients' needs be at D8's release timeframe in late 2013 and the ensuing 6 to 12 months in 2014. Will we be losing users, contracts and site builds because of an IE8 requirement?

Should we bold and lead the deprecation of IE8? Or be conservative, avoid the hurt and kick the can 4 more years?

Issue tags:+legacy

@alesr: Firefox, Chrome and Opera are all available in modern versions for XP and can easily be installed as a second browser if needed.

As many, me included, has pointed out, Drupal 7 will still be around and kicking for years to come after D8 is out.

In the event Dries decides against this, or wants to delay the decision till closer to release, I opened #1787146: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8) as a more limited issue that can still unblock JS optimization.

@tsvenson: Some companies need administrators to install new browsers. Some pain-in-the-a$$ admins wont even do that, and bullsh*t about policies.
Meanwhile try to explain a middle-aged PC user with an old laptop running Windows XP and only IE browser that there is no chance his nephew's Drupal 8 single paged blog is going to show up for him.
A lot of PC users just don't know how to install a new browser, some don't even know they can do this and still I find some people who are using IE all day and if I ask them why, the answer is: "Because it all works for me. I don't need a new browser."

It sure works, because we all have to take care of that.

Well, there is a chance we will lose some of the old XP users with killing IE8. That's the biggest con I see here.

@alesr: I'm fully aware of everything you list, and yes those things are problems.

However, this is not about how the situation is today, it is about how it is in about two years time. Sooner, rather than later, the cost of maintaining those decade+ old systems will become more costly than replacing them with newer. Now when Google is dropping IE8 support for Apps, Gmail included, many will follow suite and these organizations will have bigger and bigger problems with their old tech on the web.

I am convinced we have much more benefits to gain from dropping IE8 support than what we lose in two years time by keeping it.

Of course. I'm on the same side.
There will be a bitter taste while cutting them off, but we should not wait to do this in Drupal 9.

Yeah -- where Google leads, Drupal can follow without a problem. And not supporting IE8 does not mean we will serve you a black page. I bet that blog mentioned above will still mostly be readable even if not great.

The main question I would have around this is if contrib could provide a viable alternative. A "legacy_ie8" module/theme collection, if you will. I don't think XP usage will drop off nearly as fast as people here seem to be hoping. This has gotta be at least the 8th time that XP's EOL has been extended. Maybe Google's move will have an effect in "enterprises" but definitely not in places where there are a bunch of 10 year old computers that couldn't run Windows 8 if they wanted to, and XP is working just fine.

I know theme-wise, it's trivial to add conditional CSS to bring in special styling for IE8. There are also solutions like Modernizr that themes could rely on. I'm less sure, however, about some of the UX patterns in core: vertical tabs, contextual links, mobile-friendly toolbar, etc. Is it as simple as hook_js_alter(), swap out vertical-tabs.js for vertical-tabs+ie8.js that's 90% a copy/paste of the same code?

And the reason I ask this is because for awhile there (or possibly still), several of these admin patterns weren't just degraded in IE7&8, but completely effing broken. (Controls unable to be clicked, etc.)

swap out vertical-tabs.js for vertical-tabs+ie8.js that's 90% a copy/paste of the same code?

If we fully embrace it, no, it'd be pretty much all different. If we go halfway then yes, it'd still work without changing anything really and it just means we're not testing in IE8 that's nice but not great. To me the best way to go is #1787146: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8), that's just brilliant.

As for Windows XP, I agree -- many people won't change. In my direct family, I have a relative who refuses to learn anything new since he knows Windows XP so why learn Windows 7 (then again, he uses Foxpro for DOS still in DOSBox). He is using a mix of Chrome and Firefox Another relative (a rather young one, I must add) is using a ThinkPad T21 thrice his own age :) which obviously runs Windows XP -- and Firefox. Just because you are using XP, you do not and need not to run IE.

We need support for IE8 in D8.
Not everybody has IE9, when we start with D8 (e.g. Win XP in companies)!

It must be possible to use all functions and pages of D8 with IE8 for admin and all other users!

Drop IE8 in Drupal 8 core and put IE8 as contrib module/theme or even patch.
If we can manage to do it like this, everybody stays happy and there is one thing less to care about when developing Drupal 9.

I agree to #17.

That is the best way for D8 and all IE8-users, who cannot change the IE-version, because they are no admins at their computers.

I think #17 is the best option if it can be pulled off smoothly, per webchicks comments.

Global IE8 usage will be much less in two years time when D8 is in its prime.

Here is NetApplications from August 2011 - 2012. They start at 30% and drop to 25%. http://www.netmarketshare.com/browser-market-share.aspx?qprid=3&qpcustom... At this rate (according to NA) of -5%/year IE8 will be at 15% when D8 is in its prime in two years.

I posted this just to look at all the data, I am not arguing NA is more accurate than SC. I think we should present as much data as we can to make an argument in either direction.

Personally I think we should follow in Google's footsteps. I think the decline will accelerate at a more rapid pace than previously.

I think many more will follow in Google's footsteps and we will not be the only ones. If every website put something like www.dgo.to/jreject on their websites then we would see change happen at a much faster rate.

How would we load a no-js page for IE8- other than agent sniffing? This seems like a backwards approach. It's very out of line with the principles of progressive enhancement and responsive design. IE8 is not an incapable browser, so much so that we can't provide an experience that's at least better than text on a page. Does anyone have an approach in mind they can articulate or can point out what steps we'd take to remove IE8 support? Like what it would mean in concrete terms?

I'm also confused by the effort to reduce our dependency on jQuery by eliminating support for IE8. Do we know what would need to be removed to achieve this goal i.e. what the success criteria are? Or are we simply reacting emotionally to the smiting of a component of our daily lives that causes us grief -- protesting in the streets as it were.

I personally would rather not severely addle the experience of what will still be millions of users on IE8 throughout the life-cycle of D8 just to shave 20ms off a page load. If we're talking about 1s, then yes, there's a tradeoff to consider. But I think we need that data before we throw this adult-child-still-living-in-its-parent's-basement out with the bathwater.

I'm working on the data. see the navigation timing module and this comment for reference of what kind of things I'll have to show #1541860-42: Reduce dependency on jQuery and some of the stuff from a talk that wasn't selected for drupalcon: Measuring front-end performance.

I knew you'd have data @nod_ :D

So, during Mobile Meetup #16 (http://www.youtube.com/user/MobileDrupal?v=9Pv2_69q-Xw), we discussed 3 possible future scenarios for IE8 support (or non-support).

  1. We support IE8 and thus impose on ourselves a hard update ceiling of jQuery 1.9 on ourselves.
  2. We provide halfway support with feature detection #1787146-8: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8).
  3. We blocked scripts on IE8- with conditional comments.

Option 1 is not lovely. It locks us in the past, but it means that a browser with a large market share (even 2 years from one one could assume) has a rich experience.

Option 3 is not good. Full stop.

Option 2 is interesting. It essentially handles impoverished UAs through a progressive enhancement approach. It means that the no-js version of Drupal needs to be usable. This has benefits for UAs other than IE8-.

But I think we need that data before we throw this adult-child-still-living-in-its-parent's-basement out with the bathwater.

I just want to add how much I love that line. :-)

I also want to dissuade people from looking at the 2-years-out mark. That's not the target. 1 year is. The lag time for the major contribs (esp. Views, Panels, etc.) should be far less for Drupal 8 than it was for Drupal 7, since there's a total of 3 initiatives working on putting all of that into core directly. Even if not entirely successful, all of the work going into Views-for-core means that as a worst case scenario, Views-in-Contrib for D8 can launch the day that Drupal 8 core does. Don't assume that because Drupal 6 didn't have the full contrib experience for a year that we should bank on that for all releases. Drupal 6 was an anomaly. Drupal 7's big uptake was around the 5-6 month mark, and that was, I think, mostly people who didn't understand that a Views beta is more stable than most modules' final release. ;-)

I'm not sure which way I go on the IE 8 question, and for the most part I'm going to stay out of that decision. But we should be calibrating against what the market looks like in August 2013, at launch, not August 2014. Not unless we're just assuming that Drupal 8 will be unusable for a year after launch, in which case we've all screwed up royally.

@Crell: How do you see going for option 2 in #24 and leave any additional IE8 support to contrib?

Its possible that IE8 still has a a few percent market share (of which many will also have a second modern browser) 1.5 years from now, even though I doubt it as I believe that Google's drop announcement will soon get a lot of followers. Then what about in 3-4 years when Drupal 8 still have several years supported life left? By then IE8 should be at the same level as IE6 is today.

How much would we gain if IE9 was the benchmark. Will it be easier to maintain and also introduce complementing functionality in point releases? Will it make the UX better and snappier for sitebuilders and users of sites that offer rich media and advanced interactive features/apps without IE8 support.

Simply, will there be a noticeable difference in UX and performance of Drupal 8 sites that doesn't contain IE8 support?

Also, lets not forget that Drupal 7 will still be around and offer this support out-of-the-box...

As a developer, I'd love to see us forget about IE8 entirely. From a product strategy standpoint though, it's a tougher problem. It's not simply a "only X% of people use IE8, let them stick to D7" calculation, because the people deciding whether to use IE8 aren't the same people who are deciding what version of Drupal to use. Drupal's audience is site builders. We'd be asking every site builder to choose whether *their* audience includes enough IE8 users to disqualify D8 from the options for their site. Even if the IE8 using population drops to say only 5%, what if 30% of site builders end up feeling that abandoning 5% of their audience is not ok? Are we okay telling those site builders "use D7 or don't use Drupal"?

However, making most (or even all) of Drupal's core JS gracefully do nothing on IE8 while still leaving all site operations accessible to IE8 users, as is being discussed in #1787146: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8), seems like it could give us most of the development and optimization benefits we want without risking complete alienation of site builders needing to serve a small and shrinking population of IE8 users.

However, making most (or even all) of Drupal's core JS gracefully do nothing on IE8 while still leaving all site operations accessible to IE8 users

If I read that right we would then be able to fully take advantage of all modern cool stuff and the sites will still work OK in IE8 without explicit support for it, just not as pretty. Is that correct?

Would it then be possible to prettify it for IE8 browsers in the theme, maybe in some cases with a custom module without too much efforts (i.e. weird workarounds etc...)?

If the answer is yes to both those questions, it sounds to me that would be a good compromise that means sites will work, but at the same time core won't need to support IE8 and all the negatives that means.

I disagree with Crell about the target. Even though D8 will be ready in August 2013 it doesn't mean it will be deployed instantly by the Drupal community. We can foresee a significant amount of installation only 3-6 months after release. But the truth is that we need to calibrate D8 strategies looking at the next 3-5 years. Do we want to carry the weight of a browser that doesn't even support html5 and media queries? Soon IE8 users will see more and more broken websites and not working apps. There might be many different reasons for them to be stuck with it but that doesn't mean they can expect all of the Internet to work for them.
Other than google dropping support there's jQuery 2 as well.
And let's consider that D7 will still be supported for a long time as an alternative.
I'm not a JS expert but nod_ comments make pretty clear that dropping IE8 may offer us the opportunity to lessen our dependency on jQuery that means less stuff to load. I believe, soon, mobile users in slow wireless connection will represent a bigger target than lazy admins in enterprises. The IT world is changing already and as developers we need to look and think years ahead. Let's make the headlines and kill IE8 now !

The jQuery post is interesting read, especially the Q&A section starting with this one:

If jQuery 1.9 and 2.0 are basically the same API, what makes 2.0 compelling?
Smaller size, better performance, and the lack of problems introduced by the need for oldIE support. We expect that we can improve error handling in the $.Deferred implementation in 2.0, for example, whereas we can’t do that as long as oldIE is supported.

I also found this post from 37signals from Feb 1, where they announce that Basecamp Next wont have support for IE8.

As others have pointed out, just how much of the web will break for oldIE browsers in 1-2 years? My hunch it is quite a large part. Sooner rather than later we will see sites such as Facebook and Twitter drop the support as well. Yes, I know those are probably not that relevant for those organizations that stubbornly will continue to cap their use of browser to IE8.

However, besides them sticking to IE8 due to internal applications they still need it for, with #1787146: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8) any Drupal 8 site they visit will still work to some extent and those site owners will be able to add additional IE8 support in the theme if they so desire. I also quite convinced there will be several contrib projects that add more extensive support as well.

Just how big is the potential user/client loss for Drupal?

Can also be turned around to - Will we by by dropping the support instead gain users/clients due to that Drupal 8 will both be easier to develop with and also serve pages faster?

My stance:

  1. I share the concerns raised by @webchick and @jessebeach in #1541860-95: Reduce dependency on jQuery — tl;dr: Replacing jQuery with custom code is guaranteed to introduce Drupalisms in the long run. Which inherently means ugliness and hardly fixable bugs.

  2. According to the jQuery 1.9+ announcement and the jQuery 2 FAQ/clarification, the public API of jQuery will mostly stay the same between 1.x and 2.x.

  3. The main argument for dropping IE8 support is front-end and mobile performance, primarily rooted in jQuery's size (not jQuery's technology/functionality/implementation).
    Alas, reducing the size is the exact goal of jQuery 2 and

    "[jQuery 2.0] should be released in early 2013"

    Furthermore, jQuery intends to introduce a build/plugin system to allow to further decrease the size of custom builds.
    (According to unverified web resources, they didn't decide yet whether that's going to be AMD or another one.)

  4. Usage of JavaScript in Drupal core as well as in contrib boils down to very basic concepts and operations.
    (I'd love to amend this in any way, but this fact can only be stated this simply and bluntly.)

  5. Given the above, I wonder whether it isn't more appropriate to think about: Progressive Degradation
    Meaning:

    • Ship with jQuery 2.x AND jQuery 1.9.
    • Use jQuery 2 by default.
    • Allow users to switch to 1.9 for oldIE compatibility.
  6. Profit.

@sun, re #32-5, this expresses the intent of this issue well and it's an apt concept here.

Do you foresee a switch in the UI? Or maybe something like a distribution that arises near D8 release that flips the appropriate switches to enhance the IE8- experience?

The plan outlined in #32 is essentially based on the same architectural train of thought as #7 in #1787222-7: [meta] Strategy for updating vendor JS libraries within a major stable version - which makes more and more sense to me.

Whether jQuery can be switched from the UI or only via code, I don't really care. However, the architectural concept I'm presenting needs buy-in from others first, and the other issue doesn't go so well with that.

Actually, I'm warming up to #1787222-7: [meta] Strategy for updating vendor JS libraries within a major stable version. Will write a detailed comment there summarizing my latest understanding shortly.

We need a decision taken this month or we'll be just too short on time to do anything about it before December.

This is not just about jQuery even if it's a major part. It's also about the need to test things in IE8 for CSS/JS, that's a painful overhead.

Hm. I'm not exactly sure what the plan in #32 would translate into, with regard to "IE8 support."

One way to interpret it might be:

  1. Core encourages IE9+ and officially and fully supports that.
  2. You can, however, achieve IE8 compatibility by using the appropriate libraries.
  3. This means that CSS/JS is either kept compatible, or different versions/variants are supplied.
  4. Core focuses on IE9+ though and IE8-compatible stuff has not been extensively tested; please file core issues if you find bugs and fix them yourself + with others sharing the need for IE8.

Would that make sense? Other stances?

In addition to #37 and along the lines of #1787146-9: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8), it seems reasonable to me that we allow any given core JavaScript file to have an if statement at the top that effectively makes it not do anything in IE8. Only to be used when there's a compelling reason: if it's simple and performant enough to make something work on IE8 either directly or by using jQuery 2 APIs that work just fine on jQuery 1.9 as well, then do that, but if there's some Drupal core JS that's too much trouble to make work on IE8, then add a kill switch. As long as the site still functions (links are visible and clickable, forms are populatable and submittable) on IE8, I think we're okay, even if the lack of running that JS makes it a less optimal experience. And of course, contrib can hook_library_alter() in replacements to any core JS files we do this to. Does that seem right?

Happy to hear about this!
But I am in China where many people still have WinXP+IE6 in his/her computer,
Any way, My vote goes to DROP IE8!

Ok I'd say last chance for D8 after we won't have time to do the clean-up.

#32, #37 and #38 works for me, can we agree on it and start putting conditional styling/scripting?

( edit ) so I guess it's not fully dropping IE8 support but that'd fix this issue anyway. hopefully D9 material :)

Status:Active» Needs review

and i guess

Some more data points, since it looks like the last time this was done was in September 2012.

Source: http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Historical_usag...

StatCounter pegs IE 8.0 usage at 10.29%, IE 9.0 at 15.81%, and IE 6 and 7 both negligible:

IE usage steadily falling.W3C Counter pegs IE 8 usage at 7.4%, IE 9 at 9.6%, and IE 7 still hanging in there at 5.1%:

IE usage steadily falling.Net Market Share has IE8 usage all the way up at 23.23% with IE 9 just behind at 20.62% and IE 6 still clutching on for dear life at 6.21%. These numbers look really inflated compared to what I've seen reported in general tech news, so not sure where they get their data.

IE takes a huge portion of pie chart.

Disturbingly, in all of those graphs, IE9 usage is falling more sharply than IE8, and IE10 is not exactly taking off like a rocket ship. :\ Extrapolating from IE6's data is interesting; it likely means there's at least another year and a bit before IE8 can be called negligible. :\ Though the mobile revolution might knock some wind out of that fight; not sure.

Lets also keep in mind that D8 is not out yet and IE8 is going to keep declining. April next year Microsoft is officially killing WinXP, for wich IE8 is the highest version to run on it.

Also, lets not read too much into that IE9 is dropping faster. It was released, and requires, Vista or higher after all.

Extrapolating from IE6's data is interesting; it likely means there's at least another year and a bit before IE8 can be called negligible.

I don't think this is apples-to-apples. As noted by others, IE8 is the last version of IE for Windows XP. Removing support for IE8 is like saying Drupal doesn't support Windows XP. Of course there are other newer browsers for XP also, but I think IE8 is going to be sticking around for as long as XP itself. Considering ~38% of all computers still run XP, I don't think dropping IE8 is a good move.

Personal preference: keep official IE8 support. If sites don't care about IE8, then that's their decision, but it's going to be a lot harder for sites to add IE8 support than remove it. I think this is a situation of putting our end-users before ourselves.

As much as I hate IE8 I'd probably agree with quicksketch for now.

I can see clients coming and asking for IE8 support, even in a year or more's time, and it is going to be hard to add support if it isn't there.

In theory though I would love to drop it.

What about a compromise - we provide the degraded single column / no js experience to IE8, but have a block explaining the situation. It could have a link to a page listing the options: IE10 (if on modern Windows), Chrome and Firefox.

Would it be possible to offer a IE8 compatibility module? Maybe not bundled in core, but as a contrib.

Also, as noted in the OP, Google stopped supporting IE8 November last year for Google Apps. To be honest I had completely forgot about that. Probably mostly because it passed rather unnoticed, including no flood of posts by users complaining Google Apps stopped working for them.

Who else do we know that has officially stopped, or announced they will stop, supporting IE8? What about Facebook, Twitter, Tumblr, Wordpress and other competing CMS's?

Another factor we should remember is that if IE8 is dropped from D8, any user that still require it will have D7 as choice for years to come. Just because D8 is out it doesn't automatically means that is their only Drupal choice.

What about a compromise - we provide the degraded single column / no js experience to IE8, but have a block explaining the situation.

This isn't a compromise, this is just not supporting IE8.

Would it be possible to offer a IE8 compatibility module? Maybe not bundled in core, but as a contrib.

Again, this is core punting on a problem to our end-users. Also said above, it's much harder to add IE8 support than it is to remove it. We're talking about core removing significant amounts of jQuery and replacing it with less-compatible JavaScript, and doing the same with our CSS styles for our themes (including the admin theme, Seven). If this problem is punted to contrib, restoring IE8 support would mean significantly more effort (and page weight) for a site than core supporting it directly.

Issue tags:-mobile

Alright, so far we have mostly discussed this from the assumption that the market is going to require IE8 support in Drupal 8. Some of us, me included, have tried to point out that the IE8 market share today is way higher than it will be in 12-18 months, the time when we likely is going to see any real deployment of D8 based sites (if the current release schedule holds up that is).

We also know that Google already has cut support of it for, at least, Google Apps in November last year and that that went more or less unnoticed without any alarming reports from protesting users. There are most likely other big companies out there that either already have cut or have a plan to cut support for IE8.

What we haven't really discussed yet is the work required by the community to maintain support for IE8 in D8. Not just for core developers, contrib devs will to some extent be affected by this too.

Nor have we looked into the extra work this will add to those building sites. Including the testing and tweaking to make sure it works with both IE8 and more modern browsers.

Lastly, we have not really looked into the overhead supporting IE8 will have on sites running it. How much will that affect performance of those sites.

The overall question to all of the above is simply - Is it really worth all the extra work maintaining IE8 support in D8 or is there a better option?

As I have pointed out a couple of times, Drupal 7 is not going to go away any time soon. It will be fully supported by the community for years to come. I don't see any problem with recommending those who still going to require IE8 support in two years or so to use it. Doing so we will be able to cut cruft that will be irrelevant in just a few years and allow us to make D8 leaner. I'm quite sure that a lot of developers, sitebuilders and others will be quite pleased with that.

To avoid confusion we only need to make a visible feature and requirement list available to make it easy for people to quickly identify if they should opt for D7 or D8 for their new sites.

Issue tags:+mobile

I have absolutely no idea how the mobile tag got deleted. #strange

With jQuery 2.0 out and dropping IE8 support that seals it for me. I think we should drop it.

The overhead of supporting it in core code isn't just time spent on the workarounds, it's going to degrade performance for every browser we support that's not IE8- whether loading jQuery 1.9 as well, or CSS selector performance, more weight in markup etc.

Sites that absolutely need full IE8 support can stay on Drupal 7 for a bit longer, that'll be around for another 3 years or so.

StatusFileSize
new123.14 KB

@tsvenson at least you fessed up. :) We've all been there.

Thought this might help visualize ie8 usage.

ie8 countdown
source: ie8countdown.com

We can deconstruct what support IE8 means.

End-user (anon) support

Bartik needs to present information well in IE8 because it needs to display information well in any browser -- a PSP, a Gen1 Kindle, a toaster with a browser. This is progressive design. This is responsive design. We can't let information display (field displays, layouts) be broken.

This does not mean that we need to support complex layouts in older/incapable browsers. A one-column, JS-degraded experience is fine. We won't try to display color video on a black-and-white TV.

Administration experience

I think this is what we're really debating. How much of my site can I administer with less-capable browsers? Here I think we can set some limits because alternatives do exist. Someone using Drupal to build a site can't dictate what browser their end-users use. But we can dictate what browsers we support for site administration because folks who use Drupal as a site building tool have an incentive to get the best experience -- and probably the wherewithal to switch browsers. If site administrators absolutely cannot use anything but IE8 to administer their site, then they have Drupal 7. I agree with tsvenson and catch on this point.

Our anonymous front end experience, out of the box, does not require jQuery.

Therefore, I don't think it's unreasonable to say that we support jQuery 2.0 out of the box and thus IE8 does not get a rich site administration experience. The experience isn't broken, it just isn't rich and interactive.

Market is always about demand. Lets add jQuery to the factors by watching when they'll officially stop releasing their 1.x series and stick to only supporting 2.x. That would be a clear sign I guess and would cause less dilemmas when trying to make a decision ;)

I like the idea of breaking this down to end-users/visitors and admins/authors. From the last group, I think that admins won't have a problem using a compatible browser - whatever we throw as a requirement. I'm not so sure about authors though. They are a controversial group of people: some consider them site visitors with extra rights and others see them as "junior" admins with limited rights (they do use the admin UI).

klonos, that's a very good point about authors. I think they might be the user group that keeps us pegged to IE8 support for rich interactions.

Don't forget IE9 usage, which seems to already have more market usage than IE8:

ie9.jpg

Source: theie9countdown.com/

The overhead of supporting it in core code isn't just time spent on the workarounds, it's going to degrade performance for every browser we support that's not IE8- whether loading jQuery 1.9 as well, or CSS selector performance, more weight in markup etc.

I disagree with that being relevant to this issue. Here's why:

- We already accepted a single-column layout for IE8 in #1465948: [meta] Drop some IE8 coddling from Drupal core. A contrib module can add Respond.js in order to restore multi-column layouts to IE8. If someone here wants to make a case for adding Respond.js to core, open an issue for that.
- #1649780: Remove first/last/odd/even classes in favor of CSS3 pseudo selectors is the issue for removing some PHP and HTML bloat around those classes. There's broad consensus on that issue that IE8 is not a barrier to that, because it's just some progressive enhancement/degradation, not an information accessibility problem, and contrib can restore the enhancements with Selectivizr. That issue is stuck on problems with hidden table rows that affect all browsers, not just IE8.
- #1787146: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8) is the issue for discussing what we need to do to optimize JS for mobile performance, and what impact that will have on IE8.
- What besides the above is a factor in IE8 considerations slowing down our front-end performance?
- If nothing, then as far as I can tell, this issue is only about whether we flat out stop testing core patches on IE8 at all.

Honestly, I'm not sure why we have two separate issues. IMO, making D8 a no-js browser is just the same as not supporting it at all. IE8 is already near-death, and it'll be even closer by D8's release date. It doesn't make sense to drag it out. catch says it perfectly in http://drupal.org/node/1787146#comment-7334286

Can we merge these two issues? Seems like there's a lot of similar discussion happening in both issues. One master issue called "figure out how to deal with IE8" seems a lot easier to deal with.

Assigned:Unassigned» Dries

The main benefit of this issue would be to speed up the core development process by removing an annoying browser to test against. The main cost of this issue is to give up Drupal 8 adoption by anyone who cares about the 10% of their audience (or however that number evolves) still on IE8.

The main benefit of the other issue is to improve mobile performance. The main cost of that issue is whatever will be required of a contrib module to restore that functionality for IE8.

Those are very different cost/benefit calculations. I don't see this one making any further progress without input from Dries, so assigning it to him. I think the other one can make more progress in figuring out its details in the meantime.

I just want to link to catch comment on the other issue which is probably more relevant here than on the other issue: #1787146-22: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8).

In the context of "mobile", I think one of the biggest benefits was mentioned by _nod in the other issue: http://caniuse.com/#compare=ie+8,ie+9. The sheer amount of features not supported in IE8 that are available in all other modern browsers and particularly on mobile.

Key ones: <video> element (don't need to think about Flash anymore), CSS3 transforms/box-shadow/border-radius, SVG (think retina icons! And bandwidth savings!), WOFF/TTF/OTF fonts instead of only EOT (again retina + bandwidth savings), canvas, geolocation.

The main benefit of this issue would be to speed up the core development process by removing an annoying browser to test against.

Removing support for a browser because it's annoying to test against sounds like the kind of decision developers would make if business owners did not exist. 10% is way way way to much to drop support. One in ten people! On top of that, you also have to consider the potential influence of this 10%. What kind of person still runs IE? Employees of large, non-technical, organisations with costly upgrade bills. Not developers or site builders, these people would most likely be potential content creators.

I think it's fair to assume that there are more ‘content creators’ in that 10% than site builders or devs. Which means the % of content creators on IE8 is way higher than 10%. How many features have we added to Drupal 8 just to improve the experience of content creators?

I wholeheartedly agree with catch's comment, linked by nod_ in #62.
If we support IE8 now, we'll have to support it until some year close to 2020.

We can hopefully assume that Microsoft will have seen the light by then and started to make decent browsers. Microsoft also seems to have given up on its "one Windows version = one IE version" paradigm, making it highly likely D8 will still be forced to support IE8 long after IE15 has been out.

That does not look like a pickle we want to be in, IMO.

Personally, I don't want to be in the position of supporting IE8 for the next 5-8 years. I don't know about you guys, but I got my fill of that with IE6.

Issue tags:-mobile, -legacy

@effulgentsia; yes I keep getting confused about which issue is which. @nod_ I think the difference is that if we make a decision here then the other one becomes more of a graceful degradation task that could be done any time, whereas it's just the actual decision here to start unblocking other issues.

@LewisNyman

Removing support for a browser because it's annoying to test against sounds like the kind of decision developers would make if business owners did not exist.

Dropping support for things that are annoying is one of the few things we're able to do to make maintaining core sustainable for those who work on it, the majority of which are volunteers (I've been funded for core patches, but I'm not for maintaining 8.x for example). If business owners want to pay people to support IE8 they're welcome to, but they're not going to dictate what I do in my own time thanks very much.

What kind of person still runs IE? Employees of large, non-technical, organisations with costly upgrade bills.

using Drupal as opposed to visitors are also likely to be those who have more browser flexibility though.

I've got no sympathy with workplaces on old, legal copies of XP that are keeping people on IE8 - they're entirely capable of allowing people to use firefox or chrome instead without any costly upgrade process. If they're not prepared to upgrade/change desktop browsers then they can stay on Drupal 7 for a while too.

@LewisNyman Please don't stare yourself blind on the 10% market share IE8 has today. It is a completely irrelevant number and in two years when Drupal 8 really starts to take off it will, hopefully, be just a fraction of that.

Also, again, no one will be forced to use D8. If IE8 support is critical then D7 will be around for years to come and it will remain an excellent platform.

So, lets not add extra, and unwanted, burden on developers, site owners and users (performance) just to drag with us support for a dying web browser...

The planned date for end of extended support for Windows XP is April 8, 2014. Though I think Microsoft has been known to extend these kind of dates before, it's unfathomable to consider the notion that they would do it again for a what would then be a 13 year old OS.

After all, as mentioned, the existence of IE8 is because of Windows XP. With that being said, I've been theming a high end Java Server Pages app for the past year for a large University here in southern California and their IT department fully knows the pitfalls and limitations of IE8. They've had to embrace installing Chrome and Firefox on their users XP machines for exactly the reasons this issue exists. So the EOL support for XP I think then coincides nicely with the release of Drupal 8 and thusly justifies dropping support for IE8 in D8. Just my 2 cents...

"Drop support for IE8" is still a bit vague in this thread. I understand it to mean that we will not peg Drupal 8 JavaScript support to ECMAScript Third Edition. We will allow the JavaScript to adopt ECMAScript Fifth Edition features.

I will argue that this is just the practice of progressive enhancement. We want to keep Drupal modern, fast, light and relevant. To do that, we need to draw a line in the sand in terms of support for rich experiences. We must always support the baseline, no js, simple styling, clean markup experience because all responsive and progressive development starts at this baseline. A broken experience is unacceptable on any device.

I believe the outcome of "not supporting IE8" would be that we hide unsupported JavaScript features from IE by feature-checking. An IE8 user would most likely get a no-js experience on many administration pages.

Give that official support for XP will end in April 2014, this is not an unreasonable approach to take. Older software will run slower and tasks will take longer. We don't expect our dusty Commodore 64's to process 1080p video, right?

I believe the outcome of "not supporting IE8" would be that we hide unsupported JavaScript features from IE by feature-checking.

I disagree with this part.

"Hiding" is an active verb, as in: We write extra code to make sure IE8 works.
Which is the exact opposite of what we're trying to achieve here.

Think TV. Black-and-white televisions could still receive a signal in color, but not actually display the colors. IE8 will still get a website, but not the full version. Single column, perhaps even no JS, ...

To clarify #68 about the ECMAScript 3 and 5 difference, here is a compatibility table: http://kangax.github.io/es5-compat-table/

Biggest pro is that It allows us to use native functions like .forEach, .filter, .map and some others without the need for jQuery nor underscore.

"Hiding" is an active verb, as in: We write extra code to make sure IE8 works.
Which is the exact opposite of what we're trying to achieve here.

The difference is a little more subtle. We wouldn't write rules for IE8. Rather, IE8 would happen to not have certain code executed because it doesn't support the features that the code requires. Any browser that doesn't support these features wouldn't run the code. This is the driving concept behind Modernizr and Yep/Nope.

This is exactly how CSS works, but the difference is, when CSS doesn't apply, the engine ignores the statement. With JS, we get an error, so we need to be more proactive about feature-checking.

As with our lack of support for IE6 and IE7, lack of IE8 support would mean that we simply do not care what happens in IE8, therefore we don't need to do any feature checking. We'll just let it error and call it good.

Feature detection is a standard safeguard of front-end code, I don't see a reason not to do it. IE8 isn't going to be the first nor last browser on all the various devices that will spring up out there during D8's lifetime to support some parts of JS but not all of it. Older versions of Android are also a pain, and often those users *can't* upgrade their OS to a newer version without circumventing the law.

Status:Needs review» Needs work
Issue tags:+Needs issue summary update

Btw, before this goes to Dries we're going to need someone to write a balanced issue summary that lays out the current state of things and pros/cons. Marking "needs work" until this is done.

3 questions that I'm not yet clear on that I'd love answered in that summary:

1) Will an IE8 user have no js run, or some js run? If no js, by what mechanism will that be globally enforced? If some, will errors be triggered (if no, by what mechanism are we confident of that if we're not planning to test on it)?

2) Will an IE8 user have access to see (or if using a screen reader, hear) all content, click on all links, and submit all forms (that they have permission to)? If yes, what makes us confident of that if our plan is to use some/all of the cool modern features mentioned in #61?

3) Will contrib be able to enhance the IE8 experience if it wants to? Will it be able to do so to D7-level (e.g., States, Ajax, Overlay, etc.)? If so, how?

None of those are intended to be leading questions. Personally, I'm fine with any answer for them. Just trying to understand what the actual result of doing this would be.

Issue summary:View changes

Fix link

Issue summary:View changes

Improving issue summary

Issue summary:View changes

Updated issue summary.

If we support IE8 now, we'll have to support it until some year close to 2020.

Why?

(I'm not just directing that question at the above comment; similar comments were made by others also.)

I'm quite sure there's a middle ground in which Drupal 8 supports IE8 when it's released, and for a while afterwards, but eventually stops caring about it. (Especially true if the date at which Drupal 8 stops caring about it is picked in advanced.)

There are probably plenty of sites out there which care about IE8 now and in the near future, but won't care about it anymore in a few years.

Here's a thought: Clearly mark that IE8 support will be deprecated and removed during the lifetime of Drupal 8.

Couple of other projects:

Moodle's going to drop IE8 support in 2.6, released around November 2013. Since that's VLE software it's very much targeted at schools/colleges/universities which aren't know for bang-up-to-date windows installs.

http://docs.moodle.org/dev/Moodle_2.5_release_notes

Team Foundation Server (which I've never heard of but appears to be MS-related) is just dropping support around now:

http://blogs.msdn.com/b/bharry/archive/2013/02/08/team-foundation-server...

I'm quite sure there's a middle ground in which Drupal 8 supports IE8 when it's released, and for a while afterwards, but eventually stops caring about it. (Especially true if the date at which Drupal 8 stops caring about it is picked in advanced.)

A large part of addition or removal requests for D7 ended up being labeled as "let's do this in D8". I'm afraid that if this doesn't make it into D8 at release, it will be postponed until D9.

Also, changing minimum system requirements halfway through a major release cycle just seems dirty.

The counter to the argument for those antiquated organizations stuck in the un-upgraded past, is that catering to those needs is enabling them to stay stuck, rather than pushing them forward.

Move the web forward!

I don't think that people are going to be amicable to the idea of losing support of IE8 after 8.0 is tagged and released. That'd sort of be like tearing out the flood control subsystem. It's not critical per se, but you can bet that there will be some people that were depending on it.

I agree that launching drupal 8 with IE8 support and then pulling it later would be a bad idea.
Wouldn't we then lose out on benefits of dropping IE8 support, plus have people pissed off that their once working in IE8 drupal 8 site suddenly doesn't work anymore mid way through the life cycle (inless it reamains until IE8 usage is 0%, which could be never).

I'm definitely sold on dropping IE8 support now.

Why should we bend over backwards for the few that aren't willing to upgrade or use alternative browsers, so many years after alternatives have been released.

It's like giving the misbehaved kid preferential treatment.

Let them stay on drupal 7 if they must.

Developers are already stretched thin enough, the more we can do to make developer lives easier and more productive the better.
Hold the "Please, won't you think of the users you selfish developer!" arguments, because as stated by many, there are alternatives for these users. They can still use drupal.

3) Will contrib be able to enhance the IE8 experience if it wants to? Will it be able to do so to D7-level (e.g., States, Ajax, Overlay, etc.)? If so, how?

We could provide a file of polyfills for the ES5 features that IE8 doesn't. This file could be loaded through a module, either in core, or from contrib. If a feature is provide, such as Array.prototype.forEach, then the test for that feature will pass and the code the depends on it will run.

On competitors, it's a little hard to determine where they stand because there don't seem to be any conversations about dropping IE8 support at this point in their issue trackers.

Wordpress looks like they're going to hold off on using jQuery 2.0. IE8 support is implied but not explicitly stated.

Joomla, while I couldn't find any issues specifically around dropping IE8 support, the 3.x version of Joomla (originally released September 2012) will be supported until 2016. Not particularly helpful since this is essentially the same EOL date for Drupal 7.

Regarding jQuery 2.x, I think this blog post sums up things nicely, saying the jQuery officially still supports IE6/7/8 in the 1.x branch and that jQuery 1.9 is API compatible with 2.x. The only serious difference is a 12% reduction in jQuery script size.

Developers are already stretched thin enough, the more we can do to make developer lives easier and more productive the better.

Hold the "Please, won't you think of the users you selfish developer!" arguments, because as stated by many, there are alternatives for these users. They can still use drupal.

Let's clarify this. This is making life easier for core developers, but not anyone else. It's making life harder and less productive for the end-user developers who develop Drupal sites who are going to need to support IE8. As for contrib developers... they can choose individually what their browser requirements are anyway, so either way we go on this won't affect them significantly. The request to support IE8 is actually also a "selfish" request because it means that the effort to support it is spread out across more people. As soon as it's feasible, I'm not going to be making sites IE8 compatible either, so as an end-user developer of Drupal, core supporting IE8 will only mean more flexibility and less effort required on my part.

Issue summary:View changes

Adjusting parts that talk about IE's marketshare, including Lewis Nyman's comments.

I agree that launching drupal 8 with IE8 support and then pulling it later would be a bad idea.
Wouldn't we then lose out on benefits of dropping IE8 support, plus have people pissed off that their once working in IE8 drupal 8 site suddenly doesn't work anymore mid way through the life cycle (inless it reamains until IE8 usage is 0%, which could be never).
....
A large part of addition or removal requests for D7 ended up being labeled as "let's do this in D8". I'm afraid that if this doesn't make it into D8 at release, it will be postponed until D9.

Well, yes, large refactorings to take advantage of "no-IE8" would be off the table (it's already getting late for that in Drupal 8 anyway), but smaller improvements and bugfixes later on in Drupal 8's lifetime would benefit from not having to deal with IE8. That's what makes it a compromise :)

For example, Drupal 7 supports IE6, which in theory means that new CSS or JS patches have to be tested there to make sure there are no regressions. This is a burden which regularly prevents those patches from progressing in Drupal 7, even now. The goal would be to avoid this in Drupal 8.

Though it's worth pointing out that the official browser requirements page already stopped claiming Drupal works on IE6 (or even IE7): http://drupal.org/node/61509 ... and no one has complained that I know of. The difference, I guess, is that we haven't "dropped" support so much as stopped expecting new things we introduce need to work well in those browsers. But we still care about regressions. The proposed compromise would be to have Drupal 8 go further than that, and (at some point) stop worrying about introducing regressions in IE8 also.

I've been following both related issues and I know supporting IE8 will be a major pain down the road. I understand all the arguments presented here for or against dropping support and still I don't have all the answers. What I feel bad about though is the "move the web forward" and "less things developers should be bothered with" comments posted...

Please ask yourselves this: How would you feel if someone came along and proposed that we dropped ARIA support in D8 because it takes more time off from developers' life and kindly point people to D7 instead? Sure, we'd move at a faster pace, but we'd be ignorant towards a certain group of people that need special attention in order to make their life easier when participating in the miracle called the World Wide Web. They too have the right to the latest and greatest if that is possible.

Well, now please try to see all (or at least most of) those people, organizations or even whole countries still stuck with "old" hardware running Windows XP and thus IE8 with the same eye. Which reminds me of this short dialog I saw once in a certain infamous site (disclaimer: I don't endorse piracy)...

- "Why don't you simply buy the software you @#$ $^*?"
- "Because I'm poor!"

So, what I'm saying is don't be hopeful of this remaining ~10% of people to drop anytime soon unless they personally as well as the countries they live in start making huge progress. Think of them as "monetarily handicap" (™) if you like and please try to be thoughtful. We are not "misbehaved kids" nor "unwilling to upgrade". Sometimes it's not simply a matter of choice.

With love from Greece and on behalf of the other "poor" countries of the EU south.

- "Why don't you simply buy the software you @#$ $^*?"
- "Because I'm poor!"

"Oh, okay. Well then here's the link to Chrome and Firefox. Both are free and both are supported by Drupal 8. You're welcome."

Dropping ARIA support is a little different, IMO. This is an accessibility feature, whereas support for IE8 is more of a performance bug/developer happiness black hole.

Developers are already stretched thin enough, the more we can do to make developer lives easier and more productive the better.

Hold the "Please, won't you think of the users you selfish developer!" arguments, because as stated by many, there are alternatives for these users. They can still use drupal.

Let's clarify this. This is making life easier for core developers, but not anyone else. It's making life harder and less productive for the end-user developers who develop Drupal sites who are going to need to support IE8. As for contrib developers... they can choose individually what their browser requirements are anyway, so either way we go on this won't affect them significantly. The request to support IE8 is actually also a "selfish" request because it means that the effort to support it is spread out across more people. As soon as it's feasible, I'm not going to be making sites IE8 compatible either, so as an end-user developer of Drupal, core supporting IE8 will only mean more flexibility and less effort required on my part.

I guess it depends on the developer & the client.
To begin with there will be less and less of clients that want IE8 support.
Then you can say to them IE8 support will cost x dollars, in which case they might be a large company that will pay it, their eyes might open wide in disbelief and they suddenly don't need IE8 support that much any more, or they might pass and you move on to the next client.

That 3rd result is what depends on the developer, because some developers can afford to miss that opportunity and others cannot.

There are things to remember here though:
* In 12 months time those that require this will be fairly small (I assume).
* You can always say to the client, to have IE8 support we should go with the tried and tested drupal 7, for which so many add-on modules already exists and we have years of experience supporting. If you really want to go with drupal 8, can you compromise on IE8?
* They can have a site that looks decent enough in IE8 but for a quality experience they should use another browser (is it really going to be broken to the point you can't use it?)

The hard part is that first thing. We can only speculate on what the IE8 usage will be by the time this all matters.
I currently deal with a lot of clients that use IE8, however I would expect most if not all Australian government would be on Windows 7 by then. I don't know about other countries.

Well, yes, large refactorings to take advantage of "no-IE8" would be off the table (it's already getting late for that in Drupal 8 anyway), but smaller improvements and bugfixes later on in Drupal 8's lifetime would benefit from not having to deal with IE8. That's what makes it a compromise :)

I see your point re the compromise.

I'm still sometimes forgetting the difference between this issue and the nojs in IE8 issue.
But if I'm mindful of that maybe it would be good to drop IE8 js support and give them a cut-down experience but keep testing IE8 to make sure it isn't way broken, then fully drop support later.

- "Why don't you simply buy the software you @#$ $^*?"
- "Because I'm poor!"

I have also been excluding this group of users because of the free alternative browsers available.
I'm only really considering government/business users who have IT policy limiting their browser usage.

If you think in terms of the greatest good, which is better:
A bit of grief for the first 1/4 of the drupal 8 life cycle when people want IE8 support but it is hard to give it, or a bit of grief for the last 3/4 of the lifecycle where no-one cares about IE8 support but we have a bunch of legacy code to work around. (I'm making more assumptions here but it illustrates my point).

I think we should change the title of this issue to:

"[Policy]: Develop Drupal 8 Core JavaScript against ECMAScript 5. Prevent errors with feature detection. Provide optional polyfills for legacy browser support."

This positions Drupal 8 to not be saddled with cumbersome, verbose and heavy JavaScript in 2 years when IE8 will be forgotten, much like IE7 disappeared from Drupal 7's radar. But for those hangers-on, we'll have polyfills (more weight, but not unlike adding jQuery to every page) that make older browsers behave as if they were feature-capable.

I think that debating about market share, corporate business, browser testing and developers overhead is the wrong way to look at this issue.
As an open source, progressive community (in the technology sense) we want to embrace innovation fearlessly.
If Google drops support for IE8 for their apps (and they certainly care about corporate businesses) I can't believe we're still debating.
Let's kill IE8, embrace modern browsers and push the Web forward! We won't look back, I promise.

Title:[meta] Fully drop IE8 support from D8 core[policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection and use polyfills for legacy browsers

Creative title shortening, but hopefully close to the intent of @jessebeach's #90

Title:[policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection and use polyfills for legacy browsers[policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection

I'm strongly against putting polyfills in core, let's do that in contrib. That way, in two years time when IE8 is surely dead and buried, people can choose to drop the polyfills instead of having them still shipped with core.

As many people in this discussion have already pointed out: IE8 will be as good as dead by the time D8 usage will really take off. This isn't a matter of accessibility like ARIA (which we should never drop out of developer complacency). Instead, this is us enabling businesses to keep their employees on crappy old browsers.

Using IE8 isn't a disability, it's the hard-headedness of not wanting to switch to better free browsers or to upgrade to a newer version of IE. We should not encourage this kind of behaviour. Not now, not ever.

Just to clarify, this is not about writing obnoxious javascript that contrib can't ever make work in IE8. Hell if that makes people feel better I'm happy to maintain the D8 contrib IE8 module.

Again: it is not only big-ass, multi-national corporations that are too cheep to upgrade. There's also small businesses on the verge of closing and governments in countries that go through a serious recession right now. They simply cannot afford to upgrade. And yes we know that there's Chrome and Firefox and Linux out there, but try teaching that to 55-some year old IT admins and near-retirement public servants or even firing old-timers in order to hire young that might not have any experience in the actual field of the business but do know mobile/facebook/linux. I won't argue this any more since one needs to live in such a country in order to understand that things are easily said than actually done. But do keep in mind that this ~10% is a global estimation. For example some countries with large population might actually be on a 3% while other smaller ones be on a 25%. It's natural for people leaving in large, developed countries to ignore the ~10%, but IMHO they only do that because their direct experience is with the 3% - not the 25%.

If most insist on predicting that IE8 will die soon and believe that relying on that assumption is the way to go, then how about we compromise instead: Start with full support and let that support die (evolve to best-effort) along with IE8? If IE8 dies as people claim, then complains about "things not working" will be diminishing over time and we can choose to ignore them since that is what best-effort is about. The sooner IE8 dies, the sooner we'll enter this best-effort stage.

So how about we announce that we ship with full IE8 support now that the percentage is measurable and also announce that IE8 support will enter a best-effort stage at some point. Instead of specifying a specific date for this phase, we leave it vague by saying we will enter this phase either when global IE8 usage drops below x% or after say 01/01/2015 (almost a year after Microsoft officially stops supporting Windows XP - and we use that as an excuse then, not now).

There's already hundreds or even thousands of (more important) issues in the queue that are left unanswered and when that happens I don't see people switching to other CMSes - they instead seem to understand that there's simply not enough interest among the community in fixing the specific issue. We'll simply do the same with IE8 compatibility issues reported: see how many followers an issue has -> decide on the severity -> see if we can afford time and brain -> we either fix things or leave them lingering and dying along with IE8.

Does that sound sane?

Phasing out IE8 support during D8's lifetime is a very bad idea™.

If most insist on predicting that IE8 will die soon and believe that relying on that assumption is the way to go, then how about we compromise instead: Start with full support and let that support die (evolve to best-effort) along with IE8? If IE8 dies as people claim, then complains about "things not working" will be diminishing over time and we can choose to ignore them since that is what best-effort is about. The sooner IE8 dies, the sooner we'll enter this best-effort stage.

Unlike with IE6 it is not about predicting when IE8 will die, it is about knowing when it will be unsupported. It does not make sense to put so much core developer effort in supporting a browser that will not even be supported by its own manufacturer by the time Drupal 8 really takes off.

Holding on to unsupported software is a very bad business call and a disaster waiting to happen. Poor country or not, it's a matter of investing in the future now or paying a much higher bill later when the shit hits the fan. (Note the use of "when", not "if".)

I agree with the people saying that IE8 is unlikely to die as fast as we would like. The biggest issue is probably with Win XP users who could switch to Firefox/Chrome, but they probably need a very good reason to do so. If large parts of the web drop IE8 support then things might move that way pretty fast, but we probably can't rely on this assumption just yet.

In my eyes the best solution would be to drop IE8 support in core, but have a contrib module that adds it back. Now it has been said that this would be too much work, but after reading nod_'s post (#94) it might actually not be that bad? If switching out css/js files where IE8 support was dropped by core with old versions that still support it and do other necessary bits to keep IE8 running well sounds realistic and wouldn't be too much work then that would be the preferred solution to me.

@klonos: Stuck with XP doesn't equal forced to only use IE8. Those XP machines has no problem running much more modern, and safe, versions of both Chrome and Firefox.

I have seen way too many in this thread staring themselves blind to the 10% market share IE8 has today. Staring as if those users, or machines really, have no other choice. That simply is a very bad argument to use here.

To start with we have to, as pointed out several times, try an look into the future and predict with some certainty what will that market share be in 1.5-2 years time when Drupal 8, and its contribs, will be mature enough for sites deployed on it to start to take off. Will that number still be 10% then? I don't thinks so. My guestimate is that it will be somewhere around where IE6 is today.

Then what about those machines that still run IE8 by then, will IE8 be the only browser on those machines or will they be equipped with Chrome or Firefox as well, thus fully capable of viewing any Drupal 8 site in all its glory?

I think it is save to say that the vast majority of those machines will have more than one browser on them. Just like some still are forced to have IE6 to be able to run old legacy crap that only works on that horrible browser.

If IE8 is till the only browser on those machine. Why is that? The only reason I can think of is that someone has dictated that that machine 1) Is not going to be replaced or upgraded and 2) Can not have a modern browser installed.

Cost is definitely not a factor here as both Chrome and Firefox is free.

So, basically we will be left supporting a very small fraction of machines and users that someone is dictating can't move to the future.

Sure, I feel for those users, but I don't see any big enough reasons to support them when it is people above them that has created their situation. In fact, not supporting IE8 will probably just help them to get a better digital environment in the end as that organization is having more and more trouble to function when stuck in the technology past.

It does not make sense to put so much core developer effort in supporting a browser that will not even be supported by its own manufacturer by the time Drupal 8 really takes off.

Obviously, there's no OS-level impediment for people using Vista or Windows 7 to upgrade to at least IE9, but note that Internet Explorer support is dependent on its parent OS: Internet Explorer 8 on Windows XP will reach end of life in 2014, but based on the WIndows lifecycle, Internet Explorer 8 on Windows Vista will reach of life in 2017, and IE8 on WIndows 7 will reach end of life in 2020.

In light of the new title, I have a suggestion; The SASS Compass framework has a variable switch in it called $legacy-support-for-ie. This allows the many many compass plugins to check to see if legacy IE support is required by the project before loading redundant code and work arounds. Maybe having that setting in Core would make more sense than having a ‘legacy IE support module’ that will be tricky to maintain. Contrib developers can then choose to react on that switch or not.

Switching between jQuery 1.9 and 2.0 would be a good example use case for that setting in Core.

Internet Explorer 8 on Windows XP will reach end of life in 2014, but based on the WIndows lifecycle, Internet Explorer 8 on Windows Vista will reach of life in 2017, and IE8 on WIndows 7 will reach end of life in 2020.

Then again, Vista and 7 users have the option to upgrade.
For WinXP users, IE8 is the end of the (IE-)line.

Title:[policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection[policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support)
Issue tags:-Needs issue summary update

That's a valiant attempt at nice-ifying the title to something more neutral, but let's be clear about the impact. :)

And I'll just reiterate that if we want this issue to move forward, arguing amongst ourselves ain't gonna do it. We need a fair and balanced issue summary and then Dries needs to make the call (most likely next week). So make sure whatever points you're making are reflected there in a non-emotional way.

Sigh.

Title:[policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support)[policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection
Issue tags:-Needs issue summary update

Given the new issue title here, my understanding of its implication is:
- With core alone, IE8 users will still have access to all site content and operations, just with a degraded UX
- It would be possible for there to be a contrib module (#94) that restores IE8 to a non-degraded UX

1) Is that understanding correct?
2) Does that make #61 out of scope for this issue (not necessarily out of scope for D8, just out of scope for what's being decided in this issue)?
3) @klonos, @quicksketch, others who have been concerned about dropping IE8: are you still against this more narrowly scoped issue?

And yes we know that there's Chrome and Firefox and Linux out there, but try teaching that to 55-some year old IT admins and near-retirement public servants

Apologies for being an ignorant American, but can you clarify what the impediments are to 55 year old people in Greece and elsewhere installing Firefox? Linux is irrelevant to this conversation. You can install the latest version of Firefox (and maybe other modern browsers) on Windows XP. If it's just a "Oh? What's Firefox?" issue, we can possibly solve that with a link and some help text. If it's some other barrier, it'd be helpful to know what it is.

Title:[policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection[policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support)
Issue tags:+Needs issue summary update

xpost

IE8 in greece is ~6% and a few years ago one of the first countries to have firefox as first browser in usage, i dont think there will be a problem

Another thing to note (that I didn't think of in #97) would be that whichever way core goes will probably also affect contrib. So even if there is a module that restores IE8 in core it might not be enough for the average site if contrib modules don't support it.

Personally I'd rather see core take a bigger leap forward, but would be fine with whichever way things go. If a client wants things to work nicely in older browsers as well and doing that in D8 would be too much work then they'd just get their site on D7.

3) @klonos, @quicksketch, others who have been concerned about dropping IE8: are you still against this more narrowly scoped issue?

The new "narrow scope" still results in the same effect. Like others have said No JS + single column = unsupported browser. It sounds like the only thing we're guaranteeing is that it won't spew JS errors all over the place.

I think all the sides have voiced their opinion and the issue summary is adequate. I feel like every-other comment (including this one) starts with "as mentioned before" or "like I said above". I'm happy to defer to the core maintainers at this point.

Issue summary:View changes

Specifying Google *Apps* support, not Google itself.

Issue summary:View changes

adding "move the web forward" points

I added a section to the issue summary called "A work in progress update to Drupal's Browser Requirements documentation". Please correct as needed. This doesn't need to be fully wordsmithed just yet, but I want to make sure it accurately reflects what we're asking Dries to decide on.

As a site builder who works with a lot of Canadian nonprofits who may have older equipment, or whose users may have older computers, I've found that clients are more than happy to use a specific browser if I can also deliver a minimally functional site to anonymous users on IE8. Dropping IE8 support would not be a problem for me or my team.

This one is not easy ... I'm 200% on board for dropping IE8 support for administrative/backend interfaces, but I'm concerned about causing problems for regular visitors. At the same time, I also value maintainability, mobile adoption, and attracting more Javascript developers to Drupal.

Would it be possible to keep IE8 compatibility for JS code that we have that serves visitors rather than administrators? Can we start with replacing Javascript libraries that only affect administrative/backend interfaces (e.g. Overlay, Table drag, Vertical tabs, Toolbar, In-place editing), and hold off touching libraries that are used often by site visitors (e.g. WYSIWYG and States)? There is probably too much gray area to make this an effective strategy.

We can make that work. I'm not sure we'll have time to do any drastic changes anyway, it's all about not getting contrib stuck in the past if they don't want to.

As long as we don't consider the toolbar as part of the visitor side, it's fine. After that it's a case by case what is visitor-land and what's not. Today everything (in JS) works in IE8. A very important question from here is which jQuery version we ship with core? We can make stuff work with he 1.9/2.0 API but we can (realistically) only ship one.

Provided we don't make life hard for contrib (which is possible) I'd say let D8 ship jQuery 2.0 and have the IE8 compatibility in contrib for those who wants it for their visitors and forget about IE8 on the unquestionably admin pages.

Regular IE8 visitors will already see a single column website instead of what was intended to be shown on desktops. If we don't drop IE8 support as a whole, we might get a very confusing situation where some things (JS) are supported and some aren't (CSS).

For the sake of clarity towards both the developer and the end user, we should either support IE8 all the way or drop support altogether. Look at it this way:

  • We drop IE8 support and probably annoy some end users, but those (usually) have the option to switch to a better browser.
  • We keep IE8 support and annoy our front end devs, the kind of devs we have so much trouble attracting to Drupal.

If we want to attract and keep good JS developers, we can't have them still worry about IE8 in 2018.
No sane JS developer will still want to write code for that browser by then.

So some other considerations:

- jQuery 1.9 and 2.0 are API identical. The jQuery team plans to continue this dual-maintenance until they consider IE6/7/8 to be irrelevant. Moving to jQuery 2.0 doesn't provide developers with anything, it just shaves some KB off jquery.js.
- Even if we move to jQuery 2.0 (or subsequent versions before release), we'll still be stuck with that version throughout the core cycle, like we have been with jQuery 1.0.x (Drupal 5), 1.2.x (Drupal 6), and 1.4.x (Drupal 7). jQuery Update will continue to exist to move to newer versions of jQuery.

Most of our JS files have a dependency on jQuery, so upgrading to jQuery 2.0 would result in removing IE8 support from them at the same time, e.g. tabledrag, ajax.js, file uploading, autocomplete, collapsible fieldsets, etc. It would also remove IE8 support from jQuery UI, which would mean things like our dialogs would no longer work in IE8 either. So if we're going to maintain any kind of IE8 support, we have to stick with jQuery 1.x. We could go through the trouble of selectively loading jQuery 2.x for admin pages... but really saving a few KB only on admin pages doesn't compensate for the headache of having two versions of jQuery in the same system.

Anyone still using IE8 at this stage will be quite used to having pages break for them. I do get to a lot of different companies, supporting their computing systems; 99% have access to Chrome or Firefox or both. Really the only ones I see now who aren't running another browser are corporates running narrow-minded softwares that use ActiveX components.

All this to say: bury IE8. Drupal development cannot be held ransom to corporate IT departments that are not clever enough to install an alternative browser.

quicksketch: If jQuery 1.9 and 2.0 are API identical, then would "ship 2.0 and offer a jquery_downgrade module that swaps in 1.9 for those people that care about IE 8" be viable? Or are they not *that* API compatible? :-)

it just shaves some KB off jquery.js.

That's a bandwidth/performance improvement on every browser, multiplied across all requests (that include jquery.js) to all Drupal 8 sites over the next 5-6 years.

We've already committed to upgrading vendor js libraries within major core versions if at all possible, see #1787222: [meta] Strategy for updating vendor JS libraries within a major stable version.

This was explicitly to avoid the situation where core continues to ship with JavaScript libraries that have been EOL for several years as the release gets older.

For example, Drupal.org, right now, is running jquery 1.2.6 - http://drupal.org/misc/jquery.js

The jquery version shipped with 7.x causes webkit to log to console over the place too.

By sticking with jQuery 1.9 we'd be directly penalizing all visitors in other browsers on all Drupal sites. It's not a an IE8 users vs. developers issue, it's an IE8 users vs. everyone else until Drupal 8 support is dropped issue.

Also is it realistic that the jQuery team with support 1.9 past 2015? We know we'll have to support Drupal 8 for at least a year or three past that so that's a good 50% of the release lifetime with an EOL library being served to site visitors.

Note that there is an existing issue to serve jquery 1.9 to ie8 and 2.0 to all other browsers: #1974340: Update to jQuery 2

The jQuery team will continue to support both the jQuery 1.x and 2.x lines simultaneously for as long as those older versions of IE are still a factor. The currently released version of jQuery 1.x, which is 1.9.1, has the same API as jQuery 2.0. We are planning a 1.10 update to the 1.x line in a few months that will address any minor differences in the two versions. At that point we will still keep the two lines in sync: 1.10 and 2.0, 1.11 and 2.1, etc.

If you’d like to try jQuery 2.0 on web sites where you still need to support IE 6, 7, and 8, you can use conditional comments. All browsers except old IE will get the second script and ignore the first:

blog.jquery.com

Emphasis mine. By using the language "still a factor" it sounds like they're unwilling to put an exact date on how long they'll support it. The good news though, is it seems like they'll keep the API in sync until that point.

quicksketch: If jQuery 1.9 and 2.0 are API identical, then would "ship 2.0 and offer a jquery_downgrade module that swaps in 1.9 for those people that care about IE 8" be viable? Or are they not *that* API compatible? :-)

They're *supposed* to be API identical, but they've identified a few inconsistencies which will be fixed in minor version updates (i.e. 1.9.1 and 2.0.1). Actually looks like 1.9.1 is out, so it may have fixed those already.

That's a bandwidth/performance improvement on every browser, multiplied across all requests (that include jquery.js) to all Drupal 8 sites over the next 5-6 years.

Right, but considering it's so distributed, it hardly will make a significant impact on an individual user's experience. jQuery 1.9 compressed and gzip'd is 32.4 KB. 2.0 is 28.8 KB. We're talking about dropping 5-10% users at the time of D8's launch for 6.4KB in savings (either that or engineering a multiple-version selector of jQuery based on browsers). I think WordPress is taking the more sensible route and just sticking with the 1.x version of jQuery for the time being.

We've already committed to upgrading vendor js libraries within major core versions if at all possible, see #1787222: [meta] Strategy for updating vendor JS libraries within a major stable version.

That issue seems non-conclusive at the moment. But in most situations, writing code that is compatible with multiple versions of jQuery (or even jQuery UI) has not been difficult. Most modules today already have to deal with jQuery 1.4.x (the D7 default), 1.5.x, and 1.7.x (the jQuery update versions).

The main advantage of jquery 2.0 over 1.9 is that it requires less client side processing power. Important for mobile.

The main advantage of jquery 2.0 over 1.9 is that it requires less client side processing power. Important for mobile.

Needs citation. As far as I understand jQuery's philosophy, they've always used the latest browser APIs whenever possible and only fallback on shims when not available. e.g. using document.getElementsByClassName() when available.

Mobile is only around 10% and falling. Let's drop that instead.

Seriously though, I don't understand why this is even being discussed at all. IE8 makes up 10 to 20% of all browser-traffic worldwide. How can Drupal not support it? I know the StatCounter and Net Applications numbers differ greatly, but NA has IE8 as the world's most-used browser. IE6 went up YoY even. But OK, let's say IE8 has a 10% share and another browser has 9%, another 8% and one more 6%. Are you then going to stop supporting 33% of the people?

I know you are all developers and you love to move things forward, but the fact remains that IE8 has up to 20% of browser share. I see a lot of guessing, but no-one here can know what kind of users they are, and if they're only in stuffy old companies or somewhere in China or in other countries far away from where you live.

The trend shows that IE8 is falling, but it's not nearly falling fast enough to drop support. People that use IE8 are probably (again, guessing) people that are fine with IE8, and fine with the OS it runs on... If they are on XP they've been on XP for up to 10 years already; it obviously does what it needs to for them. They'll be on XP until their computer actually falls apart and they are forced to buy a new one.

As a developer I know that we are inherently lazy. The reasons I see here are just excuses to not have to put in any more effort. Shave off a couple of zipped kilobytes? That can be done with one less jpg. http://fourkitchens.com/blog/2013/04/24/one-less-jpg Aggregating and compressing CSS files by default in D7 would've also helped a lot.

Without being too patronising, I want to say that when you work on a project, be it unpaid and in your own time, you still carry some responsibility. I think Drupal's responsibility is to be there for everyone. If the state of the web is such that there is a large group of people lagging behind, then that is how it is.

It's an unpopular point to make, but Open Source caters to developers more than it does to customers. We're all developers, but lets first think of the customers.

I think we need to make a distinction between a site visitor and a site administrator - content authors, I think it's fair to ask site administrators to use a compatible browser to do their job, a site visitor - regardless of their browser - should be able to visit the site and "use" it. The "use" is navigating and perhaps filling out some forms, even if it means that the look & feel differs from modern browsers and even if they don't get fancy forms (like states, wysiwyg).

#123 The argument about using one less jpg is only about bandwidth, processing javascript on mobile phones is pretty expensive (extra requests and processing times of at least a couple 100ms), the idea is to have Drupal 8 no longer depend on jQuery so we can save processing time on the client, if we need full support for IE8 we will be forced to load jQuery on every page. Off topic: site developers/builders will need to keep in mind the effect on mobile, for the moment you can make sites unusable on mobile devices when using too much js or custom fonts.

If we force contrib developer to develop against old jQuery versions, we will make their life hard, for Drupal 7 there's already the problem, some module require a certain version of jquery, while others aren't compatible, so people are forced to choose between one or the other (or make them compatible).

PS: Huge companies (> +25000 people) might have a problem with this POV, because they will be using an older browser version (and mostly IE) and they aren't going to upgrade all PC's because somebody needs to use a Drupal site. So yes we might loose them as a customer.

PSS: All percentages and numbers shouldn't be used as arguments, AFAIK there's no one who can predict the future ;-)

@quicksketch what I understood to be the decision in that issue was to upgrade to the latest release of third party libraries in core, while encouraging a 'pinned' contrib module which allows people to downgrade - more or less the exact opposite of jQuery update. The idea being that people starting new Drupal 8 sites in 2-3 years time get to use the latest version of jQuery, while those sites already built that really need to stick with an older one for some reason can install the module. On performance 5.6kb is plenty, what concerns me most is cutting ourselves off from updates to the 2.x series - especially in the period up until about a year after Drupal 9 is released.

@jeroen the companies building sites with Drupal have customers, Drupal core doesn't. Where Drupal core gets used by 'end users' (as opposed to contrib developers or professional site builders) it's really in two places - site building/administration using the admin screens provided by core, and site visitors using a site that's not been heavily customized. For those, if you install Drupal 8 in three years you'd expect decent front end performance (notwithstanding CSS/JS aggregation defaults - it'd be fine to enable those in the standard install profile I think) with up-to-date libraries, not errors like this in the console log which Drupal 7 still spits with today, with absolutely no mechanism to change the version of jQuery it ships with to one with that bug fixed. That's got nothing to do with 'lazy developers' it's about trying to provide an out of the box experience with core that's not buggy and slow. We already give IE8 sites a single-column layout and that was done some months ago, so I'm finding it hard to see why so much excitement now about disabling some js features.

A couple of large companies using our Enterprise social products in Drupal (+10,000 users) are only on IE and will not use anything but IE!

I think we must give importance to site visitors & content authors or creators on IE. The content author's are very important as they bring value to the site and are mostly non technical guys!

The siteadmins can work on specified browsers.

#126 So this mean you want 100% support for IE8, both front-end and back-end, including javascript and css? Or are they using a more recent version of IE? Any ideas what their plans are when XP is EOL?

While there are valid reasons for and against it, if we're arguing on the benefits of saving 4k on a download I think there should be some discussion on #1722422: Use CDN for jQuery.

I'm not saying it has to go in, but I think for the majority of sites, an option in set-up that defaults to using jQuery (whether its 1.x or 2.x) on a CDN would probably increase front end performance more, especially on small/medium sites.

I believe that, in most cases, large businesses that can't afford to upgrade their browsers won't update their CMS either. And Drupal 7 will still be a valid option for the time being. All modern applications are geared toward modern browsers. There are many options for those who can't switch. We're not leaving anyone behind. With D7 we will support IE6 for at least 4-5 years.

Please also note that desktop usage growth will continue to slow down in 2014. In the next year, mobile usage will be projected to outgrow desktop users.

From my understanding, most IE8 users are on desktop. Unless i've been misinformed or missing something :)

comscore-mobile-users-desktop-users-2014.jpg

A very important question from here is which jQuery version we ship with core?

Is that the only question? Or do we also want to remove a jQuery dependency from some libraries entirely? For those, is the idea to use ECMAScript 5 directly? Are any of those libraries ones that are present for site visitor UIs, based on the guidelines of #111?

If the only thing the ie8.module is responsible for is adding jQuery 1.9, that seems like an easy solution for anyone wanting to cater to IE8. If, however, depending on the answers above, it will also need to implement a bunch of other polyfills just to get a site visitor experience to a non-sucky level, then how likely is it that the module will actually work and be sufficiently well maintained for the next year or two?

We already give IE8 sites a single-column layout and that was done some months ago, so I'm finding it hard to see why so much excitement now about disabling some js features.

A multicolumn layout can easily be restored with the Respond.js module. Also, I think the inability to have progressive form disclosure, wysiwyg (for comments), autocomplete, and some other JS features is both a bigger impediment to site visitor retention than a single column layout is, and depending on above, might not have a well maintained contrib option to restore.

#129 You're absolutely right, that's my experience as well.

#131 some remarks/questions

  • I'm in favor of removing as much dependency as possible, we should only use jQuery if it's really needed or if it facilitates the development/maintanance
  • Respond.js only support a subset of media queries, so it will not solve everything
  • How long will ckeditor support IE8, if they drop support in a year, do we lock an old version in D8?

I'm in favor of removing as much dependency as possible, we should only use jQuery if it's really needed

Right. That was my understanding as well. Which is why I want to make sure we don't hand wave this issue into just being about what version of jQuery we ship with.

How long will ckeditor support IE8

Don't know.

if they drop support in a year, do we lock an old version in D8?

My understanding of #1787222: [meta] Strategy for updating vendor JS libraries within a major stable version is that we would continue to ship the old version as part of core's codebase, but also ship the new one, and arrange hook_library_info() in such a way that the new one is what is used, unless there's some module identifying that it requires the old one. catch's interpretation in #125 is slightly different in terms of implementation, but I think similar enough for purposes of this discussion.

FYI: the cost of too much javascript "each additional kilobyte of JavaScript adds about 1ms of parse time to the overall page load time", source https://developers.google.com/speed/docs/best-practices/mobile

#134: ooh, that's a very interesting way to quantify it! You forgot to quote one very important part though: that 1 ms applies only to mobile devices, and then actually only those of the early 2011 era.
That being said, I think it remains a good rule of thumb :)

I still think it's true for more recent devices as well, they just ran their tests in 2011, but it's a good thing to keep in mind

Thanks @attiks for that benchmark, I hadn't heard that before. I agree that I'm not sure it still 100% applies, but it's interesting none-the-less.

The history of iOS JS performance has been a steady increase in speed with each version, with the biggest jump happening in the release of iOS 4.3, with the addition of the "Nitro" JS engine, which sped up JS 2-3x. That came out in March 2011, so it's hard to say if Google's "early 2011" benchmark is before or after this (or if they were using iOS in their benchmarking). Subsequently, iOS6 JS is another 20% faster than iOS5. (As far as my research found, iOS 5 vs. 4.3 didn't have in-browser improvements to JS). Generally speaking, it also seems like iOS and Android phones are increasing speeds at about the same rate, and are nearly equal.

So I think Wim is right that the 1ms per KB should be taken with a grain of salt. Even the *same phone* from 2011 with updated software would likely execute JS quite a bit faster today. Considerable hardware improvements would also reduce that down quite a bit further. However it's definitely interesting that even parsing JS would have a measurable impact at such a small level.

It seems still TRUE.

I tried to load jQuery 2.0, 235KB. (and min version)

Test method:
1. Open URL
2. Reload page
3. wait 2s
4. Reload page.
5. wait 2s
6. Reload....
etc

** Also tested without jQuery. Doc load / render time about 1ms.

Galaxy S3 via USB debugger. Use Chrome 26 Mobile [Webkit 537.31], Andriod 4.1.2

Chrome Timeline: 25x ~ 27x ms
Chrome Timeline (jquery-2.0.0.min): 18x ms
performance.now() / new Date(): 23x ms (first run), 7x ms (hot run)
performance.now() / new Date() (jquery-2.0.0.min): 16x ms (first run), 6x ms (hot run)

** Interesting, Chrome mobile, cool & hot run, very big difference. Cached for about 15 sec only

Native broswer, new Date(): 220 ~ 230ms
Native broswer, new Date() (jquery-2.0.0.min): 143 ~ 153ms
   

Desktop: Window 8, i7-3770K overclocked 4GHz, Chrome 28 Canary

Chrome All test result 20 ~ 21 ms
IE 10 profilling / Firefox 20 new Date(): 20 ~ 21 ms
   

new iPad, Safari

Safari timeline: 97.6 ms
new Date(): 48~ 57 ms
new Date() (jquery-2.0.0.min): 46 ~ 49 ms
   
   
   
   

 

Having thought about this more I'm comfortable removing IE8 support from Drupal 8 core. If IE8 support is important for people, we should recommend them to stay with Drupal 7 for another year or so. I also have hopes that we can build a contributed module that provide IE8 support for Drupal 8.

@Dries, thanks mate that is awesome news and I'm personally convinced this will not be a big issue for anyone who understand the implications - such as that Drupal 7 works just fine for those who need to stay in the past.

Although I don't support this actions, I'm glad to see a clear statement on earlier time. I think Drupal also need a final decision on following issues ASAP
#1666920: [meta] Where/when to use jQuery UI
#1030090: Do we support every browser (version)?
#1446166: Use JS events instead of Drupal.behaviors

Anyone add a change notification ?

----------------------

Don't suppose we can use Drupal 7 all the time. I meet a lot of clients, they don't understand browser compatibility (even if you explained to them in contract / meeting). They will request add browser supports when they see their broken site in old machine.

In business / developer view, I can't let my team to use D8 on all big Drupal development. So sad!!

#141, if that's the case, then you can request extra money to build the contrib module Dries mentioned (to add IE8 support in contrib).

SO happy about this decision.

Status:Needs work» Reviewed & tested by the community

rtbc?

Assigned:Dries» Unassigned
Status:Reviewed & tested by the community» Fixed

#142 or to use another CMS, or to let another company build their websites... Add IE8 support in contrib is not that easy, when all other contrib modules come without IE8 support in mind.

BTW this issue seems fixed since #139. Honestly, if we can't drop IE8 support at some time during D8 lifetime, between supporting IE8 in the next 5 years and not supporting it at all, I'd would go with the latter.

Issue tags:+Needs change record

tagging

A previous change notice about IE8 was created http://drupal.org/node/1722502 not sure if we update this one or create another. Whatever works.

I opened yet another meta #1993322: [Meta] Drop IE8 support and since Dries seems to be willing to keep IE8 support in contrib and I did say https://twitter.com/nod_/status/327340488019562496. Here it is: ie8 module. If we take things one at a time and backport while removing things from core there shouldn't be any major issues for this to work. Educating contrib will be the biggest task after that.

Nice move Théodore, putting your money where your mouth is :)

Title:[policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support)Change notice: [policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support)
Priority:Normal» Critical
Status:Fixed» Active

A previous change notice about IE8 was created http://drupal.org/node/1722502 not sure if we update this one or create another.

I think updating that one would be fine.

Educating contrib will be the biggest task after that.

It would be great for the change notice to contain information, or a link to information, about recommended best practice for core and contrib, to keep ie8.module viable. If we don't know that yet, I guess we can fill in what we do know now, and update it as we learn more.

Change Notification sorted by CREATED time ? Can you also alter the time when you merge them :)

Status:Active» Needs review

Status:Needs review» Fixed

deleted.
looks good.

updating tags.

Title:Change notice: [policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support)[policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support)

and title.

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

Issue summary:View changes

Added a section for updating the Browser Requirements documentation page