{"id":9026,"date":"2011-01-19T21:07:12","date_gmt":"2011-01-20T05:07:12","guid":{"rendered":"http:\/\/blog.wapreview.com\/?p=9026"},"modified":"2011-01-19T23:02:51","modified_gmt":"2011-01-20T07:02:51","slug":"how-to-fix-word-wrap-in-opera-mobile-for-symbian","status":"publish","type":"post","link":"https:\/\/wapreview.com\/9026\/","title":{"rendered":"How To Fix Word Wrap In Opera Mobile on Symbian"},"content":{"rendered":"

\"paidContent<\/a> \"Yahoo<\/a><\/p>\n

I’ve been using my N8 a lot lately and because the Symbian^3 browser is so bad (slow, too small default fonts and no text-reflow on zoom) I’ve been using Opera Mobile 10.1 quite a bit as well. It’s a much better browser overall; it’s noticeably at faster loading complex pages, has tabs, lets you copy page text,\u00a0 has some HTML5 support including geolocation and text is supposed to reflows to fit the screen width.<\/p>\n

But I keep running into pages where Opera Mobile on the N8 does not wrap text as I think it should. The problem only seems to occur with made for mobile sites. It affects some big names including the mobile editions of Yahoo<\/a>, ESPN<\/a>, Wired<\/a>, paidContent<\/a>, Mashable<\/a> and ReadWriteWeb<\/a>. It was also affecting the mobile edition of WapReview, wapreview.mobi<\/a> (image below, left) which motivated me to find the cause and a fix.<\/p>\n

I ran some tests and and discovered a strange interaction between a page’s doctype and the <meta name=”viewport” content=”width=device-width” \/><\/em> tag.<\/p>\n

My key finding was that if a page has a mobile doctype (xhtml basic or xhtml-mp) and also has a viewport meta tag specifying “width = device-width”, Opera Mobile 10.1 on Symbian only wraps text at the screen boundary when the browser’s zoom level is set to 100%.<\/span><\/p>\n

The viewport width=device-width meta tag tells the browser to fit the page to the screen width. Without it the iPhone and Android browsers assume that the page is designed for desktop browsers and display it as a tiny rectangle in the top left corner of the screen that the user must zoom into to use.\u00a0 Opera Mobile also does the same thing “most” of the time<\/p>\n

If there is no doctype or a\u00a0 “desktop” doctype like HTML 4 or XHTML 1.0 Strict or even HTML5, text wraps at the screen boundary in Opera Mobile at all zoom levels regardless if there is a viewport meta tag or not.<\/p>\n

But switching to a non-mobile doctype (or HTML5) isn’t a complete fix. Even with a non-mobile doctype, the viewport meta tag seems to cause problems with Opera Mobile for Symbian<\/span>. On wapreview.mobi I’ve set the max-width of images to 100%\u00a0 in CSS. My expectation is that this will keep images from extending beyond their container’s (the page) width. The images are the only fixed-width elements on the site so by re-sizing them to page width or less, the page should always fit the screen width with no horizontal scrolling or scroll bar.<\/p>\n

The combination of max-width = 100% and viewport = device-width does work as expected with Opera Mini, the Android browser, the Symbian 3rd ed browser and with Opera Mobile on Android. But in Opera Mobile on Symbian with max- width = 100%, images are not restrained\u00a0 to their container’s width when the page is zoomed, if the page happens to have a\u00a0 viewport width=device-width meta tag<\/span>.<\/p>\n

What Symbian Opera Mobile appears to be doing is rendering the page to fix the 360 px wide device-width at 100% zoom. Then when you zoom to 160% it incorrectly assumes that the device-width has increased to 160% of 360 or 576px and fits the page to that width! Of course, the actual device width has not changed so nothing fits.<\/p>\n

If you’re confused, and you should be, perhaps this matrix will help make it clearer:<\/p>\n\n\n\n\n\n\n\n
Opera Mobile 10.1 on Synbian^3<\/td>\nInitial View<\/td>\nText Wrap<\/td>\nimg max-width = 100%<\/td>\n<\/tr>\n
mobile doctype\u00a0 and viewport meta tag<\/td>\nzoomed in<\/td>\nbroken<\/td>\nzoomed images overflow page width<\/td>\n<\/tr>\n
mobile doctype,\u00a0 no viewport meta tag<\/td>\nzoomed in<\/td>\nOK<\/td>\nzoomed images don’t overflow page width<\/td>\n<\/tr>\n
desktop docktype and viewport meta tag<\/td>\nzoomed in<\/td>\nOK<\/td>\nzoomed images overflow page width<\/td>\n<\/tr>\n
desktop doctype,\u00a0 no viewport meta tag<\/td>\nzoomed out<\/td>\nOK<\/td>\nzoomed images overflow page width<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Note that the only time Opera Mobile gets it right is when there is a mobile doctype and NO viewport meta tag<\/span>. The browser seems to take the mobile doctype as a hint to display the page zoomed in with text fitting the page width regardless of the user selected zoom level, just as the viewport meta tag is supposed to.<\/p>\n

\"WapReview<\/a> \"WapReview<\/a><\/p>\n

With that discovery, I was able to fix (image above, right) wapreview.mobi by using the xhtml-mp doctype and removing the viewport meta tag if the browser is Opera. With that configuration text and images fit the the screen dimensions perfectly in Opera Mobile on all the platforms I tried and also with Opera Mini 4.2 and 5.1 on devices with screen widths ranging from 128 to 480 px wide.<\/p>\n

I’m pretty sure this is a bug rather than intentional. Of all the browsers and the devices I’ve tested only Opera Mobile on Symbian devices (3rd ed., Symbian^1 and Symbian^3) behaves this way. Opera Mobile 10.1 on Android and the Opera Mobile PC emulator wrap text at the screen edge at all zoom levels and any combination of doctype, zoom level, device resolution and the presence or absence of a width = device-width viewport meta tag.<\/p>\n

Opera’s own developer’s introduction to Opera Mobile 10<\/a> says; “For cross-device compatibility, we recommend setting the width to the device-width <meta name=”viewport” content=”width=device-width” \/> This adjusts the page width to fit in the full width of the screen, or put differently, it makes one CSS pixel equal to one device pixel.”<\/em> There is no mention of viewport only working as described with non-mobile doctypes, further reinforcing that this is a bug rather than intended behavior.<\/p>\n

This is a particularly nasty bug that seriously affects the usability of many sites with Opera Mobile 10 on Symbian^1 and Symbian^3.\u00a0 Heres why:<\/p>\n