Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to support browsers that don't support Media Queries (probably just IE8) #801

Closed
wesruv opened this issue Mar 5, 2015 · 6 comments
Closed

Comments

@wesruv
Copy link
Member

wesruv commented Mar 5, 2015

We're doing mobile first CSS which would look like:

.widget {
  /* Default and Mobile Styles */
  clear: both;
  background: #fff;
  color: #000;
}

@media only screen and (min-width: 600px) {
  .widget {
    /* Only changes things that change on screens 600px and larger */
    float: left;
    clear: none;
    width: 33.333%;
  }
}

Problem here is IE8 wouldn't see any of the styles in the @media query, and those users are likely to have a viewport above 600px.

CSS class to add desktop styles for IE8

Adds a lot of extra work, but light in performance
The solution I generally use is getting a class on the html tag for IE8, or do a media query test with modernizr. This requires little to no effort on the part of the IE8 user (who's computer is likely terrible). This means we'd have to find all of our media queries and add something like:

@media only screen and (min-width: 600px) {
  .widget {
    /* Only changes things that change on screens 600px and larger */
    float: left;
    clear: none;
    width: 33.333%;
  }
}

.lt-ie9 .widget {
  /* IE8 and below styles */
  float: left;
  clear: none;
  width: 33.333%;
}

JS Polyfill

Less work implementing, but may have a performance hit for IE8 folks
Another option is using a good polyfill. I don't have as much experience with these, after a quick googling @quicksketch found https://github.com/scottjehl/Respond which seems like a good option. Be good to hear if anyone knows of good ones or has experience with this one?

Or... we could 'partially support' IE8

Meaning, IE8 would get the mobile CSS (because it can't interpret the desktop css in the media queries) and we are more specific about the level of support Backdrop has for IE8.

@wesruv wesruv changed the title Support for browsers that don't support Media Queries (probably just IE8) How to support browsers that don't support Media Queries (probably just IE8) Mar 5, 2015
@pablo-romero
Copy link

I don't want to look like some sort of "IE8-hater", but I'd go with the last option. IMHO the first option is not worth the effort.

A JS Polyfill could also be fine, because the performance penalty only applies to IE8 users.

I used respond.js some time ago and it works pretty well with css3 media queries & IE8.

The only problem with Respond is that it only covers that part, so most of the times you also need html5 polyfills (html5shiv.js) to make IE8 understand html5 tags, a whatever.js...
With something heavier like modernizr.js you can customize all the features you need in a single file. It's also useful e.g. when you want to use SVGs or rems without specific fallbacks for IE. It conditionally loads the necessary scripts (client-side), based on the lack of features it detects.

@tarekdj
Copy link
Member

tarekdj commented Apr 26, 2015

👍 @pablo-romero I think a JS Polyfill is totally fine

@quicksketch
Copy link
Member

The only problem with Respond is that it only covers that part, so most of the times you also need html5 polyfills

We already include html5.js for IE8, so we're covered for making it recognize HTML5 elements at least. If respond.js does an adequate job, that seems like the least work. We're committed to IE8 support for the 1.x release.

@wesruv
Copy link
Member Author

wesruv commented Apr 28, 2015

The current large scale site I'm working on for a client that QA's the crap out of everything is using respond.js for this exact thing and they don't have any complaints.

I'm for it!

@Dinornis
Copy link

Dinornis commented May 4, 2017

@wesruv Should we close this in favour to #214 ?

@jenlampton
Copy link
Member

yes :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants