Interoperability: Enquire.js doesn't execute Respond.js fired css media-queries - media-queries

OK, so I use Respond.js a polyfill for mediaqueries on legacy browsers (ie8 being the most important).
At the same time I'm investigating in using Enquire.js which enables executing js-code based on media-query matches.
Tested in isolation this stuff works:
respond.js executes media-queries defined in css correctly for IE8
enquire.js executes javascript code correctly based on media-queries matching css. (for NON-legacy browsers)
However the combi doesn't seem to work. I.e:
Enquire.js doesn't execute javascript based on a media-query which gets enabled through respond.js (for legacy browsers)
Since Respond.js contains Paul Irish's polyfill for MatchMedia which (as per: Enquire's documentation) should be enough for legacy support, I'm not sure what could be wrong.
So just to be checking: this combination should work right?

I'm the author of enquire, so i'll help where i can.
I've just browsed through the respond.js source to find out how it works. Respond extracts any media queries from your CSS, then depending on the width of the window it will create new style blocks containing that CSS if the media query matches (this is why it only supports simple media queries such as max/min-width). This of course means that it will not help enquire JS, as it is simulating media queries.
The inclusion of the matchMedia polyfill is actually a red herring. All that does is create an equivalent to the matchMedia browser API. Thus if the browser only supports very limited set of media queries (as IE8 does), it will not expand it's capabilities, it will only allow you to work within it's means. I made this mistake myself at first!
I don't know if this will help you, but enquire's register method can accept a third parameter, shouldDegrade which is a signal to enquire that you intend the functionality to always run if the browser is deemed incapable. Thus if you pass in true, the match function will always be executed for incapable desktop browsers (whilst still being conditional for capable browsers). This will allow you to deliver a desktop experience to older browsers, especially useful in mobile-first approaches.
Happy to help further if you have any more questions

Try removing the inclusion of matchMedia from respond.js, and then loading match.media and enquire.js after respond.js. Worked for me in IE 7 and 8 with enquire v 2.0.2.

I found a solution that seems to work for IE8
1.Very important ! Remove match.media from respond JS if you use it (if not it will silently fail in IE)
2.Include Modernizr with at least mediaqueries testing, load, shiv : http://modernizr.com/download/#-shiv-mq-cssclasses-teststyles-load
3.In < head > (because we need respondjs in head)
<script src="../../common/vendor/modernizr/modernizr.custom.js"></script>
<script>
Modernizr.load([
// Test need for CSS media query polyfill
{
test: Modernizr.mq("only all"),
nope: "../../common/vendor/respond/respond.min.js"
}
]);
</script>
4.Before < /body > tag to load polyfill and your scripts
<script>
Modernizr.load([
{
test: window.matchMedia,
nope: [
"../../common/vendor/polyfills/media.match.js",
"../../common/vendor/polyfills/matchMedia.addListener.js"
]
},
'../../common/vendor/enquire/enquire.min.js',
'../../common/scripts/script.js'
]);
</script>
I hope it will work for you !

Related

Why is PhantomCSS moving the HTML elements around?

Problem: when I use a visual regression testing tool such as PhantomCSS, the screenshots produced contain the website with dramatically moved HTML elements.
Problem image:
How it should really look like: (taken from esfiddle.net )
Tools: PhantomCSS. The same problem happens with BackstopJS.
What can I do to prevent the problem image?
The flex CSS property is causing the problems.
Since version 3 backstop supports chrome as engine, so you could specify
"engine": "chrome"
I think it would work fine in Chrome.

X Displayed in dijit.form.Select

I am working on an application build on Dojo 1.4 and currently used on IE8.
When tried to run IE10 Compatibility view, I observer some X (to clear the data) are being show in the fields like dijit.form.Select. While in IE8 it doesn't display them
Please guide to remove them or what basically is happening
Thanks in Advance
If this is the same problem I just fixed then the question isn't referring to the IE10 "clear field" X. It's referring to a very large text "X" character that is displayed in the Select widget in addition to the options that are supposed to be there, making the widget twice as tall as it should be.
In my case it was because I was mixing the CSS stylesheet from one Dojo version with the API's from another. Check to make sure that your stylesheet and dojo.js versions match. For example, in my case the stylesheet was:
...href="//ajax.googleapis.com/ajax/libs/dojo/1.7.5/dijit/themes/claro/claro.css" media="screen">
while the script being included was
... src="//ajax.googleapis.com/ajax/libs/dojo/1.10.1/dojo/dojo.js"></script>
I blame the fact that I was modifying Dijit sample code without knowing what the heck I was doing...

