Determining Screen Resolution in IE

[Jim Weinberg]

I want to position the items on my webpage relative to the viewer's monitor resolution.

I'm using the following code to determine the resolution:

    var w = window,
        d = document,
        e = d.documentElement,
        g = d.getElementsByTagName('body')[0],
        x = w.innerWidth || e.clientWidth || g.clientWidth,
        y = w.innerHeight|| e.clientHeight|| g.clientHeight;

It works in all browsers except IE. Can anyone tell me how to do this in IE?

Thanks.

[jscheuer1]

You don't mean screen resolution. You are talking about browser window dimensions in pixels.

I'm not sure if you have the right and/or optimal trial objects and properties in the best order to determine x & y there. But assuming that you do, one major problem with IE in doing something like this is that it 'doesn't know' the window, document, nor page dimensions until the page has at least been parsed. It's complicated to get that in IE, so generally we wait until the window.onload event has fired before trying to figure this out (again assuming the code you have is right if used at the proper time):

<script type="text/javascript">
function dimfunc(){
    var w = window,
        d = document,
        e = d.documentElement,
        g = d.getElementsByTagName('body')[0],
        x = w.innerWidth || e.clientWidth || g.clientWidth,
        y = w.innerHeight|| e.clientHeight|| g.clientHeight;
	/* do what you want with the x and y values here */
}
if (window.addEventListener){
	window.addEventListener('load', dimfunc, false);
}
else if (window.attachEvent){
	window.attachEvent('onload', dimfunc);
}
</script>

It's easier (jQuery determines what objects to query) and faster (jQuery determines when the DOM is loaded, which comes sooner than window.onload) using jQuery:

<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1./jquery.min.js"></script>
<script type="text/javascript">
jQuery(function($){
	var x = $(window).width(), y = $(window).height();
	/* do what you want with the x and y values here */
});
</script>

[Beverleyh]

There's also a possibility what what you're trying to do can be achieved with CSS and media queries, but we'd need to see more of what you're doing in context so that we could advise which to use.

[Jim Weinberg]

Beverley. Thanks for the input, but I went with John's suggestion.

John. Once again, you're spot on. Thanks so much. I now only have one problem with IE (other than it exists and people insist on using it). I'll post this as a separate thread if you want, but thought I'd attach it here.

I'm using a common routine to build a table from a searched array, on the fly. The first call builds the table in the parent page. The second, builds the table in a pop-up page. For the first call, I pass the routine the parent window object. For the second, I pass the pop-up window object. Like everything else, it works fine in all browsers I've tried ... except IE (of course).

The code looks like this (for the first call):

<table height="100%" width="100%" bgcolor="white" border=1 cellspacing=5 cellpadding=5><tr>
<script>build_table(this,IdPeople)</script>

For the second call I use the following:

var table='<table width=90% bgcolor="white" align="center" border=0 cellspacing=5 cellpadding=5><tr>';
var w = window.open('', '', 'width=800,height=530,scrollbars=yes,left=150,top=182');
w.document.write(table);
build_table(w,searchResults);

With IE, it doesn't get past the document.write statement. The build routine isn't called. Is there another way to do this for IE?

Thanks.
Jim

[jscheuer1]

