Match does not fire in IE8 about enquire.js HOT 25 CLOSED

Noooo, anything but IE! Only joking. I've got access to a VM with IE8 installed, so will investigate. Can't remember how good the dev tools are in IE8 so may be a tricky one. Will keep you posted, I suspect it's going to be something simple.

And massive thanks for preparing a test case, life would be much more pleasant if everyone was so thoughtful :)

from enquire.js.

OK the bad news is: IE8 has very limited support for media queries. It has no support for inline CSS media queries, and even at the attribute level on a <link> element it is not very capable.

The matchMedia polyfill helps for browsers which don't have the matchMedia API (sounds obvious when you say it like that!), it doesn't bestow full media query suport for older browsers. IE8 only seems to support things like media="print" and media="screen", anything beyond that will simply not work.

See the updated fiddle here: http://jsfiddle.net/vabD4/8/, you will notice that this is matching and the match callback is being executed.

I know this is probably not what you want to hear, and I'd be frustrated being asked this, but can you just forget about IE8? Not completely of course, but just from a progressive enhancement perspective does it really matter if IE8 doesn't get a super responsive site?

from enquire.js.

And one last thing: nice to see you come over here from CSS tricks :)

from enquire.js.

Thanks for having a look. I guess my confusion came from the "Legacy Support" section of the documentation which implied (to me) that including the matchMedia polyfill would allow matches beyond IE8's limited support.

I'm finding it too early to not at least give IE8 a "desktop" design as that is the browser that many clients use. There are two ways I have been doing this:

• using respond.js
• serving IE8 a separate stylesheet compiled using a Sass wrapper function (ie. respond-to() ) to "unwrap" CSS from their media queries

Both of these methods require that (at least) the "desktop" relevant JS fires. Examples of this type of "must have" JS:

• Ajax to bring in the code for a feature slider when the media query matches "screen and (min-width: 39em)".
• Initialise Superfish dropdown code on "desktop" menu (when mobile nav solution no longer suits)

Using my current seat-of-pants ways of doing responsive JS I have gotten around IE8's lack of media query support by simply adding a "or is IE8" condition to the the "if" statement that checks for screen width, thereby being able to say whether IE8 gets that (desktop only) JS on a case-by-case basis.

I spent some time last night rewriting some existing code to use enquire.js and found that being able to fire JS in both directions of media query changes (match, unmatch) is a real boon for responsive designs! For example, you can actually re-initialise or destroy() JS widgets rather than just hiding them with CSS, and you can even remove them from the DOM when not needed (helping mobile rendering) and reinsert them when they are. Unfortunately, without a flag to say "also fire this if IE8 regardless of the result of the media query" I can't use enquire.js while I still need IE8 support.

Here's a long shot, and I know all of these suggestions are really ugly, but I thought I'd list them out to try and illustrate what I think a potential solution could be. I'm sure greater minds could think of something better. Would it be possible to add a feature so that something like the following is possible?

enquire.register("screen and (min-width:39em) or IE8", {
  // handlers here will apply to the matched/unmatched query *OR* IE8
});

Or—now that I think about it— maybe an alternate method that you could choose to use instead of enquire.register which, in addition to checking the media query string, will also run the contained handlers in any browser that does not support complex media queries:

enquire.register_legacy("screen and (min-width:39em)", {
  // handlers here will apply to the matched/unmatched query *OR* browsers that don't support complex media queries
});
enquire.register("screen and (max-width: 38.99em)", {
  // these handlers are applied via the regular 'register' method, so non-supporting browsers will not run them.
  // We could use this when the JS is relevant only to non-desktop sizes
});

Or even an optional boolean argument for the existing register method that allows you to set whether the handlers should apply to browsers that don't support complex media queries:

enquire.register("screen and (min-width:39em)", true, {
  // handlers go here
});

Sorry for the long post and—if you made it this far—thanks for reading. I just don't want to give up on using enquire.js after seeing how it can improve my mobile-first sites. If you don't want to taint your code with these sorts of workarounds I fully understand. Keep up the great work!

