Why doesn’t every browser do word wrapping?

Advertisement

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

WAPThis “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”.

“Modern” Browsers

Pocket Internet ExplorerAs 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.

Different browsers use different rendering engines (the code that turns HTML, CSS, and JavaScript into the web pages that you see). Safari, Chrome, and the Android browser all used Webkit. That was great for developers: write code once and you can be pretty certain it will look and act the same on all those browsers. Firefox, Opera, Internet Explorer, and others all used different rendering engines, and each implemented the standards in their own unique way (or incompletely). (Which drives us web developers nuts, by the way!)

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.

Silver Lining

WordPress 2014 ThemeThere 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.

Advertisement

What's your reaction?
Love It
0%
Like It
0%
Want It
0%
Had It
0%
Hated It
0%
About The Author
Joe Levi
Joe graduated from Weber State University with two degrees in Information Systems and Technologies. He has carried mobile devices with him for more than a decade, including Apple's Newton, Microsoft's Handheld and Palm Sized PCs, and is Pocketnow's "Android Guy".By day you'll find Joe coding web pages, tweaking for SEO, and leveraging social media to spread the word. By night you'll probably find him writing technology and "prepping" articles, as well as shooting video.Read more about Joe Levi here.