You are on very shaky ground here. Many browsers - Not just IE, depending upon how they are configured might block this popup before you can write to it. You might be better off popping up an absolutely positioned div that looks sort of like an independent window, and that instead of using document.write, either create the elements you need and append them to this div, and/or alter its (and/or its child element's) innerHTML property to achieve your aim.

But it's still possible that what you are doing is OK-ish and can be tweaked. I sort of doubt that though.

In either case, in order to advise you further, I would need to see a demo of the problem. Also of importance could be the version of IE that you are having the problem in. I tried in IE 11, using its console, and it blocked the popup, but that's no proof of anything because popups called from the console are treated differently than ones launched via a user's click.

One other thing, Beverley is right, in that determining how to display your content is best done via css, and for this sort of thing media queries are usually the ticket. Especially if you consider that document.write and the codes I gave you initially to resolve this do not play well with each other. At the same time, since you're already using javascript to create the content, it's not quite so bad to also use javascript to determine how that content should be displayed. It might even be preferable in certain cases.

Since I'm not as familiar with media queries as is Beverley, I would appreciate if she were to advise us further on what we might do in this specific case using them.

Still, for either of us to help, I think we need to see a demo and know which IE version is giving you the problem

[Beverleyh]

You might be better off popping up an absolutely positioned div that looks sort of like an independent window, and that instead of using document.write, either create the elements you need and append them to this div, and/or alter its (and/or its child element's) innerHTML property to achieve your aim.

This is what I would try to work with first - formatting and positioning the search results with CSS and media queries. Media queries might not be needed but I agree with John about seeing a sample/demo so we can make a better educated decision on which route to take.

[Jim Weinberg]

First, let me apologize for the confusion. The two issues are actually for two different pages. Once I have this one working I'll go back and try using CSS to do the positioning, although I'm concerned because user's have different screens and different browsers.

Anyway, I've put up this webpage and some relevant data. the URL is http://ohiobuttons.org/test/Identifiable_People.html

The initial display works, so I'm pretty sure that the build_table functions is okay. There may be some other IE problems in the search_array function, but from the testing I've done it looks like the proper data will be passed to the build_table function if I/we can solve the w.document.write issue. The actual line of code is located around line 150. BTW, I'm testing in IE8. I know that's not the latest version (I believe it's up to 10 or 11), but I like to use browsers about 2 versions back to make sure pages work for those that don't have the latest version.

One last comment. I know that some of the code needs to be cleaned up. I'll do that when this but I'm a firm believer that it's a lot easier to make working code pretty that to make pretty code work.

[Beverleyh]

Ok - I'm looking at the page on an iPad. I gather I'm to type a name to generate the search table?

I tried entering "Liz Taylor" and again as "Liz, Taylor" and a popup says "Your search returned no matches..."

At this stage I'm presuming that the search table generation is a work in progress, based on your phrasing here;

Once I have this one working I'll go back and try using CSS to do the positioning...

I'm not in a position to help with code at the mo - on iPad, but John is way better than me with JavaScript anyway - but I'll keep checking in and hop in with formatting and presentation input when that point comes. I'll be back at a desk tomorrow.

[Jim Weinberg]

Beverly. My bad. You need to enter descriptive keywords such as: man, woman, queen, etc., separated by commas. You can get a pretty good idea of what it does in you use man, child. If you select Any Words you'll get around 18 pics. If you select All words, you only get 1. Sorry for the confusion.

BTW, can I assume that the page works in an Ipad????? I can't test that.

[Beverleyh]

Here are my findings on iPad, in real time while I test and report back...

First browser tested is Mercury - not the default browser, but a common alternative and my fave due to advanced gestures and some other nifty settings; Here, unfortunately, the search generates no results. I entered "queen" as my keyword, and from the screen keyboard, tapped "go" (which is the equiv of pressing a submit button). No joy, so I refreshed, typed "man" instead, and hit the little magnifying glass icon next to your search field to see if that made a difference. Unfortunately nothing happened again. Now, I mashed around with it - pressing and holding the "go" button, and one time managed to generate the search - this came up as a separate white page, a selection of buttons and "about:blank" in the address bar. Unfortunately, what also happened is that the original page closed in the background when the search results page loaded, which meant that I had no way of returning to the original page.

So next I moved to my next fave iPad browser, Chrome (I like this because of syncing and the incognito tab is fab for testing cookie scripts). The page loaded and I typed "queen" in the search field. Pressing the screen keyboard's "go" button did nothing, BUT tapping your magnifying glass icon immediately after *did* open the results in a new window. The original window stayed open in the background too. I reloaded the page and this time typed "woman" and hit the magnify icon first. Nothing, but on the second hit the results opened in a new page. Third reload, I typed "man" and again tried the keyboard "go" button. I hit this repeatedly but nothing happened. I closed the keyboard, focused the cursor in the search field again (but didn't delete or type anything) and the screen keyboard revealed itself again. This time when I hit "go", the search results opened in a new window. So it seems that the second submit action generates the search. I also noticed that a notification bar displayed at the bottom of the browser window and reported that X popups had been blocked, so I think that what is happening is that the first submit generates search results that *should* open a new page, except they are actually been blocked by the internal Chrome popup blocker. Perseverance on the submit key seems to override this behaviour though. But it seems too unpredictable for the common user (ie to somebody who is not testing or looking for patterns).

At this point I'm thinking that generating the results in the original page are the way to go, but I'll now head over to test in Safari (default browser for iOS). This is easier to describe; the "go" key on the keyboard does not submit the search no matter how often I hit it, or if I refocus the search field or hit the magnify icon between. The magnifying glass icon however, submits the search first time, every time, and opens the search in a new window. The original page stays open too.

So you can tell from my ramblings above that different browsers on iPad behave very differently and produce vastly different results - the main problem being how they interpret or react to the new page popup. I think we should work at standardising the behaviour to make it as predictable as possible. For that, I'd like to see how the search functions with the results generated in-page.

Hope that helps