It does, however, support parts of the Shadow DOM. That means we can style this element, and give our users a visible control.

The image below shows a rather garish green-and-orange version of the range user interface widget. This is after adding some styling, as it appears in the stock Android browser.

And below is the CSS that gives us the above image.

input[type='range']{
    background: #0c0;
    height:10px;
}

input[type='range']::-webkit-slider-thumb{
    background:#f60;
    height:30px;
    width:30px;
    border-radius: 30px;
}

To date, this does not affect Chrome or Safari for the Desktop. ::-webkit-slider-thumb does partially affect iOS Safari. I’ve included an image of what it looks like below (not to scale). Notice that the thumb color changes, but the slider background does not.

This may also affect other browsers that use Webkit such as the Web Browser for S60 Nokia and Samsung’s Dolfin. I haven’t tested it yet, but if you have, please let us know in the comments.

Also keep in mind that this element has a pretty poor user interaction in Android browser. It’s not very responsive, and doesn’t operate all that intuitively. This is true of most mobile browsers, but in my opinion (and based on limited experience), Android is worst of all.

Much of what we see is that developers rely on a specific browser (e.g., Webkit) and they forget about other engines on various devices, including Opera, Firefox, and others. The problem seems most persistent on mobile, perhaps because of Webkit’s market share. Things break and developers don’t understand why; or they don’t notice the problem, of if they do they do browser sniffing to avoid the problem.

That’s Andreas Bovens of Opera from Interview: Opera on the Web of Devices. Also featured in the interview is Divya Manian, also of Opera.

WebKit’s dominance in the U.S. mobile space is pretty strong. That doesn’t mean, however, that it will stay this way forever. And it doesn’t mean that an alternative browser won’t ever reach a significant market share.

We’ve already seen that happen on desktop. You would think we’ve learned the lessons. And yet the amount of user-agent sniffing, and experimental mono-browser CSS we see in production is pretty mind-blowing. And I mean “mind-blowing” as in, Opera has a person dedicated to mobile developer education and outreach in the U.S. market to combat the problem (me).

I’m not sure how to solve the problem, except to ask that (mobile) developers show some restraint when using the new shiny in production. The vendor-prefix means that the property is in flux, and the syntax of functionality may change radically once it’s finalized and implemented.

Don’t believe me? Look at the history of gradients. Its syntax as introduced changed a few years later. And if the current draft of the specification is any indication, it may change again. Also see: “flexbox.” It’s specification changed completely and then changed mostly back to what it was just in the last 12 months.

I know we all want to be cutting edge and ahead of the curve. But my fear is that we’re creating a climate much like the one that existed in the IE6 heyday.

Back then, developers built Internet Explorer-only sites which broke in Netscape. User perception was “Netscape doesn’t work” or “IE is just better.” So they switched. IE6′s market share was something on the order of 85% at one point. And then it stagnated for five full years until Internet Explorer 7 was released.

Developers paid for this with our frustration costs. Users paid for it time by waiting for extra, IE6 friendly code to download, and in having less awesome web experiences. And Microsoft paid because Firefox ate a big chunk of its market share lunch.

Let’s learn the lessons this time, and be forward-thinking with our mobile development as well.

Requests for pages go from the user’s handset to Opera’s proxy servers. The proxy servers make the request to the requested web site, parse the HTML and JavaScript — subject to time limits — convert it to Opera Binary Markup Language and deliver it to the client on the handset.

Those time limits are about 5 seconds for Opera Mini 5+ and 2.5 seconds for Opera Mini 4. There are also XMLHttpRequest timeout limits of 15 seconds for Opera Mini 5+ and 8 seconds for Opera Mini. Those limits are in place as a way of managing resources on the proxy servers. Once reached, the scripts are stopped and the page is sent as is to the client.

As a result, things often work differently or less consistently than expected on Opera Mini. Your sites will require a bit more testing to make sure they work reliably. You can, of course, do this by installing Opera Mini on your feature phone or smart phone. Or you can install a Java ME emulator and run Opera Mini on your desktop.

To do that, download MicroEmulator. It is a pure Java implementation of Java ME in Java SE — essentially software that replicates a cell phone environment.

Next, download Opera Mini, taking note of where you’ve saved mini.jad.

When you launch MicroEmulator, you’ll be greeted by the “Launcher” screen. Go to the File menu, and select “Open MIDlet File,” navigating to the location of mini.jad. You’ll see “Opera Mini” in the menu. To open Opera Mini, make sure it is highlighted, then click “Start.”

Click to embiggen.

You can then navigate to the pages you wish to test. Those pages will need to be available to the wider internet, of course. Opera’s proxy servers can’t connect to your local WiFi network or intranet.

Keep in mind that MicroEmulator only has one device configuration by default. You can test whether your site works with Opera Mini out of the box, but questions of usability and navigability will require some skinning on your part, and ideally, some real-world device testing.

Step 1: Make sure your JAVA_HOME path is using the correct value

Edit or create a .bash_profile file in your home directory and add the following line.

export JAVA_HOME=`/usr/libexec/java_home`

This will set the JAVA_HOME environment variable to whichever version of the Mac OS X JDK is available. You can see which version is in use by firing up the Java Preferences application (in /Applications/Utilities)

Step 2: Use ./android instead of android to launch the SDK & AVD Manager

The documentation says On Mac or Linux, open a terminal and navigate to the tools/ directory in the Android SDK, then execute: android, but on the Mac, you actually have to type ./android.

That may be obvious to some, but for the n00bs among us, not so much . You can then continue with the installation instructions.

