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

Advantages

  1. Native support for media queries (no need for respond.js)
  2. Native support for media (video and audio). Take a look at the amazing work going on here to introduce media support to Drupal8 (http://drupal.org/project/html5_media)
  3. Various useful selectors :first-child :last-child :nth-child (pure css striped table)
  4. multiple-backgrounds and other background properties
  5. border radius
  6. box shadow
  7. The envy of those stuck in a dark era
  8. Inner Joy

Comments

dodorama’s picture

Jquery mobile has an interest way of grading browser support.
http://jquerymobile.com/gbs/
IE8 could still be served but with a Non enhanced still functional experience?
Some references
http://jonikorpi.com/leaving-old-IE-behind/
http://msdn.microsoft.com/en-us/hh550089

droplet’s picture

1. html5shiv is no harms for non-IE
2. no harms for non-IE
3. no harms for non-IE
4. It's a problem
5. no needs for Drupal Core ?
6. Doesn't a big problem ?
7. no needs for Drupal Core ?
8 ~ x. Doesn't a big problem ?

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.

droplet’s picture

Issue tags: +IE, +Save IE

tagging ie issues since we can't search for 2 chars.

LewisNyman’s picture

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.

As nice as it would be. It's not realistic for Drupal 8.

aspilicious’s picture

This is a no go for drupal8 for me. People with xp can't upgrade to IE8.
And comments like: "they can install chrome or firefox" are not valid.
AND in china they are replacing IE6 with IE8.

KrisBulman’s picture

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.

dcmouyard’s picture

I'm also against dropping support for IE8 in D8.

webchick’s picture

Status: Active » Postponed
Issue tags: +revisit before beta

Sounds like we should postpone this then. Tagging with a tag to revisit before release to see if things have changed, but 2017 support for IE8 sounds like no earlier than Drupal 9 or 10 to me...

JohnAlbin’s picture

I just learned that there are some IT departments migrating from IE6 to… IE8! Doh! So IE8 may not continue declining as it has been. We'll have to wait and see.

nod_’s picture

I know a lot of companies that are on WinXP and IE9 doesn't work on XP.

WinXP SP3 extended support will end April 8, 2014. SP1 and SP2 are not supported anymore. http://windows.microsoft.com/en-US/windows/products/lifecycle I hope that by that time companies will think about migrating to W7 or W8. Browser support is tied to Win version.

Can't drop IE8 for D8, it's the new IE6. We don't have a 9.x branch yet? þ

See you in two years :D

dodorama’s picture

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

dodorama’s picture

Issue summary: View changes

Added Summary template

catch’s picture

I don't think serving a mobile layout to IE8 is acceptable for the moment, but I'd definitely like to revisit this in six months or so to see how usage stats have changed.

What I'd be much more interested in is the following:

1. Properly follow-up on the dropping of IE6 and IE7 to modernize our CSS, JavaScript and markup to remove hacks. Some of this is ongoing but I'm sure there's more to do.

2. Identify any remaining hacks in core that deal with IE8 specifically, and ensure they're properly documented as IE8 hacks and not hidden away - whether that's separate stylesheets or the .ie8 selector proposed in #1471382: Add IE-conditional classes to html.tpl.php.

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.

effulgentsia’s picture

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’s picture

IE8 is only usefull on desktops, there is no internet explorer 8 on mobile devices. WHY would we make a mobile layout for IE8?

dodorama’s picture

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

effulgentsia’s picture

WHY would we make a mobile layout for IE8?

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.

LewisNyman’s picture

Absolutely not. We can't serve a poor design to a significant number of users if we are providing a theme we actually want people to use out of the box.

And yeah, it's a poor design. Optimal line length anyone?

klonos’s picture

Optimal line length anyone?

Are you actually asking here Lewis?

droplet’s picture

Response designs should be work in any uncertain cases. It can be serve a normal view to non-supported devices.

Why need a specific stylesheets for IE8 ? (even not use respond.js. serve a large screen view ?)

anywhere I can get a summary of exist "Mobile First Design Plan", Thanks.

jessebeach’s picture

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.

catch’s picture

I never got back to #13, but fwiw effulgentsia's point is a good one and I don't have a particular objection to degrading on IE8 in that way at all.

catch’s picture

Issue summary: View changes

Added detail on XP life cycle and D8 release

nod_’s picture

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.

droplet’s picture

kristiaanvandeneynde’s picture

@droplet: China gives a very distorted view because of all the pirated Windows XP (and thus IE6-IE8) copies.

"Breaking"

I support the idea of thinking this through before postponing it to D9. IE8 can't really break the way IE6/7 broke as far as CSS goes. The worst it could get is that you seem to try and watch a colored movie on a black and white tv. There is a very interesting article on this Tiered, Adaptive Front-end Experience (TAFEE), written by front-end expert Paul Irish.

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.

Wim Leers’s picture

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.

Dries’s picture

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.

catch’s picture

Status: Postponed » Active

OK moving this back to active :)

