Problem/Motivation

Over the past decade, the general sentiment of web developers and clients has been visual fidelity to a common design across platforms. To be specific, a web site was expected to look the same on every platform. In the past couple years, as devices of all shapes and sizes flourish in the market, the expectation that a web site will maintain the same layout and appearance across devices is waning. In the coming years, desktop web experiences will become just another access point to information on the web. Drupal must evolve to support the flexible content presentation modes that web developers will demand of it in the not-too-distant future.

Given our focus in D8 on forward-looking technologies, devices and development techniques, we need to ask ourselves how much effort we should invest into support of older browsers such as Internet Explorer 6-8.

We must recognize that IE8 still holds a significant web traffic market share although this share has trended downward for years. IE8 market share fell below 13% in June 2012 (source). Even though XP users are getting updated to IE8 we can easily predict that from here to when Drupal 8 will reach its plateau of productivity (2014?) IE8 will have a marginal marketshare (considering mobile browser growth).

Considering that XP support will end April 2014 and Drupal 8 will be released August 2013 we can assume that by the time people will start to deploy D8 sites–in those scenarios where supporting old IT departments makes sense– (6-9 months after release?) XP will be almost dead and IE8 with it. (Vista supports IE9)

Proposed resolution

Eliminate layout and styling exceptions for IE8 in Drupal core.

Remove IE specific stylesheets. We should have no IE specific stylesheets in core after this effort is completed.

Drop microsoft vender properties such as filter for shadows and opacity. These destroy performance.

Use @media queries to drive layout changes. Support for @media queries in IE8- can be achieved in contrib with tools like respond.js

We dropped IE6 because it's bad layout supports. Dropped IE7 because less usage. Every reason almost same as IE6/7 issue thread.

Drupal doesn't care about "box shadow" -like effects for IE for few years. Dropping IE8, what we gain is CSS selectors only. I suggested in somewhere since D8 is based on JS enabled (html5shiv.js..etc). we could include http://selectivizr.com/ like script into CORE, enable CSS3 for everyone.

The market share of IE8has dropped about 8% in the last year. There is no way we can presume that it's market share will be insignificant a year from now. If it maintains it's current rate then it will be just above 10%. That's too many people to drop support for.

Further push back D8 adoption due to lack of browser support? I think this is a bad idea, IE8 will surely be approaching IE6's current status by D8 release, but dropping it when extended MS support for Vista isn't slated to end until 2017, is a bad decision. I would say late 2014, early 2015 is a safe bet for dropping it.

The main reason to drop IE8 is that it doesn't support html5 and media queries.
HTML5 is one of the major initiative for D8 and D8 is already the most ambitious release ever. In this sense I was expecting more support for this proposal. It's definitely bold and based on an assumption (supported by mobile growth and html5 adoption forecasts).
To be precise only XP machines are migrating to IE8 (and Microsoft will end XP support in April 2014). Vista machines can install IE9.
We need to consider that Drupal 8 will be released in August 2013. This doesn't mean that Drupal8 websites will be deployed the day after. There are early adopters, for sure, but those won't probably be the one who needs to support old IT departments (corporate). If we see what happened with D7 it will take at least 6-9 months. By then XP will be practically dead and IE8 with it.
By dropping IE8 we make ourself a favor and we stay true to the ambitious goals we set for Drupal8. We either innovate or die :)

3. Look at specific areas like the :first-child selectors for proper CSS table striping and similar, and consider providing a degraded experience on IE8 for specific features like that. Additionally where we don't drop support for IE8 completely, look at providing those selectors for IE8 via a JavaScript compat library that's conditionally served, rather than what we currently do which is embedding the logic in PHP theme functions.

All of this would make it much easier to properly remove IE8 support when the time comes.

I don't think serving a mobile layout to IE8 is acceptable for the moment

Why not? There's a difference between dropping support, and serving a suboptimal layout. Some would even argue that a smaller layout is better than a larger layout. Why is it unacceptable for D8 core to provide a perfectly functional experience (just one targeting a small window size) for IE8, and let contrib modules/themes add Respond.js or whatever the hot technology is in 18 months if at that time, some percentage of websites feel it's important to provide a large window layout for people using IE8?

@aspilicious We would eventually serve IE8 a mobile layout because we're taking a mobile first approach and since IE8 doesn't support media queries (and we decided to not include respond.js that would activate that functionality for IE8) it will get the mobile layout (in a desktop environment).

That's not the question. We *are* designing our core themes to be "mobile first". And we *are* using CSS media queries to progressively add stuff to larger screens. So the question is what to do about IE8 which doesn't support media queries. The simplest answer is "nothing: let IE8 get the default layout, which is a small one". To do anything else means more work and more code to maintain: either ie8-specific stylesheets or Respond.js or whatever. The question then becomes: what is the justification for adding this extra code to core? The answer so far has been "because websites using D8 will care about giving their IE8 users a layout that's appropriate for a larger screen". I'm questioning to what extent that answer is true, and is sufficiently true to justify it being core's responsibility rather than contrib's. I'm also wondering whether this is the correct issue to be discussing this particular nuance, since it's not about dropping support for IE8, only about dropping the requirement for core themes to provide a desktop-optimized layout for IE8. But catch requested in #1471382-51: Add IE-conditional classes to html.tpl.php for that discussion to take place here.

