Problem/Motivation

There is a strong consensus for removing ie6 *FRONTEND* support out of core.

1) Major web project doesn't supprt IE6 anymore: all the google stuff (docs, youtube, ...). Even wordpress dropped IE6 support ;)
2) IE6 doesn't support css class chaining, this makes it hard to theme and has lead to some ugly css code.
3) IE6 usage dropped to +/- 1.5% in most countries. Globaly it is still 10% of the market mainly caused by China
4) Drupal 7 has crappy support for IE6 and nobody complained. The admin theme looks rly bad and I'm not even sure the overlay is working. Bartik looks also bad due to the transparant png.
5) Nobody cares about IE6 anyway when developing for drupal these days. This will lead to garbage css code and IE6 won't render correctly in the end.
6) ...

We need committer feedback because we want the approval of Dries for this.

Proposed resolution

Summary of catch
*************
The overall consensus on this thread has been for the following, as far as I understand it anyway:

- Actively remove IE6-specific hacks from CSS, markup and Javascript. A module or base theme could add back IE6 compat from contrib if desired, but core will no longer offer any specific IE6 tweaks. The patches here do that.

- Once this is done, go back and refactor all everything that's not so much a hack but just very dated - use modern CSS selectors, remove redundant class names etc. Removing IE6 support is a pre-requisite to that. These are all follow-up tasks though.

- Do not yet remove IE6-specific code from FAPI (checkboxes, security)- it will be much harder if not impossible to make that work from contrib, and it looks like there will still be IE6 usage in countries like China and Japan when Drupal 8 is released, so that might be a Drupal 9 issue.

- IE7 has lower usage than IE6, however any decision on that is being punted to a follow-up issue since it could happen on a different schedule.

Remaining tasks

Everything is done

User interface changes

IE6 will be even more unusable

API changes

None

Original report by catch

This came up in the redesign group, but I don't think it's very relevant to that. Might be worth testing the water with a core issue though.

I don't know how much practical impact this would have in terms of D7 development, but something like #102743: new forum icons maybe have a different outcome depending on whether we support IE6 or not due to PNG transparency, also some cross-browser issues with jQuery and themes. So we could agree in principle to drop IE6 support in icons/js/themes, then on a per-case basis decide what exactly that means.

It seems in the spirit of PHP5.2 MySQL5 and PostgreSQL8, but probably a bit more contentious.

Of course individual sites can easily support IE6 even if core doesn't, by using iepngfix, or their own theme etc. We already have progressive enhancement in at least one place - sticky tableheaders simply don't work in IE6, so there's a precedent. Of course we don't know when D7 will be released, or to what extent IE6 will still be in play when that happens, so this might need to be 'postponed' and revisited when and if it's a practical barrier to improvements.

Files: 
CommentFileSizeAuthor
#183 drupal-308865-183.patch12.95 KBtim.plunkett
PASSED: [[SimpleTest]]: [MySQL] 32,956 pass(es).
[ View ]
#179 exposedFilterIE7.png75.06 KBaspilicious
#179 verticalTabsIE7.png55.17 KBaspilicious
#159 code-reviewed3.patch12.7 KBcosmicdreams
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch code-reviewed3.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]
#153 code-reviewed2.patch12.67 KBcosmicdreams
PASSED: [[SimpleTest]]: [MySQL] 32,212 pass(es).
[ View ]
#150 code-reviewed1.patch15.77 KBcosmicdreams
PASSED: [[SimpleTest]]: [MySQL] 32,184 pass(es).
[ View ]
#148 308865-toolbar-rtl.patch15.17 KBcosmicdreams
PASSED: [[SimpleTest]]: [MySQL] 32,188 pass(es).
[ View ]
#147 308865-toolbar-rtl.patch0 bytescosmicdreams
PASSED: [[SimpleTest]]: [MySQL] 32,178 pass(es).
[ View ]
#144 308865-with-toolbar.css_.patch14.88 KBcosmicdreams
PASSED: [[SimpleTest]]: [MySQL] 32,173 pass(es).
[ View ]
#142 ie7.png46.92 KBcosmicdreams
#142 ie8.png46.52 KBcosmicdreams
#142 ie9.png50.99 KBcosmicdreams
#134 die6.patch13.91 KBRobLoach
PASSED: [[SimpleTest]]: [MySQL] 32,195 pass(es).
[ View ]
#101 ie6isdead.patch10.15 KBcasey
PASSED: [[SimpleTest]]: [MySQL] 29,396 pass(es).
[ View ]
#77 zinch-china-ie-share.jpg43.31 KBt_melcher
#77 zinch-china-browser-share.jpg56.16 KBt_melcher
#63 screenshot_052.png115.78 KBchx

Comments

Progressive Enhancement is fine.

Dropping support for IE6 completely is still a pipe dream.
As long as a browser still commands 5% market share and higher, then I don't believe we have the option to completely drop support for it.

Perhaps a better plan would be to put our weight behind
http://www.savethedevelopers.org/
or a similar initiative,
in the spirit of gophp5.org

Alan

Status:Active» Postponed

I agree, only sites with technical audiences can really think about this now. Drupal serves a wider community.

Well, I'd say the "admin interface of Drupal core" has a technical audience, which is where we'd most likely be dropping support in any real sense.

Status:Postponed» Active

Marking -Postpone to Active. Otherwise, this discourages discussion and debate. We are all about discussion and debate. There's no patch here so it's all academic at this point.

Here are some reasons off the top of my head for Drupal 7 to add to the discussion.

Pros
1. For garland: Code cleanup and removal. We can remove fix-ie.css and fix-ie-rtl.css and phptemplate_get_ie_styles(). There are still some IE7 hacks in style.css but not as bad as the dedicated fix-ie.css.
2. For garland: Tiny performance increase. Less data transferred. One less CSS file to bootstrap in IE browsers.
3. Less debugging, less work doing fixes and any future new theme for Drupal. This includes any new DHTML/AJAX/AHAH features and fixes in jQuery code. As we can all agree, IE6 is a major waste of time for every web designer and developer since August 2001.
4. As previously mentioned, we can accept PNG transparency in our themes. No need for CSS or JS hacks. This opens up a whole can of creativity and possibilities for garland or any 3rd party theme.
5. Gives a gentle nudge for people to upgrade their browser to "Anything But IE6" (TM)

Cons
1. We annoy people who simply refuse to upgrade especially conservative corporate IT staff, people using old computers, the laggards, people who use default themes in Drupal.
2. We may break old sites/upgraded sites based on IE6 themes.

It may not a big of a problem as in may seem since most custom sites switch out their CSS for custom themes. I would guess most big Drupal installations, are NOT using Garland or any default Drupal theme. That just leaves custom module CSS (which is out of scope here) and jQuery IE6 hacks.

Supporting data for December 2008
-Market share quotes IE6 at 21.53% and IE7 at 47.39%
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2
-thecounter.com quotes IE6 at 35% and IE7 at 42%
http://www.thecounter.com/stats/2008/December/browser.php

In the timeframe of D7 release, I'm guessing that'll be Q2-Q3 2009, IE8 will have been out a few months. I'm guessing IE8 will release Q1 2009. At that point IE6 will become the IE5.5 of today. IE6 market share will plummet precipitously as everybody will finally make the move.

Another less disruptive path... We may accept a new default theme, other than Garland and choose to break IE6 compatibility there.

Any more ideas?

I can understand using market data , but what about the real world, its affected by usersbase, so has anyone checked their sites?

I will just throw in REAL statistics for my own site for consideration for or against the argument

These are January 2009 figures so not a full month but the percentages should help as a guide. I have only broken it down to show the major browsers with IE6 as a comparison.

MSIE - 1101390 hits - 55.8%
comprising
IE 8 - 16175 hits - 0.8%
IE 7 - 809441 hits - 41%
IE 6 - 272170 hits - 13.7%

Firefox - 685751 hits - 34.7%

The rest 185815 hits - 9.2%

As a thought, formal release of IE8 may not mean a drop in IE6 but in IE7.

IE8 RC1 was just released. It'll go gold in a month or so. It'll have really good CSS 2.1 support and Acid 2 compliance. Meanwhile Dries stated D7 will hit Q4 of 2009. Also, Windows 7 will release Q4 2009 or Q1 2010.

Hitslink and thecounter are huge stat aggregators across thousands of sites spanning all genres. The sample size is as good as any.

Just to put my $0.02 in: For 2009, I am no longer working to make my new site developments work fully in IE6. I'm still fixing show-stopping bugs and layout problems, but if there's a 10px gap somewhere, or if a PNG has a grey background, so be it.

It's my view that the world would be a better place if we leave IE 6 stragglers out to dry so they will be forced to upgrade. Even the 'conservative old guard IT shops.' The only people that actually require IE6 anymore are the few shops that wrote heavily customized IE6-only apps and database interaction software. I would venture to say that 20% of current IE6 users can upgrade, but are just too lazy. Let's give them the impetus to do so!

We dropped PHP4 support for Drupal 7 when there was still a considerable percent of servers using PHP4. Why do we have to continue to sacrifice for the sake of backwards-through-the-hoop compatibility and IE6 when we do not do the same internally? Do we need a GoIE7.com? :)

There is one big difference when we talk about which version of PHP and browser versions. The person developing the site has control over the hosting choice and therefor PHP version. Same developer has no control over end users and the reality is there are still more than a few people using IE6.

I must agree with nevets. As much as I despise IE6 (I loath it. I really, really loath it.), accessibility is part of my organization's mission. That includes schools and individuals who are too poor to afford even remotely modern computers. In the last month, over 17% of our site's visitors were using IE6, so I expect I will need to support it for quite some time (sigh).

Pushing developers and hosting companies to use newer/better/safer technology is one thing. Forcing users to upgrade is a good way to loose users.

Just to add some perspective (warning: offensive language inside): http://hugsformonsters.com/

(And no, this is not a serious solution to the problem ;-)

Title:Drop (or restrict) IE6 supportDrop (or restrict) IE6 support for new core themes
Issue tags:+CSS

I'm pulling refining the title. New core themes, such as "Stark" and new core themes to be included should work with IE7 & above and not support IE6. We can all agree to that I hope. Garland will be a snapshot in time back when we supported IE6.

Regarding D7 core CSS, there shouldn't be any specific IE6 hacks. If there are, we need to rip them out!

We're using jQuery 1.3 in Drupal 7, which keeps the IE6 support. As much as I hate it, I think we should follow what jQuery supports in terms of browsers for Drupal 7. Drupal has a very handy browser compatibility CSS conditional goodness, so we should use it. I vote a yes on dropping the IE6 support in Drupal 8 though, because come on, how much of your time have you given to Microsoft already over IE6 issues? Seriously.

