This has recently become even harder to do with Microsoft’s attempt to force-feed browser updates – at least to those on Windows 7 & 8. And while I applaud this effort, it has also complicated matters even more. I recently fired up my copy of Parallels and loaded a Windows 7 image that I use to test IE9… only to find out that IE had updated itself to version 10! Thankfully, Microsoft has begun to provide “locked” VM’s for testing purposes. You can find them at: http://www.modern.ie/

Of course, IE has had a method of testing in its Developer Tools for several versions now which allows you to “fake” which version of IE you are running. The problem with the feature is that there are two different modes, and it’s hard to tell (at least for me) what the difference is between the two. So, in the hopes of saving some hair pulling, here’s an explanation and example.

Browser Mode vs Document Mode in Internet Explorer

I was recently assisting my wife, Stephanie, on a promo page for her company, Contatta. On the page, they wanted a streamlined (i.e. single page) process for signing up prospects, and we chose to build the experience like an image slider. In keeping with best practices – and the fact that they only wanted IE9+ support, we chose to use CSS3 transitions to generate the motion and state changes. For the four “states” of the page, we created a wrapper div that was set to a fixed width/height and set to overflow:hidden. All of the “elements” that will “slide” in were set to position:absolute and transform:translateX(125%). To create the illusion of movement, we’ve also created a class that specifies transition:transform .5s linear 0s. Note: I’ve removed the vendor-specific prefixes.

To slide the element into view, a class is applied (or removed) that changes the translateX() value between -125%, 0 and 125%.

[フレーム]

As you can see it works great in IE 10 – and all kidding aside, Microsoft has done a great job adding HTML5 and CSS3 features to IE 10. But, as you might know, transitions (the “animation” of the form) were not supported in Internet Explorer 9. Since my version of IE9 had upgraded itself to IE10, we needed a way to see what the lack of transitions in IE9 would do to the experience. Enter the developer tools…

[フレーム]

As you can see, when we changed the Browser Mode to IE 9, the browser still transitioned (animated) the form – but IE 9 doesn’t support transitions! It’s not until we changed the Document Mode to IE 9 that the transition no longer happened.

Browser Mode defines the User Agent – what IE tells the server it is. Document Mode on the other hand determines “what” or “how” IE will render the page.

Using logic, we could just switch the Document Mode and think we’re “good to go”. But that’s not true either… as you can see below:

[フレーム]

As it usually happens, after the page was built, “the powers that be” decided that they, in fact, did want IE 8 support. Which meant that not only did we have to come up with a solution, we needed to test it too.

There are a number of ways to serve alternate CSS to IE, but we chose to use an IECC (Internet Explorer Conditional Comment) – a stylesheet that is only shown to IE versions less than 9. As you can see, when we switch the Document Mode to IE8, we get craziness because IE8 does not understand the transform property. As I mentioned earlier, we’ve used the translateX() value to move the form “off screen”. So, for these older versions of IE, instead of using tranform:translateX(125%), we need to set the left (or right) property of the element.

Simply switching the Document Mode, however, did not tell the browser to read the IECC. As far as IE was concerned, it was still IE 9 (or 10 if we had left it at its default). In order to truly emulate IE 8, loading the page and its resources properly, we have to set the Browser Mode as well as the Document Mode.

While I still try to test on an actual version of Internet Explorer, the fact that the Developer Tools allows me to quickly test functionality as well as look and feel, while remaining in IE 10 is a great time saver… once I figured out what the two modes meant!

When I updated this blog to “HTML5″, I took the leap and used CSS3 everywhere that I could. This post area was a prime candidate for border-image. For the uninitiated, border-image allows you to use a single image as both a border and fill for an element. All you need to do is specify how much of the top, left, bottom, right of the image will be the borders, and how those pieces should fill each area (stretching or repeating).

Illustration of 9-slice from the W3C specification Diagram illustrating the cuts corresponding to the value ‘25% 30% 12% 20%’ from the W3C specification

If you’ve ever used Fireworks, Illustrator or Flash, they all have a feature known as 9-slice scaling. Border-image is basically the same thing, but done on the fly via CSS. The rule for all posts here looked like this:

.post {
margin: 0 0 40px 0;
-webkit-border-image: url(images/article-background-stretch.png) 29 50 55 32 round round;
-moz-border-image: url(images/article-background-stretch.png) 29 50 55 32 round round;
border-image: url(images/article-background-stretch.png) 29 50 55 32 round round;
border-width: 29px 50px 55px 32px;
}