One can argue that adding more code and increasing processing time on IE8 actually worsens the experience by slowing down page response times. In 1.5 years, when D8 launches, and then in 2 years when usage picks up, IE8 will have a very small market share given current usage trends. Mobile, on the other hand, will be ascendant and surpass IE8 usage by a significant amount.

Making a huge exception now for a browser that will be marginal in 2 years saps resources that could be focused on improving the Drupal experience for the future, not for our present.

Serving a single-column layout to IE8 is perfectly acceptable as long as the interface is usable. To say that a single-column layout is sub-optimal is to say that our mobile design will be sub-optimal (this assumes that the single column layout will be the primary layout on mobile devices). Rather than make exception for IE8 in core, I'd rather see us make the mobile experience so killer, that interacting with Drupal through a single column layout in IE8 will be completely acceptable. And if folks want a more complex layout, they can install one of many free, alternative, modern browsers on their system. The days of making exceptions for holdout browsers really needs to be put behind us.

This would be a huge win for javascript as neither jQuery nor compatibility libraries would be needed for what we're doing in core (at the moment at least). This means removing 32kb of JS on every page. I hope we can review this in september/november.

Now, as far as functionality goes IE could break if we start implementing HTML5 elements such as canvas, video and audio. However, I see no use for that in Core. Also note that there is already a movement for implementing HTML5 form elements in Core, although they don't tend to break in IE8. See #675348: META: Support HTML5 form input elements

IE is the boat-anchor browser

Finally (and this is a very biased thing to say), we're talking about Internet Explorer here: the nightmare of all designers and developers across the universe. There will always be something wrong in IE that won't be fixed/supported until the next release. Reading another article by P. Irish on IE's browser market pollution, we're in for a world of pain regarding the lifetime/support of the new IE versions.

Bottom line: we have to draw the line somewhere. Seeing as D8 releases (or at least, is scheduled to release) near the end-of-support date for IE8: why not just draw it there?

For those that didn't read the second article:

boat-anchor browser (noun): the browser with enough users and not enough capability, holding back the potential of the web.

I second effulgentsia's and jessebeach's solid arguments in #16 and #20, respectively.

See IE8's descent. It's strong. And as Jesse already indicated: there's about two more years to go until we'll see D8 adoption. And *then* D8 must last for several years. Those are most likely the years in which the CMS with the best support for mobile will gain more market share than its competitors.

And would the typical internet user not prefer faster sites over prettier/"more typical" sites? If we agree on that: all the more reason to serve a single-column layout to IE8 users.

At the end of the day, we have a lot of work ahead of us to improve the user experience of Drupal. Making that progress is more important than trying to optimize for IE8. I'm comfortable with a single-column layout for IE8 users, especially if that means we see velocity improvements elsewhere in the project.

Making this issue a meta issue. I suggest opening similar new policy issues for other specific suggestions (e.g., an issue for removing Drupal custom even/odd classes in favor of :nth-child selectors and allowing core themes to therefore lack zebra striping in IE8) for whatever someone wants to make a case for, though realize that Dries might be less willing to accept these other kinds of degradations.

Personally, sometimes I preferred normal views of the sites in my phone. Display single column to 30% of IE users is a big idea. This is killing the user experience of Drupal and the relationship of Drupal developer & their boss (especially, the small team & solo developers). Your customers won't believe single column is better than normal view in IEs. Okay, we can choose D7 for it. But at the time of D8 release, will newbies choose an OLD version for long time development?

In the other way, dropping IE MQ supports, we can add respond.js to solve this problem. But is it work perfectly ?

@kristiaanvandeneynde,
Yeah. China marketing is difference. But I can tell you a real case, one of my friend remove Chrome and back to IE9 after one week trial. He told me that Chrome is no diff, not faster than IE9. :-/

@droplet: It's not about being faster, it's about being better. IE has been absolute shit for the last decade. As long as Microsoft keeps inventing its own standards, its browser will remain sub-standard (pun intended).

The sheer fact that IE still won't implement WebGL is a great example of why people should abandon IE altogether: Microsoft only intends to implement those standards that don't compete with its own product line. Same goes for WebM, although Apple is being a little <insert favorite curse word> about that one too.

Finally: mobile first is the future. The author of the article you linked to has no clue what he's talking about, as in his first point (Letting the Browser Scale Images is a Bad Idea) he already assumes the developer is going to load full-scale images for mobile browsers.