This definitely isn't a place for Stark though, like momendo mentioned.

@Dave Reid at #8: Maybe a GoOpenStandards.com would be better ;-) . Gecko and Webkit are much better rendering engines then any of the Internet Explorers, and they conform to the open web standards...

Let's at least move all IE6 hacks to a specific ie.css so we know where they are for later removal.

I also think we shouldn't go out of our way to deal with PNG transparency issues and stuff like that.

@ catch/#14 - I agree with you 100% there. With IE 8 out now, we would need to make sure conditionals are targeted for IE6 and IE7, because if you use the normal "If IE," then IE 8 gets screwed up, because, ironically, it's actually fairly compliant.

Status:Active» Closed (won't fix)

The difference is that we can control which version of PHP or jQuery we support.

Drupal sites cannot control which browser their visitors are using.

Neither can we control which browser an organization is using. If we would do this, we would lose a fair amount of potential Drupal users.

This is an utopian feature request.

I agree that the lack of control over users for IE6 makes it still mandatory to support IE6 in the core where visitors to the site are concerned, and that each of us as site administrators will choose to what extent we support it in our custom themes (my latest site has downgraded functionality for IE6). Also, that if the functionality is in the admin. section that IE6 is irrelevant, as a developer and/or site admin. I have enough influence to simply make everyone use FF for the admin. of Drupal - and for the most part I do.

One question remains in my mind which is given that:
a) Last I checked bots & scanners of various kinds will most likely use an IE6 looking agent
b) That my corporate users who have IE6 mandated by their arcane IT depts., also have FF3
, how accurate is this 18% or so of IE6?

I have very little faith in this number but since I have nothing better reluctantly base my decisions on it. I have even less faith in elevated levels of FF use on my owns sites since I already know my own influence on them greatly elevates that percentage above the norm.

Regarding catches comment #14 and geerlingguy's follow #15: this is how I do it on my custom themes and with IE8 will probably drop the first condition but haven't had time to test with IE8 yet. Agreed, all IE hacks (perhaps not just IE6) should be in a specific (or set of) CSS file(s).

<!--[if IE]>     <![endif]-->
<!--[if IE 7]>   <![endif]-->
<!--[if lt IE 7]><![endif]-->