:)

from enquire.js.

I see your dilemma. For a mobile-first solution it would be problematic for scripts not to fire in IE8. Apologies about the confusion caused by the website, my fault really - I made the cardinal sin of assuming IE8 was semi-capable when it came to media queries. Assuming anything of any IE <9 is asking for trouble! I will tidy up the wording on the site to make this clearer.

I spent some time last night rewriting some existing code to use enquire.js and found that being able to fire JS in both directions of media query changes (match, unmatch) is a real boon for responsive designs! For example, you can actually re-initialise or destroy() JS widgets rather than just hiding them with CSS, and you can even remove them from the DOM when not needed (helping mobile rendering) and reinsert them when they are.

This is exactly why I wrote enquire, so many possibilities are opened up by being able to work on the DOM in relation to media queries. Hiding/showing elements using CSS just isn't enough for any reasonably complex responsive design, so it's good to hear my thoughts have been validated!

Now! Let's try to work out an answer to the problem :) Ideally, any solution would be lightweight and easy to utilise.

I'm not particularly keen on the first idea, introducing a slightly modified query syntax could get confusing for consumers of the library, and means I'd have to introduce code to start parsing the string.

The other approaches are more appealing, if we could reliably test how extensive a browser's support of media queries is. As far as I can tell there isn't any way to do this without resorting to running an exploratory suite of tests to determine capability (on say page load). This wouldn't be too difficult, but should you then blindly apply every media query (after deciding a cut off point for support) or should you try to work out which media queries are supported? That could get complex!

One very simple solution that you can do right now - before i try to work something into enquire - is as follows...

First, use H5BP style <html> definition:

<!--[if lt IE 7]> <html lang="en" class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>    <html lang="en" class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>    <html lang="en" class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html lang="en" class="no-js"> <!--<![endif]-->

Now you can target browsers which aren't capable with a little extra javascript. It's easier at this point to show a working example, so check out this updated fiddle (i've had to substitute the <html> tag for a <div> here mind because i don't think you can manipulate the <html> tag in JS Fiddle, but principle is the same). http://jsfiddle.net/vabD4/10/

I may have stumbled across a simpler solution than this, which wouldn't require any extra code, just another clause in your media query. I will test and get back to you as it would definitely be a neater solution

from enquire.js.

OK my super backup plan that I alluded to does not in fact work, very sad. Basically, this article on smashing magazine (see technique 3) led me to believe that a media query such as:

@media screen, all and (min-width: 500px) {
    /* code here */
}

would be applied by IE8 unconditionally, and would be applied by all capable browsers only if the second condition was met. Whilst IE8 does in fact apply this unconditionally (because it understands the screen part), it seems that capable browses apply the media query unconditionally as well. Guess it makes sense if you consider how CSS selectors usually work. Such a shame.

Back to the drawing board...

from enquire.js.

A shame indeed! That would have been very cool. Seems like its current behaviour has very limited use.

The workaround you described in your previous comment is identical to what I came up with. Maintaining a separate list of functions for IE8 to run isn't DRY but it's probably worth it for the benefits enquire.js brings to other browsers/devices.

Thanks for your time. I really appreciate your work.

from enquire.js.

You know what they say about great minds :) Yeah it's not great, but it's a good stop gap. But stop gaps are never great in the long run and I'm committed to making enquire as useful as possible.

So with that in mind, i have added an optional third parameter to the register method as a short circuit. If this is set to true and enquire deems the user agent incapable then the match callback will be invoked regardless of the media query. The browser is deemed incapable if it does not recognise the media query "only all" (this seemed like a decent cut-off point). Note however, this is done at a query level and not a handler level. So if you have multiple handlers registered for a single query they will all degrade, even if they aren't registered at the same time.