Regarding "choosing D7 if you want a non-single column layout on IE8": that might actually make *more* sense. Companies who tend to evolve/update their workstations very slowly are also likely the companies that only want to use "mature" technology, which means they likely won't use Drupal 8 until 2015–2016 anyway?

Companies who tend to evolve/update their workstations very slowly are also likely the companies that only want to use "mature" technology, which means they likely won't use Drupal 8 until 2015–2016 anyway?

RE: #29, Yes, the distinction needs to be made that we're not "dropping support" for IE8.

If we're going to put HTML5 elements in core, and we are doing this, then we need to include the HTML5 Shiv script. Otherwise, IE8- will break. Breaking is much different than displaying content in a simple layout. Breaking means content can't be accessed and interactions are broken. Breaking is unacceptable. Formatting layout according to the capabilities of an agent is future-proofing.

I hope we end up landing in a good middle ground where IE users can access all the functionality of Drupal in version 8 and where we aren't burdened with the lacking capabilities of older browsers.

We should, however, stop going out of our way to make things look or feel the same in IE8. If people want to use an inferior browser, they should learn to live with an inferior user experience.

As for implementing the html5shiv: that script has nothing to do with media queries. Even if we do add it, mobile first designs will still show up as single-column lay-outs in IE8. So let's hold our horses on adding yet another script to make up for IE's shortcomings?

@kristiaanvandeneynde, the HTML5 shiv is like a little kick that makes IE recognize HTML elements that have been introduced since IE8- minus browsers were launched. It's necessary to prevent complete failure in the rendering of HTML5 elements and styling of those elements.

@jessebeach I know what the html5shiv is and does. Please reread my earlier comment: it has nothing to do with media queries. Media queries are the reason IE8 would get served a single column layout instead of a full sized one.

As I understand it it's a case-by case choice where supporting IE8 would be too much work to be worth it. Or if the IE8 solution adds a whole lot of code to maintain/load that would have a negative effect on performance.

@droplet: this has become a meta issue, meaning it is more of a policy discussion than an actual fix for one specific problem. As soon as this issue gets a decent issue summary, the discussion can continue in an orderly fashion.

EDIT: In continuation of what @nod_ posted in #41:
we're not dropping IE8 as a whole just yet, but some opinions were put forward in favor of dropping the extra code that is required just to make a website look evenly nice in IE8.

For instance, we could not spend time on making IE8 show a desktop sized version in "mobile first" themes. Additionally, we could drop all zebra/striping logic in favor of nth-child pseudo selectors.

Rather than changing the issue summary, I think it makes sense to now consider this a duplicate of #1507960: [meta] Isolate and/or remove IE-specific hacks in core markup, CSS and JavaScript, since as I understand it, the conclusion of this issue is that we still want sites to work in IE8, but are willing to accept less optimal styling in some cases. I think that other meta issue is the best place for collating which CSS we're willing to drop entirely for IE8, and which we require to keep but need to isolate.

I think we need to be careful with dropping IE8 support. If people choose not to update their browser, they should be fine with a less beautiful website. However, considering how long the web world has been sticking with IE6, dropping code that may break a site entirely in 8, is perhaps too early.

People who only use an outdated browser, will not notice when rounded corners or zebra striping is missing. They will notice when a site breaks though and that I think, is not acceptable. It may be 'evolve or die', but the evolve part in that takes time. I doubt we want to scare people by being radically against these browsers (while many are not ready for this yet), for they may choose to abandon Drupal.

@mhlut, I think everyone in this thread is in agreement with your observation. We can't break IE8, because we must assume that if IE8 renders a broken site experience, then other devices will have a broken experience as well.

The intent of this effort is to

Eliminate as much as possible exceptions for IE in the core codebase. We don't want device-specific code in what should be a device-agnostic platform.

Make core work on any device, to the extent of that device's capabilities.

Of course (2.) is open to interpretation because a device's abilities can be augmented with JavaScript, such as building dropdown menus, which are native to no device right now. To the extent that fancy styling such as columns don't enable information access but simply make it more pleasant, we can eliminate these exceptions in core.

No one here thinks that a broken experience in IE is acceptable. I think we're debating what level of degraded experience we're willing to live with. And of course, contrib will always have the ability to layer in layout and presentation complexity for older browsers when a project requires that kind of investment.

It's always good to remind ourselves what we, in the Drupal Community, mean by non-support for IE8.

No special layout or styling consideration will be made for IE8. Users of IE8 will get the basic page layout, what one might call the mobile layout. All administrative functions and data manipulation will be possible just as it would be on a small screen.

The experience of Drupal, both administrative and end-user, cannot be broken on IE8. It can be simple and unsophisticated.

The experience of Drupal, both administrative and end-user, cannot be broken on IE8. It can be simple and unsophisticated.

That correctly reflects the current decision. This issue still has a "revisit before release" tag, and given Google's decision to fully drop IE8 support from their apps, and some of the discussion on tsvenson's blog post, it's possible this may yet change, but only Dries can make that call.