Title:Drop (or restrict) IE6 support for new core themesDrop IE6 support in Drupal core
Component:other» markup
Category:feature» task
Priority:Normal» Critical
Status:Closed (won't fix)» Active

New title.

New scope, category, and priority.

New direction.

Berdir pointed me to (yet another) announcement on the net of a major web site dropping IE6 support.

Just like the PHP5 initiative, the entire issue seems to turn into a provider initiative. When major internet players drop support for IE6, Drupal should support this campaign.

Well.... Mozilla Firefox is free, and runs on older computers.... No cost except a time for an install.

While Firefox is free if you work in corporate America, you can easily stuck with the companies choice of browser.

Sorry guys, I just opened up #522006: Conditional Styles in .info files, since drupal_add_css has it :-P . Definitely a big plus from me on dropping complete support for IE6 though.

Although I can definitely see the benefits of dropping IE6 support, I wanted to point people to the relatively recent WebAIM survey of screen-reader users http://webaim.org/projects/screenreadersurvey/ .

Although the survey is not necessarily a representative sample, it does show that around 33% of screen-reader users are still using IE 6. One of the reasons for this is that upgrading a browser also means ensuring that the version of assistive technology that is being used is compatible with the newer version of the browser. Assistive technology can be costly and some people may not be economically, or technically, in a position to upgrade their technology.

Although browser support is typically a discussion around visual design, I wouldn't want problems to arise in core that would decrease functionality for assistive technology users on IE 6.

Just a point to consider.

@ Everett Zufelt / #23 - I think that 99.9% of the reasons for dropping IE6 support have to do with CSS support and would not affect the structure or the way a screen reader would read the page. It would be useful to keep in mind, though, that things should be tested for accessibility!

While I wish IE6 could be diasppear for a lot of reasons, it is still a standard for many many large companies and US federal departments. Security issues one, and internal apps that have been built to run correctly only on IE6. OK IE6 is not 100% secure, but the thought process is better the devil you know. The other thing to keep in mind is that users can not install any software on machines. Telling them to put on FF or IE7/8 will not happen.

I remember many years a when Netscape was just getting started. I hated websites that checked my broswer and incorrectly determined that I couldn't display the site becuase I was not using Netscape. I know that locking out IE6 users is not being proposed, but my reaction was to het upset and forget about that site if they didn't respect my browser.

If you want people to use a site, you don't piss them off. If people don't use a site becuase it was built with Drupal, then not that many will want to use it as a framework.

Just my $.02

I think IE6 is on its deathbed and D7 shouldn't care about any measures to prolong the suffering. When youtube decides the turn its back on IE6 this is a very good sign that it is time. I guess that other major players will follow soon. So given the amount of extra trouble IE6 support makes I am opting to stop the support.

As a sidenote: Is it an option that D7 drops the core support for IE6 but a contributed module could replace this? Or is this not feasible in contrib?

Big names like YouTube, Mobile Me, Digg, and 37signals have all announced the end of IE6 support. IE8 and Firefox 3.5 are available now. Windows 7 will be out before Drupal 7. By the time Drupal 7 is preferred for production sites, IE6 will have a small sliver of market share & remaining users will (should) be used to sites looking a bit off.

IMO, it is reasonable for Drupal 7 to have a policy of IE6 being a very second class citizen. As long as D7 sites load and key functionality (add a node or comment) works, that should be good enough. Why make sacrifices or extensively test for an increasingly irrelevant 8 year old browser? The drop needs to move on...

Another FYI, #481682: Decide what to do with Farbtastic library is blocked by an issue with Internet Explorer depending on a Canvas plugin for Farbtastic to render the control properly. When you're on IE, it looks like this:
http://skitch.com/mattfarina/bj2ru/farbtastic-v2-ie6 .... Grrrrrrrrr.

What percentage of Drupal users, specifically those using IE6, will ever touch Farbtastic? Or any other D7 config page for that matter? I've venture to guess the number is very small. Reminds me of Digg's statistics showing that only 1% of logged in users were on IE6 (http://blog.digg.com/?p=878).

Drupal is gaining traction currently amongst government. Many government agencies around the world are still saddled with IE6. Stop supporting IE6 at this point - functionally - and all those big government projects currently turning to Drupal will go elsewhere.

This is not just about people with IE6 not being able to access your sites, this is about government agencies, companies, and non-profits which will still require IE6 support either way.

As much as I hate it, dropping support for IE6 is a foolish move.

I believe this issue is less dramatic than some people depict it. If we were to Drop IE6 support officially it is not as if IE6 will not be able to access Drupal sites. They will see some minor deficiencies in Drupal core's themes and maybe a bug like in the farbtastic colorpicker as described in #481682: Decide what to do with Farbtastic library.
All that governmental agencies and companies that rely on IE6 will have to do in most (=99%) cases (i.e. on what kind of site does the average user get to see the colorpicker) is write a custom theme.
...Which they will do anyways. They will just have to keep IE6 in mind along the way. Big deal.
Therefore I think dropping IE6 support is not a foolish move, it is another much needed signal to the IE6-using world and means in no way the exclusion of a major part of internet users from all Drupal sites.

I agree with tstoeckler.

This issue is about dropping IE6 support in core!

Themers and developers will not be restricted about supporting IE6. As mentioned a few times above, Drupal themers will be able to support IE6 if they choose.

This is mainly going to effect the Admin interface to Drupal, as most sites will use a custom, user facing theme. Most developers will be using something newer than IE6, so I think that we are only keeping legacy code around which isnt used.

D7 is continually being updated. All the code in Garland, for the most part, still works with IE6. We dropped most of the older themes. If you want to see IE6 still work, you must be able to help in the Drupal 7 issue queue, code and test patches against IE6 to make that happen. This is a do-ocracy.

I know many want to drop IE6 support and make a philosophical, ideological stand. I feel the same way. But if someone commits the hours to keep IE6 working, its yours to give.

There are plenty of IE6 issues in the queue to look at.
http://drupal.org/project/issues/drupal?text=ie6&status=Open&priorities=...

Priority:Critical» Normal

Rebasing. This isn't *critical* by any stretch.

This is something that Dries needs to say " We will commit patches that look broken in IE6 ". I would think that would be a good thing, yeah. Oh, and 37signals dropping IE6 is way more important here than YouTube.

Note that IE6 users already get degraded experience - sticky tableheaders don't, have never, and will never work in IE6.

I think Sun marked this critical due to #523058: Optimize check_plain(), we managed to find ways to speed it up a bit, but I'd guess it could be twice as fast again if we actually said "you're on your own if you're using IE6, good luck" in that case - and in that case every Drupal site suffers just in case an admin happens to be using IE6.

dropping that is not acceptable, it's one thing to give users a degraded experience it's another to give 'em an insecure one.

@chx, although I tend to agree with #38, technically IE6 has been unsupported for quite a while and, hence, as soon as you install it you (willingly) have an insecure experience.

sadly "officially" IE6 still has Mainstream Support from Microsoft until at least 21 April 2013 and when used with Windows XP SP3 (just like Windows XP SP3 itself) and till 13 July 2010 when used with XPSP2

http://support.microsoft.com/gp/lifesupsps/#Internet_Explorer
http://support.microsoft.com/lifecycle/#Service%20Pack%20Support

I really hope W7+IE8 will replace WXP+IE6 quickly so it deminishes IE6 marketshare.

I agree with chx on this one, considering how many people are still (forced to be) using IE6, I don't think entirely dropping support is a good idea here

if the issue is just the alphatransparent PNGs, then either serve them with an ugly gif alternative or just serve them the same PNG and shift the blame to the browser

dropping support altogether seems like something we can't afford, now that governmental instances are starting to get interested in Drupal (as you probably know, most gov instances think IE6 is still the most secure and they have stuff that only runs on IE6, so they only use IE6)

I have never tested anything against IE6. I am thinking about adding IE 6 Update module to every site, just to make sure there is no problem with IE6.

Version:7.x-dev» 8.x-dev
Component:markup» base system
Issue tags:+DIE

A few disparate issues suggest the following:

We can't drop IE6 support for security (check_plain()) because a lot of big organizations wouldn't be in a position to use Drupal any more.

We can't render IE6 unusable in core in terms of markup / CSS / javascript, but it seems to me like less and less patches are getting tested with it, so it's likely it'll be functional but not necessarily pretty. Actively removing IE6 specific hacks isn't going to fly at this point, forthe same reasons as above.

I reckon that's the best we can do for now, nothing stops contrib themes from actively failing to support IE6 - and it's sites not working which will force users to upgrade, rather than the admin panel of a CMS.

So, moving this to Drupal 8. And putting it back to base system since we have IE6-specific code not only in the theme layer.

If Google can get away with it, Drupal and EVERYONE ELSE should do it too: http://is.gd/7r6EH kill IE6

-- Robert Douglass on Twitter

I propose that Drupal 8 will not have any support for IE6. Besides security, there should be no considerations or special work to make sure things work in IE6 (especially when it comes to theming). I agree with the DIE tag. The drop is always moving, let's not hold it back by supporting ancient browsers ;)

Here here, drop support for IE6.

I have to use the IE6 on government computers. In administration departments I find old Computers that can't run a newer version of IE and guidelines forbid the use of any other browser. We had Firefox installed and had to uninstall it, when the superior authority took notice of this.

So for now we should at least support IE6 as much, that Drupal is still usable. We don't need all new fancy functions (like sticky table headers, or cool JS animations, i.e. #781116: "Add to Default shortcuts" does not display good in IE6)

I think there is an analogy with video games :

For having video games better and better, we must buy newer consoles to support it.
If we stay with older console, we stay with the same old games.

So if all new sites will don't support IE6 anymore, maybe people who want to keep IE6 will think differently and will upgrade to a newer browser.

We can't be stuck with this old and buggy navigator for ever...

The difference from games consoles is that the games that they purchased before (in this case the sites they always visited) would not suddenly stop working in their existing console.

More, for business sites ignoring the % marketshare that IE 6 will have when D8 is released will just be costing them business - be that 5% marketshare, 10% or more.

This will mostly be a theming/JS issue so the sites that are willing to throw away potential customers can do so currently too.This should not be enforced on core IMO.

There is a big difference between not supporting IE6 browsers for the website you are building, and not supporting IE6 for the website-building tool we are making. If we drop IE6 support in Drupal, then we are assuming that everyone who uses Drupal is dropping IE6 support for their users.

I hate IE6. I hate supporting it. I want all my clients to decide we don't have to support it. But I live in the U.S., and most of the sites I build are for a U.S. market. The same would be true if I lived in Canada or Europe, where many of us live. But it's not the same everywhere.

I spent two months in China in the fall of 2010, and the Drupal developers I worked with there could not fathom the idea of dropping support for IE6. Their reality is that 50-60% of their users are on IE6 (Internet Explorer Six alone, never mind IE 6+7+8)! They have to support IE6, and will for a long time to come.

If the Drupal community if ok with saying to China (a country of 1.3 billion people): "our software will not support what you do" — then we can drop IE6. But if we want developers in China, and countries like China, to use Drupal and adopt Drupal and get excited about Drupal like we have, then we must continue to support IE6 in core, as much as we hate it.

Yes, Facebook and YouTube and most Google services dropped support for IE6. But Facebook and YouTube and most Google services are all blocked in China, by the firewall. They don't have a Chinese market. Instead the people of China go to RenRen and YouKu and other social networking sites in Chinese — sites that could be built on Drupal if we decide to continue supporting that market.

Not supporting IE6 in Drupal core does not mean that Drupal could not support IE6. We could, for example, open up http://drupal.org/project/ie6 and tell people who want/need to support the old, deprecated, proprietary browser to install the module on their site. This module could load up additional conditional stylesheets, inject complimentry JavaScript and make IE6 "work". This would also give IE6 compatibility its own issue queue and project release workflow. We should not impede the release cycle of an open source project on something like this.

This is not only about styling and user experience. Form API contains lots of ugly code to support IE6, of which some is even related to security.

There's some serious FUD implying Drupal will become worse without IE6 support. And it's more acute in 3rd world countries or low-income communities using outdated software and computers.

Let's look at the facts.
- 15% worldwide market share but is declining rapidly
- The last update IE6 SP3 was April 21, 2008. You can't talk about IE6 without talking about Windows XP since they are both one and the same. Microsoft extended support ends April 8, 2014 along with Windows XP Service Pack 3. After that deadline, there will be no support from Microsoft. There are also no indications of an Windows XP SP4.

Factors that contribute and will accelerate its disuse:
- The release of Internet Explorer 9 in H1 2011
- The release of Windows 7 Service Pack 1 in 2011. Conservative corporate IT are waiting for a stable, mature Windows upgrade cycle.
- The continuing march of Google Chrome taking market share from both Firefox and IE
- Google and Facebook have previously announced IE6 is deprecated and will not work with many of their web applications.
- More bugs and exploits will emerge and exploit IE6 bugs
- Web applications will emerge taking advantage of HTML5, Canvas, SVG, web fonts, CSS3 and Javascript. There are so many hacks to make IE6 support these, ex HTML5 shim, IEjs, PNGfix, It's getting more complicated, slows down IE6, and costs clients more time & money.
- IPv6 is not installed by default in Windowx XP. As those 1.3 billion Chinese come online, there won't be enough IP addresses to support them using IPv4.
- New computer technologies will continue to emerge and will not be supported by Windows XP. Drivers will be updated less frequently. For instance, USB3, Firewire 800, multi-core processors, Bluetooth 3 & 4, etc.
- Microsoft will release Windows 8 in 2-3 years. Drupal 8 will probably be released around that time. When we talk about this subject, we have to frame it in the 2013-2014 timeframe. Meanwhile, Drupal 5, 6 and 7 support IE6.

We can all agree that we have wasted so much time on IE6. Personally, I have better things to do with my life. I am OK with Drupal 8 dropping IE6 support in 2013.

As web developers & designers, we have to educate, inform and provide solutions to clients that don't know there are alternatives to Internet Explorer. We have to promote and advocate browsers that support HTML5 and software freedom. We have to demand better browsers from the software vendors. I refuse to believe we have to settle because it seems to be an insurmountable goal.

If you run a shop would be willing to tell 15% of the people to go elsewhere?

I remember people making the case for web standards and suporting firefox when it had less than 10% marketshare...

IE may not be liked, but everyone knows its not ideal - no point dropping it when it can be supported.
If there is an either/or situation that is arrived at that results in security weaknesses, that would be the time to drop official support.

Before then, allowing things to be not as nice in there as is the current way is good enough.

@momendo What I was saying is not FUD. It's fact. Right now, China's #1 browser is IE6. And people in China could care less whether or not Microsoft is supporting IE — most copies of Windows are pirated. I'm not saying we have to keep IE6 support. I am saying dropping IE6 has different effects in different cultures, and it's a big decision to basically not support China anymore. I just want people to realize this as the decision is made. It's easy if you've only worked in the U.S. to forget the reality of the rest of the world is quite different than our reality.

I'm sorry, but your implying that supporting HTML5 and IE6 at the same time will make things slower — now that's FUD. We can do both IE6 and HTML5 if we want to.

We need to remember that dropping IE6 does not mean that IE6 users will be blocked from viewing and using Drupal 8 sites. It means that we are not making an effort to work around the quirks of a 10+ year old browser. I'd expect that the real impact of this will be some broken formatting and a few pieces of functionality may not work correctly. This is a trade-off that I think is more than worth it, especially considering that contrib can step in for added IE6 support if there is a need.

A question worth asking:

@Sun states: "Form API contains lots of ugly code to support IE6, of which some is even related to security". Others have stated that IE6 support can be moved to a contributed module.

Can the security related matters in form API be moved to a contributed module?

If this is possible, does anyone with the skill to do this also have the interest in doing this?

What other ways might it not be possible to move IE6 support out of Core and to a contributed module?

I agree, that the idea behind "not supporting" IE6 is not that Drupal 8 sites will not work, but that they may not work as well. I'm not really for or against this issue, but would like to start developing some rationale. A good way to do this is to start to develop an understanding of what the affect of no longer supporting IE6 will be on IE6 users.

I accept as fact that many users do, and will continue to, use IE6. Rhetoric about educating clients and users aside, we need to support these users. We are an inclusive community building an inclusive tool that powers an inclusive web, and ought to continue in that tradition as much as it is reasonable so to do.

I'm for #51 Rob's approach and support #56 rickvug point.

1. We already support progressive enhancement, whatever breaks, breaks safe.
2. Moving off IE6 legacy support into a module is pragmatic and reasonable. We clean up dead code, less bits, less man-hours, smaller core. We already have polite reminder modules, but this would be the next logical step.
http://drupal.org/project/iedestroyer
http://drupal.org/project/block_ie6
http://drupal.org/project/ie6update

To clarify:

Can the security related matters in form API be moved to a contributed module?

Dealing with design/styling quirks (or not) is not really the question. We already have a heavily reduced experience for IE6 users in D7. Further decreasing the default experience and moving off special support code into a contrib module is not a big deal at all, and could be done at any time. Likewise, there could be a konqueror.module, attempting to support an equally inane browser.

However, Drupal's Form API, and I think also the AJAX framework contain a range of special workarounds/hacks to support IE6. No time to verify and go into details right now, but fundamentally, dropping support for IE6 would mean to remove that code, which in turn might mean security problems as well as broken JS/AJAX functionality in IE6.

That's what we're really talking about. The security related code won't be moved into contrib, because no one cares about contrib. With regard to that, it's a 1/0 decision.

Dropping security support for IE6 doesn't mean that people can't use it either - in the same way as Microsoft has dropped security support for it already but people continue to use it.

If we make more things pluggable in Drupal 7 (i.e. allowed people to swap out form.inc and ajax.inc) then it would be easier to add back that IE6 support from contrib, although I really, really doubt that anyone with the skill to do that well would also be prepared to spend the time to do it, it is often issue to do with obscure character encoding bugs that Microsoft never fixed themselves.

For an example of IE6 support making /every Drupal site in the world/ slower, we need only to look at check_plain():

#523058: Optimize check_plain().

Note that while check_plain() is now a lot faster than it was, there is still code in there only to support IE6, it's hard to know for sure, but I'd reckon check_plain() gets run several billion times per day, I wonder how many tonnes of coal that is per year.

As far as the '15%' argument goes (or whatever percent it will be in the future) — one must always ask: Is it worth it having to spend whatever percent more time, and not develop whatever percent more features (or improve others by such-and-such a percent) simply to support that 15% (or whatever it will be)?

In my opinion, it will not be worth the tradeoff. By 2012/2013, when Drupal 8 is released, we can move forward and drop IE6 support... One thing I love about Drupal is that it's always moving forward—the Drop is always moving—and it's been pushing the web forward since the day it was released. I'm not trying to screw China, but they do have Drupal 7 (a great platform), and they do have the opportunity to upgrade between now and whenever D8 comes out... or wait until D9, or simply give up on Drupal.

Does anyone have statistics on how many Drupal sites are hosted in China/for a Chinese audience? If we're going to cater to their needs over the rest of the world's, then either they should have a high percentage of Drupal sites already, or it should be our mission to promote Drupal, open source software, and more freedom of information, in their country. Just sayin'.

It strikes me that noone here arguing is Chinese. Scratch your own itch, I say. We floated the dropping of PostgreSQL and PostgreSQL maintainers have shown up. Can we do something similar?

StatusFileSize
new115.78 KB

Oh and I tested this page and it's accessible from China.

@chx

Users are not developers, and users don't know or care what db is storing the data for a site. Users care about accessing and contributing data to a site.

Clearly, as an open source community, there needs to be someone interested in an issue to provide a solution to the problem. However, if we know that there are users who might be affected by a decision we make, and if we see no developers stepping up to solve the problem, then we as a community need to ensure that the problem is solved.

I suppose the question I ask is if we are making a tool for developers, who are soley responsible for their users. Or, if we are making a tool for developers where we ensure that the tool will work as well as possible (however that is defined) for their users, advocating on the users behalf.

Taking accessibility as an example, there have been major improvements in D7. This is due to the contributions of many contributors, but really was lead by a handful. Had that handful not have acted D7 would have had far less improvements, and less users would be able to fully interact with D7 powered sites.

The users don't care that we put in the work, some of the developers don't care that we put in the work, but because we put in the work D7 powered sites are more inclusive to a broader number of users, and users do care about being able to access and contribute content to the sites they visit.

What exactly are we talking about here?

About three lines of code in form.inc, some UTF8 enforcement (that is probably a good idea anyway) in common.inc, some CSS styles, maybe some workarounds in some of our JS? Can anyone tell us exactly what is the amount of IE6-specific support in core? I feel it's close to zero.

The IE6 string can be found in 36 files of the current 7.x-dev. Mostly css and js. I do not see any good reason why should we keep that garbage for D8..

Everett, you cared about accessibility so D7 is now more accessible. That's what I am talking about. If someone shows up and says "I am using IE6. I will continue using IE6. I am willing to help test / code around / etc" then there is the IE6 maintainer. I can be replaced with "my clients". Personally, I myself can't care less about that piece of ancient garbage.

@Damien / #65 - many theming issues require (in my estimation) about 10-20% more work to make sure it all works in IE6. Not only does one have to test in IE6 (which is easy with IEtester or virtualization), but there are many CSS rules and HTML structures that simply don't work (or need extra tweaking, consideration and testing) in IE6.

[Edit: Not the least of which are floats, inline styles, padding/margin problems, general layout issues, and JavaScript bugs. And some of these, sadly, also happen in IE7.]

It seems to me that there are two distinct issues here: the theming layer and the API. These are two different problems and should be evaluated independently.

As a themer, I see no reason why Drupal 8 should require out of the box IE6 compatibility in the theming layer. The whole point of the theming layer is that it is themable. Who cares if Garland is IE6 compatible? If I want IE6 support in my site, then I can develop a theme with the requisite CSS hacks. As it is right now, Drupal 6 doesn't support HTML5 out of the box, so I'm building that into my themes myself. And if enough people need IE6 support, then someone can (and will) release a D8 base theme in contrib that includes the necessary overrides and hacks. This does not seem like a problem to me. No Chinese need be worried.

The API is a different monster all together. Now, I am only a psudo-developer, so correct me if I'm wrong, but doesn't the API execute on the server? And therefore, shouldn't it be largely browser agnostic? If there are security issues that crop up with IE6 clients, then those of course will need to remain in Core, given that we have no control over what browsers people will use to access our websites and we don't want to open up any vulnerabilities. Other than that, can anyone tell me what IE6 specific code is in Core that doesn't relate to presentation and isn't in any way themable? I'm still not sure what "dropping IE6 support from core" actually means.

Maybe give an end of life announcement, and let it coincide with Drupal 5?

I stopped working with IE6 for my own site a couple of years ago. Haven't looked back. It hasn't damaged visitors stats all that much, but did cut down development and deployment time tremendously. Time that can be spend on accessibility and usability for example.

Not to mention the fact that Microsoft itself recommends repeatedly for users to upgrade from IE6. This is really something for a while for the last remaining IT departments to solve. If they want continued support for IE6 in Drupal I do believe they should contribute (financially) to Drupal, or convince Microsoft to make a compatibility filter in newer IE browsers with backwards compatibility to IE6. I'm not spending any more time on it unless I'm getting paid for it.

Let's get concrete — functional support code for IE6 throughout Drupal core:

filter_xss():

  function testFilterXSS() {
...
    // Null between < and tag name works at least with IE6.
    $f = filter_xss("<\0scr\0ipt>alert(0)</script>");
    $this->assertNoNormalized($f, 'ipt', t('HTML tag stripping evasion -- breaking HTML with nulls.'));
...
    // Works at least with IE6.
    $f = filter_xss("<img o\0nfocus\0=alert(0)>", array('img'));
    $this->assertNoNormalized($f, 'focus', t('HTML filter attributes removal evasion -- breaking with nulls.'));
...
    // DRUPAL-SA-2008-006: Invalid UTF-8, these only work as reflected XSS with
    // Internet Explorer 6.
    $f = filter_xss("<p arg="\xe0">" style="background-image: url(javascript:alert(0));"\xe0<p>", array('p'));
    $this->assertNoNormalized($f, 'style', t('HTML filter -- invalid UTF-8.'));
    $f = filter_xss("\xc0aaa");
    $this->assertEqual($f, '', t('HTML filter -- overlong UTF-8 sequences.'));
    $f = filter_xss("Who&#039;s Online");
    $this->assertNormalized($f, "who's online", t('HTML filter -- html entity number'));
    $f = filter_xss("Who&amp;#039;s Online");
    $this->assertNormalized($f, "who&#039;s online", t('HTML filter -- encoded html entity number'));
    $f = filter_xss("Who&amp;amp;#039; Online");
    $this->assertNormalized($f, "who&amp;#039; online", t('HTML filter -- double encoded html entity number'));

drupal_validate_utf8() (see previous)
check_plain()
potentially also _form_button_was_clicked() (not verified)

tabledrag.js:

    // Hack for IE6 that flickers uncontrollably if select lists are moved.
    if (navigator.userAgent.indexOf('MSIE 6.') != -1) {
      $('select', this.table).css('display', 'none');
    }

color.js:

    // Fix preview background in IE6.
    if (navigator.appVersion.match(/MSIE [0-6]\./)) {
      var e = $('#preview #img')[0];
      var image = e.currentStyle.backgroundImage;
      e.style.backgroundImage = 'none';
      e.style.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled=true, sizingMethod=crop, src='" + image.substring(5, image.length - 2) + "')";
    }

overlay-parent.js:
- Various "IE6" hacks -

Subscribe. I'm still finding it commercially necessary to support IE6 in all css and some js, sadly. My clients are going to expect that Drupal doesn't make IE6 any less secure than it already is, but I'd certainly be OK with core themes dropping all IE6 workarounds, and purely visual glitches (like flickering) are not sufficient reason for a workaround in my book. I've already refused to allow IE6 for admin logins.

It looks like we raised our PHP version high enough to not have that IE6 workaround in check_plain() any more, or at least if we do, then it is being handled by PHP internals properly now.

I agree that core theme compatibility with IE6 is a different question to explicitly removing security and other FAPI workarounds for IE6 from the API. There's also a difference between refusing to support newly-found IE6 security issues, and going through removing all the stuff we already cover.

While we have work so hard to compatibility with IE6 now, why drop EXISTS codes ??
we can don't pay anymore time to support IE6 in new development but don't clean up exists codes.

for theme part, unless you have a lot of transparent images and position: absolute, otherwise it wont spend your 10%~20% time. (loading a IE-7.js or whatever, it fixes all for you).

Theme is only one thing we can easily fix it ourself but JS/PHP are so hard to fix it.

Subscribing.

subscribing.

I don't see much point in retaining IE6 specific css exceptions, nobody runs drupal with default styles anyway

the FAPI stuff (and the likes) however, should prolly be retained as I imagine certain things to seriously break without these quirk fixes

I sure as hell don't want to maintain it though

StatusFileSize
new56.16 KB
new43.31 KB

I'm very hesitant to post anything here, since I'm way over my head technically. However, I thought it might be helpful to shed some light on the browser situation in China.

We run a relatively large Drupal-powered site, in the US and in China (12 million nodes, 100+ modules, etc). We get alot of traffic, mostly from students in both countries. The browser share differences are amazing. In the US, most students use the latest browsers. In China, most use IE6. My guess is that it's because the new browsers are better at detecting a pirated OS...

In any case, I've attached the browser share graphs from Google Analytics for our China site (not including our US site). As you'll see, IE6 is very popular in China, and accounts for about 45% of our traffic.

Given that, it would be great if Drupal kept supporting IE6.

Thanks for listening!

Tom Melcher
VP, Global Products and Partnerships
www.Zinch.com
www.Zinch.cn

@Tom - thanks for posting those stats! That is a very helpful data point in this discussion. I hope others who have strong Chinese sites will be able to chime in as well.

Tom, as my post previously, if you have such a huge site, are you willing to commit resources to Drupal core to upkeep IE6 support?

#61, #62, #79 totally agree, if users have needs then scratch the itch, that's not me, not going to be me, I don't want to waste any more time supporting this piece of junk - so yes, lets at least drop IE6 requirement in themes, in fact I would almost say IE7 is questionable also, usage is dropping fast.

Subscribing and..

..some CSS styles........ Can anyone tell us exactly what is the amount of IE6-specific support in core? I feel it's close to zero.

it's actually ALL of the CSS, in core and every module.. ALL selectors could be made much more efficient (ultimately affects rendering speed) if they were able to use the Child Selector.. there is no child selector support in IE6

I would be in favour of dropping IE6 support in the next version, as mentioned before - developers still having to support IE6 at that time could continue to use D6/7

If support could be dropped there could be a major refactoring of the CSS across the board as well as a clean up of cruft ref: http://drupal.org/node/694382, which when you have got to the stage of 20-30 stylesheets being pulled in to your pages has got to be a major plus minimised/compressed or not.. IMO

Deciding as a community to drop IE6 support in Drupal is a business decision, but most of this thread isn't talking about it as such. Mostly people are saying "I don't want to do the work to support ie6 anymore". I say — cool. Don't do the work. If you don't want to support ie6, then don't. Make a personal decision to stop.

But making such a giant business decision for Drupal on a developer issue thread in response to a handful of developers saying "I don't want to do the work"... that doesn't seem like a good way to make this kind of decision.

Ok, that basically is business decision as jensimmons sayed.

However think this comes into 2 points.

#1 Will there be significant market share (or usage-share) on ie6 by the time D8 would be released
#2 Would not-supporting-ie6 affect more negatively (to usability, usage and community) than supporting-ie6 (performance, happier developers and themers and more bleeding edge stuff). Also there has been discussions about html5 and D8.

So basically would we get more in return than we lose?

Good way or not, Drupal is still a do-ocracy. When developers say that nobody is willing to do the job, then the decision is made already..

In reality, we are not talking about making Drupal incompatible with IE6. We are just moving IE6 compatibility to the theme layer, where arguably it belongs anyway. The impact, as I understand it, is that some of the default CSS output by a base Drupal install will not render correctly in IE6. So, if you are using the Stark theme, you loose IE6 compatibility. However, all of this CSS can be overridden by CSS in the theme. We could even have a simple Stark-like theme that did nothing but provide IE6 compatibility for core. This would then be the base jumping off point for anyone wanting to build an IE6 compatible theme.

It seems to me that removing all the CSS cruft required for IE6 compatibility is a prudent business decision at this time. It creates a leaner, more optimized core, making the product more attractive to Drupal's core user base, while still allowing those who need this compatibility to build it into their themes. As long as we don't go so far as to make building an IE6 compatible theme impossible, I think this is a good thing.

Yeah, honestly, I don't think the Drupal CSS needs to work with IE6. Anyone building a big site with Drupal will be writing all custom CSS, and they can support ie6 — whether it's a site in China or a big corporation here (because both of those clients have to support ie6).

The question for me is more about the other things in Drupal. The Form API. Security. All the APIs really.

I think we're agreed. If IE6 clients expose security holes in Drupal, then those fixes will always need to be in the APIs. Otherwise IE6 will just turn into a site hacking tool. However, if we're talking about usability problems with the Form API, or other APIs, then my first question is, can the problem be reasonably fixed in the theme layer? If so, then that is probably where it belongs, so lets get it out of Core. If the fix is more involved and really needs to be in the module, then can we separate out the IE fixes into an optional support module? That way, even if it's in Core, it can easily be disabled.

Personally I'm still a little fuzzy on what could possibly be in the APIs that would conflict with IE6, given that they contain server-side logic and should be largely independent of the display. In theory, any display output could be overridden by a template file or theme function.

E6 will just turn into a site hacking tool.

come on, such a false conclusion. If a site would be hackable with IE6 then it would be hackable with any other custom made hacking tool. We are not allowing that.
simply the site will be mostly unusable with IE6, not hackable..

Issue tags:-IE

This is interesting, Microsoft's public display of IE6 use stats. It's posted at http://ie6countdown.com/

a screenshot of the ie6countdown.com website

They are graphing IE6 traffic on whichever websites Net Applications is tracking. (Not the whole web. The Chinese developers I know report 45-60% IE6 use on the sites they build.)

China is the number one market for IE6. Followed by South Korea. And then other countries in Asia. Microsoft is putting a lot of money and effort into killing IE6. Yeah! I doubt, however, that they will impact China much. What their efforts will hopefully do is get U.S. corporation holdovers to upgrade, and most of us can stop building IE6 sites for our clients.

But the question still remains, do we care enough about promoting the adoption of Drupal in China (with 1/5th of the world's population) to keep supporting that market's need to build websites for IE6 users?

IE6 users are already living a hard life surfing the web with reduced functionality, security vulnerabilities and broken websites.

With IE9 coming out at SXSW in ten days and Windows 7 Service Pack 1 out, there really is no more excuse.

#90: There is plenty of excuse if you're a business with intranet apps written years ago that specifically target IE6 and its quirks, and don't work correctly (or are untested and unapproved) with anything else. That's a lot of development and testing time required to for them to switch their browser standard, and the budget allocation simply isn't seen as a priority when what they have now still "works".

I wouldn't trust those MS stats too far. A site I run here in New Zealand which targets financial advisory organizations is seeing more like 10-15% IE6 use.

Issue tags:+IE

for most of cases, using IE6 is a personal habit and it really running more better than other browsers on their PC. Promotion and eduction do not make them move to a new browser.

Issue tags:+IE

http://www.computerworld.com/s/article/9213320/Microsoft_launches_IE6_de...

By Gregg Keizer
March 4, 2011 01:53 PM ET
Computerworld - Microsoft today launched a deathwatch for its 10-year-old Internet Explorer 6 browser, saying it wanted to "see IE6 gone for good."

According to Microsoft, which cited statistics from Web analytics firm Net Applications, IE6 still has a 12% global usage share, with almost half of that in China, long a stronghold of the aged browser.

Microsoft wants to drive IE6's share under 1%.

"We bring you the next step in our mission to see IE6 gone for good," said Roger Capriotti, the head of IE's marketing, in a blog post Friday. "To demonstrate our commitment to getting rid of IE6, we're launching a Web site."

That site, ie6countdown.com, shows Net Applications' usage share numbers for IE6 in 43 countries, including the U.S., China, Japan, Germany and Russia, as well as the browser's current global share.

(more text in article)

I wouldn't trust those MS stats too far. A site I run here in New Zealand which targets financial advisory organizations is seeing more like 10-15% IE6 use.

You have to remember—every website will have a different share. One site I run as 12%. Another one is less than .5%. It really depends on the audience and the geographical region. This is not the point, though. The point is: do we decide that, for those few sites that will have, say 4-6% of their users on IE6, we force those site developers to make their own theme, or tweak another theme to get their site to look okay in IE6, or use another solution... or do we do that work for them, and spend less time developing awesome fit-and-finish features that might not work so well in IE6.

I vote the former.

One of the questions I have about the China issue is if this will actually change in the next 2 to 4 years (certainly we don't want to be hacking for IE6 in D9), because afaict IE6 popularity in China is mostly the product of pirated software. Will this change any time soon - could it in fact increase?

Presumably it's people running pirated copies of Windows XP. Assuming that's 99% of IE6 usage in those countries, then there are a few ways for people to get off IE6.

1. Upgrade to a pirated version of Windows 7.
2. Switch to free software.
3. Buy a copy of Windows 7.
4. Switch to firefox (or whatever) on Windows XP.
5. Switch to Mac.

Those are ordered in what I reckon the likelihood would be of each. So if Microsoft really wants to get people off XP in China and South Korea, assuming most people are using pirated copies because they don't want to or can't pay the license, they'd need to either flood china with pirated copies of Windows 7 and turn a blind eye for a while, hoping people will convert to a paid copy later (this kind of thing is not exactly unheard of), or move people onto free software, or give away free licenses.

It's worth keeping an eye on the numbers over the next year or so. There are massive lines between not actively supporting IE6 any more, and removing all existing hacks plus making an effort to use browser features that IE6 doesn't support, I think the first is going to happen anyway, the latter are where there starts to be a real trade-off.

For me that is where I am at on this issue - not actively supporting IE6, but not removing specific code such as the code sun pointed out earlier, nor re-writing all core CSS to use child selectors and other things that will essentially abandon IE6 and create a lot of work for a theme developer to support IE6. While we could put the onus on them (IE6 theme developers) I think we need to think carefully about this - doing this rewrite is a big job and will pretty much abandon IE6 wholesale right through contrib and core. Most themes do not overwrite all core CSS and in fact rely on huge chunks of it, for example vertical tabs. I suspect we could do the re-write and move IE6 specific requirements into conditional stylesheets, that is an option.

Our core themes work in IE6 reasonable well enough now so that is OK and can't see that needing to change, however we may have a bigger debate looming regarding HTML5 support for <IE9 for our core templates and themes, that's another issue but there is cross over for IE6 - if we use a single new HTML5 element we need the html5shiv, and that is proving to be a point of contention. Using the new elements and not using the shiv will abandon IE6.

Rewrite + conditional stylesheets doesn't sound bad to me at all - because it'd make it very easy to drop IE6 support completely at a later date, and the actual logic to show the conditional stylesheets could easily be skipped by sites that explictly don't want to support it at all.

Regarding Bartik, there are 62 lines of overrides to fix IE bugs (IE in general), and an additional 17 lines of code to fix IE6 bugs. Not much at all.

Support IE6 in a theme becomes much harder when you are building a custom complex site with specific designs. Bartik is a fairly simple theme, and was visually designed to be elegantly coded (and not require crazy hacks).

w/ regard to HTML5, I'm thinking Drupal 8 might take a bit of a conservative approach, having one HTML5 theme, one non-HTML5 theme, and something like Stark. By D9, we might be able to only have an HTML5 theme...

Of course, if we use the shiv, I would have no problem having only HTML5 in core. I don't see any reason to not have it.

Status:Active» Needs review
StatusFileSize
new10.15 KB
PASSED: [[SimpleTest]]: [MySQL] 29,396 pass(es).
[ View ]

Stop supporting IE6 in core but starting a theme or module for that support which can either be included as part of the Drupal core package or be part of contrib seems like a good solution to me.

I think one advantage of not supporting IE6 would be a lot cleaner html. In the form api we're currently adding classes to indicate the type of an input element. All browsers except IE6 however supports the [attr]-selector so could remove all those classes and just use [type="text"] as the selectors instead - which would be a lot cleaner and DRY:er approach.

A IE6 theme or module could override all of the form themes to restore the old classes and add an additional CSS-file with the rules for them.

Status:Needs review» Active

Moved patch from #101 to a seperate issue: #1182870: Remove IE6-specific code.

Google going to drop more brosewrs:
http://googledocs.blogspot.com/2011/06/our-plans-to-support-modern-brows...

and Wordpress discontinue support IE6

I'd like to weigh in on the side of modernizing css/js in Drupal 8. If the child and attribute selector were allowed (as mentioned in #81 and #102), along with the multiple class selector (.node.views.page), Drupal core classes could be rewritten and significantly reduced. Developers also sink hours into reducing the class-and-tag soup Drupal is known for (see projects like Mothership, Semantic Views, etc., and any themes I've ever written for a client) to lighten Drupal's generated code and bring it in line with the clean, semantic html provided by a design team.

I understand the reluctance to remove functioning support for a traditionally important use case (and when we're talking about a decade in web time, tradition is certainly an appropriate term), but I think the rising and soon to be more common use case is developers demanding cleaner, more modern structure and css delivered out of the box. None of the shops I work with include i.e. 6 support in their basic services -- it's an add-on that requires additional dev time and a correlating price tag. It makes sense to me that Drupal should follow suit, providing legacy browser support as an additional (contrib) service, and not maintain a policy that hobbles overall cleanliness, efficiency, and standards compliance.

According to the ie6countdown link posted above, unless you are targeting Chinease or Korean markets your only looking at alienating < 5% of worldwide market. And those folks can use Google Chrome Frame.

We should also remember that D8 will be released in about 2 years and that D7, which supports IE6, will be supported for around 4 more years. It's the usage numbers for IE6 2-4 years into the future that we have to keep in mind and that share will be so low that it will cause more harm to support IE6 in Drupal Core than it would do good.

So....... in that case perhaps the question is should we continue to support IE7.

http://www.theie6countdown.com/default.aspx : 10% worldwide
http://theie7countdown.com/ : Today, 7% worldwide.
http://theie8countdown.com/ : Today, 30% worldwide.

Sorry, for repeating myself here. IE7 has less worldwide support than IE6. So if we're really talking about not supporting IE6, we should probably also be talking about dropping support for IE7 as well.

What would not extending an effort to support IE7 mean?

Well according to http://caniuse.com/#agents=ie&eras=farpast,past,now&sort=ralpha&show_con...
* Expect support for WAI-ARIA globally :
* querySelector/querySelectorAll : http://www.w3.org/TR/selectors-api/
* JSON parsing : http://www.ecma-international.org/publications/standards/Ecma-262.htm
* Hashchange Event : http://www.w3.org/TR/html5/history.html#event-hashchange
* Data URLs : http://www.ietf.org/rfc/rfc2397.txt
* we could rely on display : inline-block : http://www.w3.org/TR/CSS21/visuren.html#fixed-positioning
* CSS3 Box-sizing: http://www.w3.org/TR/css3-ui/#box-sizing
* CSS3 Table display : http://www.w3.org/TR/CSS21/tables.html
* use of :before and after CSS3 pseudo-selectors: http://www.w3.org/TR/CSS21/generate.html

Some of those you might be thinking, eh, so what. But some are pretty big.

Agree, dropping support for IE7 should be on the table.

+1 for dropping IE7. It does seem the barrier to upgrading from IE7 is lower than IE6.

Would it be feasible to adopt a policy like Google's in Drupal core—supporting only the last two major browser releases at the time of a Drupal release—but create a contrib module that provides compatibility with older browsers?

Interesting... very interesting....

In the spirit of planning for browser support 2 years from now, perhaps we should completely forget and refactor out support for IE 6, 7 and 8 into a module so we can plow ahead with targetting IE9 and the awesome CSS advancement they accomplished there (over IE8).

This choice is based on the assumption that in 2 years time, we won't have to care too much about IE 8, 7, and 6. The module would exist in case that assumption is wrong.

All those old clunkers running old-IE have to die sometime.

Much like IE6, IE8 may be difficult to kill. There are a lot of people still running XP who can't upgrade to IE9. But generally speaking, I support the concept.

IE8 typically at least shows things correctly. Border radiuses, shadows, etc. (many CSS3-specific selectors) are supported in IE9, but usually amount to nothing more than eye candy. Basic layout and positioning properties are almost always supported well in IE8. Javascript support is also pretty good in 8... a heck of a lot less to worry about than 7!

In my experience, 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). IE8 is the most modern IE browser for Windows XP, and I still support it for 100% of my projects, as most clients are either running 7 or (more often now) 8.

Drupal 8 will come out at least 2 years from now so...

I don't see any harm in leaving the FAPI/security related code for one more cycle, since it's already there, but I think we should definitely drop CSS support. We'll be revamping pretty much all templates and CSS files over the D8 development cycle. Having to support IE6 will unnecessarily hinder our efforts. There is nothing stopping theme developers from making the decision to support IE6 themselves. WordPress and Google have officially dropped support for IE6 and a bunch of us had a discussion with the Microsoft team about this a couple of months ago. We should not waste any more developer cycles on IE6.

That's my 2 cents.

@Jacine,

You right!!! Drop CSS supports and keep other FAPI/JS code.

I agree that it might be a good idea to also drop IE7-support in Drupal 8, dropping support for IE8 would be to go too far though.

Developing for IE6 and IE7 is painful with special workarounds needed for them both. Developing for IE8 and newer is pretty cool - for them it's possible to do good progressively enhanced sites without any weird workarounds.

So, +1 on on dropping support for both IE6 and IE7 - they won't be worth supporting 2 years from now. (They are barely worth supporting today)

Title:Drop IE6 support in Drupal coreDrop IE6/7 support in Drupal core

Updating the title to reflect the broadened scope. I can't think of a single reason to keep support for IE7, it will be all but dead in two years, aside from that its just time to move on, we have a whole new world to account for, new issues with mobile browsers and devices and so on. Personally I would love to ditch support for IE8 because it does not reflect this brave new world of media queries, HTML5, robust CSS3 support and so on, however I have to be conservative and accept, albeit reluctantly, that some people are stuck on XP and will be for some time.

So If we apply the strategy of leaving FAPI/security related code in and only focus on removing the hackish CSS and/or JS and/or markup that previously supported IE6/7, how much code are we talking about?

When Jen posted the map from ie6countdown.com, China was on 34.5% IE6 usage (February stats). Now it's on 33.9% according to the graph as of today (May stats).

That's not exactly rapid decline but it could accelerate. Regardless I'd be happy with dropping CSS/JS/Markup, and leaving existing IE6-specific security/FAPI code in to be re-visited later.

This topic made me wonder what set of expectations could we have if we lived in a world where IE 6,7,and 8 didn't exist. Using to the same resource I used to determine the set of features we could use if we didn't support IE 7, I performed the same analysis to find what features we could use if we didn't support IE 8. Here are the results:

source : http://caniuse.com/#agents=ie&eras=farpast,past,now&sort=ralpha&show_conc=1

XHTML served as application/xhtml+xml : http://www.w3.org/TR/xhtml1/
WOFF - Web Open Font Format : http://www.w3.org/TR/WOFF/
Video element: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#v...
TTF/OTF - TrueType and OpenType font support : http://developer.apple.com/fonts/TTRefMan/index.html
Text API for Canvas : http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-e...
SVG :
1) http://www.w3.org/TR/html5/embedded-content-1.html#the-img-element
2) http://www.w3.org/TR/SVG11/extend.html#ForeignObjectElement
3) http://www.w3.org/TR/css3-background/#background-image
4) http://www.w3.org/Graphics/SVG/
5) http://dev.w3.org/html5/spec/the-canvas-element.html#svg-0
rem (root em) units : http://www.w3.org/TR/css3-values/#relative0
HTML5 elements : http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.ht...
getElementsByClassName : http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom...
Geolocation : http://www.w3.org/TR/geolocation-API/
CSS3 Transforms : http://www.w3.org/TR/css3-2d-transforms/
CSS3 Multiple Backgrounds : http://www.w3.org/TR/css3-background/
CSS3 Colors : http://www.w3.org/TR/css3-color/
CSS3 Selectors (like nth-child) : http://www.w3.org/TR/css3-selectors/
CSS3 Opacity (without using filter) : http://www.w3.org/TR/css3-color/
CSS3 Media Queries : http://www.w3.org/TR/css3-mediaqueries/
CSS3 Box-shadow : http://www.w3.org/TR/css3-background/#box-shadow
CSS3 Border-radius : http://www.w3.org/TR/css3-background/#the-border-radius
CSS3 Background-image options (background-clip, background-origin, etc...) : http://www.w3.org/TR/css3-background/#backgrounds
Canvas : http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-e...
Audio element : http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a...

