greetings

following the #308865: Drop IE6 support in Drupal core, many people are now also advocating to drop support for IE 7, along with IE 6, citing numerous reasons, with the release of Drupal 8, circa 2013. however, it was asked to move the discussion elsewhere, so it ended up getting here for now...

marking the issue from the start as postponed, because as outlined by others, work to remove IE 6 support has to be finished first... and there's plenty of time to revisit this until 2013.

IE7 usage statistics are at http://theie7countdown.com/

Major sites that have already dropped IE7 support:

Google:
September 2011:
http://www.computerworld.com/s/article/9217279/Google_to_dump_support_fo...

Facebook:
Not sure when, but before December 2011:
http://thenextweb.com/facebook/2011/12/30/not-a-fan-of-timeline-on-faceb...

Microsoft:
January 2012
Auto-updating all XP, Vista and Windows 7 to the latest version of IE (IE8 on XP).
http://windowsteamblog.com/ie/b/ie/archive/2011/12/15/ie-to-start-automa...

previously in the discussion:
* #1223640 Posted by midkemia on January 27, 2009 at 8:17pm talks of a 41% market share of IE 7 in 2009
* #4624650 Posted by cosmicdreams is the first post advocating to drop support for IE 7 as well. also mentions a market share of 10% for IE 6 and just 7% for IE 7, down from 41%, as of June 2011. after this, people started talking of dropping or not IE 7
* #4628428 Posted by geerlingguy says "supporting IE7 is easier than IE6, but supporting IE8 is almost as simple as supporting FireFox 3.x... I say we keep the discussion centered on dropping support for IE6 (definitely), and IE7 (most likely, especially considering Dries' timeline for D8 development (1.5-2.5 years from now)"
* #4632526 Posted by cosmicdreams on June 21, 2011 talks of the things we could use if we dropped IE 6, 7 and 8 for Drupal 8
* #4636296 Posted by catch on June 22, 2011 outlines a plan
* #4636420 Posted by voxpelli on June 22, 2011 nice argument in favor of removing IE 7 code
* #4636554 Posted by Jeff Burnz on June 22, 2011 reports the conclusions of the debate: IE 6 goes, IE 7 postponed to do after IE 6
* #4726038 Posted by LPCA on July 12, 2011 some harsh reasoning provided by me, to remove IE 7 too
* #4728264 Posted by seutje on July 13, 2011 gives counter arguments
* #4728390 Posted by dddave on July 13, 2011 asks that IE 7 be made a separate discussion, which resulted in this issue

a bigger discussion log, including IE 6 arguments:
* #1223640 Posted by midkemia on January 27, 2009 at 8:17pm talks of a 41% market share of IE 7 in 2009
* #1830546 Posted by rickvug on July 20, 2009 talks about major sites letting go of IE 6
* #3990330 Posted by momendo on January 23, 2011 talks about Windows upgrade cycles and other things. relevant for IE 7 too
* #3990758 Posted by jensimmons on January 24, 2011 talks of the consequences of dropping IE 6 (relevant for IE 7 too), but...
* #39908722 Posted by rickvug on January 24, 2011 refutes them
* #3991564 Posted by geerlingguy on January 24, 2011 talks about the tradeoff to drop IE 6, which he says is positive
* #3993138 Posted by Pasqualle on January 24, 2011 talks of IE 6 code garbage in Drupal 7
* #3994334 Posted by geerlingguy on January 24, 2011 talks of the work involved themers have to support IE 6. applicable to IE 7 too
* #3996418 Posted by jstoller on January 25, 2011 talks of theme layer vs API. nice argument here
* #4018254 Posted by t_melcher on January 28, 2011 says Drupal 8 should still support IE 6 (and therefore IE 7), because of china
* #4019532 Posted by chx on January 29, 2011 nice counter-argument to the above
* #4154316 Posted by Suzy on March 1, 2011 a very good technical reasoning here, which i am in favor
* #4155042 Posted by jensimmons on March 1, 2011 talks of business decisions and why we should support IE 6 and up
* #4155196 Posted by exlin on March 1, 2011 refutes those with the market share and MS support arguments
* #4155814 Posted by jstoller on March 1, 2011 again the theme layer vs API argument
* #4169338 Posted by jensimmons on March 5, 2011 shows an IE 6 countdown graph

... some more debating meanwhile ...

* #4624650 Posted by cosmicdreams is the first post advocating to drop support for IE 7 as well. also mentions a market share of 10% for IE 6 and just 7% for IE 7, down from 41%, as of June 2011. after this, people started talking of dropping or not IE 7
* #4628428 Posted by geerlingguy says "supporting IE7 is easier than IE6, but supporting IE8 is almost as simple as supporting FireFox 3.x... I say we keep the discussion centered on dropping support for IE6 (definitely), and IE7 (most likely, especially considering Dries' timeline for D8 development (1.5-2.5 years from now)"
* #4632526 Posted by cosmicdreams on June 21, 2011 talks of the things we could use if we dropped IE 6, 7 and 8 for Drupal 8
* #4632558 Posted by cosmicdreams on June 21, 2011 then reminds we can't drop IE 8 just yet
* #4633442 Posted by RobW on June 21, 2011 reminds of the html gargabe we could drop and shorten CSS soup with multiple classes
* #4634108 Posted by aspilicious on June 21, 2011 asks that the IE 6/7 issue be about just IE 6
* #4636296 Posted by catch on June 22, 2011 outlines a plan
* #4636420 Posted by voxpelli on June 22, 2011 nice argument in favor of removing IE 7 code
* #4636554 Posted by Jeff Burnz on June 22, 2011 reports the conclusions of the debate: IE 6 goes, IE 7 postponed to do after IE 6

... things finally get going for IE 6, patches and all, and then debate restarts ...

