How do I get modernizr to work with respond.js? - internet-explorer-8

I'm creating a progressively enhanced design with CSS3 media queries, responsive to small screen sizes first, and then larger, using media queries.
Of course, media queries don't work on IE8 and below. My attempted solution is to use modernizer and respond.js.
I have this in my head:
<script type="text/javascript">
Modernizr.load({
test: Modernizr.mq,
nope: '/js/respond.min.js'
});
</script>
In firefox, I can see no JS errors in the console. The network bar indicates that modernizr is being delivered.
In IEtester, I have an IE8 panel open. The page is behaving as if respond.js is not present. In IETester's debug bar, I go to 'links'. Respond.min.js is not listed.
What am I doing wrong?

From the Modernizr docs: http://www.modernizr.com/docs#mq -- the string argument seems to be required to use the media query testing. You could use a test such as:
Modernizr.mq('only screen')
You might want to look at this comment from Alex Sexton (creator of Modernizr.load) that recommends against asynchronous loading of Respond.js due to its highly visual impact on a website.
https://github.com/scottjehl/Respond/issues/14#issuecomment-1017652

Related

try google webfonts on html5 canvas every method: standard, #import, javascript and webfont loader, neither work

I need render google web fonts on html5 canvas. I tried every method : standard, #import, javascript and webfont loader but they all fail. My html can be found at https://gist.github.com/susquehanna/5851382 . Any idea? Thank you.
update:
works on jsfiddle: jsfiddle.net/susquehanna/44k4U/3/

What causes the "user agent stylesheet" to use "border-box" instead of "content-box" for box-sizing?