I've not yet committed the code as I want to do a little more testing, and get confirmation from you that this is an acceptable solution. Look forward to your feedback, especially around my assumption of the short circuit being set at query level rather than handler level.

from enquire.js.

Sounds good to me, although I don't quite grasp what you mean with regards to query level vs handler level—I'm pretty dim ;)

So if you have multiple handlers registered for a single query they will all degrade, even if they aren't registered at the same time.

Given the following code where handlers are set to the same query but at different times, and the optional parameter is set to true only in the first 'register', are you saying that all five handlers will fire in IE8? I think what I would like to happen in this case is that IE8 would run setupFunc and handlerA as soon as the page loads, and never run handlerB, handlerC or handlerD.

enquire.register("screen and (min-width:39em)", {
  setup: setupFunc,
  match: handlerA,
  unmatch: handlerB
}, true);

enquire.register("screen and (min-width:39em)", {
  match: handlerC,
  unmatch: handlerD
});

That said, I think I've reached the extent of my brain-power, so I may only be confusing the issue now!

from enquire.js.

You've got it precisely right. enquire has a many to one relationship with media queries, and the media queries have a many to one relationship with handlers. As I've written it now, the shouldDegrade param is applied to the media query rather than the handler, as the handler is like a delegate, it does not know which query it is registered against and it's callbacks are invoked by the media query not the handler itself. I'll have to have another look at it if you think it would be more useful to have shouldDeagrade applied at the handler level, as that may be more tricky given the currect architecture.

FYI, the setup function is always invoked at page load, even now (unless, of course you, set the defer flag). Also, when this fix is finally committed, IE8 and other incapable browsers will never invoke the unmatch callback as the query is never technically matched, thus it cannot be unmatched.

from enquire.js.

I see. Your explanation has cleared up how setup and deferSetup work for me, so thanks for that. Also, I like that unmatch will never fire for IE8. That makes perfect sense.

I'm now thinking maybe it will be enough that shouldDegrade is applied at query level. Really looking forward to having a go at using enquire.js with this feature added, now! Thanks again Nick!

from enquire.js.

OK cool, I'm going to thoroughly test my changes tonight and hopefully get it committed, meaning you should have a brand spanking new version by tomorrow morning :) I'll then update documentation in due course.

I think my next task is to thoroughly improve documentation, add lots of examples etc. If you've got any interesting use-cases that you think would make good examples for the docs please feel free to share.

from enquire.js.

Fix committed! I even went as far as testing all the way back to IE6, works like a charm. Enjoy :)

from enquire.js.

Hey Joel, did you get a chance to test this out?

from enquire.js.

I haven't had chance yet, but I'm itching to get to it! Sorry for the delay in responding.

from enquire.js.

Sweet! Keep me posted if you do encounter any further issues when you get to it.

from enquire.js.

My 2 cents : the true parameter comes handy and works for me on IE 7 & 8. Such an interesting discussion here, thanks again for your work @WickyNilliams !

from enquire.js.

Thanks @nicooprat! Glad to hear everything is working well for you and you enjoyed the discussion. I love how open source allows this type of iterative improvement, amazing stuff :)

from enquire.js.

Right ! Glad to see you glad ;P

from enquire.js.

Thank you so much for this! You really saved my ass there :)

from enquire.js.

Haha seems this was quite the popular feature!

from enquire.js.

Did I missed something? The fiddle test by joel doesn't work on IE9 http://jsfiddle.net/vabD4/5/

from enquire.js.

I've done a little investigation and it seems IE9 will block hot-linking of resources from github repositories because of a MIME mismatch (github serves as text/plain instead of application/javascript). You can see this message being displayed in the console, followed by an exception "enquire is undefined" - which makes sense if it's been blocked.

If you clone the repo to your local machine, point a server to the root of the repo, and navigate your browser to /demo you will see it in action.

from enquire.js.

Works great for fallbacking mobile first with bad old androids as well.

from enquire.js.

@vicenterusso I also cannot get this to work on IE9.

from enquire.js.