But now some see a new “digital divide” emerging—with Latinos and blacks being challenged by more, not less, access to technology. It’s tough to fill out a job application on a cell phone, for example. … Fifty-one percent of Hispanics and 46 percent of blacks use their phones to access the Internet, compared with 33 percent of whites, according to a July 2010 Pew poll. Forty-seven percent of Latinos and 41 percent of blacks use their phones for e-mail, compared with 30 percent of whites. The figures for using social media like Facebook via phone were 36 percent for Latinos, 33 percent for blacks and 19 percent for whites.

From For minorities, new ‘digital divide’ seen in the Washington Post. (Log in may be required.)

Emphasis mine.

This is why it is so troubling that many companies are shifting to online-only applications, even for jobs — such as janitorial positions — where computer use and required computing skills are minimal. I remember sitting in the human resources office at Georgia Tech when a middle-aged (black) man to ask for a job application for a janitorial job and was told to sit at a computer (one set aside for such things) to fill out an application online. He didn’t know how. He walked out a few minutes later.

I tell this story to ask: who is excluded by your technical decisions?

The fact that the user has a small screen in their hand is one thing – the fact that it is in their hand at all is another. The fact that the user may be walking, driving, or lounging is yet another. In fact, it’s quite likely that they really deserve different content and services altogether – or, at least, a differently prioritized version of the default desktop experience.

Emphasis mine. That’s possibly the most important paragraph from James Pearce’s post Not a mobile web, merely a 320px-wide one.

In other words, a “responsive” web site design works best when the site’s content has been prioritized.

[Via Jen]

Also see: How to Design and Build a Mobile Website, an Inc.com piece with lots of awesome advice from Brian Fling.

But the mobile Web means different things to different people. For more affluent populations, it generally means wireless access with a laptop computer. For poorer people it means a cellphone, which is not a perfect replacement for other forms of online access, said Mr. Smith and several others who study social issues related to technology.

From yesterday’s New York Times blog post Mobile Web Use and the Digital Divide by Joshua Brustein. [via @negrophile]

Also see: Mobile Access 2010 from The Pew Research Center’s Internet & American Life Project.

I carry around a Nexus One and an iPhone. Karanja carries around a Nokia 1600, the cheapest data-enabled phone you can buy ($25). Why? He does this so that he understands what his customers need and use. His clients aren’t your upper-class Blackberry toting professionals, they’re the “wananchi” (the ordinary person).

That’s Erik Hersman of WhiteAfrican.com talking about Kenyan entrepreneur Karanja Macharia in his post A Rising Tide: Africa’s Tech Entrepreneurs.

Hersman gives us a fantastic overview of the ingenuity that African entrepreneurs are showing by working with what’s there: SMS infrastructure, low internet penetration (mobile and otherwise), low incomes, and high mobile penetration.

Also see: Peter-Paul Koch’s February post The iPhone obsession.

We looked at the Motorola i455 cell phone, which is under $30, available even cheaper on eBay, and includes a free GPS applet. We were able to crack it and create a simple compasslike navigation system. We were also able to add other information, like where to find water left by the Border Angels, where to find Quaker help centers that will wrap your feet, how far you are from the highway — things to make the application really benefit individuals who are crossing the border.

Here we have:

• A relatively cheap phone with a GPS application, accessible to its target audience: (comparatively) poor Mexican migrants.
• Relevant information for someone trying to cross a desert.
• Portability and ubiquity. It fits in the pocket

That’s context. When developing mobile applications, we should ask:

• What do people need to know?
• What kind of device can they afford?
• What are the technical limitation of that device (physical size, screen size, input capability, battery life, available memory)?
• How can we build an application that works well on such a device?

A two-part question for Dominguez: how’s the battery life on the phone and how does this application affect it? Getting stuck in the desert with no phone would suck rocks.

[Via PSFK]

UPDATE: Turns out, I wasn’t wrong. I was just clairvoyant . WorldMate is working on an Android version of its application.

Hrm. It appears I was wrong about a WorldMate application for Android. I managed to find an unused download page (by typing “android site:www.worldmate.com” in Google) that listed Android as an option. I assumed — and y’all know how the rest of that goes — that meant there was a WorldMate for Android available now. The HTC device (running S60) pictured on the homepage added to my confusion. Nope. No, WorldMate Android app. My bad on that. The post has been updated below.

Yes, I stole the title from Chris Elliott‘s post on iPhone applications for travelers.

I’m (currently) an Android girl, so I wondered whether it was possible to find similar applications for my G1. I couldn’t find perfect matches for Elliot’s list, but here’s what I came up with.

Where

• What: Where is a series of GPS widgets that you can use to find points of interest, find the cheapest gas, check the weather, or find an area brewery
• Sort of like: Aroundme and Cheap Gas! for the iPhone
• Cost: FREE, but ad-supported.

WorldMate

• There is no WorldMate for Android. What: As Elliott explains, WorldMate offers a bunch of features, including a currency converter, flight updates, integration with Google maps, and an online travel planner with the ability to consolidate your itinerary.
• Sort of like: Um, WorldMate for iPhone.
• Cost: Most features are FREE. Some require a $39.99 subscription.

WeatherBug

• What: Location-aware weather reports for 8,000 U.S. cities. Displays the current temperature in the Android status bar.
• Sort of like: He didn’t mention a weather app, but I am including one anyway.
• Cost: FREE, but ad-supported. Don’t like ads? Try The Weather Channel‘s application.

BistroMath

• What: Determine who owes what and how much to tip — in case you’re not down with using the built-in calculator.
• Sort of like: CheckPlease!
• Cost: FREE

Unfortunately, a FREE flight tracker isn’t yet available for Android. But if you really need one, FlightStats costs $5.99.

Do you use a travel-related Android application? Tell us in the comments.