nod_’s picture

Don't get my hopes up, if this is active and we're allowing JS to break — depending on #1532996: [Policy, no patch] Strategy for dealing with javascript in IE6/7 — It's possible to remove 32kb of JS and speed up the rendering by 20ms on desktop and 200ms on mobile for every drupal pages. It would also end up fixing the biggest JS issue we have right now: #1279226: jQuery and Drupal JavaScript libraries and settings are output even when no JS is added to the page.

So, can we have some scope about all those "Drop support for IEX" issues please?

effulgentsia’s picture

Title: Drop IE8 support in Drupal core » [meta] Drop some IE8 coddling from Drupal core

if this is active and we're allowing JS to break

I do not read #26 as implying we allow IE8 to break. I spun off the specific #26 decision into #1645494: Allow core themes to display single-column on IE8: do not compensate for lack of media query support.

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.

droplet’s picture

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?

and is it the best deal? the "mobile first" plan solving all these issue? will it increase the difficulty of create a separated mobile & desktop views?
http://blog.cloudfour.com/css-media-query-for-mobile-is-fools-gold/

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. :-/

kristiaanvandeneynde’s picture

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

Don't blindly believe every blog post you read.

Wim Leers’s picture

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?

Also, here's a way to easily rerun the tests @droplet linked to in #30: http://timkadlec.com/2012/04/media-query-asset-downloading-results/ (the blog post @droplet linked to was from 2010, this one is just a few months old).

kristiaanvandeneynde’s picture

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?

Well said, couldn't agree more.

jessebeach’s picture

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.

kristiaanvandeneynde’s picture

I agree we shouldn't break IE8.

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?

webchick’s picture

Let's get an updated issue summary in place. The issue summary and recent comments don't seem to be in-line at all.

jessebeach’s picture

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

Here's the src: https://github.com/aFarkas/html5shiv/blob/master/src/html5shiv.js

@webchick, I'll update the description.

jessebeach’s picture

Issue summary: View changes

Updated IE8 Market Share at June 2012

kristiaanvandeneynde’s picture

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

effulgentsia’s picture

Summary for this meta issue does need updating. In the meantime, here's a new specific issue for nth-child selectors: #1649780: Remove first/last/odd/even classes in favor of CSS3 pseudo selectors.

droplet’s picture

Anyone commit this issue??

Does it drop MQ supports ? Drop JS ? Drop all IE8-specific CSS??

For example:
#1458216: Border-right of any admin table with a grippie is not visible (IE8)
This is a fix for the layout.

nod_’s picture

Well no we're not forsaking IE8. JS has to work on it.

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.

kristiaanvandeneynde’s picture

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

effulgentsia’s picture

Status: Active » Closed (duplicate)

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.

MHLut’s picture

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.

jessebeach’s picture

@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

  1. 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.
  2. 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.

droplet’s picture

Supporting modern browsers: Internet Explorer 8 support discontinued
see: http://googleappsupdates.blogspot.hk/2012/09/supporting-modern-browsers-...

KrisBulman’s picture

This is a pretty big move for Google, and they are the best ones to push the mark forward. Most of my hesitations and worry around this ticket have now subsided.

wusel’s picture

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

jessebeach’s picture

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.

effulgentsia’s picture

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.

effulgentsia’s picture

Issue tags: -revisit before beta
effulgentsia’s picture

Issue summary: View changes

Updating issue description to reflect the current state of the discussion.