Webkit equivalent of :-moz-system-metric(touch-enabled)

:-moz-system-metric(touch-enabled) looks like a really useful CSS selector for working on mobile sites.
Unfortunately Webkit is dominant on mobile touch devices so does anyone know if there is a Webkit equivalent?
(Ideally it'd be good if this was managed by CSS3 media queries)
Edit: Looks like it is supported in Gecko as a media query
There's no way to accomplish this without resorting to Javascript, at present.
As #easwee said, Modernizr is a well-regarded JS library that focuses on feature detection. You can use its touch test for your use case.
If you don't need all of Modernizr's bells and whistles, you can do the following:
A) Load the following JS as early in your <body> tag as you can:
<script type="text/javascript">
if( !!window.TouchEvent ) body.className += " touch-enabled ";
</script>
B) Write your CSS. Since Gecko uses a media query to inform you of touch availability, you'll have to dupe the touch-specific CSS, like so:
BODY.touch-enabled DIV.foo
{
/* touch-specific CSS */
}
#media screen and (-moz-touch-enabled)
{
DIV.foo
{
/* touch-specific CSS */
}
}
If the per-selector code is identical in both circumstances, GZIP ought to optimize away some of the duplication. (You are using compression, I hope.)
In Ian Wessman's answer the test !!window.TouchEvent works incorrectly. In current desktop Chrome (23.0.1271.52, Linux) window.TouchEvent is a function, so Ian's code considers the browser touch-enabled.
If you want short code, it's probably best to copy-paste the relevant code from Modernizr.
Chrome is another browser that tried to implement a similar selector but unfortunately it was removed out for now.
Modernizr could be and interesting detection tool since it can detect touch events too.
http://www.modernizr.com/docs/#touch

How to stop firefox from downloading and applying CSS via a firefox extension?

Thanks to everyone in advance -
So I have been banging on this issue for quite a while now and have burned through all my options. My current approach to canceling css requests is with nsIRequest.cancel inside of nsIWebProgressListener.onStateChange. This works most of the time, except when things are a little laggy a few will slip through and jump out of the loadgroup before I can get to them. This is obviously a dirty solution.
I have read through the following links to try and get a better idea of how to disable css before a nsIRequest is created...no dice.
https://developer.mozilla.org/en/Document_Loading_-_From_Load_Start_to_Finding_a_Handler
https://developer.mozilla.org/en/The_life_of_an_HTML_HTTP_request
https://developer.mozilla.org/en/Bird's_Eye_View_of_the_Mozilla_Framework
How do I disable css via presentation objects/interfaces? Is this possible? Inside of nsIDocShell there are a few attributes that kind of imply you can disable css via the browsers docshell - allowPlugins, allowJavascript, allowMetaRedirects, allowSubframes, allowImages.
Any suggestions?
Thanks,
Sam
The menu option that disables style sheets uses a function
setStyleDisabled(true)
so you probably can just call this function whenever new browser tab is created. Style sheets are still requested from server, but not applied. This function is not very sophisticated and doesn't mess with nsIRequest, source:
function setStyleDisabled(disabled) {
getMarkupDocumentViewer().authorStyleDisabled = disabled;
}
Digging in Web Developer Toolbar source code I have noticed that their "disable stylesheets" function loops trough all document.styleSheets and sets the disabled property to true, like:
/* if DOM content is loaded */
var sheets = document.styleSheets;
for(var i in sheets){ sheets[i].disabled = true; }
So if the key is to not apply CSS to pages, one of the above solutions should work. But if you really need to stop style sheets from being downloaded from servers, I'm affraid nsIRequest interception is your only option.
Set permissions.default.stylesheet to 2 and voilĂ !
You can actually use the permissions manager to block or allow stylesheets on a host-by-host basis.
Unfortunately there doesn't seem to be a simple flag like allowImages. The bugzilla adding for that is https://bugzilla.mozilla.org/show_bug.cgi?id=340746. You can now vote for it using the new bugzilla voting functionality. You can also add yourself to the CC list to be notified if anyone ever works on it.
A related request is to just give us basic HTML parsing support, which may be what you are trying to do. Unfortunately that isn't supported yet either, but you can vote/track the bugzilla for that at https://bugzilla.mozilla.org/show_bug.cgi?id=102699.
So the only workable solution seems to be some sort of interception as #pawal suggests. Here is a link that talks about the basics of interception to at least get you/us started https://developer.mozilla.org/en/XUL_School/Intercepting_Page_Loads. It lists several options that I list below.
These first few seem to just be at the page/document level so I don't think they help:
Load Events (addEventListener load)
Web Progress Listeners (nsIWebProgressListener) - I tried this approach, it only seems to be called for the page itself, not for content within the page.
Document Loader Service - A global version of nsIWebProgressListener so I think it has the same problem (page level only)
That leaves two others I have not tried yet. They work globally so you would need to filter them to just the browser/pages you care about.
HTTP Observers - Seems like it might work, need to verify it calls back for CSS
Content Policy - Seems like the best option to me since it explicitly is called for CSS, someday I hope to try it :)