* #4726038 Posted by LPCA on July 12, 2011 some harsh reasoning provided by me, to remove IE 7 too
* #4728264 Posted by seutje on July 13, 2011 gives counter arguments
* #4728390 Posted by dddave on July 13, 2011 asks that IE 7 be made a separate discussion, which resulted in this issue

that's all i think

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lpalgarvio’s picture

reply for #174 Posted by seutje on July 13, 2011,
regarding #173 Posted by LPCA on July 13, 2011:

the explanation for IE 6 and beyond is quite raw and direct. that is why it is short.

the IE 5.5 explanation was just a prelude/preface to that, that is why it's big. if you read it again, you will notice it's more informal talk than technical arguments or facts.

i couldn't care less if my banks here in Portugal, like BCP, BES, CGD, Banif, etc, still use IE 6 and Windows 2000 / XP in their offices, servers and workstations. it's their problem. and they aren't going to be browsing much anyways, since they have web access very restricted/limited or unavailable even. their computers are mostly if not all for intranet usage only.

IMO, when market share drops bellow 10%, with signs that say it will keep dropping until it's close to nothing, then it's time to move. you don't want to bet on a dead or sick horse for a race.
that's the case of IE 7 with just 7% share:
http://theie7countdown.com/
in 2 years from now will be close to nothing.

regarding the IE 6 <-> IE 7 differences, i've consulted this one and other similar studies in the past. my conclusions are the same, after re-reading them over and over.

for the most part, they added support for these in IE 7:
>, +, ~, attr, :hover, min/max-width/height, outline, overflow, text-overflow, position (partial), fixed multiple classes bug, PNG transparency
(didn't include all the things they only added partially)

i bet people praise that the PNG problem was finally fixed... when i started playing with PNGs years ago, i hated that problem.
also nice they added > selector, but i won't use it because IE 6 does not support it, so i don't want to duplicate CSS code.
and min/max height and width, really nice. unfortunately though, i still have to first try fix with height and width, before using that, because IE 6 is still biting me.

it's an improvement, for sure, and with IE 6 gone, it will be easier for everyone. maybe then i can use the things mentioned above.
but they left outside many CSS 2.1 selectors and declarations... and for many, at least 9 of them, it's still incomplete.
and what about the incomplete CSS3 selectors? like background-repeat and background-size? borders? rounded corners missing? correct gradients?

not to mention different behaviors, which are not more not less, than noncompliance with standards.

lpalgarvio’s picture

http://theie6countdown.com/ -> very plausible
http://theie7countdown.com/ -> plausible
http://theie8countdown.com/ -> little unrealistic for now
http://theie9countdown.com/ -> unrealistic
http://theie10countdown.com/ -> a funny dream

geerlingguy’s picture

I, for one, vote for ditching IE7 in D8 core. According to Dries' D8 timeline, we won't be seeing a release until sometime in 2013 (most likely). By that time, IE7 will likely be hovering (and remaining) around 4-5% worldwide market share.

Heck, for a few of my sites, there are already more IE6 visitors than IE7... but if we're definitely dropping support for IE6 (see: #308865: Drop IE6 support in Drupal core), why not save ourselves half the hassle and also drop IE6? IE8, as far as JS and layout go, is simple to work with compared to 6/7.

Clean’s picture

We could considered the rise of mobile browsing and declined pc/laptop sales that will accelerated the end of IE7 within Dries' D8 Timeline. There're many news about projection from many specialist firms, I remembered I read it somewhere on techcrunch.com , cnn.com etc. We can get exact market prediction for sources.

This factor is play an important role in consumer side, IE7 quite irrelevent on mobile/tablet side already. US consumer spend more and more time browsing on those small screen devices, less and less on laptop/pc, but still no other demographic data but seem like things are going that way. So, the time Drupal 8 out, it's look like there's not much problem in consumer segment to drop IE7.

But the key factor is a lot Drupal users are organization. And it's an organization segment that is not clear and need informations as some comment stated. How could we have data on this side?

And Drupal 8 timing seem relevent to Windows 8 launch, which will shipped with IE10. That's 3 version ahead IE7 out of the box.

Also, at the moment Windows 7 shipped with 500 millions PC, and 650 millions total sales already. I'm quite sure that I it hard to see IE7 on Windows 7.

lpalgarvio’s picture

IE 8 is included with Windows 7 RTM.
Windows Vista has IE 8 as automatic update i think.

IE 9 is a manual update for both.

Vista and Service Pack 2:

Service Pack 2

Service Pack 2 for Windows Vista was released to manufacturing on April 28, 2009,[80] and released to Microsoft Download Center and Windows Update on May 26, 2009.[81] In addition to a number of security and other fixes, a number of new features have been added. However, it did not include Internet Explorer 8:[82][83]

webchick’s picture

Wow. And the award for most comprehensive issue summary EVER goes to... LPCA!

webchick’s picture

Another data point in favour: as of August 1, Google dropped support for IE 7: http://googleenterprise.blogspot.com/2011/06/our-plans-to-support-modern...

gkatsanos’s picture

I saw you were asking for Organization statistics. In the European Commission the standard is IE7, with some small percentage of users having IE8 (often running in compatibility mode! - so basically IE7). Some Designers/Developers have FF, but that's no more than a small percentage of the users.

Sad.. but true:/

lpalgarvio’s picture

i've recently noticed that many offices of MillenniumBCP (one of the biggest banks in Portugal) has been changing their hardware and software... they are now running Windows Vista and 7, with IE 7 minimum. previously they had Windows NT4/2000/XP with IE 5/6.

either way, MillenniumBCP doesn't uses Drupal or other software, only their own, nor has direct access to internet in their offices - like with most banks and other special entities.

state offices have been changing to more recent software and operating systems too.

but i don't think this is a road block for Drupal and IE 7 deprecation - they don't upgrade because they are basically stubborn or don't want to spend money. evolution eventually comes anyways.

catch’s picture

Priority: Minor » Normal
Status: Postponed » Active

IE6 is out. There's going to be cleanup post that but it's worth discussing IE7 in its own right now.

Devin Carlson’s picture

Per catch's recommendation in #308865: Drop IE6 support in Drupal core; reposting some information about the deployment of new versions of Internet Explorer in Canada and support for why IE7 support might also be dropped.

The plan, which is currently in progress, for the public sector in Ontario, Canada is to go from XP + IE6 to Windows 7 + IE8. The Ontario Public Sector is one of Canada's largest sources of IE6 traffic.

New systems are currently being shipping with W7 + IE8 where appropriate (when there are no backward comparability problems) and by 2014 all computer systems will be deployed with Windows 7 + IE8.

I think you'll find that many large organizations are moving directly to IE8 from IE6/IE7 and not from IE6 to IE7 as there is little reason not to already deploy IE8 if you are using IE7 (as there aren't many enterprise applications that specifically require IE7 and do not work on IE6/IE8).

droplet’s picture

On some of Google service, they may discontinue to support the browsers but still able to visit the site (layout aren't broken). But Drupal is going to Kill the totally supports. It's a bit different I think. (Even in D7, it's error on some page.)

Anyway, I was argue don't drop IE6. but now Drupal dropped IE6. It's time to drop IE7 in "DRUPAL 8" too. IE shipping with Windows Vista and has lower usage than IE6.

jstoller’s picture

Based on the data presented so far, I see no compelling reason not to drop IE 7 support in D8. There seems to be a trivial downside and a potentially significant upside, so I say lets do it.

cosmicdreams’s picture

Caniuse.com provides a very nice visual way to see what we would gain if we didn't focus on supporting IE7. We could depend on these features:
http://caniuse.com/#compare=y&b1=ie+7&b2=ie+8

My personal favorite is display: inline-block.

seutje’s picture

sup

j0rd’s picture

Im fine with dropping ie6 but dropping ie7 might be a little harsh.

What i would be fine with is dropping ie7 with some kind of compatibility layer added specifically for ie7. sites dont have to look as good, but certainly need to work.

If that requires some ie7 specific js or css then so be it. Its really not that hard to support browsers.

cweagans’s picture

To be clear: Dropping IE7 support in core doesn't mean that themes can't support IE. It just means that core developers won't go out of their way to support IE7 at admin/*. I am completely fine with this plan. +1 from me.

DjebbZ’s picture

Statistics. Per StatCounter Global Stats, w3schools IE stats and AT Institute (in French, study about Europe only), IE 7 has a really small market share, less than 6-7% in each continent, and going down. AT Institute shows 9%, but still going down. Other stats : mobile browsing ? StatCounter has interesting stats, but we know them : mobile browsers are mainly webkit-based, so no IE around. Windows 7 ? AT Institute shows that it's the second most installed OS in Europe, and there's no IE7 on it, mainly IE8, Firefox and Chrome. Even with XP (the most installed OS in Europe), some people have upgraded to IE8, or a better browser.

Conclusion : the IEx family is going down, the old versions IE6 and IE7 are simply disappearing. People are using more and more A-standards browsers on desktop, and definitely on mobile (iOS and Android). The world is almost ready to drop IE7. By the time Drupal 8 is out, should we really continue to support IE7 for several years ? No. Should we kick it off the game, pushing for a better web through standards and better browsers ? Yes.

catch’s picture

It's pretty likely the stats are going to look good in a couple of years (they don't look too bad now).

Two things I'd like to see here:

1. How much IE6 crap do we have left? It's my understanding it's things like CSS selectors and redundant markup, does that all have open issues?

2. Is there a way to identify all the IE7 code in core once that's left.

Grep says:


includes/common.inc: *   the next STYLE tag. Furthermore, IE7 does not support media declaration on
includes/common.inc:              // browser-caching. IE7 does not support a media type on the
misc/tableheader.js:      // Exception for IE7.
misc/vertical-tabs.css:  position: relative; /* IE7 */
misc/vertical-tabs.css:  list-style-image: none; /* IE7 */
misc/vertical-tabs.css:  min-width: 0; /* IE7 */
modules/overlay/overlay-parent.js:  // IE7 isn't reflowing the document immediately.
modules/overlay/overlay-parent.js:  // and IE7, so in those browsers, the underlying page will still be reachable
modules/overlay/overlay-parent.js:  // Manipulating tabindexes is unacceptably slow in IE6 and IE7. In those
modules/system/system.base.css:  clip: rect(1px 1px 1px 1px); /* IE7 */
modules/system/system.base.css:/* IE7 */
themes/garland/style-rtl.css:/* Fix Opera, IE6 and IE7 header width */
themes/garland/style-rtl.css: * Fixes for IE7 - Does not break other browsers
themes/garland/style-rtl.css:/* Position:relative on these breaks IE7. */
themes/garland/style-rtl.css: * Apply hasLayout to elements in IE7, using standard property "min-height"
themes/seven/template.php:  // Add conditional CSS for IE7 and below.
themes/seven/ie.css:/* IE7 renders legends in nested fieldsets without a width. */
themes/seven/reset.css:/* IE7 */
j0rd’s picture

Status: Closed (fixed) » Active

@cweagans . I mostly work on eCommerce sites and have some big and successful installs which use eCommerce marketplace installs. This means that my "users" end up in "admin/*". So for me, it's kind of important to make sure things at least work.

What are the benefits of IE8 that we don't get from IE7? I know everyone hates IE (including me), but really, IE7 and IE8 are not that much different. The CSS3/HTML5 benefits don't come until IE9, which requires vista or higher. So if you drop both IE7 and IE8, you're essentially dropping WinXP support. jQuery gives us decent JS support cross browser, unless you write lazy jQuery, which isn't a good idea anyways. I always find that debugging my sites after their done with IE browsers allows me to catch some bugs I wrote from being lazy. I know this translates to better support among all browsers as well.

I don't think it's that much more work to support IE7 if we're going to support IE8. Otherwise change this discussion into dropping them both. So long as you follow standard design heuristics, you get decent support in IE7 and IE8.

With that said, I think the analytic tech people in here might be using are skewed since you're all in the tech community and have these users are your user base. aka "Oh my drupal blog only has 0.00002% of users using IE7". You really need to think about the internet as a whole and think about who generates cash on your websites (ad clicks, online purchases). I think if you thought in these metrics instead of thinking of "number of people" it might change the debate.

Case study:

My latest website is an eCommerce store which sells Christian books. The only metric which counts on my website is revenue. IE7 has more sales than all versions of Safari or all versions of Chrome by roughly double. IE7 has 1/2 of all sales of all combined versions of Mozilla. IE7 has over 10% of all sales on my website. IE7 has the highest conversion rate of all browsers. So for my website, it would make more economic sense to drop Safari and Chrome support over IE7.

This is because users who are too lazy to update their browser, are also the users who are too lazy to find a torrent for something and pay for it. This is the market, I need to cater to. These users also touch a lot of core javascript. And if core drops support, then contrib will as well.....and then I'm left supporting all my IE7 cash cows myself.

--
I can't predict the future, but I know IE7 will slowly lose ground. I just don't know if dropping support for IE7 is that much additional work if we're going to support IE8. And I still support IE6 on my sites depending on the audience, because if I don't, my sites lose money.

I'd be fine with not worrying about IE7 until Drupal 8 is almost done, then spending a couple weeks resolving IE7 issues, so the backend is usable. It should help catch issues anyways. This is usually what I do anyways when developing.

j0rd’s picture

Issue summary: View changes

Updated issue summary.

JurriaanRoelofs’s picture

Right now I would say no. For most website it would be fine to drop ie7, hell for sooperthemes.com ie7 usage is 0.7%. But think of websites that provice business to business services in 'slow' industries. I've heard one example where ie7 was about 15% of the traffic, but accounted for 90% of the website's revenues because ie7 was still the standard for businesses in their particular industry.

But if Drupal 8 comes out in 2013, or 2014, maybe the time is right and ie7 will be obsolete because of all the new technologies that our moving into our homes and handhelds. Maybe it's too early to decide.

bleen’s picture

I just wrote a comment nearly identical (frighteningly similar actually) to #17 ... I agree with cweagans

+1 for removing IE7 support from core.

catch’s picture

But think of websites that provice business to business services in 'slow' industries.

I think they can expend the time and effort on providing IE7 support to their customers rather than Drupal core contributors, or they can stick with Drupal 7 a bit longer - since that will be supported for quite a while after Drupal 8 comes out.

lnunesbr’s picture

subscribe

droplet’s picture

I think they can expend the time and effort on providing IE7 support to their customers rather than Drupal core contributors

wow?? so why not drop IE8/9 supports?

things like CSS selectors and redundant markup

Redundant markup, with supporting IE "6", we can remove many "redundant" markup. I don't think it's a problem of IE.

geerlingguy’s picture

Most sites I'm running right now have a smaller share of IE7 users than IE6. Both are well under 10%, even for a few church and nonprofit sites that cater almost exclusively to an older audience. I was surprised to find that more people are on 6 than 7, but I don't go out of my way to support either anymore. If someone reports problems with IE 7, I simply ask them to upgrade to IE8; nobody's complained about that yet.

catch’s picture

wow??

There are lots of features I don't think Drupal core should support because they only cater to particular business cases rather than being generically useful, nothing stops people trying to support those in contrib.

so why not drop IE8/9 supports?

Because browser support is more or less effort vs. usage.

I am not really working on browser support at all any more, but it's my understanding that IE8/IE9 take very little if any effort to support over most other modern browsers. http://www.quirksmode.org/css/contents.html for example looks not terrible. IE8 certainly comes out a lot better than IE7 does even if it's lagging behind some of the others.

lpalgarvio’s picture

people need to think a little bit more out of the box... look to the future

just think about,
- how long does a sucky laptop last? 3-5 years
- how long does a sucky desktop computer last? 4-6 years

people upgrade, buy new computers, trash the older ones, all the time.
in Portugal there's this bad habit of replacing cell phones and laptops every 1-3 years.

IE7 was released in 2006 along with Windows Vista. Vista sales were deprecated in 2010.
2013 and 2014 is 2-3 years from now.
upgrades to D8 won't happen from day to night. and it isn't mandatory either...

rafamd’s picture

Sure, I say drop it. And to convince the skeptics, don't only consider what is lost but what will be gained, happier devs, more time for more important features, etc. I see it as a positive trade off.

sepeck’s picture

The IE7 usage link is deceptive. It is not an IE7 usage statistics page, it is an anti-ie advocacy page. This is not the same thing as a data driven statistics argument. If you have to deceive others to justify your arguments, then your position should be ignored.

The site adds to the deception as the theie6countdown.com is hosted by Microsoft and this is obviously hosted by some anti-Microsoft fanatic as are the ie8/9 sites which are essentially template versions of the same thing. We shouldn't link to or use such deceptions to decide on a course of action and people who do this kind of thing should be ignored as a matter of course. There are plenty of data driven reasons to not worry about supporting ie7, this link on the justification is not one of them and it should be removed for the false, deceptive advocacy site that it is.

IE9 is a modern browser supporting modern standards yet curiously absent on any of those sites other then having it's own dedicated site repeating the same copy/paste template of an anti-ms crusader who fails to tell the truth.

j0rd’s picture

@catch in relation to http://www.quirksmode.org/css/contents.html on IE7 and IE8. You pretty much prove my point. IE8 gives you nothing (box-sizing?) that IE7 doesn't have. Essentially they are the same browser.

None of these fancy CSS selectors are very useful either and with Drupal outputting proper CSS (like class="row-1 first") you never really need them. Nor should you ever use them.

If you want to be bold, drop support for IE7 and IE8 and then we could use CSS3 and HTML5, since all browsers we would support would use these standard. But dropping IE7 is an axe for the sake of an axe and in my opinion won't do much good. If you support IE8, IE7 will most likely work.

If you slipstream user submitted patches quickly to enable support, I'm fine with this. Let the end users worry about it, but dedicate some resources to allow for patches to get into core in a reasonable amount of time.

--
I'd rather have resources into making Drupal work better on mobile handsets, since this kind of traffic will out pace IE7 in 2 years.

sepeck’s picture

On the specific issue of the IE7 life cycle. IE7 is regarded as a component of the operating system Windows Vista. As a component Microsoft is committed to providing some level of support for a published amount of time.
http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha...

Windows Vista was released 1/25/2007 with a mainstream support end date of 4/10/2012.
As of 4/13/2010 no new serivce packs will be released.
Windows Vista Service Pack 1 was released 2/4/2008 with a SP support end date of 7/12/2011.
Windows Vista Service Pack 2 was released 4/29/2009 with a note indicating end of support after 24 months or which end of product support life, which ever comes first.

That said, at this point in the USA, IE7 will no longer be supported by Microsoft after 4/10/2012. (It may have a slightly different support cycle by Microsoft in other countries to comply with local laws but I am not looking). Therefore, if Drupal 8 is not expected to be released until after April 10, 2012 it seems that IE7 will no longer be supported by Microsoft at that time.

On that basis (vendor no longer supporting product and providing 2 current (ie8/9) and a next release version in the works (ie10)) it would seem to be prudent to no longer support IE7 in Drupal 8 core.

Devin Carlson’s picture

@j0rd You're absolutely right about IE8 not provide many additional CSS features over IE7. However, my main problem with supporting IE7 isn't the the browser's feature set so much as the increased developer time required to support it.

For every additional CSS tweak, a review of its interaction with IE7 is needed. I find most developers run up-to-date Windows/Mac/Linux systems, so for every Drupal core patch that touches page layout, a developer will have to fire up an old Windows XP/Vista system or virtual machine or testing application, review the page layout and take screen shots of what it looks like in IE7 instead of working towards solving other issues.

To be honest, since (as you said) IE7 does render content very similarly to IE8, even if official support for IE7 is dropped, Drupal core should still be completely usable with IE7.

Also, don't forget that IE8 has much better JavaScript performance than IE 7.

sepeck’s picture

While a minor point someone else mentioned mobile browsers. Currently the Windows Phone 7 is based on subset of ie6. This will be gone when the next update 7.5 is released (soon) and the mobile ie version will be ie9 across all Windows Phones OSes and handles html5 quite nicely.

cweagans’s picture

@jord:

But dropping IE7 is an axe for the sake of an axe and in my opinion won't do much good. If you support IE8, IE7 will most likely work.

...

I'd rather have resources into making Drupal work better on mobile handsets, since this kind of traffic will out pace IE7 in 2 years.

These two statements are contradictory. We will likely continue to support IE8, so IE7 will most likely work. If we drop support for it, we're not going out of our way to make sure it doesn't work - we just don't really much care. Since IE8 will continue to be supported, IE7 will most likely continue to work.

If we have resources spent on making sure IE7 works, there will be less resources available to make sure mobile browsers work 100%.

j0rd’s picture

My worry is though, is that if IE7 support is dropped and I find bugs in IE7 and submit patches, I'll get this response.

"We don't support IE7" -> closed.

Same will end up happening in contrib, as it will follow cores lead.

It would be nice to put out a statement like "You don't have to support IE7 during the development cycle, but please integrate patches in a timely manor"

---

So long as this doesn't happen I'm completely fine with having core developers ignore IE7 during the development cycle and allowing others to submit patches to resolve the issues.

cweagans’s picture

Drupal 8 won't be released for 2-3 years. We will not care about IE7 at that time. I like #36 for Drupal 7, though.

iflista’s picture

Internet Explorer 6 was released in 2001. It took 10 years to drop support of this browser. Internet Explorer 7 was released in 2006. So logically it can be dropped in 2016, but internet was changed alot in last few years after social networks appeared and new Html5 markup. So I think this time have to be divided by 2. And the support of IE7 has to be dropped in 2013. And this is the date of Drupal 8 release. So there is no reason to include support for IE7 in D8.

stovak’s picture

Drop it like its hot.

catch’s picture

We could do this in steps for Drupal 8 as well.

Pretty much immediately remove IE7 from browsers that must be tested for CSS and JavaScript changes.

For now, leave IE7 hacks in CSS and JavaScript in (but consider trying to move those out to conditional stylesheets so they're easier to dump later?).

Later on, if we want to actively drop IE7 support, we could make a separate decision around that.

j0rd’s picture

It's a good idea to move them into conditional stylesheets just for logical seperation.

Additionally I would stress the importance of conveying this to the contrib world via wording.

Instead of saying "Dropped support for IE7" I would say "Core is not developing or testing support for IE7, patches welcome". This is certainly something that can be easily offloaded to the rest of the community as it doesn't require much skill and if it's conditional fixes in a separate stylesheet, it shouldn't effect much else than IE7.

It might also be a good idea to create some kind of proper CSS aggregation to merge all IE7 specific CSS into a single stylesheet, otherwise there's a large end user performance issue. Ala drupal_add_css() aggregation keys or something. This could prove useful to the end developer for other use cases as well.

jstoller’s picture

Lets assume we were to completely drop support for IE7—not just depreciate support—and take full advantage of whatever CSS/JS advances exist in IE8+. In that case, would it still be possible for a theme's author to support IE7, without requiring any Herculean feats, or resorting to hackish means?

If the answer is yes, then I see no reason to include any IE7 specific code in D8. Let individual theme authors decide if they want to support it. Core should have no more code in it than is required to enable these theme authors to do so.

That said, the idea of moving IE7 fixes to conditional stylesheets should really be applied to all browser specific fixes. Including the current versions. That will make things easier in the future as browser versions come and go. And as @j0rd points out, providing a standard method of doing this could help contrib developers as well.

cosmicdreams’s picture

@j0rd: For the answer of what we will gain if we dropped our efforts to support IE7 (but not IE8) please reference the link I previously posted here : http://caniuse.com/#compare=y&b1=ie+7&b2=ie+8

In short there are a few, but possibly very important new tools we get to use as developers. My personal favorites include:
1. the use of display: inline-block
2. Better JSON parsing
3. WAI-ARIA Accessibility features
4. CSS Table display
5. Data URLs

So, the refocusing our efforts to implement Drupal without concern for IE7 compatibility will yield benefits in simplicity of code and performance even if we don't include ignoring IE8's existence.

Many points have been made that in 3 years we will still likely need to support holdout WinXP based browsers and I think they still hold weight. Whether or not that will be the case in a few years is a discussion for another time, IMO. For now I'd be content with dropping this entire discussion. I think that new work needs to give priority for the latest browser first and support for legacy browsers be added later.

That said, I'm sure MS would very much appreciate if we helped them depreciate their older browsers. IE 10 (and maybe 11) will be out by the time Drupal 8 launches. I'm hopeful that multi-browser support issues will be few by the time that hapens.

jstoller’s picture

I agree that we will still need to support Windows XP when D8 launches, but doesn't IE8 support handle that? All of my Windows XP installs were updated to IE8. Is there something preventing IE8 installation on XP that I am not aware of? Or are we just concerned about people who never run updates on their computer and corporate workers who are forced to standardize on IE7?

seutje’s picture

don't forget generated content and box-sizing

also, various padding/margin quirks, position:relative weirdness and so on

j0rd’s picture

@cosmicdreams There's not much in that list which actually gets used in web design. Most people have learned to live with out them, due to browser support issues, thus they are not commonly used.

inline-block is pretty handy though, but there are ways to design around this. Hashchange event is also becoming pretty commonly used in ajax'y sites. Overlay must deal with this some how already (or just not deal with it at all).

Data URLs would most likely not be used in core. This is mostly for speed freaks if I'm not mistaken.

CSS Table Display, there's other ways around this and is pretty hacky itself. Useful for vertical-align, which people try and avoid in design and can be accomplished with line-height or margin-top: -50% type stuff. CSS Grid layouts are the more common way of duplicating tables.

JSON parsing, don't add commas on the last elements, which most people know not to do. I get caught on this myself fairly often, but I consider it lazy JS on my part. Not sure if this has other benefits aside from speed. If people wanted speed in their browser, they wouldn't be using IE7.

I can't comment on the WAI-ARIA Accessibility as while I make my sites as accessible as I can, my budgets don't really factor this extra work cost in.

My point is, you don't gain much from dropping IE7 with out dropping IE8. If core doesn't want to handle it, let other submit patches to resolve the issues. Don't get contrib believing they don't need to support IE7, because core isn't. Also a bad idea to get large enterprises believing that Drupal 8 doesn't support IE7, as they might choose other options because of this limitation.

My support for this mostly comes down to how Drupal relates this to the community now. Proper wordsmithing and procedures for accepting patches is required. Let core devs ignore it and pick up some rookie core devs or contrib space people to fix the minor issues. This probably wouldn't happen until D8 is almost released and common folk start using it.

cosmicdreams’s picture

@j0rd, it sounds that we disagree on the point that we should eliminate support for IE7 and continue support for IE8 but agree on the point of how we should proceed in developing Drupal 8. That we should basically ignore support for IE7 and focus work (in most cases) on the latest browser support first.

That's cool with me.

In fact I think we should postpone this issue until we've made more progress on the HTML5 and CSS refactoring initiatives. Unless there are concrete examples of bugs or issues that are caused by supporting IE7 to discuss.

seutje’s picture

there are ways to design around this

WAT??? o.O
Do you honestly want to tell a designer to limit himself due to a quirk in a browser that will probably only catch ~5% of traffic?
note that this includes explaining how & why it occurs and how to avoid the need for it... good luck!

Useful for vertical-align, which people try and avoid in design and can be accomplished with line-height or margin-top: -50% type stuff.

really? that's the only use-case for the display: table; family? how about displaying non-tabular data in a tabular fashion? and people definitely don't avoid it in design, just look at the popularity of various equalHeights jQuery plugins...
using line-height for it would destroy flexibility, just imagine it wrapping over 2 lines
negative top margin of 50% doesn't take in account the height of the actual element, so it'll never be in the middle, unless if it's 0 pixels in height
And grid layouts don't even try to replicate table layout behavior, floats were never really meant for what they are being used today, and this is easily visible in all the extra stuff grid systems add to make it not collapse on itself

don't add commas on the last elements

not entirely sure how this is related to JSON parsing in specific o.O
IE7 doesn't even have a native JSON object, which essentially means you need to load a library for it, or use some sort of "safe eval" (which is what jQuery's parseJSON does when there's no native JSON object)

Who do you think has to maintain the code from those patches once they go in?
Not the people who submitted them, I'll tell you that!

cosmicdreams’s picture

@seutje, I think the discussion about whether or not to drop IE7 support in core Drupal css is becoming a bikeshed argument. Perhaps the best way forward is to:

1. Ignore support for IE7
2. Focus front-end development toward browser feature-sets, not to the browsers themselves
3. Postpone actual removal of IE7 supporting CSS and JS until it becomes a hurdle that we need to overcome.

Unless I hear opposition to the idea of mark this issue postponed, I'll mark it as that tomorrow.

catch’s picture

Title: Drop IE7 support in Drupal core » Make IE7 support optional and document required/optional/not supported browsers

Do we already have a page somewhere with which browsers core supports and at what level in terms of front end testing?

If not, since we already dropped IE6 could we add one?

If so we can have required/optional/not supported in terms of what needs to be tested for front end patches on there.

That's allow it to be clearly differentiated whether something needs testing, or whether fixes will be accepted (i.e. people posting IE6 fixes are going to be told no now).

I'd be very happy to not require IE7 testing for patches from now (although that's something Dries will need to sign off on since he did not want to immediately drop IE7 support in the IE6 issue), but as important is that there's a way to find out what is and isn't required for patches.

cweagans’s picture

I really disagree with changing the scope of this issue. IE6 became the nuisance that it was because everyone insisted on supporting a 10 year old browser. Then, when they wanted to stop supporting it, their users got upset.

j0rd, I know IE7 support is important to you now, but do you really think that will be the case in 2-3 years? I'd be really sad if that was the case.

We should be the ones advocating for dropping support for legacy browsers on principle, even if there are decent technical reasons behind it. IE7 came out in 2006. By the time Drupal 8 is released, the browser will be 7-9 years old. Let's not make the same mistake that we made with IE6. That is, let's kill this beast where it stands so we don't have to drag it along anymore. It's really just going to be dead weight by the time we release D8.

And dropping support for IE7 now would likely make the HTML5 initiative pretty happy.

I'd really like to see us adopt a policy of "We support the most recent 2-3 versions of any given browser".

jstoller’s picture

Title: Make IE7 support optional and document required/optional/not supported browsers » Drop IE7 support in Drupal core

I'm with @cweagans. I still think dropping IE7 is ultimately the way to go and I've heard significant support for that. At the very least, it is still a relevant issue to discuss. If consensus is that we should postpone this issue and make support optional for the time being, then so be it, but I don't want to see the issue get muddled, or go away.

To me the way forward is:

  1. Implement a system for separating out all browser-specific code into conditional files. This will not only help with the removal of IE7, but with the eventual removal of other browser support as well.
  2. Ignore IE7 and target IE8+ support, at least for the time being. If the ultimate decision is to include IE7 support, then we can test and patch later.
  3. Document the official state of browser support, with links to issues such as this where things are in flux.
jrabeemer’s picture

Action items:

- Look at Catch's #19 post and compare/contrast in IE7 and IE8 and remove bits piece by piece.

- Look at GIT/CVS commit history for "IE7" / "Internet Explorer 7" references for additional hints and bits to remove

- Anything in Form API to look at?

- Get a preliminary patch going

cosmicdreams’s picture

There are a few references to IE7 that remain. This should serve as a good starting point:


grep -rn "IE7" *
includes/common.inc:3157: *   the next STYLE tag. Furthermore, IE7 does not support media declaration on
includes/common.inc:3285:              // browser-caching. IE7 does not support a media type on the
misc/tableheader.js:101:      // Exception for IE7.
misc/vertical-tabs.css:5:  position: relative; /* IE7 */
misc/vertical-tabs.css:10:  list-style-image: none; /* IE7 */
misc/vertical-tabs.css:32:  min-width: 0; /* IE7 */
modules/overlay/overlay-parent.js:425:  // IE7 isn't reflowing the document immediately.
modules/overlay/overlay-parent.js:877:  // and IE7, so in those browsers, the underlying page will still be reachable
modules/overlay/overlay-parent.js:923:  // Manipulating tabindexes is unacceptably slow in IE6 and IE7. In those
modules/system/system.base.css:230:  clip: rect(1px 1px 1px 1px); /* IE7 */
themes/seven/ie.css:2:/* IE7 renders legends in nested fieldsets without a width. */
themes/seven/reset.css:208:/* IE7 */
themes/seven/template.php:21:  // Add conditional CSS for IE7 and below.

at the very least we should use the patch from #865536: drupal_add_js() is missing the 'browsers' option to properly target IE7 specific modifications to only effect that browser.

mortendk’s picture

if were looking 1.5 year ahead for a d8 release & we know that loads of websites wont upgrade right away - even be build before almost another year has passed, and all of contrib are up to speed with the d8 platofmr - So were looking at winter 2013 right ?

Taking this step now (instad of waiting a year) would make the work were doing now in the theme layer hell of a lot easier, else we have to use months of work in a year to through the themes & css files again. - unless we wanna be trapped forever in clearfix methodes & polyfills hell ?

With the jump towards the mobile platforms this is a really good spot to draw a line in the sand and skip ie6 retarded cousin ie7 once & for all.

The numbers from theieXcountdowns - are totally off for what we have here in DK now its a 15% ie7 users, with a fall of about 1% a month (http://www.fdim.dk/Statistik/teknik/browserbarometer#simple=true;list=br...)
So lets not make the decission based on a site thats clearly just a we all hate ie fanpage.

But unless my math is totally of then were down on around 3% in about a year (and dk is a extreme microsoft loving country)

cweagans’s picture

draw a line in the sand and skip ie6 retarded cousin ie7 once & for all

I'm less in favor of drawing a line in the sand and more in favor of planting a landmine.

Seriously, we really need to not waste time with legacy platforms. If organizations need to keep IE7 support, they can stay on Drupal 7. If they want the latest and greatest stuff, then they shouldn't be using IE anyway.

MrMaksimize’s picture

I definitely agree with @cweagans and @mortendk, ie7 should not be supported by d8. It would handicap us and for no real good reason.

cosmicdreams’s picture

Good then I wouldn't have to continue to work on #404302: Improve tabledrag grippie CSS (and fix an IE7 alignment issue)

cweagans’s picture

That you wouldn't, and I suspect there are many other timesink issues that are blocking people from doing real work, like detangling core.

mortendk’s picture

If we came to a conclusion to have like a bolt on module for IE7 fixes, I could probably be talked into it (with a couple of other sad souls)

mortendk’s picture

just to add to the argument list yet another service drop support for ie7
http://www.getharvest.com/blog/2011/11/harvest-ending-support-for-intern...

cweagans’s picture

bleen’s picture

I made a similar argument here #1296128: Replace autocomplete with jQuery TokenInput ... though I think "Chosen" is an even better UX

mortendk’s picture

Heres a suggestion to get this moving.

All issues about ie7 dosn't belong in core.
They belong in a theme, for core this will all be done for bartik, and only bartik in one file -> ie7.css

This will make us able to move forward with core development & still make ie7 "working" outta the box.

Lets not bikeshed the "who why when" blah bla about ie7 & see how we can move forward.

Jacine’s picture

Article posted today has IE7 share @ 4.26% worldwide, and still dropping: http://www.sitepoint.com/browser-trends-december-2011/

Is anyone working on a patch here? We'll need one of those to give people an idea of what dropping IE7 support means, and to eventually mark RTBC, or this will go nowhere. We're probably better off putting effort into that as opposed to waiting until we get 300+ comments. ;)

droplet’s picture

Status: Active » Needs review
FileSize
6.96 KB

first patch

droplet’s picture

FileSize
9.28 KB

more

Status: Needs review » Needs work

The last submitted patch, remove_ie7.patch, failed testing.

droplet’s picture

droplet’s picture

Status: Needs work » Needs review
FileSize
7.91 KB
droplet’s picture

FileSize
8.58 KB

remove IE7.css

catch’s picture

Microsoft is going to start auto-upgrading IE, which will force a lot more people off IE7:

http://windowsteamblog.com/ie/b/ie/archive/2011/12/15/ie-to-start-automa...

via
http://morten.dk/blog/time-ie7-tax

catch’s picture

Issue summary: View changes

Updated issue summary.

catch’s picture

Assigned: Unassigned » Dries

The last time Dries commented on IE7 support was here: http://drupal.org/node/308865#comment-4974900

That's several months ago, and since then there is new data in terms of IE7 usage slipping further, Microsoft rolling out automatic updates, Facebook timelines disappearing etc. so I think it's time to assign this issue to Dries for feedback.

Just in case it's not clear, I'd be in favour of dropping IE7 support as soon as possible - we can help accelerate the decline if we make a clear decision early on, and there are clearly benefits here in terms of removing crufty CSS rules and a fair bit of JavaScript clean-up in the current patch (currently the patch is 2/3 the size of the IE6 one that was committed).

Dries’s picture

Assigned: Dries » Unassigned
Status: Needs review » Fixed

It's official: we're dropping IE7 support from Drupal 8.x core. Committed to 8.x. Thanks!

webchick’s picture

WOOHOO. Who wants to announce this at http://groups.drupal.org/core so all themers everywhere may rejoice? :)

geerlingguy’s picture

I want to drink to this, that's for sure! Hooray!!!

David_Rothstein’s picture

Status: Fixed » Needs review
FileSize
2.98 KB

I assume we're not supporting it in Bartik either?

droplet’s picture

Status: Needs review » Reviewed & tested by the community

awesome.

#77 looks good.

Please includes IE6 in change notification too, we missed that before. :)

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 8.x. Thanks David.