In keeping with best practices, you can see that I have listed the official property (without the vendor prefix) last, so that as browsers drop the need for the vendor prefix, they will simply read the last property – and the change will be seamless. Except in the case where all browser vendors are rendering a property different than the spec—thus lulling us into believing their rendering is correct when it is not.

A hole-y article Don’t adjust your screen! This is what every post looked like!

There is actually an additional value in the spec called “fill”. The “fill” keyword instructs the browser to render the middle of the image as the background of the element. Without the keyword, the middle remains transparent (ie, the background-image or color is rendered instead). If there is no background-image or color defined for the element, it is simply transparent. Till now, all browsers have ignored the lack of the “fill” attribute and rendered the middle regardless. The code above worked perfectly—but it was based on improper rendering.

Chrome (actually, the change was made in Webkit) has recently changed their implementation of the border-image “fill” value as described in the spec. This is good, but it will ultimately break a lot of sites since many of us left the fill attribute off since vendors were ignoring it. Sloppy, sure. But it worked… until today.

So, dive back into your code and add the “fill” keyword if your site suddenly looks like swiss cheese. But you’ll want to (for now) only add the fill value to the non-prefixed version, as the addition of the value currently breaks Firefox if added to the -moz version of your rule (hat tip to @chriseppstein for that little nugget). My post class now looks like this:

border-image: url(images/article-background-stretch.png) 29 50 55 32 fill round round;

“fill” tells Chrome (and eventually other browsers) to render the center of your image as the background of the element. The two “round” values instruct the browser to tile the images on the x- and y-axis.

To illustrate the problem, have a look at this simplified example:

The two columns of text each have a transform: translateY(-100px); applied to them on :hover. Additionally, they are both set to transition the effect – thereby “scrolling” the text up by 100px. Simple enough. And if you are looking at this in anything other than Firefox, both columns behave the same. Of course, if you are looking in Internet Explorer, you won’t see anything because even with IE9, transforms are not supported. UPDATE: I’ve added the -ms- prefix for transforms/transitions, and in IE10 this works as it does in the other standards-compliant browsers.

Being that I like to write CSS shorthand when possible (but am moving back away from it for many CSS3 techniques, especially backgrounds), I wrote the transition line in shorthand. Simply transition: transition 2s linear 0; (with the browser specific code omitted for the moment). Testing in Webkit (which is what I use as my initial dev environment browser) showed everything was working properly. So, of course, I didn’t think more about it until the project was basically complete and I began the round of testing in Firefox, Opera and, yes, IE.

I knew that IE was not going to perform the “scroll”, but I was completely shocked to discover that FF was simply “jumping” (as you can see in the left column of the example) – exactly the same behavior as IE. I scratched my head in wonder as I ran over to CanIUse.com to make sure that my summer vacation in the Caribbean sun hadn’t confused my recollection about FF’s support of the transition property. I was completely baffled, and, in an effort to get to the bottom of the issue, I broke the shorthand out – going from -moz-transition: -moz-transform 2s linear 0; to
-moz-transition-property: -moz-transform;
-moz-transition-duration: 2s;
-moz-transition-timing-function: linear;
-moz-transition-delay: 0;

And suddenly things appeared to be working in FF. This is also what you see above. The left column uses shorthand, the right column uses the longhand notation.

Okay, the simple assumption was Firefox doesn’t support shorthand – but I knew for a fact that that couldn’t be. After looking at the code for the umpteenth time, I was as baffled as when I wrote it. But a shout-out on the Twitters revealed the answer… no “s”.

The “0″ at the end of the shorthand doesn’t have a unit. And with that, Firefox fails to execute the entire line. But wait, the longhand version doesn’t have a unit, so what gives?! Well, that line is actually being ignored as well. But because it’s longhand, the property, duration and timing-function are all being executed. To confirm, I changed the -delay property in the longhand version and, sure enough, no delay. Going back to the shorthand version, I added the “s” to the “0″, and, problem solved!

Of course, this begs the question “why”, which a number of us spent Sunday afternoon discussing on the Twitters. Tab Atkins confirmed that, in fact, the spec requires the unit on instances of time. So, actually, the problem isn’t a Firefox issue, but rather the fact that Chrome, Safari and Opera are “allowing” us to be slack in our code. Hmm. My position is, the default is “0s”, and in no other instance am I required to type the unit when specifying “0″, so why do I have to here? But who listens to me anyway?!

I happily added the stupid “s” and will definitely never make that mistake again… Oh, and I invoiced myself for several lost hours and frustration…! We’ll see if I pay the bill. ;-)

