Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Consider including Respond.js as an option in the builder #286

Closed
scottjehl opened this Issue · 11 comments

4 participants

@scottjehl

Hey, Paul asked me to file a ticket for this one.

It's becoming common for people to include both Modernizr and Respond.js in a page (the H5BP and 320andUp both recommend it as well). When building a responsive design -- particularly one that's mobile-first -- a media query polyfill (like Respond.js) is similarly important to an html5 shim: without it, the styles won't apply as written.

Respond.js includes its own media query check that is redundant with Modernizr's mq method, so it'd be cool to have it borrow that one instead of including its own. That'd be one benefit to its optional inclusion; there are probably others.

One restriction is that Respond.js needs to load and block from HEAD, otherwise you'll get a fouc in IE 6-8 and any other non-native media query supporting browsers.

If there are any improvements / changes that could be made to Respond so that it would be easier to include as a builder option, I'm happy to help with that (and very happy to take suggestions).

The repo's here https://github.com/scottjehl/Respond

thanks!

@paulirish
Owner

challenges:

  • it needs to be synchronously loaded
    • which means a doc.write internal for yepnope i suppose?
    • unless we just inlined the whole thing

notes:

  • afarkas wants to split up IEPP so the printing aspect is separate. if so, i'd be interested in yepnope'ing in that part .. (the createElmenet loop woudl be inline but the print hookups would be lazy)
@SlexAxton
Owner

I think if it were in the build, it would be best inlined, for sure.

+1 on making printing async (maybe even on an intentional delay, so it doesn't even slow other downloads down, since most people don't load and immediately print)

@SlexAxton
Owner

Also, it's super easy to add to the build tool (inlined). If it's a common use, I'm totally cool with adding it in.

@KuraFire
Owner

I'm fine with it being inlined, just like the HTML5 shiv / IEPP is, and just like yepnope when you include Modernizr.load() in your build.

@KuraFire
Owner

If we're inlining it and adding it to the build cool (I'm in favor), we need to update the documentation to reflect that feature, and explain how to use it (even though it's technically automatic).

@SlexAxton
Owner

Scott, if we gave you commit rights to the site (you may already have them), could you be the man on point to keep respond up to date? That's my only concern. It should just be a single file update, from old to new. It would be great to always have the most recent (released) version in the builder, as I know it's pretty new and likely to change for a few more months.

@scottjehl

slexaxton: sure thing :)

@SlexAxton
Owner

Seems like everyone is plus one. I'll get it in ASAP.

@SlexAxton SlexAxton closed this
@scottjehl

nice. Any recommendations on eliminating redundancy for Respond.js' media query support check? Hmm... not sure it'd be ideal to maintain two versions, but I'm not against the idea.

Right around here things start to get repetitive: https://github.com/scottjehl/Respond/blob/master/respond.src.js#L256

@paulirish
Owner
@SlexAxton
Owner

I have it working locally, paul, you wanna jump in and refactor the obvious stuff (and wrap in comments so updates are easy)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.