Status: Fixed » Closed (fixed)

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

xjm’s picture

Title: Drop IE7 support in Drupal core » Change notification for: Drop IE7 support in Drupal core
Priority: Normal » Critical
Status: Closed (fixed) » Active
Issue tags: +Needs change record
Tor Arne Thune’s picture

Title: Change notification for: Drop IE7 support in Drupal core » Drop IE7 support in Drupal core
Priority: Critical » Normal
Status: Active » Closed (fixed)

Change notification looks good to me. I don't think we need to wait for citations to be found before this CRITICAL task can be closed.

cweagans’s picture

Change notification in here, if anyone is looking for it: http://drupal.org/node/1569578

xjm’s picture

Title: Drop IE7 support in Drupal core » Change notification for: Drop IE7 support in Drupal core
Status: Closed (fixed) » Needs review

I disagree with #82 (on principle). The entire point of opening them as critical tasks is to make sure complete documentation of changes is done. If we close the issue, no one will ever finish it.

xjm’s picture

Alright, the citations for usage have been added. Thanks @Dig1!

It looks like there's a couple other spots for citations (regarding frontend performance and CSS/JS functionality not supported by IE6/7).

Additional information that we could add to the change notification (that is not covered in this issue) would be what, exactly, our policy is. More discussion for that is in #1532996: [Policy, no patch] Strategy for dealing with javascript in IE6/7 and we can add the resolution of that issue to the existing change notice.

Dig1’s picture

Status: Needs review » Closed (fixed)

OK I have added citations where required in http://drupal.org/node/1569578. I think they give some credence to what has been written.

Cheers

ParisLiakos’s picture

Title: Change notification for: Drop IE7 support in Drupal core » Drop IE7 support in Drupal core
Issue tags: -Needs change record

sorry for the noise, just restoring title

xjm’s picture

Issue summary: View changes
Status: Active » Closed (fixed)

d.o upgrade zombie