Could not load 'dijit.Menu'

I want to run Dojo/Dijit with the Google CDN:
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/dojo/1.3.2/dojo/dojo.xd.js">
</script>
I've tried 1.3.2, 1.3, 1.2 and all give this same problem.
If what I've read is true, I only need to include the dojo.xd.js - then the requires will properly find dijit somehow relative to dojo.
In Firebug I see the following:
http://ajax.googleapis.com/ajax/libs/dojo/1.2/dijit/Menu.js
200 OK
I'm confused by this, because I if http status=200 is okay - then why is this line showing up in red?
The next line says
could not load 'dijit.Menu'; last
tried '../dijit/Menu.js'
I had this working with all the Dojo/Dijit source code local - but I'm determined to get it running with the CDN.
I did some searches, and the best I could find was that Menu.js was included in certain releases, but I think they were talking 1.2 or before.
Same error occurs in the Chrome browser.
Thanks for helping.
Neal Walters
More Info Added:
Thanks for the example. I took it and got a simple menu working:
http://3wcloud-com-provisioning-qa.appspot.com/testDijitMenuOnly
Here's the "beast" that I'm trying to get working.
http://3wcloud-com-provisioning-qa.appspot.com/testDijit
This was originally a copy of the Dojo Theme demo - and it was working when I was running with Dojo local. It does a delayed/manual parse.
Like I said above, I tried 1.2, 1.3, 1.3.2 and so on, so it was just a matter of timing when I copyied/pasted into my question.
And OOPS - I didn't have djconfig - so I added that - but similar problem - just more explicit paths.
Thanks again - I'm going to love Dojo when I over these little humps.
This is the page I'm trying to reproduce:
http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html?theme=soria
Do you have something strange in your djConfig? The fact that it's spitting out "../dijit/Menu.js" makes it seem like you have a path setting in there.
I set up a simple demo page that uses the Google CDN and does:
dojo.require('dijit.Menu')
without problem.
Also, the script tag has 1.3.2 but it's loading menu from 1.2 which is strange.
Post a the full source code of what isn't working and that'll help track down the problem.
EDIT AFTER POSTING LINK
Remove these lines from your testDijit page:
<script type="text/javascript" src="/dijit/dijit.js"></script>
<script type="text/javascript" src="/dijit/dijit-all.js" charset="utf-8"></script>
YET ANOTHER EDIT
Call me crazy (since you don't seem to approve or upvote answers on SO making this a kind of no-op for me) but I got it working with the CDN here.. It still has problems because the CDN doesn't have all the test files on it (dijitTest.css and countries.json for example). You can download it and do a diff on your ow file to see what I changed. I mostly added a bunch of missing requires and changed paths to CSS and images. You also have a script tag referencing /dojo.js in your file.
I'm curious why you are so driven on getting the dijit tester running on your app since it seems like it'd be more fun/productive to learn dojo solving problems within your application.