This paper assumes - as was discussed with people on the team some months ago - that in IE8 Beta2, the values returned by window.screen.width/height, and window.screenTop/Left will, as it does in IE7, reflect the true "physical" pixel values even when the page is being zoomed to something other than 100%.
I'm aware that you are aware of that problem and that a fix is in the works - but this is not sufficient to re-instate the script functionality that has been with lost in regards to detecting the size of the browser viewport - a common task.
It's a subtle and difficult problem to describe and that's the reason for this brief paper.
The breakage I'm strongly alerting you to is this: At any zoom level other than 100% - a condition which can't be detected via script in IE8 - the new Zoom breaks the one and only available, standard, time honored, and widely deployed script technique for detecting the size of the browser window viewport in Internet Explorer.
That one and only method of detection available in IE - the values of document.documentElement.clientWidth/Height (Standards Mode) or document.body.clientWidth/Height (Quirks Mode) are rendered unreliable for this purpose as an unintended consequence of IE8's new Zoom. Developers have been able to rely unquestioningly on these properties for this purpose for the past ten years, but not in IE8 even if screen.width/height and window.screenTop/Left are fixed to report the true "physical" pixel values.
I have made a close study of browser zoom features (IE7, IE8, Opera, FF). This came about through my involvement in an unusual development project: a script library that collects statistics on user-agent capabilities and user-habits that most other stats products don't pick up.
In IE, for example, it will detect things like:
As will be explained - proven, really - without an additional property that allows for the computation of the window viewport's true physical pixel size regardless of the zoom level, developers are, suddenly, as a practical matter being denied the ability to do it at all. IE8 really does break this little piece of the web, I assure you. And IE8 will be a better product with it fixed.
When zooming up in size, IE8's Zoom works by recalculating the resolution of the "physical" screen to create an imaginary, "logical" screen with a smaller resolution. It then, in a sense, transplants the IE window into that screen. The window, now "thinking" it has to display it's contents within a space having less pixels in width and height than it did before, adapts to its new environment and, as a consequence, the contents of the window enlarge and the layout shifts (or not), accordingly.Therefore, what happens when you zoom up is the same as what happens when there is no zoom applied (100%) and the window is simply sized down within the unrecalculated "physical" screen resolution. In both cases, the window has to display it's contents within a space having less pixels in width and/or height. And this is why, when zooming up, the same sort of shift in layout occurs as when no zoom is applied and the window is simply sized down to take up only a portion of the screen.
Consider these two screen shots based on an example from Page 10 of the Zoom Version 2 Windows IE8 Whitepaper:
In the comparison above, you can easily see the effect I'm describing. In both cases the value of document.documentElement.clientWidth is 803 pixels. This is what IE "sees", even though it might not be physically true.
And bear in mind, of course, that this is not an isolated example, but behavior that happens accross a continuum. Consider the pattern of decreasing pixel size for document.documentElement.clientWidth in each of the following examples:
As you can see, there is an inverse relationship between the "logical" pixel size of the viewport and the zoom level: as the zoom level goes up, the pixel size of the topmost container object goes down. It's a continuum with a nearly endless supply of potentially false values. As a practical matter there is no way to distinguish between a window that has been zoomed up, as opposed to a window that is sized smaller than full-screen with no zoom applied. And all gradations and mixtures in-between.
And so, using document.documentElement.clientWidth/Height to detect the size of the browser window becomes a gamble with no way to tell if you've won! Maybe it's accurate, maybe not. There is no way to know.
In order to maintain the integrity of the system, with IE relying upon a recalculated DPI resolution - the topmost container objects which are either document.documentElement or document.body - must adjust and report their clientWidths based on the recalculated values. And therefore, at any zoom setting other than 100%, these values are going to be different than those based on the physical screen size.
And this is why the clientWidth/Height values of these properties are no longer reliable indicators of the window viewport size.
This is also, incidentally, exactly what happens in Opera's and FireFox 3's, implementations, as well. And I can't see how this behavior can be altered, either - it's a natural and necessary outgrowth of the system being used.
That is why the only remedy is an additional property that allows developers to calculate the true physical size of the browser viewport.
Zoom breaks the expected functionality of these properties. The only question is: what repercussions will it have if it goes unaddressed? If it goes unaddressed, I think it's certainly a big enough break with past behavior to issue some sort of advisory in the MSDN documentation telling developers that the thing is broken. Don't you think? However, I can't imagine the IE team wanting to do that when the problem is so easily remedied.
Zoom Version 2 gives IE users an improved feature and I'm all for it. But I don't see why it should be at the expense of taking away from developers something of value they have always had available to them.
Especially now, with the use of wide-screen and extra-large displays on the rise, I'm sure you'll agree that being able to track how much screen "real-estate" users are devoting to the browser is too important a tool to muck up. Plus, Microsoft itself is a fairly huge provider of web content, how do YOU feel about losing this ability?
This problem will affect every and any developer who wants to use script to determine the true size of the browser window viewport. At the very least, EVERY STATS IMPLEMENTATION THAT REPORTS THE PIXEL SIZE OF THE BROWSER WINDOW WILL BE AFFECTED.
Zoom is fairly new to IE's feature set and, especially in light of the problematical nature of IE7's Zoom implementation, it's fair to say that we are all, to some extent, sailing into uncharted waters. For example, I suspect that the need to include the new zoominherit property in IE8 grew out of a problem illuminated by the zoom feature in IE7 - a problem that was, initially, unanticipated and unforeseen.
Zoom is one of those incidental "accessibility" features that few care about and therefore receive little scrutiny. And in my experience, and it's the low-priority areas like that - the ones going unscrutinized - that tend to sneak up on you later. My gut tells me that breaking something as basic as this can easily ripple out negative repercussions beyond those which I, or you, are able to envision today. Hey, if you've got something that's produced an expected result in all situations for ten years, and then change it, it's gotta break something, somewhere. Maybe a lot, maybe a little, but why not just fix it?
Opera has had a zoom feature for quite a few years now. Time-tested. And an analysis confirms that being further along in the experience curve (usually, and probably in this case) counts for something.
Here are the properties relevant to browser window size and position and what they report in Opera:
What was that I wrote earlier about things that go unscrutinized? Expecially in light of a successful, time-tested implementation to emulate? (Opera's) And bug reports? (Mine.)
In short, FireFox 3 breaks not only the newly supported (for them) clientWidth/clientHeight properties but also window.innerWidth/Height and window.outerWidth/Height, too. A price will be paid for these oversights and it's just a question of who will pay it. So much for "free software"!
Here are the properties relevant to browser window size and position and what they report in FF3:
Obviously, the IE team has had to address issues of this nature before. Properties like screen.logicalXDPI/YDPI and screen.deviceXDPI/YDPI were included in IE6 for a solid reason, no doubt, even though these properties are used by few. And whitepapers like Adjusting Scale for Higher DPI Screens, weren't drafted for the fun of it.
I'm suggesting the addition of a window.screenRight property which gives you the upper right pixel position of the viewport. (Pixel position meaning the position based on the physical "device" resolution regardless of zoom level) Unless I'm missing something, this will solve the problem.There are however, other ways to go:
I'm an MCSE (from the NT 4.0 days). After some years of consulting in New York's financial and entertainment industries I got into web development via Intranet work at the New York City Transit Authority's Internet Technologies department. Internet Explorer was the only user agent, and I came to know it really really well and from every angle.
I was also, for some years, through my association with the firm of Cartwright & Goodwin in New York, a Microsoft Partner. (An association that was tragically cut short just a few months ago by the untimely death of my friend Stephen Goodwin, a Microsoft MVP and, in his former career, one of the first prominent African-American faces on Wall Street. Voted Newsweek's Economist of the Year in 1992. Steve, this one's for you, pal.)
Anyway, I'm on your side, folks. I hope IE8 is a top-notch release.
July 18th, 2008