Sadly, the Dolphin browser is not really optimized for Honeycomb, and its interface can look a little small on large tablets. So I have found myself using the native browser more and more. But the native browser suffers from the “Android” user agent string – but it doesn’t have to. There is a hidden (and I mean really hidden) gem that allows you to change the user agent string, among other things (like a Javascript console)!

To change the user agent string, start by opening a tab in the browser and typing “about:debug”. Be sure that the tablet’s “intelligence” doesn’t put a space between the colon and “debug”. Hit the Return key to “load” the page.

You won’t see anything load in the page, but if you go to the options menu in the upper right hand corner, you will see some new entries at the bottom of the list.

Choose Settings and you will see an option for Debug. Tap the UAString item and choose Desktop.

Viola! Your tablet will no longer identify itself as a “mobile device”, but rather as a “desktop”.

When you’re ready to validate your page, simply click the W3C Validator button and choose whether you want the local page on your computer validated or a page on a server.

If you have any errors, they will appear in the W3C Validation panel. Simply double click each error to be taken directly to the culprit in Code View. You can also choose to save the report if you’re into that sort of thing.

But very often during development, the list of errors can be quite extensive – and even irrelevant. For example, I don’t bother to put alt text (or even an empty alt attribute) on placeholder images that aren’t actually going to be used in the final page. For that reason, Dreamweaver also allows you to suppress errors from a report. Right click on the desired error and choose Hide Error to add it to your list of suppressed errors.

Of course, you’ll want to make sure you’ve actually fixed those errors before going live. Therefore, Dreamweaver CS5.5 allows you to remove errors from the list of Hidden Errors by choosing Settings from the W3C Validator button and clicking the Manage button.

Actually, one of the best features of Dreamweaver, Live View, can be used in a way that you might not have thought of. We know that Live View allows us to see the page, rendered by the embedded Webkit engine, exactly as it would appear in Webkit-based browsers. But there is also an interesting text field that becomes active in Live View at the top of the document window – an address field – just like in a browser!

The address field in Live View

And yes, you can type any URL into the field. Dreamweaver, just like the browser, will load the page in Live View. If you are in Split View mode, you might notice that the actual HTML from the page you are viewing is not there because Dreamweaver is still showing the code of your original page.

Live Code displaying the generated source

But click the Live Code button, and Dreamweaver will display the generated source of the page you are looking at — complete with all the corresponding CSS and Javascript files appearing in the related files bar. It’s a great way to learn from what others are doing.

To get the most out of this feature, I have simply created a “tools page” with links to all of my favorite online tools. In order to interact with your local tools page, you will need to choose “Follow Link” or, even better, “Follow Links Continuously” from the Live View Options menu.

The follow links continuously command

So now, when I start Dreamweaver, I immediately open this page, turn on Live View, enable the Follow Links Continuously option and then go about working on my projects. Any time that I need a gradient, transition or anything more complex that I don’t want to “think about” how to create, I switch to my “tools page” tab where all my online friends are ready to help. I can then easily copy their code into the stylesheet that I am working on.

Live View rendering Colorzilla's Gradient Maker

Let me know what you think about this – or if you have an even better “Best Tip Ever”!

Before proceeding, you’ll obviously want to go grab the updated libraries themselves. For the core jQuery library, I suggest using the minified version. Because images are also part of jQuery Mobile, I recommend grabbing the zipped version of the framework. After you download and unzip the folder, you’ll find a full version of the css and js files. I recommend using the minified versions, so go ahead and delete the full versions of the files (ie, they don’t have “.min” in their names).

Arguably one of the most powerful features of Dreamweaver is its extensibility. In fact, the application itself is built around the very technologies that it itself writes, namely HTML, CSS and Javascript. All of these pieces are located in the Configuration folder that you can find where Dreamweaver is installed on your computer. For me, since I’m a Mac user, it’s at Applications>Adobe Dreamweaver CS5.5>Configuration. There are tons of other folders in the Configuration folder, but the one that holds the files that we are interested in is the Third Party Source Code folder.

Inside this folder, you’ll find the jquery-mobile folder. If you want to backup the folder, feel free. None of the sites that you have worked on previously are reliant on these files, as Dreamweaver makes a local copy in each site you create (if you are not using the CDN versions of the Mobile Starter Pages – which we will talk about later). Replace the two jquery-mobile files (css and js) with your newly downloaded files. Replace the entire images folder as well. Finally, replace the jquery-1.5.min.js file with your jquery-1.6.1.min.js file (or whatever you named it).

