Mobile devices used to be primarily portable email boxes with integrated calendar and contacts. In the early days, some of them may have included web browsers, but they were very primitive. Back then the Web was very complex, and designed for screens with resolutions of 800 by 600 and higher.
To accommodate phones and PDAs a “new” web was invented, one that used a completely different protocol to address the concerns of much smaller screens, slower processors, and mobile data plans. None of which were anywhere close to what we have today.
WAP & WML
This “new” web was based on something called WAP. The Wireless Application Protocol was a standard which allowed mobile devices to send and receive data over very early wireless networks. To view content thusly delivered, a person’s mobile device needed a WAP browser — a web browser of sorts, for mobile devices.
WAP wasn’t the only standard competing for the top spot. In Japan, “i-mode” was another wireless data protocol, with certain advantages as well as disadvantages to WAP. Most of Europe and these United States adopted WAP as the mobile protocol of choice.
After the standard had been selected and devices were shipping with compatible browsers, all that was left were the web pages. Unfortunately, people that wanted their sites to be viewed on mobile screens had to mark up those pages again in WML — Wireless Markup Language. It wasn’t all that similar to HTML, which every other website and web browser in the world used. What’s more, compatible websites were encouraged (in some cases, required) to use a .mobi domain. These domains were relatively expensive, and fairly unintuitive, requiring users to type an additional letter on a keypad (usually not a keyboard) to get to the mobile site versus the desktop site.
Lastly, to add insult to injury, some handset manufacturers removed the address bar completely, allowing their users access only to the sites which were directly linked from their “deck”.
As operating systems got more robust and processors became more powerful, mobile web browsers that could consume the “desktop” version of the web started to become more useful. Unfortunately, without some pretty significant “dumbing-down” to make web content useful on a small screen, viewing desktop versions of web pages in such tight quarters was still unattractive.
Web developers (like myself) began writing content that could scale and adapt to smaller screens, and browser manufacturers started making their apps “smart” enough to render full, “zoomable” pages. When “zoomed out” the pages looked just like you’d expect on a desktop computer. With with a double-tap or a pinch, you could zoom in on a certain area of the page. It wasn’t a perfect solution, but it was getting close.
Text (Re)Flow, Word Wrapping, & Auto-Fit
In the early days of Android, the stock browser would render a web page, and intelligently focus in on what it thought was the main textual content on the page. It would then reflow the text such that all of it appeared in a single column that was exactly the same width as your screen. This allowed users to simply slide their finger up or down the screen to scroll. It was very useful, and worked — most of the time. If you wanted to see more of the screen, you could zoom out, but the text would reflow to fit the new screen width.
Then, one day out of the blue, that feature just up and vanished. Our own Michael Fisher noticed the change and longs for the days of easily readable non-mobile content on his smartphones. He’s not alone. Doing a quick search for “android browser text flow” will return more documents, bug reports, forums, and gripe sessions than any one person could ever hope to read. Let me save you the trouble.
That’s when Google started spending more time working on Chrome (both desktop, tablet, and Android versions), and less time on the stock browser. Around the time of Android 3.0 Honeycomb, the auto-fit and text-flow all but vanished from the code.
Eventually Google and Webkit started parting ways. Google opted to include its own rendering engine, Blink, in Chrome and Chromium. It did so because Webkit was getting “bloated” and rendering pages slower than Google wanted. To help speed things up, Google removed features, even ratified standards from newer versions of its web browsers.
It doesn’t make much sense to update and maintain code for two different rendering engines, so Google has been blending them. This means apps which use the “webview” are slowly getting the features that Google is putting into the Chrome browser for Android — and losing the features Google is taking out.
Many third-party browsers, like those bundled into Sense, TouchWiz, and other ROMs simply include Google’s rendering engine, complete with its benefits — and repercussions. As these OEMs update their apps, features such as text-flow and auto-fit are going away.
There are a few benefits we can take away from all this. First of all, because these browsers are all based on the same rendering engine, web pages should look consistent across all of them. This means web developers can spend more time making websites that are fast and function well, rather than troubleshooting strange issues and ultimately developing code for the lowest-common denominator (some of us still have to write code that’s compatible with Internet Explorer 6 and 7).
More importantly, web developers are getting more experience, development tools are getting more powerful, and both are starting to approach development from a “mobile first” perspective. Before too long, zooming web pages at all will be a thing of the past. Until then, web developers will enjoy quite a bit of job security as we (eventually) make your favorite web sites a nearly native experience.