That's a big list and there are quite a few very important features listed. It would be nice if the world was this way. If we really wanted to utilize these features we could use progressive enhancement / graceful degradation strategies to properly handle any browser's deficiencies.

Yet, it seems it is highly likely that we will need to support IE8 within 5 years time. According to ( http://royal.pingdom.com/2011/06/17/report-the-most-common-web-browsers-... ) IE8 is the most used browser world-wide.

BTW: according to this source, there are more people using Safari 5 than use IE6, and more people use IE7 than IE9 (by a slim margin)

@cosmicdreams, I think the biggest gains will be not from the amount of code/hacks that can be dropped, but from refactoring and reducing css code and classes in the html to utilize modern selectors.

Think about all the class cruft we could remove if we could use .comment.new input[name='title']. An end to Drupal class/tag soup through utilizing .multiple.class and attribute selectors in core and eventually projects like views -- that makes me honestly excited.

Don't talk about IE8, xp will never ever ever ever ever ever support IE9 so lots of people will use IE8 in 2 years.
So please don't dream about a world with all html 5 browsers.

And please let us remove IE6 support first before thinking about IE7. Seriously...

I'm one of the few in this issue actually working with windows on a daily basis.
In the weekends I help one of my friends in his computer shop and I still see lots of computers with IE7 installed as primary browser. This will only change if those old xp machine start dying, and that can take a while because some people still install xp on a new machine :) (and no they never upgrade). I don't see IE6 at all anymore on personal home computers.