One last step and your update is complete. When you choose to create a new file from the New Document dialog, Dreamweaver makes a copy of the selected file from the Configuration folder and places it in your site file. The Mobile Starter layouts (New Document > Page from Sample > Mobile Starters) are located in Configuration > BuiltIn > Mobile Starters. There are 3 pages – two of which reference the files that you have now deleted, jQueryMobileLocalMultiPage.htm and jQueryMobilePhoneGapMultiPage.htm.

Open each of these files in Dreamweaver. You’ll see in the head of the document links to the two old jQuery Javascript files and the old CSS file. Simply update these links to point to your new files and save the document. Test that everything worked properly by closing the file, then creating a new page from the Sample that you just changed. Make sure to save the file into a site to make sure that Dreamweaver copies the proper files into the site.

Finally, if you want to change the CDN version, it points to the jquery repository online, simply update jQueryMobileMultiPage.htm to point to the location of the CDN versions of the files.

Happy mobile coding!

But moving an app to your device means plugging it in, turning on USB storage mode (and thereby dumping access to your SD card from the phone while it is in that mode), copying the file over and then installing it – and potentially then, turning off USB storage, etc. It’s such a painful process that I started even dreading doing it — crossing my fingers that everything was working properly and continuing to code until absolutely, positively the last minute, and only then connecting my phone.

Then it hit me – there is a MUCH simpler way… in fact, it was a firm face-palm! Dropbox! Doh! That’s right, simply sign up for a free account, and then use the Dropbox application to add easy access to Dropbox right from your OS. Download the free app from the Marketplace on your Android devices and sign in. Now, I just compile and copy the apk file into my designated Dropbox folder. On the device, a single tap and the app is downloaded and installed! You gotta love it when the simplest solution was staring you in the face all along.

As for UI, I’m a big jQuery fan, so the choice of using jQuery Mobile is a natural — and it’s even more attractive because Adobe is one of the sponsors of the project.

I’ve got several ideas for additional blog posts surrounding my early learnings in this space (Android development, in particular) – especially due to the fact that the Phonegap and jQuery Mobile documentation is not very detailed, but I thought I’d start with one that had me completely perplexed — an application splash screen. The need for a splash screen started almost immediately. Even with the simplest of “Hello World” applications, once I got it onto my Android phone, I would notice a blank white screen for several seconds before the main “page” showed up. I tried modifying the HTML, CSS and JS of my pages – all to no avail.

It turns out, the white screen is the embedded browser starting up, and until it is loaded, nothing is going to be shown onscreen. Enter the need for a splash screen. After spending the better half of a day wandering the rabbit holes of the intertubes, it seemed that the solution was easy on iOS. Just add a Default.png file to the resource structure of your app and you are done. On Android… not so much. And yes, I did attempt that “simple solution” however, when attempting to compile the app, it would error out with “res/drawable-hdpi/Default.png:0: error: invalid symbol: ‘Default’“.

