Russell Beattie writes about integrated browsers on modern mobile phones:
First, there’s little standardization among phone manufacturers right now for minibrowsers. And suprisingly most minibrowsers are *very* tolerant of non-perfect XML. They rarely check DTDs, almost never validate and like your PC browser, do their very best to parse and render whatever XHTML-MP or HTML markup you throw at them. Also, from what I’ve seen, WAP-CSS is supported, but only in a marginal way and the latency to download a linked-to CSS file means that the XHTML-MP sites I’ve seen include the style with each page, rather than have the style of the page “jump” because of the late-loading stylesheet.
I’m starting to generate some design theories as I develop pages as well, which can be summed up as: Long is good, links are bad.
The first part is somewhat controversial, as “long” means more data downloaded per page – which many mobile users are still pay for per KB – and some phones/networks have strict limitations on how large a page can be grabbed and rendered. But the fact is that latency on GPRS and CDMA 2000 1x networks is painful. It takes anywhere from 10 to 30 seconds to load a new page on a decent connection. Better to give users longer pages with more information so they they don’t have to wait for their cellular network every time they view a new page.
The second part is related to network latency as well and is also based based on a mobile user use-case. For most PC-based websites, the links are at the top and the left, and when rendered on the phone, makes users have to scroll endlessly to get to their content. And many minibrowsers navigation is not very good, so you actually have to skip from link to link to move down the page, which could literally mean 40 button clicks to get to the meat of your data. The solution? A lot less links.