So can we make this an IE6 issue again?

@aspilicious: As has been pointed out, IE8 runs on XP and IE7 already has lower usage world-wide then IE6, so I think IE7 should stay on the table. I would be shocked if there were significant IE7 usage two years from now.

Yeah, and we really got to get off this idea that XP users cannot upgrade to a decent browser, it seems reasonably clear to me that significant numbers are switching to Chrome.

No lots of people stay on ie. They don't know what a browser is. Internet == internet explorer, the icon on their desktop. If they don't upgrade automaticly they stay on their first version. Why dropping IE7 if people don't agree on IE6. First fix IE6 than IE7.

I completly disagree with the idea lots of people will switch to firefox or chrome, if they knew about versions and other browsers they would upgrade to IE8 themself.

This can be done in stages:

- stop adding new hacks for IE6
- go through and remove specific IE6 support from core.
- stop adding new hacks for IE7
- go through and remove IE7 support from core (is there much? Wouldn't it mainly be in themes and specific js if so?)

That probably leaves "adding new features that will break in IE7" as the one thing that could get caught up, so I agree with aspilicious - there's a difference between choosing not to go out of our way to support something, and explicitly committing lots of patches that break that support - the latter there's no reason not to do the IE6 stuff first (or if there is, someone should explain in the specific issue when that comes up).

Yeah, and we really got to get off this idea that XP users cannot upgrade to a decent browser, it seems reasonably clear to me that significant numbers are switching to Chrome.

It's not about whether people can - of course they can,
but that they don't.
Ideally, as a first step we could drop IE6 support from core,
and those concerned with supporting it could develop an 'IE support' module in contrib.
Along the same lines as the jquery update module, but in reverse.
If that went well, we could look at dropping IE7 support from core, and relying on 'IE support' module to handle IE7.
All of this could happen within the D8 cycle.
But we really need support that this will be accepted from core committers.
Removing support is easy, but the real benefits come from continuing work with the knowledge that IE6 support would not be needed.
Can Janice or Jeff Burnz make this call?
Or just Dries?

@catch: Removing IE6 hacks while still supporting IE7 will probably result in replacing some of the IE6 hacks with IE7 hacks - thus it would be easier and probably also get cleaner if support for both IE6 and IE7 was removed at the same time - especially if support for IE7 will be gone in D8 anyway which I think it should be.

So where are we at:

Drop IE6 - strong consensus.
Drop IE7 - debatable.

Looks like we have a clear consensus on IE6. So I'm going to agree with catches plan in #127 and back the staged removal plan. Dropping IE6 clearly opens things up for us and allows us to get on with the work of improving cores CSS.

IE7 can wait, perhaps we can revisit in 12 months, which still gives us plenty of time to work on it depending on the outcome.

Initially I have opened two issues for the core themes:

#1196170: Remove IE6 CSS in Bartik
#1196172: Remove IE6 CSS in Seven

@Jeff: I think we should keep IE7 in mind in issues like the ones you created. If we see that it would be a lot of extra work to support IE7 for now and instead remove it in a year or so then we should reconsider. We don't have to actively remove support for IE7 right now - but I don't think we should actively support it either - that's just wasting peoples time :)

Title:Drop IE6/7 support in Drupal coreDrop IE6 support in Drupal core
Issue tags:+Needs committer feedback

Since we've got strong consensus on removing IE6, let's just proceed with that right now. IE6 is the biggest offender here, and dropping support for it would be a huge win for all of us, so can we please not bikeshed the discussion by throwing IE7 in here too? I think it'd be great to drop support for IE7, but we've probably got 2 years before D8 comes out, so we can always revisit the IE7 question in a few months in a follow up issue.

Hopefully Dries/webchick will chime in here soon.

Status:Active» Needs review
StatusFileSize
new13.91 KB
PASSED: [[SimpleTest]]: [MySQL] 32,195 pass(es).
[ View ]

Updated the patch. It also removes any IE6-related CSS files.

Please now we have 3 patches that removes the same code. o_O

Status:Needs review» Reviewed & tested by the community

Thanks, @Rob Loach!

Status:Reviewed & tested by the community» Needs work

If we are going to fix it here we should at least remove the ie6 hack from the reset.css file (seven theme)

Please now we have 3 patches that removes the same code. o_O

The patch I uploaded also removed all the ie6.css files as well. That was missing from the other patches.

If we are going to fix it here we should at least remove the ie6 hack from the reset.css file (seven theme)

Not sure about removing it from reset.css, as it's a CSS library from Eric Meyer, and I'm not too keen on forking external libraries that we use. I suppose since it says it's "Based on Eric Meyer's "Reset CSS 1.0", then it's already a fork anyway?

It's a modified file so I think we can remove it.
Yeah I closed all the other issues.
Now there is only this one. :)