Back to Google, I finally discovered that splash screen support on Android was added in version 0.9.3. A single thread in a forum, seemed to solve the issue, but there was lots of confusion (as I would find) surrounding the implementation of the solution. The thread indicated that a line super.setIntegerProperty( “splashscreen”, R.drawable.splash ); needed to be added to DefaultActivity.java file in the onCreate method. A second argument to the loadURL method defines the length of time the splash screen should be displayed. The value is given in milliseconds: super.loadUrl(“file:///android/www/index.html”, 1000);

After upgrading to 0.9.3 the error changed to “res/drawable-hdpi/Default.png: Invalid file name: must contain only [a-z0-9_.]“, which really puzzled me until I realized that the file name started with a capital letter. Changing it to a lowercase “d”, brought the original error back. After some head scratching, I decided to change the file name to “splash” to match the line “R.drawable.splash” that I had added to the java file — and surprise, it worked!

The moral of the story?

• Make sure you’re testing using version 0.9.3 or later
• Add

  super.setIntegerProperty("splashscreen", R.drawable.splash);

  to DefaultActivity.java file in the onCreate method before the loadURL method

• Add a second argument to the loadURL method for the timing
• Be sure to use splash as your file name – which can be either a JPG or PNG file

First, I created a simple page that contains a few boxes (list elements styled with CSS). In addition to text, one of the boxes contains an image that I used for a subsequent test. The page also has a background image that I want to swap out when the viewport changes orientation. The CSS to make that happen looks like this (other irrelevant code omitted):

@media screen and (orientation:landscape) {
body {
background: url(img/oia.jpg) no-repeat top center;
}
}
@media screen and (orientation:portrait) {
body {
background: url(img/nighttime.jpg) no-repeat top center;
}
}

For the purists among you, you’ll notice that I have (intentionally) omitted device-width and/or min/max-widths so that I could see if desktop browsers, responding to the media query, reacted in the same way as the mobile devices. For the initial test, I left the CSS in the HTML page itself. In a follow-up test, we will see what effects, if any, moving the code to externally linked stylesheets has on the downloads.

In order to be sure I captured every server request, I turned on logging on my MAMP server and opened a console to watch the results of what is actually being served. Making sure that all browser caches have been emptied, I requested the page using my desktop browser (Chrome) set to the standard, somewhat wide, width that I use to surf.

The browser requested the HTML page, along with the background image called for by the landscape media query and the image placed in the page. After setting a marker in the log, I then resized the browser window to a portrait aspect. This resulted in the browser only requesting the background image needed for the portrait media query.

Note: I later tested what happens if a background image is assigned in the global styles, ie without a media query, and is subsequently overridden in the appropriate media query. I found that WebKit-based browsers (Safari and Chrome) download the initially defined background image as well as the background image to be applied by the media query. Firefox and Opera ignored the overridden background image.

This had me really excited, because it would seem to indicate that devices would only download what they needed for a given situation.

Now on to some devices for testing…

The little device lab that I’ve accumulated is made up of an iPad (running iOS 4.2.1), an iPhone 3G (also running the latest OS), Samsung Galaxy Tab, Motorola Droid 2, Samsung Desire HD, Blackberry Torch and a Nexus One. After testing the page with every device, I was (happily) surprised to find the exact same behavior exhibited by the desktop browser. Each of the devices only downloaded the background image for the orientation in which they found themselves when the page was requested.

Note: This was especially difficult to test on the iPad, as it seems it is overly agressive about caching background images. I repeatedly chose the “Clear Cache” option, only to have the iPad not request the image from the server. It appears that you must clear the cache and then reboot in order to truly clear the cache.

The next test involved moving the body rules into two separate stylesheets.

<link href="css/landscape.css" rel="stylesheet" type="text/css" media="only screen and (orientation:landscape)">
<link href="css/portrait.css" rel="stylesheet" type="text/css" media="only screen and (orientation:portrait)">

Once again, only the image needed for the current orientation was requested from the server for all devices (including the desktop browser). However, all of the devices downloaded both stylesheets. Of course, this made sense because all of the devices are “capable” of both a landscape and portrait orientation.

The next logical question would be, does a device request a stylesheet if there is no possible way that it would need it? To determine this, I changed the parameters for the portrait.css file.

<link href="css/portrait.css" rel="stylesheet" type="text/css" media="only screen and (orientation:portrait) and (max-width:700px)">

You’ll notice that I specified a max-width of 700px. This way I could sure that the iPad (with a width of 768px in portrait mode) could not possibly need the stylesheet, while all of the other mobile devices in my test would need it. The result was the same as before — all of the devices, including the iPad, downloaded every single stylesheet, regardless of whether or not it could actually “use” the rules within. I played with several different values, even providing values that didn’t work for any of the devices, and yet, they all still downloaded every stylesheet.

Are you sure you want to display:none?

During my research, I also got to wondering about the use of display:none. I knew that images (or other content for that matter) would still download to the client even if it was set to display:none. This makes sense, because we often see display:none used to show/hide content in a page – and display:none just “hides” the content, it doesn’t remove it from the DOM. Well, or so I thought…

In testing, it turns out that even an image in the page, ie contained within the HTML not the CSS, is not downloaded in Firefox and Opera if its parent element is set to display:none in the applicable stylesheet. In Chrome and Safari, however, the image is still downloaded, regardless.

Basically, all of the mobile devices tested exhibit the Chrome/Safari behavior when using their WebKit-based browsers, which makes sense. On Android devices, Opera Mobile also exhibited the same behavior as its desktop counterpart.

At least now I know

If all of this leaves you scratching your head, join the club! But really, it’s quite simple. The thing to remember is that all of your stylesheets will be downloaded no matter what. Background images in rules that do not apply to a given device/situation will not download, so you don’t have to worry about eating a person’s mobile data plan up with your 12 megapixel background image! ;-) But remember that images which are in “perfectly good rules” that are overridden later in the cascade do download in WebKit-based browsers — even the mobile versions.

The other takeaway, of course, is not to rely upon display:none to hide image content from mobile devices.

And finally, remember that all of this goodness is only for standards-compliant browsers. For Internet Explorer 6/7/8, you’ll still need to do the IECC dance. I would assume this also applies to the Windows Mobile 7 browser, as it is based upon a combination of 7 and 8. Sadly, no one has sent me one of those phones to test… Anyone? Bueller?