Wednesday, December 23, 2009
Into and Out of the Screen We Go
Blog Entry #166
Having done the browser sniffing thing in the last few entries, we switch gears a bit today and take up HTML Goodies' "Post by Screen Size" tutorial in order to briefly address another factor that can play a major role in the rendering/presentation of document content: screen resolution.
In thinking about how to approach this post, it occurred to me that a full discussion of the screen resolution topic would require us to delve into some rather technical matters:
• If a monitor screen has, for example, a 1024 x 768 native resolution, what does that mean in physical terms? Just what is a screen pixel? (If anyone out there is capable of writing up a good "Screen pixel" Wikipedia entry, it'd be great if you would do so.)
• If on a given computer the screen resolution setting is changed, say from 1024 x 768 to 800 x 600, what exactly happens?
• How is content - in a document, or on the desktop for that matter - 'painted' onto the screen in the first place?
Undoubtedly the engineers at IBM and Apple could answer these questions, but I can't, so we'll keep it simple in the discussion that follows.
Joe also keeps it simple in "Post by Screen Size", concerning himself with two practical issues:
(1) How do we reconcile document content with the various screen sizes out there in 'userland'?
(2) What should be done about a content element (specifically an image) that overflows a user's screen?
So many monitors, so little time
As detailed in the tutorial's "Redirection Choice" section, Joe's first plan of action for mapping content onto varying screen sizes is to create separate pages for those sizes, an approach he later concedes
might be overkill; these pages are to be accessed via a 'screen sniffer' script analogous to a browser sniffer:
if (screen.width == 1600)
{ parent.location.href = "1600page.html"; }
if (screen.width == 1280)
{ parent.location.href = "1280page.html"; }
// etc.Go here for the rest of the code. Joe's screen sniffer specifically tests for the following screen widths: 1600px, 1280px, 1152px, 1024px, 800px, 640px, and less than 640px. If your screen.width is 1600, you'll be sent to a 1600page.html page; if your screen.width is 1280, you'll be sent to a 1280page.html page; and so on. The screen object and its width property have long had cross-browser support but are not standard as of this writing; however, they are on track to be incorporated into the W3C's CSSOM View Module.
Joe provides a demo page for his screen sniffer here. The demo's ####page.html destination pages contain no real content to speak of (just a bit of text and an incorrectly pathed, and thus nonfunctioning, Back to the Tutorial hyperlink); as 'normal' pages, they are meant to be scaled so that the user doesn't have to do any (read: is spared the ultra-annoyance of) horizontal scrolling.
My iMac has a 1680 x 1050 native screen resolution, which is not flagged by Joe's screen sniffer, but it also supports a variety of other display resolutions:
If I downgrade my display resolution to 1280 x 800 and then go to Joe's screen sniffer demo page, I am duly redirected to the 1280page.html page.
So far we haven't said anything about what kind of content we might want to scale for different screen sizes. A purely textual document marked up in a normal manner wouldn't need to be scaled at all. But what about a really large image, huh? In fact, any block-level element - a div, a table, a form, or even a p(aragraph) - could be given a sufficiently large CSS width such that it poses a nuisance for a user with a smaller screen.
My img runneth over
As document content, an image that is wider than the user's screen will require horizontal scrolling to see all parts of the image. Joe takes up the large image/smaller screen situation in the tutorial's "Internal Page Choice" section and offers the following solution thereto:
The easiest way to solve the problem is to create [smaller] version[s] of the image for [smaller screen sizes].With a set of differently sized images in hand, and drawing inspiration from the "Internal Browser Test" code that we've been discussing in the last couple of entries, Joe then writes one of those images to the page via a modified version of the "Redirection Choice" screen sniffer:
if (screen.width < 639) document.write("Hello there");
if (screen.width == 640) document.write("<img src='630px.gif'>");
if (screen.width == 800) document.write("<img src='750px.gif'>");
if (screen.width >= 1024) document.write("<img src='850px.gif'>");In order to illustrate the "Internal Page Choice" code, Joe created the three rectangular images below:
850px.gif:
750px.gif:
630px.gif:
If your screen.width is 1024 or greater, you'll see the 850px.gif image; if your screen.width is 800, you'll see the 750px.gif image; and so on. Go here for a demo.
Making a bunch of images is still too labor-intensive for my tastes, however; much better would be to proportionately shrink the largest image's width and height for smaller screen sizes as follows:
function scaleImage(imageWidth) {
if (screen.width < imageWidth) {
document.images["imageID"].width = 0.8 * screen.width;
document.images["imageID"].height = 0.8 * screen.availHeight; } }
/* For the browsers on my computer, the screen.width and screen.availWidth returns are equal but the screen.availHeight return is typically (not always) less than the screen.height return. */
...
<img id="imageID" width="####" height="####" onload="scaleImage(this.width);" src="myImage.gif" alt="[Alternate text]" />To try out my script, click on the thumbnail image below - a photograph of somewhere in Mexico (downloaded once upon a time from Desktopia.com) that will occupy ca. 80%* of your 'screen real estate' should open in a new window.
*More specifically, it'll occupy 80% of the screen if your screen.width is less than the imageWidth, 1601px in this case; otherwise you'll get the actual-size (1601px-by-1198px) photo.
FYI: On my computer, Firefox's screen.width return varies with and is inversely proportional to the Zoom setting; upon increasing the Zoom, the photo in the new window gets progressively smaller.
Other elements
Anything else that we need to worry about? I trust y'all know better than to deploy width:2000px; headings, paragraphs, and blockquotes, although such elements can be easily downsized via code similar to that given above:
<body onload="scalePara( );">
<p id="p1">My interminably wide paragraph, blah blah blah...</p>
...
var myPara = document.getElementById("p1");
myPara.style.width = "2000px";
function scalePara( ) {
if (screen.width < parseInt(myPara.style.width)) myPara.style.width = 0.8 * screen.width; }But some large content should be left alone, IMO. Imagine a div holding a timeline depicting historical events on a long, horizontal axis - you wouldn't really want to shrink something like that (at least I wouldn't). Or consider a table with long rows of data: in this case you might want to put the data in a spreadsheet and then make the spreadsheet file available for download (this is not the time/place to discuss CSS 2.1's "Dynamic [table] row and column effects").
All the same
In the "Post by Screen Size" introduction, Joe links to an earlier "So You Want To Get Them All The Same, Huh?" article that presents a series of twenty-one
cross-platform tips for HTML artists. Some of the information in this article is seriously out of date, but the overall philosophy of the article - code to the lowest common denominator and use the most recent technologies sparingly - remains quite valid. An important corollary to this philosophy is that part of being a coder is to understand that not everyone in the world is using the same (type of) equipment that you are using, and that if you're serious about what you're doing, then you need to think about reaching out to as many users and user agents as possible.
Three of the "So You Want To Get Them All The Same, Huh?" tips are directly relevant to the "Post by Screen Size" tutorial:
Tip Fourteen: If possible, use percentages when [setting] widths.
This is a generally good practice as it will keep your content within the bounds of the user's screen/viewport (assuming, of course, that you don't set those percentages above 100%). FYI: Joe's statement that
you must be using pixels when denoting an image's HEIGHT and WIDTHis incorrect. The height and width attributes of the img element have a %Length; data type, which can be specified in pixels or as a percentage.
Tip Thirteen: Force your page's width.
Tip Twenty: If you need to pick a screen resolution to design for, choose 640 x 480.
"Force"? 640 x 480?? Again, the details are much less important than the underlying idea: Keep tabs on a page's width and be able to catch when it might cause a problem for a user with a small screen.
We'll check over the remaining "JavaScript Browser Test Scripts" tutorial, "Test Visitors for the Flash Plug-In", in the next entry.
reptile7
- posted by A. Peak @ 1:12 PM
Actually, reptile7's JavaScript blog is powered by Café La Llave. ;-)