Has still some ie6 code:
- toolbar.css
- toolbar-rtl.css

should the additional work be submitted in a seperate patch or rolled up into the main patch?

currently testing the patch as is for IE7,8,9 / Chrome (stable, canary) / Firefox 5 / Safari / and Opera

I know that there are some more exclusions to be made but I thought I'd test before I make alterations.

StatusFileSize
new50.99 KB
new46.52 KB
new46.92 KB

I'm not sure if this patch caused this glitch, but the status report page is rendered dramatically different depending on which version of IE you are using. Please review these screenshots:

... everything else looks good.

@cosmicdreams,

sounds like this issue: #1001932: Clean up Status report CSS (and IE fix)

Status:Needs work» Needs review
StatusFileSize
new14.88 KB
PASSED: [[SimpleTest]]: [MySQL] 32,173 pass(es).
[ View ]

toolbar-rtl.css didn't have any IE specific code. I've removed the IE6 code from reset.css and toolbar.css

I also noticed that there was some IE specific code in jquery.ui.datepicker and jquery.ui.autocomplete. Should we remove that code as well?

Status:Needs review» Needs work

Jquery is an external library so no :)

And toolbar-rtl has a IE6 hack

* html #toolbar {
left: 0;
padding-left: 0;
}

you can search for ie6 hacks by grepping for
* html

