Katherine Lynch.org

So, mobile stylesheets are not the Holy Grail of mobile web development that they once were, but they do still come in handy.  Rather than attempting to recognize the technology or the OS specifically, it's easier now to go by device width.  I used this technology in order to have a "switch to mobile version" toggle in the footer of the full browser version of a site, but only on mobile devices:

<link rel="stylesheet" href="handheld.css" type="text/css" />
<meta name="viewport" content="width=device-width" type="text/css" />
<link rel="stylesheet" href="override-handheld.css" type="text/css" />
<link rel="stylesheet" media="all and (max-device-width: 480px)" href="handheld.css" type="text/css" />
<link rel="stylesheet" media="all and (min-device-width: 481px)" href="handheld.css" type="text/css" />
<link rel="stylesheet" media="all and (min-device-width: 1024px)" href="override-handheld.css" type="text/css" />

Let me expand this a little.  In "handheld.css," we have the following:

#footer-switch{
    display: block;
}

This allows the toggle switch in the footer of the full browser version to be displayed.  In "override-handheld.css," we have, not surprisingly:

#footer-switch{
    display: none;
}

This is, obviously, meant to hide the toggle.  Please note, this CSS will actually remove the toggle entirely from the browser, not just visually, but for all hardware including screenreaders, as if it doesn't exist.  This is our goal though, as we only want to call "override-handheld.css" when this particular navigational element should not exist.  

So, in the first line, we call the "show" CSS.  We do this as a "just in case," should all of our conditionals fail for an edge-case mobile user, the switch is available.

This little line - 

<meta name="viewport" content="width=device-width" />

is used to help ID the device width, and is mostly needed to make Android 2.2 and beyond play nicely with mobile stylesheets.  Without this, Android devices running 2.2 and above will simply ignore these media queries. 

Now, these last three -

<link rel="stylesheet" media="all and (max-device-width: 480px)" href="handheld.css" type="text/css" />
<link rel="stylesheet" media="all and (min-device-width: 481px)" href="handheld.css" type="text/css" />
<link rel="stylesheet" media="all and (min-device-width: 1024px)" href="override-handheld.css" type="text/css" />

work for all other mobile devices.  Most devices will be served by the first line, as many handhelds still have a width of 480px or less.  The second line is for (again) many newer Androids, some Blackberries, and of course, tablet devices (*cough iPad cough*).  The last line of CSS is only called for desktop devices, and this hides the mobile toggle switch.  Win!

And speaking of iPads, if your mobile optimized site needs some love especially for the iPad or tablet devices, you can use this same technique in your mobile site's CSS.  Just throw this into the header -

<link rel="stylesheet" media="all and (min-device-width: 481px)" href="tablet.css"> 

and put your tablet-optimized CSS into the appropriate file.  Yay, many conditions!

What’s the deal with Flash on the iPhone?  There have been many reports that a lack of Flash support for the iPhone will continue.  This is despite the fact that more mobile devices including Blackberry, Palm, and even Google Android (custom installs with wide support coming next year), are building up support for the web technology.  Whether you love Flash sites or hate them, Flash is a prevalent technology, meaning that users require some sort of support on popular user agents, and if no support, then a good explanation for its absence.

According to Adobe, the developers of Flash have been attempting for over a year to work with Apple to get Flash loadable on iPhones, but are not getting the support from Apple that they need.  And why not?  According to an article from PC World Magazine, speculation includes two main reasons now.  One, a lack of support for Flash on iPhones based on their one-app-at-a-time functionality, which could make users unable to access other features in Safari or other web browsers on the iPhone.  And two, far more likely also, is Apple’s heavy involvement with the development of HTML 5, which promises to make plugin applications a thing of the past, ultimately.  They’re already testing HTML 5 in browsers.  It is important to note that Apple has not come out and said there will be no Flash support on the iPhone, but chances are, it’s going to take a long time if it comes at all.

So Adobe has come up with a solution.  In an effort to keep Flash relevant, usable, and adaptable on the Internet, according to an article in yesterday’s Computer World, an announcement was made at the Adobe Max conference that Adobe Systems has developed a workaround for Flash developers who want to work with the iPhone.  It will not be able to run in the Safari browser due to Apple’s license terms, and will not be able to compile runtime code.  It will, however, allow Flash developers to compile things written for other mobile devices, and reinterpret them as standalone applications for the iPhone.