On 5 Sep 2010, at 13:49, tee wrote:
I have a mobile site (just using media queries) that initially used
XHTML Basic 1.1, the site rendered fine except with a few glitches
(bugs!!??) that I know existed in this browser. Decided to convert
the site to HTML5 and all I did was change the HTML5 doctype, it has
no validation error, it renders the same in Safari Mini and Andriod,
yet in Opera Mini it results a very long horizontal scrolling bar in
portrait view, in landscape view it's a bit shorter (about 50px I
think). I switched back to XHTML Basic 1.1, the horizontal scrolling
bar gone!
Without seeing the site it is hard to tell, but it i probably due to
the rendering mode. When using a mobile doctype (such as XHTML Basic),
the site displays as the author intends (i.e. assumes the site is
designed for small screens and the author knows what they are doing).
For the HTML5 doctype, it is a regular (you could say desktop)
doctype, so Opera Mini/Mobile use the overview rendering mode. This is
when the browser has the zoom in/zoom out mode. The viewport becomes
the width of the virtual viewport (around 8xx pixels, I forget
offhand), so that the full page is laid out/rendered to this virtual
width, rather than the device viewport (the width of the device
screen). It is probably taking 98% and 100% of this virtual viewport,
but I'd have to see and understand the code to know exactly what is
going on.
Like other mobile browsers, it does this to be able to render sites
designed for desktop without breaking the layout. The user can then
zoom in to sections to make the content readable.
The cause:
The #container width is 98% + 1% left/right margin. A plugin that
the site used, has a style sheet that has a 100% width in the
div.widget.
The 100% width from .widget should obey the #container width because
it's wrapped inside the #container but it doesn't. There is an even
scary bug, I brought the widget class to @media screen and (max-
device-width: 480px), if the width stays between 95 to 100% the
horizontal scrolling persist, if 94% or less, it disables the entire
@media rules, the site shrinks to minimum view just like you see in
NYTimes the none-mobile optimized site.
However I also used 100% width for a child class (forgot to get rid
of it) that causes no issue when I display none the plugin. It
appears that the bug is triggered by a combination of javascript -
jquery-ui-accordion.min.js (other scripts are fine).
If the width is removed in the widget than the bug gone, so the bug
is avoidable if one knows it.
tee
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [email protected]
*******************************************************************
David Storey
Chief Web Opener / Product Manager, Opera Dragonfly
W3C WG: Mobile Web Best Practices / SVG Interest Group
Opera Software ASA, Oslo, Norway
Mobile: +47 94 22 02 32 / E-Mail/XMPP: [email protected] / Twitter:
dstorey
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [email protected]
*******************************************************************
