Re: [WSG] Opera Mini rendering issue with HTML5 doctype

[David Storey]

On 5 Sep 2010, at 23:53, tee wrote:

Sometimes next week I maybe able to setup a test site with pages  
that show different doctypes and widths.


Just a quick question, shouldn't Opera Mini obeys the rules even  
when a desktop doctype is used?


@media screen and (max-device-width: 480px)




Opera Mini doesn't support the viewport Meta element (yet). Opera  
Mobile does though. It is something Apple invented and isn't  
standardised (yet). We reverse engineered it for Opera Mobile, but  
there is some cases where it doesn't work exactly the same due to  
assumptions and the two step zoom. We are fixing those issues though  
and trying to standardise Viewport so it is consistent across browsers  
without having to make assumptions die to lack of a spec. We are  
looking to standardise it in CSS though, where it belongs (some people  
on the WG consider it to be like the font tag when used in HTML rather  
than CSS). For the initial proposal, look at http://people.opera.com/rune/TR/css-viewport/ 
 . I expect we’ll support some form of viewport (be it element or CSS  
properties) in Opera Mini eventually. I can't say how soon (yet).





Without them, I would take what I saw isn't a bug. I am pretty sure  
it's more a HTML5 doctype issue than desktop doctype because when  
this site was created,


There shouldn't be a difference between a regular desktop doctype and  
the HTML5 one. It was designed so that it just works in current  
browsers, rather than browsers doing something special when they  
detect it.



I adapted a base template that uses XHTML 1.0 strict, in the first  
round mobile browser check I didn't change it to XHTML Basic 1.1,  
and I didn't see the horizontal scrolling bar (will remember to add  
it to my test). Since that this browser is intended for mobile  
devices,  your reasoning is sound, but I guess developers won't be  
accepting it if we specifically tell the browser to follow the above  
rules.


Make me think maybe I should wait till 2022 to start using HTML5!

tee


Will the media='all' affects how Opera Mini renders Desktop Doctype  
that it ignores the @media screen and (max-device-width: 480px)  
rule?  Some sort of specificity that media='all' overrules other  
media types including media queries?


No, it shouldn’t.





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



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: dsto...@opera.com / Twitter:  
dstorey




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Opera Mini rendering issue with HTML5 doctype

[tee]

 
> 
> 
> Ah, yes -- fun and games on the mobile device funny-farm...
> 
> Long-shot on html5, try ?:
> @media screen and (max-device-width: 480px), screen and (max-width: 480px) {
> } /*for high-end handsets*/
> 
> @media  (max-width: 240px) {
> } /*low-end handsets  running OperaMini */

Doesn't make a difference.

Before I put this issue at rest until I get a chance to setup the test site, 
I'm adding one more possible cause for anyone who is interested in this bug to 
ponder. 

Will the media='all' affects how Opera Mini renders Desktop Doctype that it 
ignores the @media screen and (max-device-width: 480px) rule?  Some sort of 
specificity that media='all' overrules other media types including media 
queries?

It's a WordPress site, I'd just noticed, the plugin stylesheet has a 
media='all' declared which is  taken from WordPress  function 
wp_enqueue_style(). The 

Though a quick test removing the plugin style sheet doesn't seemed to make a 
difference for me.


And a doctype question, will it be safe to use Mobile Doctype for desktop 
browsers too? Part of the reason I decided to switch to HTML5 from XHTML Basic 
1.1 was due to this question.


Quote myself: in the first round mobile browser check I didn't change it to 
XHTML Basic 1.1, and I didn't see the horizontal scrolling bar.

I was wrong; obviously I didn't check carefully in the first round. It resulted 
the same behavior. This new found bug of Opera Mini (and the Opera Mobile too) 
makes me think perhaps it's not a prime time and is a very BAD idea to use 
non-mobile doctype for mobile version of site as it added too much complication 
and unexpected possible bugs. Sort of strengthen my though on media queries 
alone cannot make a good usable mobile version of site. Alas!

tee

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Opera Mini rendering issue with HTML5 doctype

[tee]

Sometimes next week I maybe able to setup a test site with pages that show 
different doctypes and widths.

Just a quick question, shouldn't Opera Mini obeys the rules even when a desktop 
doctype is used?

@media screen and (max-device-width: 480px)
 


Without them, I would take what I saw isn't a bug. I am pretty sure it's more a 
HTML5 doctype issue than desktop doctype because when this site was created, I 
adapted a base template that uses XHTML 1.0 strict, in the first round mobile 
browser check I didn't change it to XHTML Basic 1.1, and I didn't see the 
horizontal scrolling bar (will remember to add it to my test). Since that this 
browser is intended for mobile devices,  your reasoning is sound, but I guess 
developers won't be accepting it if we specifically tell the browser to follow 
the above rules. 

Make me think maybe I should wait till 2022 to start using HTML5!

tee




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Opera Mini rendering issue with HTML5 doctype

[David Laakso]

 On 9/5/10 7:49 AM, 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...

tee






Ah, yes -- fun and games on the mobile device funny-farm...

Long-shot on html5, try ?:
@media screen and (max-device-width: 480px), screen and (max-width: 480px) {
} /*for high-end handsets*/

@media  (max-width: 240px) {
} /*low-end handsets  running OperaMini */

Best,
Dr Larka
Mexico City, Mexico
SanyoMirro on BoostMobile


--
:: desktop and mobile ::
http://chelseacreekstudio.com/



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Opera Mini rendering issue with HTML5 doctype

[David Storey]

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: memberh...@webstandardsgroup.org
***



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: dsto...@opera.com / Twitter:  
dstorey




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

[WSG] Opera Mini rendering issue with HTML5 doctype

[tee]

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!

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: memberh...@webstandardsgroup.org
***

Re: [WSG] HTML5 Boilerplate

[Ben Buchanan]

On 4 September 2010 18:30, tee  wrote:

> I was reviewing the HTML5 Boilerplate that was mentioned in one of the
> thread, curious if this really is a good practise:
>
>  
>  
>

If you don't set the mode explicitly IE8 will pick its own rendering mode,
so I think it's worth doing. I've seen some debate about whether edge is
better than specifying a version of IE, but nothing truly conclusive.

-Ben

-- 
--- 
--- The future has arrived; it's just not
--- evenly distributed. - William Gibson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***