I'm under the impression that the user agent stylesheet in browsers such as Safari, Chrome and Firefox is something that is internal to the browser and can't be directly modified (rather a style property needs to be overridden).
I'm also under the impression due to various websites including Mozilla's that the default value of the box-sizing property for Webkit and Mozilla is "content-box."
I tested this on a rather simple dummy page viewed in various browsers.
My problem is that on two pages in our production application the default property is different, and we can't figure out why this is.
One one page we see a box-sizing property of "border-box" in the Web Inspector or console. It's assigned to the CSS selector input:not([type="image"]), textarea.
On the other page there is no mention of the box-sizing property in the Web Inspector or console.
Does anyone know if there's some way to directly affect the box-sizing definition in the user agent stylesheet for a particular page? Maybe there's a library that does this? We're using prototype.js and swfobject.js in the application...
UPDATE: In case I wasn't clear on almost every page in my web application and in every "dummy" page I've tested on the box-sizing property has the default "content-box" value. For some reason one particular page in my web application shows in the web inspector that the user agent stylesheet (the one used by the browser for its defaults) has set that property to "border-box." I can't for the life of me figure out why this is. I'm looking for anything that might cause Firefox to change what its default value for that property is.
Just had this same issue. What was happening in my case was that someone had put a snippet of Javascript code above the <!doctype html>. As a result, when I inspected DOM through firebug, it appeared that the document didn't have a doctype.
When I removed the snippet of JS code such that the doctype declaration was at the very top of the file, the doctype reappeared and fixed the box-sizing problems I was seeing (the same one you had).
See:
Hope this helps.
I had the same issue on chrome which by default added the following user agent style rule:
input:not([type="image"]), textarea {
box-sizing: border-box;
}
After adding the doctype property <!DOCTYPE html> the rule no longer appeared.
No, you can't touch the browser default stylesheet, and yes, browsers do have different rules for box-sizing specifically in respect to form fields. This is for compatibility with old browsers that used to implement form fields entirely with native OS widgets that CSS couldn't style (and so which didn't have ‘border’ or ‘padding’ as such).
Why not just put your box-sizing/-moz-box-sizing/-webkit-box-sizing rule in the site stylesheet? Works for me, I often use this to make inputs with set widths line up across modern browsers. (IE 6–7 don't support it, though, so need some extra help.)

Twitter #anywhere API problems in firefox only

I've implemented a simple example of the Twitter #anywhere api to display user hovercards. The example works great in Internet Explorer and Chrome. However, whenever I the page loads in Firefox I receive the following message in an alert window:
To set up #anywhere, please provide a
client ID
Surely if the results are correct in Chrome and IE then everything must be setup correctly?
Here is a simple code block which I've tested recreates the problem in Firefox only:
<script src="http://platform.twitter.com/anywhere.js?id=WMg5kRMlIw807lRTsktnNQ&v=1" type="text/javascript" >
</script>
<script type="text/javascript">
twttr.anywhere(onAnywhereLoad);
function onAnywhereLoad(twitter) {
twitter().hovercards();
});
</script>
This problem is showing up in various forums and mailing lists. I'm seeing it on Firefox 3.0.5 (but not 3.6). Looks like Twitter didn't do enough testing before springing this one on the world.
(Later: Try clearing hour cookies. Yeah, that's a very 90's thing to have to do.)

Strange problem with Google Maps and Ajax in Google Chrome and Safari

I am developing web-application using Google Maps API and ASP.NET Ajax. Here is my JavaScript-code for PageLoad:
map.openInfoWindowHtml(map.getCenter(),'Hello, <b>world</b>!');
First run is successful. But after execution some ASP.NET Ajax-function we have strange effect: In Internet Explorer, Mozilla Firefox and Opera everything is good, but in Google Chrome and Safari text with html-tags is invisible. In other words in Google Chrome we have text: “Hello, !”
I want to make the application that would normally in Google Chrome and Safari too. How can I do it?
Update:
String "Hello, <b>world</b>, <strong>world</strong>, <span style='font-weight: bold;'>World</span>, <a href='http://ya.ru'>Link</a>." transform to "Hello, , , , . " (I examined the DOM). Words really are disappearing.
I observed this strange effect on any Ajax-function with request to server.
Update2:
Many thanks to Koobz for many leading questions. They helped me a more detailed understanding of the problem.
First of all, full description of actions:
Load the page. GMap have several markers with dblclick-event in JavaScript. Dblclick event exec marker.openInfoWindowHtml(/My text/). /My text/ is located in JavaScript of my Page.
I double-click on the marker. I see a infoWindow with a normal formatting
Exec __doPostBack (starndard ASP.NET PostBack)
In server side JavaScript is updated with same
Server return some information with /My text/ to my page
I doouble-click on the marker. I see a infoWindow with a wrong formatting.
An interesting fact, which puts me in embarrassing:
I try set to “Hello, <b>world</b>, <b>test</b>”
Before Ajax function in all browser I have: “Hello, world, <b>test</b>”
After Ajax function in Google Chrome and Safari: "Hello, ,test"
After Ajax function in Mozilla, Opera and IE: “Hello, world, <b>test</b>”
What Chrome and Safari have features that may cause such behavior? Now I can write separately necessary infoWindow-text for each browser. But I would like to find a normal way to solve my problem.
Hit ctrl+shift+j to open up your chrome developer tools.
Set a breakpoint right before the function call that breaks everything.
Attempt to reproduce the bug.
After the break point hits, step through your code until the text disappears.
Set a breakpoint after the text first disappeared.
Repeat this process. Refine your breakpoints until you've narrowed down where the bug is occurring.
It could be any number of things. I have no idea what kind of Ajax things you're doing. Are you dynamically updating content on your page after doing the request? It's possible that this update code is modifying dom elements that it shouldn't be. Tracing through using the methodology above will help nail it if this is the case.
If you're using jQuery, maybe one of your selectors is out of whack and it's eating up content. Chrome is very good and I'm hesitant to believe it's a javascript bug or anything like that.
Validate your HTML. If you're traversing the dom, invalid markup might result in chrome "seeing" a different picture than other browsers. Just look for broken tags and ignore all the other things a validator complains about.
Wild guess: but the way it's stripping out HTML might point to some kind of XSS protection. Is the Ajax script that's returning the new HTML code on another domain than the one the visitor is viewing?
Some info here:
http://groups.google.com/group/chromium-dev/browse_thread/thread/d2931d7b670a1722/d56bdfccfcef677f
Do you see the problem with any html tags in the info window? As an experiment, try:
<span style="font-weight: bold;">World</span>.
I am wondering if there is a unclosed bold tag somewhere in the DOM?
I am messing around with this problem, but I haven't been able to reproduce it. Having a look at what the Ajax function does would be helpful.
Try this:
map.openInfoWindowHtml(map.getCenter(),'Hello, <strong>world</strong>!');
the strong tag is more standards compliant, worth a shot
As others have said, you need to post your code.

Stop the browser "throbber of doom" while loading comet/server push iframe

When using Comet, or Ajax Long Pull techniques - an iframe is usually used. And while that iframe is waiting for the long connection to close, the browser is spinning its throbber (the progress/loading indicator).
Some websites, for example etherpad.com, managed to make it stop.
How do they do it?
After digging for a day and a night in the guts of the internets, here is what I came up with:
server-sent events - Very cool, currently works only in Opera, but may be part of HTML5 and other browsers may support it sometime. Adds a new element tag with content-type of "application/x-dom-event-stream" which allows the Server to fire events in the Client DOM. And it should not show a progress indicator, as far as I understand. It's also a working draft of a standard, and not a hack like the whole iframe comet thing.
XMLHttpRequest - in Firefox and Safari, but not in IE, it can be used for long-pull page loading that enables to handle fragments as they appear on each readyStateChange event. Will not show progress indicator*. -- see comment below
ActiveXObject("htmlfile") - can be used in IE to create a page/window that is outside of the current window scope. This makes the progress indicator go away! The loaded iframe will be in an invisible browser.
More about server-sent-events:
http://my.opera.com/WebApplications/blog/show.dml/438711
And more about the other two techniques (also explains the problem better):
* http://meteorserver.org/browser-techniques/
Even more in-depth about each technique, and more techniques:
http://cometdaily.com/2007/12/11/the-future-of-comet-part-1-comet-today/
http://cometdaily.com/2008/01/10/the-future-of-comet-part-2-html-5’s-server-sent-events/
For me, running a setTimeout on the ajax request solved everything. When I ran the request from document.ready, I got the "throbber of doom". But with setTimeout it doesn't happen. (This fix also works for Chrome).
Just in case that you may need some examples, this guy did give a solution to solve firefox problem.
http://www.shanison.com/?p=237
I had the same problem, and the solution was to use Ajax instead of hidden iframe. So instead of generating iframe somewhere in the page:
$("#chat .msg_list").prepend('<iframe id="hidden" src="chatFrame?id=$userId" frameborder="0" height="0" width="100%"></iframe>');
I used jquery ajax call to load iframe contents into some div:
$('#chat #chat_comet').load('chatFrame?id=$userId');

Resources