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

Closed
scottjehl opened this Issue Jun 2, 2011 · 11 comments

Comments

Projects
None yet
4 participants
Contributor

scottjehl commented Jun 2, 2011

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!

Owner

paulirish commented Jun 2, 2011

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

SlexAxton commented Jun 2, 2011

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)

Owner

SlexAxton commented Jun 2, 2011

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.

Owner

KuraFire commented Jun 2, 2011

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.

Owner

KuraFire commented Jun 2, 2011

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

Owner

SlexAxton commented Jun 2, 2011

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.

Contributor

scottjehl commented Jun 2, 2011

slexaxton: sure thing :)

Owner

SlexAxton commented Jun 2, 2011

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

@SlexAxton SlexAxton closed this Jun 2, 2011

Contributor

scottjehl commented Jun 2, 2011

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

Owner

paulirish commented Jun 2, 2011

L234 to 385 could be completely replaced with Modernizr.mq('only all')

Right?

that's pretty simple, i'd say.. your completely bizarre architecture pays
off! :)

Owner

SlexAxton commented Jun 2, 2011

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