ah, I hear ya.

Even though it wasn't specifically labeled as a IE6 hack, because it used * html it is one. I'll revise the patch tonight and test.

Status:Needs work» Needs review
StatusFileSize
new0 bytes
PASSED: [[SimpleTest]]: [MySQL] 32,178 pass(es).
[ View ]

Here's the patch that removes the code from toolbar-rtl.css

Now for the testing....

StatusFileSize
new15.17 KB
PASSED: [[SimpleTest]]: [MySQL] 32,188 pass(es).
[ View ]

did the diff wrong, here's the actual patch

Status:Needs review» Needs work

+++ b/modules/overlay/overlay-parent.jsundefined
@@ -410,7 +405,6 @@ Drupal.overlay.eventhandlerAlterDisplacedElements = function (event) {
-  // IE6 doesn't support maxWidth, use width instead.
   var maxWidthName = (typeof document.body.style.maxWidth == 'string') ? 'maxWidth' : 'width';

this comment is removed but the following line is untouched. Either we need a new comment or the next line unhacked.

4 days to next Drupal core point release.

Status:Needs work» Needs review
StatusFileSize
new15.77 KB
PASSED: [[SimpleTest]]: [MySQL] 32,184 pass(es).
[ View ]

this patch fixes that issue.

I"ve tested IE7, IE8, and 9, I've also tested Opera and Safari. All looks good so far.

Status:Needs review» Needs work

+++ b/modules/overlay/overlay-parent.jsundefined
@@ -410,8 +405,6 @@ Drupal.overlay.eventhandlerAlterDisplacedElements = function (event) {
-  // IE6 doesn't support maxWidth, use width instead.
-  var maxWidthName = (typeof document.body.style.maxWidth == 'string') ? 'maxWidth' : 'width';
   // Consider any element that should be visible above the overlay (such as
   // a toolbar).
@@ -424,9 +417,9 @@ Drupal.overlay.eventhandlerAlterDisplacedElements = function (event) {
@@ -424,9 +417,9 @@ Drupal.overlay.eventhandlerAlterDisplacedElements = function (event) {
     }
     // Prevent displaced elements overlapping window's scrollbar.
-    var currentMaxWidth = parseInt($(this).css(maxWidthName));
+    var currentMaxWidth = parseInt($(this).css('width'));
     if ((data.drupalOverlay && data.drupalOverlay.maxWidth) || isNaN(currentMaxWidth) || currentMaxWidth > maxWidth || currentMaxWidth <= 0) {
-      $(this).css(maxWidthName, maxWidth);
+      $(this).css('width', maxWidth);
       (data.drupalOverlay = data.drupalOverlay || {}).maxWidth = true;
     }

"IE6 doesn't support maxWidth use width for IE6"
If we remove IE6 we should use maxWidth and you're using width.

I woulnd't change all the other lines I would just replace the line with

var maxWidthName = 'maxWidth';

Those other changes are a more dangerous.

Powered by Dreditor.

StatusFileSize
new12.67 KB
PASSED: [[SimpleTest]]: [MySQL] 32,212 pass(es).
[ View ]

I've revised the patch with the following modifications:

Reverted overlay-parent.js back to HEAD
Only changed my handling of maxWidthName to the recommended strategy above.

Status:Needs work» Needs review

OK, looks like a solid patch, I've previously tested on Opera, IE (7,8,9), Chrome (current and canary). Can I have this patch peer reviewed?

No time for testing, the only thing I'm "concerned" about are unordered lists inside vertical tabs. They need to be verified in all browsers.

If there are screenshots for those I can rtbc this.

Status:Needs review» Needs work

+++ b/misc/vertical-tabs.css
@@ -2,15 +2,13 @@
-  list-style-image: none; /* IE6 */

You need this for IE7, it's not an IE6 only thing.

Powered by Dreditor.

Thanks Jeff, aspillicious:

I tested the vertical menus and didn't see any specific issues. I'll look more closely to see this bug in action. Is there an issue that was created in the past that could provide more insight on what I should be looking out for?

StatusFileSize
new12.7 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch code-reviewed3.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Here's the revised patch as Jeff wanted.
Also, I've revised the comment to target IE7 instead of IE6.

Status:Needs work» Needs review

Surely it is a bad idea to actively remove finctionality in this instance?

The code is already written and working.

If it is decided to no longer support IE6, then isn't the best way to add no *new* workarounds for IE6, leaving what is there in place unless the code is actually touched in another issue?

Surely it is a bad idea to actively remove finctionality in this instance?

One of the things that makes Drupal unique and desirable to many (myself included) is the fact that it's always forwards-compatible, but not always backwards-compatible. This means there are often times when old 'features' are stripped off if they're dead weight, to allow for a leaner, better, more streamlined and awesome Drupal.

In this case, we'll save 1-2KB of data (maybe more), which is good in my book, and additionally, the development time in making sure all the IE6 specific code that's already in core isn't ruined by future improvements.

And as mentioned earlier in the thread, which I suspect nbz hasn't read fully, dropping IE6 support means css can be refactored to use more specific selectors - element > child, element[attribute], and element:first-child for example.

This can result in a further reduction of css and html size by removing the more general classes IE6 needs to target those elements, and potentially a speedup in browser rendering due to more specific selectors.

Just removing CSS won't be a big deal. Load an extra JS like IE7.js could solve 9x% of layout problem. It's a simple action we can do.

and everyone who want to save IE, please share your love:
http://drupal.org/project/issues/search/drupal?status%5B%5D=1&status%5B%...

only ONE issue is killing IE :)

Agreed with #162/#163, that probably means it's time for an issue summary.

The overall consensus on this thread has been for the following, as far as I understand it anyway:

- Actively remove IE6-specific hacks from CSS, markup and Javascript. A module or base theme could add back IE6 compat from contrib if desired, but core will no longer offer any specific IE6 tweaks. The patches here do that.

- Once this is done, go back and refactor all everything that's not so much a hack but just very dated - use modern CSS selectors, remove redundant class names etc. Removing IE6 support is a pre-requisite to that. These are all follow-up tasks though.

- Do not yet remove IE6-specific code from FAPI (checkboxes, security)- it will be much harder if not impossible to make that work from contrib, and it looks like there will still be IE6 usage in countries like China and Japan when Drupal 8 is released, so that might be a Drupal 9 issue.

- IE7 has lower usage than IE6, however any decision on that is being punted to a follow-up issue since it could happen on a different schedule.

soooooo............ can someone review this please? I'm excited to have a patch so close to being committed to core, so please pardon my excitement.

+++ b/misc/vertical-tabs.cssundefined
@@ -2,15 +2,14 @@
-  position: relative; /* IE6 */
   margin: -1px 0 -1px -15em; /* LTR */

I'm still not sure this is an IE6 only thing. I fixed a lot of stuff with position: relative in IE7. I need screenshots from IE7. No time for testing this myself now.

+++ b/modules/system/system.admin.cssundefined
@@ -243,7 +243,6 @@ table.screenshot {
.exposed-filters .filters {
   float: left; /* LTR */
   margin-right: 1em; /* LTR */
-  width: 25em; /* IE6 */

This is another thing we have to be carefull with. Where do we use this selector? We need also screenshots or manual testing for that.

These are the only two things that could go wrong. :)
So needs review as I'm not sure yet if this needs work.

Powered by Dreditor.

@droplet: let's not impose yet another unnecessary dependency on an external project, and a wonky one at best

@seutje,

ahh. YES. I should clarity in my comment before. It's just a suggestion to someone looking for quick solution :)

I will have time to test this extensively Friday night, if you tell me where the dragons are. Can you give me specific examples/pages where this code would lead to problems?

I'll work up a new patch tonight regardless.

- Exposed filters, ar the filters on top of this page for example: admin/content
- And the others are the vertical tabs. Click through vertical tabs and check if they are ok.

Please make screenshots of this in IE7.

@aspilicious: will do, I'll submit before and after patch screenshots.

this is the reasoning i think we should have

do we care for the long dead IE 5.5 for Windows 95 and IE 5.0 for Windows NT 3.51 and 3.1? No

(long done before)
reason: why? to start with, technical specs and capabilities. oh, and really old age.
heck, i still have old machines that still work, of the Pentium II and Pentium I era, and even 286, 386, 486 eras, but who cares? they can't possibly run modern sites, not even if Firefox 3 could be installed. not enough memory or CPU!
it will already be with great luck if they can run PartedMagic boot disc and access simple HTML4 sites from the bundled browsers or lynx... and if they don't, too bad. it would just be funny, not really useful.
solution: stop living in the past.

with that in mind...

i say kill IE 6 for Drupal 8

(this is being done)
reason: who will use Windows 2000, Me, NT 4 or 98 or a very outdated browser (12+yo) in 2013? no one that matters.
solution: Windows XP and Server 2003 users can use IE 7 or IE 8. easy upgrade.

and please kill IE 7 for Drupal 8 as well (2013-2014)

(postponed)
reason: it improves nothing or almost nothing HTML or CSS or JavaScript wise. it's brings mostly the GUI and library changes. IE 7 has very low usage today, now that we have IE 8 and IE 9.
solution: Windows XP and Server 2003 users can use IE 8. easy upgrade. no complications.

and what next?

IMO, kill IE 8 for Drupal 9 (2015-2018)

(future?)
reason: while IE 8 does improves things over IE 7, suffice to say, not all we want. also old age. and more over, Browser and OS version support by Microsoft and Market share - Windows XP support ends in 2014, Server 2003 in 2015.
By 2015, in time for D9 release, Windows XP will be 14 years old and Server 2003 will be 12 years old. Market share will be close to nothing, with the release of Windows 8 and beyond, and IE 10 and beyond. Even Windows Vista will get unsupported by 2017, and Server 2008 by 2018, with that ending the last resistance from IE 7 and IE 8.
solution: Windows XP and Server 2003 users should upgrade to Windows Vista and Server 2008 and beyond, and upgrade their browsers to IE 9 and beyond. or get Linux. duh...

regarding IE 10, it's likely that it will be released by 2012.
sorry for being harsh. the world has been talking IE 6 for the past 10 years and i think everyone is tired.

more reading:
* http://people.mozilla.com/~prouget/ie9/
* http://en.wikipedia.org/wiki/Internet_Explorer#OS_compatibility

I like how you make a lengthy explanation about dropping IE 5.5 support, which isn't even being argued, yet only mention a line or 2 about IE 6 & 7...

also, I hate to point out the rather well-known fact that a lot of corporate machines are locked down, this means that for those users, there is no easy upgrade and there are a lot of complications.

If you really believe IE7 doesn't bring any CSS improvements over IE6, you really need to have a look at http://www.quirksmode.org/css/contents.html & http://caniuse.com/#compare=y&b1=ie+6&b2=ie+7 etc.

and your "no one that matters" includes over 10% of the world population today, just saying...

Guys and Gals,

haven't we already established many posts ago to botch IE6 definitely and make IE7 a separate discussion?

There is work done on a patch for the dropage of IE6 so let us focus on this and reserve IE7 work for a follow-up.

that's a good idea dddave. thanks for the suggestion.

created a issue for IE 7 here:
http://drupal.org/node/1217788

regarding #174, see the comment at:
http://drupal.org/node/1217788#comment-4729760

#308865-177: Drop IE6 support in Drupal core: thanks!

@LPCA - just fyi, to create more readable (and automatically updating) links to other issues, you can use the syntax [#1217788], which will return: #1217788: Drop IE7 support in Drupal core. This is helpful for those perusing the issue that might not have the time to click through the link and read up on the linked issue.

Additionally, you can link directly to a comment by doing something like [#1217788-1], which will return: #1217788-1: Drop IE7 support in Drupal core. Just cleans things up in these longer threads somewhat, and makes it more 'human' readable :-)

Anyone want to review the patch in #159?

It'd be great to have a RTBC patch that can be committed and possibly referenced when the announcement to drop support for IE6 comes. Also, when it's RTBC it will be on Dries/webchick's radar more than it is now. ;)

Status:Needs review» Reviewed & tested by the community
StatusFileSize
new55.17 KB
new75.06 KB

I had found 2 potential problems (#161). After manual testing they are not a problem so I can mark this rtbc for the patch in #159.

Issue summary:View changes

Made summary

Issue summary:View changes

Added dots

Issue summary:View changes

Dries approval

I think this thread also needs a mention of Chrome Frame (http://code.google.com/chrome/chromeframe/), a plugin that allows IE to render css, handle javascript, and use modern html5/open web tech like chrome/webkit. Its newest version can be installed without admin access (so corporate and business users can choose to use it), and it switches on only when there's a "use chrome frame" tag in either the head or htaccess of a site (htaccess preferred).

Html5Boilerplate is using it, and has some simple explanation (http://html5boilerplate.com), while complete docs are on the Chrome developer site (http://chromium.org/developers/how-tos/chrome-frame-getting-started).

The options Google suggests are to:

a) Just use chrome frame if installed, or
b) Detect if chrome frame is installed and if not redirect to a "how to install chrome frame" page.

For a more conservative Drupal-wide implementation, I would suggest option a, or

a) + c) write a base theme drop down notification, like the notifications on http://stackoverflow.com, that would ask users to install chrome frame if they'd like the optimal site experience while using Internet Explorer.

Chrome frame isn't necessarily an IE6 issue alone -- it helps all the way up to IE9, to lessering degrees per version. The greatest gains are modernization and standardization of css and js implementation on IE6 and 7 though, and since it is a tool we can use to drop direct support for IE6 code while still supporting IE6 users I think it is a good idea to discuss it here first.

We're definitely dropping support for IE6 in Drupal 8. We'll continue to support IE7 for the time being.

Unfortunately, the patch in #159 no longer seems to apply against 8.x-dev. Asking the test bots for a re-test .

#159: code-reviewed3.patch queued for re-testing.

StatusFileSize
new12.95 KB
PASSED: [[SimpleTest]]: [MySQL] 32,956 pass(es).
[ View ]

Reroll, the changes to themes/seven/template.php in http://drupalcode.org/project/drupal.git/commit/2e7b2073 were what broke it.

Status:Reviewed & tested by the community» Fixed

COMMITTED! :)

HOORAY! :)

+1,000,000

Oh thank god, I will sleep a little easier this Fall.

#180 That sounds like a great idea for a contrib module.

YAY! dIE6

epic win baby!

good job=)

This is a prudent move.

A bolder message would be to drop support for IE7 however I guess this would need to consider the installation base in key markets to Drupals growth. The public sector in the UK is still locked into IE6, for example. By the time D8 is released I wonder will they have just upgraded straight to the latest version, leap frogging IE7 etc? Others are better informed than I on that.

@pdjohnson

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

Maybe we can get more comments on who uses IE7 specifically and what their plans for updating are.

That's the kind of data that would be great in #1217788: Drop IE7 support in Drupal core, and is going to get completely lost here since it's fixed ;)

First, I'm from China.
Second, I don't think he IE6 share will not change a lot in the future two years.

Don't let it block the step of modern web technology. It's a national shame.

I think the best solution is droping IE6 support for the default Theme and keeping the Garland (or other) theme in the core with IE6 support.

LOL. How come it's a national shame. Keep those in default theme means "Drupal still support IE6". and Garland is being kill...

Sometimes, IE6 is a good tester. When you see errors on IE6, don't think about it just a IE bug. some of them are your mistakes. It can be rewrite to get it work on IE without patch and better on those modern browsers.

Let't look into the Windows XP market share, only when people are not using XP, then they will not using IE6.

Hey all, IE6 is officially dropped, per Dries' commit in #184, so this very long issue is fixed and done.

Please post any further discussion about IE7 in #1217788: Drop IE7 support in Drupal core. We need your comments there, not here, because this issue will fall off of everyone's radar within a week or so and no further decisions will be made here.

woo, a long thread, subscriber this.

Software is just a software, it's none of business of country shame.

A vote to close comments on this issue. Anyone second that?

I would love to see comments closed on this thread.

OK I'm closing comments here. I opened #1277294: Closed comments on http://drupal.org/node/308865 in case anyone disagrees.

Please discuss dropping IE7 in #1217788: Drop IE7 support in Drupal core.

Issue summary:View changes

FRONTEND

Status:Fixed» Closed (fixed)

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

For posterity, the change notification for this issue is here: http://drupal.org/node/1569578