Re: [WSG] Opera Mini fontsize settings

[tee]

Forgot to mention, it's Opera Mini 6.

On Oct 13, 2011, at 5:52 AM, tee wrote:

> Yes, it used to be there, but not anymore.
> 
> 
> http://bit.ly/qa9GmY
> 
> tee
> On Oct 13, 2011, at 5:13 AM, Patrick H. Lauke wrote:
> 
>> settings > font size (3rd option down)
>> 
>> or am i missing something?
>> 
>> --
>> Patrick H. Lauke
>> 
>> 
>> On 13 Oct 2011, at 13:55, tee  wrote:
>> 
>>> I clearly remember OM used to have this feature, but in my recent upgrade, 
>>> it's gone. Anybody knows about this? This list has Opera Inc employee(s), 
>>> and I wonder if you are aware of this.
>>> 
>>> Thanks!
>>> 
>>> tee
> 
> 
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: memberh...@webstandardsgroup.org
> ***
> 



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

Re: [WSG] Opera Mini fontsize settings

[tee]

Yes, it used to be there, but not anymore.


http://bit.ly/qa9GmY

tee
On Oct 13, 2011, at 5:13 AM, Patrick H. Lauke wrote:

> settings > font size (3rd option down)
> 
> or am i missing something?
> 
> --
> Patrick H. Lauke
> 
> 
> On 13 Oct 2011, at 13:55, tee  wrote:
> 
>> I clearly remember OM used to have this feature, but in my recent upgrade, 
>> it's gone. Anybody knows about this? This list has Opera Inc employee(s), 
>> and I wonder if you are aware of this.
>> 
>> Thanks!
>> 
>> tee


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

Re: [WSG] Opera Mini fontsize settings

[Patrick H. Lauke]

settings > font size (3rd option down)

or am i missing something?

--
Patrick H. Lauke


On 13 Oct 2011, at 13:55, tee  wrote:

> I clearly remember OM used to have this feature, but in my recent upgrade, 
> it's gone. Anybody knows about this? This list has Opera Inc employee(s), and 
> I wonder if you are aware of this.
> 
> Thanks!
> 
> tee
> 
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: memberh...@webstandardsgroup.org
> ***
> 


***
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]

 
On Sep 5, 2010, at 5:30 AM, David Storey wrote:

> 
> 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. 

I setup a test case:
http://bit.ly/aPlv1b 

If you can test from Opera Mini, please let me know what you see in 2 to 4 test 
pages. Do you see a horizontal scrolling bar and shrunken page? 

If you could help identify the behavior and result of #5 would be great.

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 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
***

Re: [WSG] Opera Mini

[tee]

 
On Aug 24, 2010, at 1:51 PM, Patrick H. Lauke wrote:

> On 24/08/2010 21:33, tee wrote:
>> Despite what I have learned from David Story about Opera Mini, media
>> queries along cannot make a usable mobile version of site that is
>> truly targets mobile user. Content negotiation and adaption cannot be
>> forgone, there are more to it to make usable mobile version site than
>> displaying none to elements you don't want the mobile users see.
> 
> Of course that depends on the type of site and the content that's currently 
> there. A site that's very focussed on just the essential actions (say a very 
> specific web application or single-purpose site) will have the same content 
> on both desktop and mobile devices. What's often the case is that desktop 
> versions of sites (remembering my days as university web editor here) start 
> to bloat dramatically (with departments angling for a bit of space on the 
> homepage, then slapping on videos and "welcome from the Vice Chancellor" type 
> messages), when really both on mobile and desktop they should be pared down 
> to the absolute essentials of what visitors come there to do. It's just that 
> on desktop, with our large monitors and mice (leaving accessibility 
> considerations to the side for a minute) we've become adept at quickly moving 
> past the cruft to the actual bits we want. These are then the ones that 
> developers want to hide from mobile views.
> 
> This sort of approach has recently been expounded by Luke Wroblewski with his 
> "mobile first" philosophy. It's a good wake-up call (but of course this is 
> only applicable in certain situations). http://www.lukew.com/
> 

A laudable presentation. 

I have reached a state where everything heading towards subtraction, this state 
of mind helps problem solving and clarity, be it personal issue or web 
development. I was using the similar approach, not in the first mobile site 
though. The first time it was unclear, a bit uneasy what to expect, what to 
show due to un-familiarity of mobile devices and what can mobile browsers do 
and was very much in the "desktop mode". It got better each time, then the 
third, the fourth, before I begun I knew what elements not to include or 
include but using different approach than I would normally do. 

Even that, there are still situation this Mobile First approach may not work 
out quite well using only media queries. Two examples:

1. An element that you want display both in desktop and mobile version, it 
maybe a long list of menu items (this maybe easier to solve by using a dropdown 
list) or a block of content that you want it place above the main content 
structurally for desktop version (in the header perhaps), not through source 
ordered and CSS manipulation, then in the mobile version, you want it placed 
after the content [1] , I have not figured a smart and clean way to do this 
using media queries or CSS manipulation (absolution positions can do this but 
it requires precise calculation for height which I think is ugly and bad) than 
content adapation.

2. Using a blog site for example, a site may want to display 5 popular posts 
but in the mobile version to display only two, the same can be for homepage 
that a site may want to show a handful of recent articles for desktop version 
but 1 for mobile version.

Maybe displaying none using :nth-child could do that. Can Opera Mini handles it 
I have not tested; I wouldn't go this route though, and the moment you start 
thinking to solve this in the template, it's a content negotiation


[1] It may not be so important structurally long as visually it's placed after 
the content, but if google or any search engine service offers a mobile search 
than this might be something worth consider especially if SEO gurus buzz about 
it and then clients come to tell you they want it done this way or that way.

> As ever, your mileage may vary,

My mileage is good, though can always improved :-)

tee



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

Re: [WSG] Opera Mini

[MichaelMD]

On Tue, 2010-08-24 at 09:09 -0400, David Laakso wrote:

> However, it would be a grave mistake to advocate not using  CSS, media 
> queries, or Opera Mini for "low-end" handsets. Opera Mini has brought 

I wasn't saying not to use css ... just don't *rely* on it rendering as
you expect on all mobile devices. 

> the Web to these devices. And it is to the credit of Opera Software / 
> Opera Mini that in some parts of the world the privilege of experiencing 
> the Web is now possible for the first time...

I tried Opera Mini .. but only the most basic version can be installed
on my phone and (like every other java app I have ever tried on it) it
was very slow and clunky to use compared to the built-in browser. (this
is not Opera's fault. I guess the api available to java apps on some
such handsets is just too limited to do anything really useful with!) 

on such handsets, people *are* going to be stuck with the inbuilt
browser. 







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

Re: [WSG] Opera Mini

[Patrick H. Lauke]

On 24/08/2010 21:33, tee wrote:

Despite what I have learned from David Story about Opera Mini, media
queries along cannot make a usable mobile version of site that is
truly targets mobile user. Content negotiation and adaption cannot be
forgone, there are more to it to make usable mobile version site than
displaying none to elements you don't want the mobile users see.


Of course that depends on the type of site and the content that's 
currently there. A site that's very focussed on just the essential 
actions (say a very specific web application or single-purpose site) 
will have the same content on both desktop and mobile devices. What's 
often the case is that desktop versions of sites (remembering my days as 
university web editor here) start to bloat dramatically (with 
departments angling for a bit of space on the homepage, then slapping on 
videos and "welcome from the Vice Chancellor" type messages), when 
really both on mobile and desktop they should be pared down to the 
absolute essentials of what visitors come there to do. It's just that on 
desktop, with our large monitors and mice (leaving accessibility 
considerations to the side for a minute) we've become adept at quickly 
moving past the cruft to the actual bits we want. These are then the 
ones that developers want to hide from mobile views.


This sort of approach has recently been expounded by Luke Wroblewski 
with his "mobile first" philosophy. It's a good wake-up call (but of 
course this is only applicable in certain situations). http://www.lukew.com/


As ever, your mileage may vary,

P
--
Patrick H. Lauke
__
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
__
twitter: @patrick_h_lauke | skype: patrick_h_lauke
__


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

Re: [WSG] Opera Mini

[tee]

 
On Aug 24, 2010, at 3:24 AM, Michael MD wrote:

> 
>> I am working on  a mobile version WordPress site that I have not done
> content negotiation yet, but display none the content >including inline
> images that I don't want them show up in mobile version. The homepage is a
> little heavy due to a large 
> 
> I wouldn't rely on css for mobile sites ... to many phones don't support it
> properly ... 
> Mine doesn't (it just ignores it)

On top of serving media queries for mobile version, a very basic phone style 
sheet will be served even though I am pretty sure my clients' targeted 
audiences won't be those who use low-end phones for web browsing - the way I 
look at this is, it's like food, if it isn't taste good, nobody will want to 
eat it unless one is starving at near death stage. There are just too many 
limitation, too costly , too unappealing reason for anyone willing to visit a 
site (even if it's mobile web optimized) in older phones. I don't built sites 
that can be used for surviving purpose so I can rest assure no starving people 
come to the sites I build for emergency and hope to be rescued.

Despite what I have learned from David Story about Opera Mini, media queries 
along cannot make a usable mobile version of site that is truly targets mobile 
user. Content negotiation and adaption cannot be forgone, there are more to it 
to make usable mobile version site than displaying none to elements you don't 
want the mobile users see.

tee

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

Re: [WSG] Opera Mini

[David Laakso]

Michael MD wrote:

I wouldn't rely on css for mobile sites ... to many phones don't support it
properly ... 
Mine doesn't (it just ignores it)
 

  




Mobile devices in the category such as yours [older less capable 
handsets] respond well to the method proposed by Luca Passani [1].


However, it would be a grave mistake to advocate not using  CSS, media 
queries, or Opera Mini for "low-end" handsets. Opera Mini has brought 
the Web to these devices. And it is to the credit of Opera Software / 
Opera Mini that in some parts of the world the privilege of experiencing 
the Web is now possible for the first time...


Best,
~d

[1]





--
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

[Michael MD]

>I am working on  a mobile version WordPress site that I have not done
content negotiation yet, but display none the content >including inline
images that I don't want them show up in mobile version. The homepage is a
little heavy due to a large 

I wouldn't rely on css for mobile sites ... to many phones don't support it
properly ... 
Mine doesn't (it just ignores it)
 
Opera mini (or ANYTHING that comes as a java app) works rather poorly my
phone 
So I end up just using the built in browser - even though can't do css or
javascript...

If you want to build a mobile site for the *general public* it will need to
be usable on devices WITHOUT css, javascript or flash.

Don't forget there are a lot of people like me out there who just won't
spent $1000 on a phone and are not willing to go into debt on some "plan"...
and ... how often does the average person buy a new phone?



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

Re: [WSG] Opera Mini

[David Storey]

On 23 Aug 2010, at 20:28, tee wrote:


Hi David from Opera,

Quote you:
I'm a member of that WG but honestly it is complete useless and out  
of date. It was commissioned when 12kb all together was a big deal.


From the Mobile Web Best Practices course class I got an impression  
the mobileOK Checker is an improved version (v1.4.1) but I have no  
prior experience to compare it.


Improved as in improved to test to the requirements to what MobileOK  
was set out to test when it was commissioned, yes. That was when  
things like Palm WebOS, Android, iOS etc didn't exist and browsers for  
low end devices which can handle heavy content like Opera Mini were in  
their infancy.




I am working on  a mobile version WordPress site that I have not  
done content negotiation yet, but display none the content including  
inline images that I don't want them show up in mobile version. The  
homepage is a little heavy due to a large image (display none  
already), both mobileOK Checker and mobiReady test showed the page  
is over 80K and picked up all inline images.


I'd forget .mobi. It is already dead. People like Cameron Moll which  
were early cheerleaders of .mobi are already not renewing their .mobi  
domains. I consider that a checker bug if they are counting resources  
that are not loaded. Of course there are some  devices that load them  
(which are also devices that are commonly pay per kb of content  
downloaded) so you have to decide if you are targeting your content at  
those browsers (if there are a significant number of your users using  
those browsers). If not then you can ignore it. If so then you have to  
care about it.


Is there a way to find out exactly how many kilobyte Opera Mini  
loaded the page since you said it doesn't load anything sets to  
display none.


for us (Opera) yes, but I'm not sure there is for developers We  
average 90% compression so you can look at what Opera desktop does and  
remove 90% (just a guestimate on the avg).



You mentioned Dragonfly, I do use this tool when I check site in  
Opera, but it will not be a tool that can be replaced by FF Web  
Developer tool for most developers who live and breath by FF and the  
extension I believe


Ok, your choice. I'm PM of DFL so I'll aim to remove that argument by  
improving our tool, but sure…
(the UI is more intuitive and easier to navigate for layout  
troubleshoot  or  to find what classes/ID are in a block etc. ), and  
I do not see Dragonfly for Opera Mini and Opera Mobile. I searched  
for it few months ago.


You don;t need to download DFL for a device. DFL is the first tool  
that supports remote debugging (WebKit is now coming out with this).  
Basically you can set it in the desktop browser to remote debug mode  
(in settings, but we'll make it more obvious soon) then you can go to  
opera:debug on the device and connect to the desktop Opera DFL. It  
currently works on Opera Mobile and opera for devices. It can't work  
on Mini as the client uses some binary content rather than HTML/CSS  
(as it transcodes). IT may be possible in the future to debug what the  
Opera Mini sever sees, but as the client isn't HTML, there isn't much  
point to expose that in any meaningful way.





Another thing, Opera Mini does not load the font family (along with  
many other elements) but the default Sans-serif, however it's able  
to pick up some CSS3 elements (one that I see is text-shadow). Is  
this a device restriction preventing Opera Mini from doing this? I  
have a doubt because iPod (I think iPhone too but I don't have one  
to check) is capable of loading both default Sans and Sans-serif.



Thanks!

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
***

Re: [WSG] :: opera mini 5.1 ::

[tee]

 
On Aug 6, 2010, at 6:59 PM, David Storey wrote:

> 
> On 7 Aug 2010, at 00:44, tee wrote:
> 
>> 
>> On Aug 5, 2010, at 4:23 PM, David Storey wrote:
>>> 
>>> Not strictly true. First of all Opera Mini compresses the content and 
>>> images (which is one of the reasons for the image quality setting - it will 
>>> compress it less on high setting) to optimise it for low bandwidth devices. 
>>> Opera (in general) also doesn't load resources that are set to display: 
>>> none; until they are set to show on the page.
>> 
>> Hi David,
>> 
>> This is interesting but I am not sure I fully understand it. Compression 
>> this I understand, but not loading the display none part. Are you saying 
>> that Opera Mini able to exclude inline elements in the markup that are 
>> declared display none in the style sheet.
> 
> Yes that is correct. If a resource is display: none, opera will not load it 
> until you set it as display: block or whatever. Providing I  understand your 
> english correctly.
> 
>> 

Hi David, 

Thanks for the answers! One last question.


I am still having a tiny bit of issue to fully understand it, for the reason 
that I view at a html page a non-abstract object, it's real solid. A header, a 
left column, a content block, they are real filled with content (images and 
texts). Taking off the style sheet, we see a un-styled page, look into the 
source code, we see the skeleton of the page (still with content in it except 
the inline object such as image).


After my previous message, I realized that using inline 
image for my question wasn't  a best example, because inline image requires an 
action, a "link" to call the image, so strictly speaking, the image is not 
exactly part of the content but a standby that gets call in if it's told so  
whereas the "link action" (img src="image.jpg") is part of the content 
(skeleton of the page ). In this sense I do understand fully that Opera Mini 
able to exclude an inline image that is set to display none. I assume if the 
link action has a wrong command (link path not correct) or the image is not 
presented in the server, then desktop browser will not load the image too thus 
no extra file size. 

But how about the content ? Whether a paragraph of texts is of static HTML 
or get pulled in dynamically, it's loaded into the page and is part of HTML 
structure.


.no-display {display:none}

Can Opera Mini not load the "no-display" paragraph?

p/s. If you have difficulty understand my English, I can write in Chinese or 
Malay, and you can use Google translation :-)

tee



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

Re: [WSG] :: opera mini 5.1 ::

[David Laakso]

Duncan Hill wrote:
On Fri, 06 Aug 2010 01:51:17 +0100, David Laakso 
 wrote:


Hmm. Doubt it is Opera Mini. SanyoMiro okay this end. N80 cache 
issue? AP from sidebar [digits] and/or header "metroedition" 
display:none; not holding? I will check it out. Thanks for the 
"heads-up."


Best,
~d


I've reset Opera Mini on the N80.
Default image quality appears to be 'Medium', which results in a small 
width image but with no side-scroll for the page.

Is max-width 35% correct for the image on the 480px screen ??

Duncan






re: 

Doing considerably better on a low-end Sanyo/Mirro on this end. Unable 
to test in N80.
No scrollbar portrait or landscape. Settings at "mobile view-off," 
text-size medium and large, everything else at default.
Now feeding a separate set of much smaller images only to the handset. 
This seems to be the answer?


Best,
~d


--
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 5.1 ::

[David Storey]

On 7 Aug 2010, at 00:44, tee wrote:



On Aug 5, 2010, at 4:23 PM, David Storey wrote:


Not strictly true. First of all Opera Mini compresses the content  
and images (which is one of the reasons for the image quality  
setting - it will compress it less on high setting) to optimise it  
for low bandwidth devices. Opera (in general) also doesn't load  
resources that are set to display: none; until they are set to show  
on the page.


Hi David,

This is interesting but I am not sure I fully understand it.  
Compression this I understand, but not loading the display none  
part. Are you saying that Opera Mini able to exclude inline elements  
in the markup that are declared display none in the style sheet.


Yes that is correct. If a resource is display: none, opera will not  
load it until you set it as display: block or whatever. Providing I   
understand your english correctly.


If so, I would like to learn more the technical aspect how Opera  
Mini does it.


Not much to learn (not that it really matters to you). Basically the  
browser reads the style sheet and doen't load the resource that are  
not displayed.




If David L display none his 170kb inline image, Opera Mini will not  
load that 170kb or whatever reduced size that is after the  
compression?


Not sure I understand but if it is what I think then no it will not  
display.




When I did my final assignment for the Mobile Web Best Practices  
course I mentioned, I needed to make a page  (a WordPress blog) stay  
within 10k file size


I'm a member of that WG but honestly it is complete useless and out of  
date. It was commissioned when 12kb all together was a big deal. Now  
it is trivial. On smart phone no one cares as it is often unlimited  
data. On regular devices it matters cause you often pay per kb, but  
devices like OM have compression  and 12 kb is too small for a  
realistic page. The limit is set brcause many on the WG are browser  
vendors or such from WAP browsers  who have poor quality products  
(only IMHO) , that can't cope with real web sites (unlike Opera Mini  
or webkit browsers_


, it was more than a challenge having to watch over every byte in a  
dynamic page. I first used the media queries, "display:none" side  
column items (e.g., tags, archives, recent comment and inline image  
etc...) that I wanted to exclude in mobile version. Visually I get  
the result I wanted, but as far as markup and file sizes are  
concerned, they were still there in the source code.


But not loaded unless the browser is very low quality.

I tested the page over MobileOK Checker, the validator picked them  
up too, and that is how I concluded without some sort of content  
negotiation


Don't trust automated systems. They will lead you up blind ally  
without a paddle.


(along with other more aggressive methods), media queries is just a  
very nice idea for mobile version of site without much practical use,


Bull terds.

unless, we don't care at all optimization.


unfounded and incorrect.



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
***

Re: [WSG] :: opera mini 5.1 ::

[tee]

 
On Aug 5, 2010, at 4:23 PM, David Storey wrote:
> 
> Not strictly true. First of all Opera Mini compresses the content and images 
> (which is one of the reasons for the image quality setting - it will compress 
> it less on high setting) to optimise it for low bandwidth devices. Opera (in 
> general) also doesn't load resources that are set to display: none; until 
> they are set to show on the page.

Hi David,

This is interesting but I am not sure I fully understand it. Compression this I 
understand, but not loading the display none part. Are you saying that Opera 
Mini able to exclude inline elements in the markup that are declared display 
none in the style sheet. If so, I would like to learn more the technical aspect 
how Opera Mini does it. 

If David L display none his 170kb inline image, Opera Mini will not load that 
170kb or whatever reduced size that is after the compression?

When I did my final assignment for the Mobile Web Best Practices course I 
mentioned, I needed to make a page  (a WordPress blog) stay within 10k file 
size, it was more than a challenge having to watch over every byte in a dynamic 
page. I first used the media queries, "display:none" side column items (e.g., 
tags, archives, recent comment and inline image etc...) that I wanted to 
exclude in mobile version. Visually I get the result I wanted, but as far as 
markup and file sizes are concerned, they were still there in the source code. 
I tested the page over MobileOK Checker, the validator picked them up too, and 
that is how I concluded without some sort of content negotiation (along with 
other more aggressive methods), media queries is just a very nice idea for 
mobile version of site without much practical use, unless, we don't care at all 
optimization.

tee





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

Re: [WSG] :: opera mini 5.1 ::

[Duncan Hill]

On Fri, 06 Aug 2010 14:50:57 +0100, David Laakso  
 wrote:



I misunderstood, Duncan. Now I see what you mean...

On this end the scroll is only seen on the 7 portfolio pages. All the  
portfolio images are 10px left-aligned and approx 160px wide [35%] and  
fit within the window. However, I can scroll horizontally in which case  
there is white space and the double rule [border].  I have found that it  
is solely the image that causes this -- no image -- no horizontal  
scrollbar.


I will try Tee's suggestion but modify it so that a smaller set of  
portfolio images is used specifically and only for mobile.


Thanks to all for your diligence and persistence in helping me to  
resolve this little dilemma.


Best,
~d


No, maybe it's me getting confused.

As you have not set any width on the image in the html, I was seeing it as  
the image would be constrained to 35% of its parent container,   
which has no styling set and is itself constrained by #main with a  
max-width of 40em.


Corrections to my thinking are more than welcome from all.

 I'll just quietly watch developments.

Best wishes

Duncan


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

Re: [WSG] :: opera mini 5.1 ::

[David Laakso]

Duncan Hill wrote:


I've reset Opera Mini on the N80.
Default image quality appears to be 'Medium', which results in a small 
width image but with no side-scroll for the page.

Is max-width 35% correct for the image on the 480px screen ??

Duncan









I misunderstood, Duncan. Now I see what you mean...

On this end the scroll is only seen on the 7 portfolio pages. All the 
portfolio images are 10px left-aligned and approx 160px wide [35%] and 
fit within the window. However, I can scroll horizontally in which case 
there is white space and the double rule [border].  I have found that it 
is solely the image that causes this -- no image -- no horizontal scrollbar.


I will try Tee's suggestion but modify it so that a smaller set of 
portfolio images is used specifically and only for mobile.


Thanks to all for your diligence and persistence in helping me to 
resolve this little dilemma.


Best,
~d





--
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 5.1 ::

[Duncan Hill]

On Fri, 06 Aug 2010 01:51:17 +0100, David Laakso  
 wrote:


Hmm. Doubt it is Opera Mini. SanyoMiro okay this end. N80 cache issue?  
AP from sidebar [digits] and/or header "metroedition" display:none; not  
holding? I will check it out. Thanks for the "heads-up."


Best,
~d


I've reset Opera Mini on the N80.
Default image quality appears to be 'Medium', which results in a small  
width image but with no side-scroll for the page.

Is max-width 35% correct for the image on the 480px screen ??

Duncan


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

Re: [WSG] :: opera mini 5.1 ::

[David Laakso]

tee wrote:

Checked one of a mobile sites I did that has inline image larger than 480px 
...trimmed, thanks [I think  :-) ].







Oh, easy for Leonardo.
-- Dylan Thomas




--
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 5.1 ::

[tee]

I forgot to mention, when switching between  portrait and landscape, Opera Mini 
dosen't auto re-adjust and refresh the layout, you need to refresh it manually 
if you try to see the examples from the O browser. This bug gave  a false 
impression the first time I used Opera Mini, that the media rule doesn't get 
picked up, and took me days to realize the quirk (guess I am a slow learner :-) 
). 

tee
On Aug 5, 2010, at 7:55 PM, tee wrote:

> Checked one of a mobile sites I did that has inline image larger than 480px 
> and  no width/height attributes were declared in the CSS and markup, but 
> Opera Mini is able to resize the image fits in the screen.
> 
> I think I have a fine guess what has gone wrong with your inline image-it's 
> simply too long, and Opera Mini resizing the whole image to fit in the screen 
> propotionally using Height, though I suspect the way you have your img 
> declared  (auto height and max-width) might have attributed to it but I 
> didn't test it more thoroughly.
> 
> your vision - orignial image
> image sie: 620 x 2254px
> http://bit.ly/mwdd  
> 
> I thought maybe html5 be contributed too it too so I made a XHTML version to 
> compare just in case. 
> 
> image sie: 620 x 861px
> image trimmed - xhtml version
> http://bit.ly/mwddd2
> 
> trimmed image - html5 version
> http://bit.ly/mwddd3  
> 
> Screen shots taken from Opera Mini and Safari
> http://greensho.nexcess.net/mweb/s1.png  - landscape, note that it resized 
> the image to fit in 320 height thus making the image rendered smaller than 
> the portrait view below.
> 
> http://greensho.nexcess.net/mweb/s3.png  - portrait.
> 
> I guess David from Opera has a good explanation for it.
> 
> A note for Safari and Andriod, the trimmed image is still too wide and part 
> of it got cut off, but this can be compensated with reduced percentage in 
> both width and height.
> http://greensho.nexcess.net/mweb/d4.html
> 
> David, FYI re input padding bug
> http://greensho.nexcess.net/mweb/s2.png  
> http://greensho.nexcess.net/mweb/s3-safari.png
> 



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

Re: [WSG] :: opera mini 5.1 ::

[tee]

Checked one of a mobile sites I did that has inline image larger than 480px and 
 no width/height attributes were declared in the CSS and markup, but Opera Mini 
is able to resize the image fits in the screen.

I think I have a fine guess what has gone wrong with your inline image-it's 
simply too long, and Opera Mini resizing the whole image to fit in the screen 
propotionally using Height, though I suspect the way you have your img declared 
 (auto height and max-width) might have attributed to it but I didn't test it 
more thoroughly.

your vision - orignial image
image sie: 620 x 2254px
http://bit.ly/mwdd  

I thought maybe html5 be contributed too it too so I made a XHTML version to 
compare just in case. 

image sie: 620 x 861px
image trimmed - xhtml version
http://bit.ly/mwddd2

trimmed image - html5 version
http://bit.ly/mwddd3  

Screen shots taken from Opera Mini and Safari
http://greensho.nexcess.net/mweb/s1.png  - landscape, note that it resized the 
image to fit in 320 height thus making the image rendered smaller than the 
portrait view below.

http://greensho.nexcess.net/mweb/s3.png  - portrait.

I guess David from Opera has a good explanation for it.

A note for Safari and Andriod, the trimmed image is still too wide and part of 
it got cut off, but this can be compensated with reduced percentage in both 
width and height.
http://greensho.nexcess.net/mweb/d4.html

David, FYI re input padding bug
http://greensho.nexcess.net/mweb/s2.png  
http://greensho.nexcess.net/mweb/s3-safari.png

tee

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

Re: [WSG] :: opera mini 5.1 ::

[David Laakso]

tee wrote:



This site may give you a general idea how much it may cost your mobile user per 
page.
http://mobiready.com


tee




  






Granted all 7 images in the portfolio section are heavy, Nevertheless, 
the mobile device is SanyoMirro [ a "low-end" handset-- it is not a 
"smart-phone" ] for BoostMobile [ the carrier charge is a flat-fee of  
50 dollars per month for /unlimited/ phone and internet use -- there is 
no mobile user per page charge ]. Unlike my former iPhone I do not need 
to constantly re-charge the battery; I can make  audible phone calls to 
a friend who lives in the same apartment building as me; I can also make 
audible phone calls to downtown Boston [4 miles away]; I am able make 
frequent audible phone calls to California,
Tennessee, and Michigan. And it sure is a lot /easier and cheaper/ to 
read the New York Times on a daily basis on my SanyoMirro than it ever 
was on my iPhone...


Rock-on Opera Mini/BoostMobile.

End of AT&T/smart-phone rant :-) .

Best,
~d

--
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 5.1 ::

[David Laakso]

Duncan Hill wrote:
On Thu, 05 Aug 2010 21:41:33 +0100, David Laakso 
 wrote:




Having checked in Opera desktop, which does respond to the @media 
queries, and the N80, I have a suspicion that there may be something 
in your header that is maintaining a side scroll on the handheld.

Could that be an overflow failure in Mini or a minimum size setting.

Best wishes

Duncan






Hmm. Doubt it is Opera Mini. SanyoMiro okay this end. N80 cache issue? 
AP from sidebar [digits] and/or header "metroedition" display:none; not 
holding? I will check it out. Thanks for the "heads-up."


Best,
~d


--
desktop
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 5.1 ::

[David Storey]

On 5 Aug 2010, at 23:51, tee wrote:



On Aug 5, 2010, at 2:05 PM, David Storey wrote:



On 5 Aug 2010, at 21:12, tee wrote:


Hi David,

Having done 2 full sites+ many exercise mobile sites, I view at  
Opera Mini (including the Mobile 10) the Internet Explorer 6+7,  
it's a browser one will hate it, curse it more than praise it :-(


What are your issues with Opera Mobile (Opera Mini has known  
restrictions as it is designed for low-end devices which can't  
power a full browser; .





Are you mixing up Mini and Mobile,


Oops, I must be. Mini and Mobile sounded very much the same browser  
to me, and I got an impression that  Opera had consolidated the two  
name from Mini to Mobile 10 since the version 5.


No. Opera Mini is for JavaME enabled feature phones and restrictive  
devices (such as iOS), but does work on Smart Phones as it works  
anywhere (and there are special versions for a number of smart phone  
platforms to take advantage of features they offer such as being able  
to be set as the default browser, which Java often can't offer)


Opera Mobile is for Smartphone platforms: Symbian, Windows Mobile,  
Maemo and Android.





So the one I been using is Opera Mini 5 in my iPod (should this be  
called a smart phone equivalent?)


No, iOS doesn't allow Opera Mobile due to its licensing terms and  
conditions. It is capable of running  browser such as Opera Mobile  
technically, but not politically.



, but it does look to me like a full browser (and with many quirks).


We have a shared UI layer across our mobile (and a number of other  
devices such as TV) products. On the surface the UI is the same  
between Mini and Mobile, but the engine is different. Mobile is a full  
Opera Presto rendering engine under the hood. Mini is a thin client  
(you could almost think of it as something like a PDF viewer) which  
renders on a server and sends the transcoded content to the Opera Mini  
client. Mobile runs on more advanced platforms so it will allow for  
more things in the UI like higher DPI rendering and such. Mini can  
also cope with those things if running on smart phones.


I have experienced many issues in Opera Mini 5 which took quite a  
bit of time to get rid of, some were fixed, but these two are quite  
stubborn.


1. Pre tag - in portrait view if a line of content is longer than  
the device width, it doesn't wrap.


Pre is special in that it doesn't suppose to wrap.

2. padding issue (I think) in the input. If I add a background image  
like so and the image has a width of, say, 12px


input {
background: url(search-icon.png) no-repeat left top;
padding: 1px 2px 1px 16px
}

The input has  a value of "search site", the text should be pushed  
16px to the right. Andriod and Safari obeyed the rule, but Opera  
Mini ignores the padding rule which resulting the text and  
background image overlapped.


I'd need to see an example, but Mini makes a number of trade-offs to  
fit on basic devices, such as the transcoding I mentioned earlier.  
This does some reformatting to wrap content to a page width so no  
horizontal scrolling of text and such is needed when zooming in  
(horizontal scrolling is often difficult on feature phones, and  
generally isn't a good experience in general to have to scroll left  
and right to read text). This transcoding and line length wrapping  
could be causing issues, especially if it works on desktop. The engine  
on desktop and the engine run by the Opera Mini server is basically  
the same. Some advanced graphical features are not supported (eg.  
transforms, border-radius etc.) as they require our Vega graphics  
engine to render, which isn't available in the device as it is a thin  
client. We could transcode such things technically to images, but that  
would be too costly in terms of bandwidth.


I am sure I will find more issues in this browser as I get more  
opportunities to work on Mobile version of websites.


Sure. Remember to file bugs: bugs.opera.com/wizard/ . That way we will  
fix them if it is possible, as we can't fix issues we don't know  
about. Of course there is always trade offs in making a browser for  
such limited devices, so we can't promise we will be able to fix  
everything.


I often think Opera desktop has paddings/margins/line-height bug  
related to EM and % which seems never fixed, but then it might be  
Opera way of handling them, and they are carried over to Mini.


Opera has some rounding issues with large values of em's and % yes.  
They are on the roadmap to be fixed but it takes time as browsers are  
complex and there are always lots of things to fix, and lots of new  
HTML5 or CSS3 or SVG features to support which are used by many  
popular services and need to be supported. There are trade offs to be  
made to support the rounding correctly, but we will fix it sooner  
rather than later.


A browser that has only 5+% usage (based from many stats of the  
sites I did)


Depends which market you

Re: [WSG] :: opera mini 5.1 ::

[David Storey]

On 6 Aug 2010, at 00:48, tee wrote:



On Aug 5, 2010, at 1:41 PM, David Laakso wrote:



Whoops. Hit send too soon. Here's the rest of it...


Got the iPod screenshot, thanks -- will look into it.

The image issue has been resloved in the Opera Mini Simulator and  
in the Sany Mirro handset [a low-end device] with Duncan's  
suggestion of setting Image Quality High. This makes the image from  
too narrow to too wide.


I changed the CSS as follows to reduce the image width: /* was 96% */

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

body#p #main img {
max-width : 35% !important;
height : auto !important;
}
} /* for Opera Mini 5.1 on SanyoMirro 4 BoostMobile*/



If you add this in the above @media rule the horizontal scrolling  
will go away.


header, #page {
margin : 0 auto;
width: 100%;
}


I was not aware the Opera Mini image rendering differences in image  
quality setting with low, medium and high until Duncan pointed out.


From the mobile user point of view, changing image quality to high   
might not be a good approach though. In my iPod, the default quality  
is medium, and I  assume this is the majority will see in their  
Opera Mini.


Some thoughts, not related to the issue you are having, but I think  
they are valid points for your mobile users.


A side note, I have just completed the W3C Mobile Best Practice  
course taught by Phil, and have learned many practical, useful  
skills and knowledges. One of the strong emphasizes Phil taught us,  
is to "Specify the size of images in markup, if they have an  
intrinsic size."


To get a Mobile OK (optimized) site, a page cannot be more than 10K.  
That image you have, is 170kb and that you using one style sheet  
with media queries to target all devices, if I am a user on the go  
who needs to watch over bandwidth and monthly phone bill, I don't  
think I would be happy visiting your site.


I was very excited when I first learned how to use media queries  
just few months ago, but after the course, I found that just the   
media queries will not do if you need to optimized a mobile version  
site.


I completed the course with a conclusion that Content negotiation  
almost is a must just for one simple reason, using media queries to  
"display:none" only makes the content/element you do not want mobile  
user to see off the screen, it does not eliminate the sizes that  
slow the page load, eat up user's phone bill.


Not strictly true. First of all Opera Mini compresses the content and  
images (which is one of the reasons for the image quality setting - it  
will compress it less on high setting) to optimise it for low  
bandwidth devices. Opera (in general) also doesn't load resources that  
are set to display: none; until they are set to show on the page. Your  
mileage may vary with other browsers though. Opera Mini is designed  
for feature phones with slow networks that cost per kb. This is why it  
is hugely popular across Asia, Africa and South/Central America. It of  
course has some trade offs in what it can support using the client  
server approach, but those trade offs are worth it for the users, as  
the alternatives would be no internet at all or one that costs too much.


Ignoring the strengths of Opera Mini, you can easily use Media Queries  
without just using it to override screen styles to hide them for  
mobile. For example you can provide two stylesheets; one only  for  
screen and one only for small screen devices. you can set the media  
query to be mutually exclusive so the mobile browser never gets the  
stylesheet designed for desktop and thus doesn't have to override the  
styles. Or otherwise you can use the default stylesheet to style the  
mobile page, and use another stylesheet to override those styles for  
desktop. The mobile will then never download those styles.


Depending on the context, it is often best to try to keep the images  
linked from the style sheet, rather than in the HMTL (especially if  
presentational ) so you can specify an optimised one to the device  
based on the media query. This doesn't matter for Opera Mini as it  
will optimise it anyway (and not load it if display: none;, but will  
benefit less bandwidth-smart browsers and devices.






This site may give you a general idea how much it may cost your  
mobile user per page.

http://mobiready.com


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




*

Re: [WSG] :: opera mini 5.1 ::

[tee]

 
On Aug 5, 2010, at 1:41 PM, David Laakso wrote:
> 
> 
> Whoops. Hit send too soon. Here's the rest of it...
> 
> 
> Got the iPod screenshot, thanks -- will look into it.
> 
> The image issue has been resloved in the Opera Mini Simulator and in the Sany 
> Mirro handset [a low-end device] with Duncan's suggestion of setting Image 
> Quality High. This makes the image from too narrow to too wide.
> 
> I changed the CSS as follows to reduce the image width: /* was 96% */
> 
> @media handheld, screen and (max-width: 480px), screen and (max-device-width: 
> 480px) {
> body#p #main img {
> max-width : 35% !important;
> height : auto !important;
> }
> } /* for Opera Mini 5.1 on SanyoMirro 4 BoostMobile*/
> 

If you add this in the above @media rule the horizontal scrolling will go away.

header, #page {
margin : 0 auto;
width: 100%;
}


I was not aware the Opera Mini image rendering differences in image quality 
setting with low, medium and high until Duncan pointed out. 

>From the mobile user point of view, changing image quality to high  might not 
>be a good approach though. In my iPod, the default quality is medium, and I  
>assume this is the majority will see in their Opera Mini.

Some thoughts, not related to the issue you are having, but I think they are 
valid points for your mobile users.

A side note, I have just completed the W3C Mobile Best Practice course taught 
by Phil, and have learned many practical, useful skills and knowledges. One of 
the strong emphasizes Phil taught us, is to "Specify the size of images in 
markup, if they have an intrinsic size."

To get a Mobile OK (optimized) site, a page cannot be more than 10K. That image 
you have, is 170kb and that you using one style sheet with media queries to 
target all devices, if I am a user on the go who needs to watch over bandwidth 
and monthly phone bill, I don't think I would be happy visiting your site.

I was very excited when I first learned how to use media queries just few 
months ago, but after the course, I found that just the  media queries will not 
do if you need to optimized a mobile version site. 

I completed the course with a conclusion that Content negotiation almost is a 
must just for one simple reason, using media queries to "display:none" only 
makes the content/element you do not want mobile user to see off the screen, it 
does not eliminate the sizes that slow the page load, eat up user's phone bill.

This site may give you a general idea how much it may cost your mobile user per 
page.
http://mobiready.com


tee





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

Re: [WSG] :: opera mini 5.1 ::

[Duncan Hill]

On Thu, 05 Aug 2010 21:41:33 +0100, David Laakso  
 wrote:



I changed the CSS as follows to reduce the image width: /* was 96% */

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

body#p #main img {
max-width : 35% !important;
height : auto !important;
}
} /* for Opera Mini 5.1 on SanyoMirro 4 BoostMobile*/



Best,
~d


The image rendering for ingo.png is very poor with the max-width: 96%;  
setting in all main browsers on Win XP.



Best wishes

Duncan


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

Re: [WSG] :: opera mini 5.1 ::

[Duncan Hill]

On Thu, 05 Aug 2010 21:41:33 +0100, David Laakso  
 wrote:



Whoops. Hit send too soon. Here's the rest of it...


Got the iPod screenshot, thanks -- will look into it.

The image issue has been resloved in the Opera Mini Simulator and in the  
Sany Mirro handset [a low-end device] with Duncan's suggestion of  
setting Image Quality High. This makes the image from too narrow to too  
wide.


I changed the CSS as follows to reduce the image width: /* was 96% */

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

body#p #main img {
max-width : 35% !important;
height : auto !important;
}
} /* for Opera Mini 5.1 on SanyoMirro 4 BoostMobile*/



Best,
~d

I've tried just about every combination of settings on the N80
screen size is 352x416
tried portrait and landscape, it lands in an awkward patch of your @media  
values.


Having checked in Opera desktop, which does respond to the @media queries,  
and the N80, I have a suspicion that there may be something in your header  
that is maintaining a side scroll on the handheld.

Could that be an overflow failure in Mini or a minimum size setting.
Best settings for Portrait or Landscape:
Images: On
Image Quality: High
Font: Medium
Mobile View: Off
Fullscreen: On or Off


Best wishes

Duncan


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

Re: [WSG] :: opera mini 5.1 ::

[tee]

> 
> 1. Pre tag - in portrait view if a line of content is longer than the device 
> width, it doesn't wrap.

Correction! Not that it doesn't wrap (can pre tag wrap? I thought not), I think 
it's the font size (even in % and EM) does not re-adjust like other two do when 
you switch from Landscape to Portrait and this creates issue with certain html 
tags.

tee



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

Re: [WSG] :: opera mini 5.1 ::

[tee]

 
On Aug 5, 2010, at 2:05 PM, David Storey wrote:

> 
> On 5 Aug 2010, at 21:12, tee wrote:
> 
>> Hi David,
>> 
>> Having done 2 full sites+ many exercise mobile sites, I view at Opera Mini 
>> (including the Mobile 10) the Internet Explorer 6+7, it's a browser one will 
>> hate it, curse it more than praise it :-(
> 
> What are your issues with Opera Mobile (Opera Mini has known restrictions as 
> it is designed for low-end devices which can't power a full browser; .


> 
> Are you mixing up Mini and Mobile, 

Oops, I must be. Mini and Mobile sounded very much the same browser to me, and 
I got an impression that  Opera had consolidated the two name from Mini to 
Mobile 10 since the version 5.

So the one I been using is Opera Mini 5 in my iPod (should this be called a 
smart phone equivalent?) , but it does look to me like a full browser (and with 
many quirks).

I have experienced many issues in Opera Mini 5 which took quite a bit of time 
to get rid of, some were fixed, but these two are quite stubborn.

1. Pre tag - in portrait view if a line of content is longer than the device 
width, it doesn't wrap.
2. padding issue (I think) in the input. If I add a background image like so 
and the image has a width of, say, 12px

input {
background: url(search-icon.png) no-repeat left top; 
padding: 1px 2px 1px 16px
}

The input has  a value of "search site", the text should be pushed 16px to the 
right. Andriod and Safari obeyed the rule, but Opera Mini ignores the padding 
rule which resulting the text and background image overlapped.

I am sure I will find more issues in this browser as I get more opportunities 
to work on Mobile version of websites.

I often think Opera desktop has paddings/margins/line-height bug related to EM 
and % which seems never fixed, but then it might be Opera way of handling them, 
and they are carried over to Mini. A browser that has only 5+% usage (based 
from many stats of the sites I did) and offers no browser specific option for 
developer to tackle a slight difference that maybe required at time, does make 
a web developer hard to love it and embrace it :-)

tee

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

Re: [WSG] :: opera mini 5.1 ::

[David Storey]

On 5 Aug 2010, at 21:12, tee wrote:


Hi David,

Having done 2 full sites+ many exercise mobile sites, I view at  
Opera Mini (including the Mobile 10) the Internet Explorer 6+7, it's  
a browser one will hate it, curse it more than praise it :-(


What are your issues with Opera Mobile (Opera Mini has known  
restrictions as it is designed for low-end devices which can't power a  
full browser; which are the majority of the worlds devices people use  
to access the web. Smart phones are only big in the West).


Are you mixing up Mini and Mobile, as you state "In my iPod Opera  
Mobile 10". Opera Mobile doesn't exist for iPod as Apple do not allow  
full browsers on iOS as JavaScript engines bar their own pre-installed  
one are banned.




I think the problem might be this:

body#p #main img {border: 3px solid red;display: block;
max-width : 96% !important;
height : auto !important;
margin : 20px 0 0 0;
}

Should it not be "body#p, #main img"?

Apart for this, I don't think it's a good idea to declare max-width  
for any mobile browsers, be it container or inline image. This rule  
you have should take care of the width for portrait and landscape  
view:
@media handheld, screen and (max-width: 480px), screen and (max- 
device-width: 480px)


In my iPod Opera Mobile 10, your site results horizontal  
scrolling,   you might want to overwrite all the EM declared in  
(max)widths to % in your @media.


A side note , next time you might want to post a tinyURL or bit.ly  
(I like this!) address if ask mobile browser check because typing on  
a tiny screen keypad on a tiny screen for a long url address is no  
fun :-) Some mobile emulators do not allow copy and paste either.


tee
On Aug 5, 2010, at 11:27 AM, David Laakso wrote:


markup

css
around line 669


The image does not fill the width of the window in
Sanyo Mirro scp3810 for BoostMobile running Opera Mini 5.1
nor in the Opera Mini Simulator.


What to do?


It does fill the window in Mac OS X 10.4 at 600, 480, and 400.
And it fills the window in the iPhoney Simulator...


Best,




***
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 5.1 ::

[David Laakso]

David Laakso wrote:

tee wrote:
I sent you a screenshot taken from Opera Mini directly from iPod 
using landscape view
It might go into your junk box.  I am quite certain the image is the 
result of the max-width declaration in your img and the horizontal 
scrolling is the product of EM width with the combination of max-width.


Opera mobile 10 emulator doesn't has the same issue though, but then 
I have learned to never trust the emulator from day one.


tee
  









Whoops. Hit send too soon. Here's the rest of it...


Got the iPod screenshot, thanks -- will look into it.

The image issue has been resloved in the Opera Mini Simulator and in the 
Sany Mirro handset [a low-end device] with Duncan's suggestion of 
setting Image Quality High. This makes the image from too narrow to too 
wide.


I changed the CSS as follows to reduce the image width: /* was 96% */

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

body#p #main img {
max-width : 35% !important;
height : auto !important;
}
} /* for Opera Mini 5.1 on SanyoMirro 4 BoostMobile*/



Best,
~d














http://chelseacreekstudio.com/



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





--
desktop
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 5.1 ::

[David Laakso]

tee wrote:

I sent you a screenshot taken from Opera Mini directly from iPod using 
landscape view
It might go into your junk box.  I am quite certain the image is the result of 
the max-width declaration in your img and the horizontal scrolling is the 
product of EM width with the combination of max-width.

Opera mobile 10 emulator doesn't has the same issue though, but then I have 
learned to never trust the emulator from day one.

tee
  




Got the iPod screenshot, thanks -- will look into it.

The image issue has been resloved in the Opera Mini Simulator and in the Sany 
Mirro handset [a low-end device] with Duncan's suggestion of setting Image 
Quality High. This makes the image from too narrow to too wide.

I changed the CSS as follows to reduce the image width: 
/* was 96% */






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 5.1 ::

[tee]

I sent you a screenshot taken from Opera Mini directly from iPod using 
landscape view
It might go into your junk box.  I am quite certain the image is the result of 
the max-width declaration in your img and the horizontal scrolling is the 
product of EM width with the combination of max-width.

Opera mobile 10 emulator doesn't has the same issue though, but then I have 
learned to never trust the emulator from day one.

tee
>> 
> 
> A friend checked it on an iPod prior to the inclusion of the @media 
> declarations and reported no issues at that time. I will ask her to check it 
> again.
> 
> Thanks.
> 
> Best,
> ~d



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

Re: [WSG] :: opera mini 5.1 ::

[David Laakso]

Duncan Hill wrote:
On Thu, 05 Aug 2010 19:27:24 +0100, David Laakso 
 wrote:



markup



Best,
~d


Only an old Nokia N80 to test on.
Messed with Opera Mini settings and the only way to get the image to 
display at larger than mini size was to set Image Quality to High, but 
then it did not respect the screen width.

Doesn't seem to provide any clues I'm afraid.

Best wishes

Duncan








Bingo, I bet!!!

Image Quality High with max-width re-set to 40% or a little less ought 
to do it.

If you do not hear back from me in an hour or so it is resolved.

Thanks!

Best,
~d



--
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 5.1 ::

[David Laakso]

tee wrote:

Hi David,

I think the problem might be this:

body#p #main img {border: 3px solid red;display: block;
max-width : 96% !important;
height : auto !important;
margin : 20px 0 0 0;
}

Should it not be "body#p, #main img"?


tee

  




#p is the id for the styles specific to the portfolio pages, so I don't 
think your suggestion would work as you've written it -- and, just

#main img {...}
does not work, either.

I have had no difficulty with Opera Mini 5.1 on Sanyo Mirro [ a low-end 
device ] whatsoever, other than the problem I wrote about.


A friend checked it on an iPod prior to the inclusion of the @media 
declarations and reported no issues at that time. I will ask her to 
check it again.


Thanks.

Best,
~d


--
desktop
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 5.1 ::

[Duncan Hill]

On Thu, 05 Aug 2010 19:27:24 +0100, David Laakso  
 wrote:



markup

css
around line 669


The image does not fill the width of the window in
Sanyo Mirro scp3810 for BoostMobile running Opera Mini 5.1
nor in the Opera Mini Simulator.


What to do?


It does fill the window in Mac OS X 10.4 at 600, 480, and 400.
And it fills the window in the iPhoney Simulator...


Best,
~d


Only an old Nokia N80 to test on.
Messed with Opera Mini settings and the only way to get the image to  
display at larger than mini size was to set Image Quality to High, but  
then it did not respect the screen width.

Doesn't seem to provide any clues I'm afraid.

Best wishes

Duncan


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

Re: [WSG] :: opera mini 5.1 ::

[tee]

Hi David,

Having done 2 full sites+ many exercise mobile sites, I view at Opera Mini 
(including the Mobile 10) the Internet Explorer 6+7, it's a browser one will 
hate it, curse it more than praise it :-(

I think the problem might be this:

body#p #main img {border: 3px solid red;display: block;
max-width : 96% !important;
height : auto !important;
margin : 20px 0 0 0;
}

Should it not be "body#p, #main img"?

Apart for this, I don't think it's a good idea to declare max-width for any 
mobile browsers, be it container or inline image. This rule you have should 
take care of the width for portrait and landscape view:
@media handheld, screen and (max-width: 480px), screen and (max-device-width: 
480px) 

In my iPod Opera Mobile 10, your site results horizontal scrolling,   you might 
want to overwrite all the EM declared in (max)widths to % in your @media.

A side note , next time you might want to post a tinyURL or bit.ly (I like 
this!) address if ask mobile browser check because typing on a tiny screen 
keypad on a tiny screen for a long url address is no fun :-) Some mobile 
emulators do not allow copy and paste either.

tee
On Aug 5, 2010, at 11:27 AM, David Laakso wrote:

> markup
> 
> css
> around line 669
> 
> 
> The image does not fill the width of the window in
> Sanyo Mirro scp3810 for BoostMobile running Opera Mini 5.1
> nor in the Opera Mini Simulator.
> 
> 
> What to do?
> 
> 
> It does fill the window in Mac OS X 10.4 at 600, 480, and 400.
> And it fills the window in the iPhoney Simulator...
> 
> 
> Best,



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

Re: [WSG] opera mini and table

[tee]

Forgot one important note.

Even if max/min widths are removed, OM still show the same rendering for table 
whether a width is declared in table.


tee


On May 15, 2010, at 7:45 AM, tee wrote:

> I'd just discovered that Apple approved Opera Mini browser for iPhone/iPod 
> (maybe only available for US Apple Store as of now). 
> 
> This is the first time I ever have a firsthand experience browsing web via 
> OM, so I am not sure if some of the behaviors I saw only apply to Apple 
> mobile devices.
> 
> A brief explanation on the page that I tested.
> 
> (a) a style sheet for all media 
> 
> #container {max-width: 40em;min-width: 240px;margin: 10px;}
> 
> (b) A style sheet for media queries targeting iPhone, Andriod and I thought 
> OM too
> - Special treatment for floated columns to prevent the same classes in the 
> handheld file taking over.
> 
> (c) A handheld style sheet for older devices
> #container {80%}  <-- my thought is  iPhone, Andriod picked up this and 
> ignored max/min-widths in (a), I thought OM should do that too, but it 
> doesn't and this is the reason  I was seeing below behaviors.
> 
> 
> Max-width/min-width declared but not width in (a):
> 
> OM doesn't treat Table elements well, at first I thought it was because the 
> online emulator doesn't accurately reflect the actual rendering (this is 
> before I found out OM for iPhone), but browsing from iPod, I am seeing the 
> same behavior.  If width is declared in (a), it will take the width based on 
> the total given width (width + paddings + margins) of the #container, and 
> ignores the second div (intend to serve as a wrapper for table just for 
> testing purpose), so if a layout is 2 columns floated, the table overlaps the 
> right column, and from a rough estimation, I believe it inherits the 
> #container {80%} in (c) + 10px margin right in (a).
> 
> Whether a second div is given or not, OM ignores the width declared if the 
> table's width is smaller than the given width of outer div, but if the width 
> is wider than the given width of #container, it doesn't ignore. This behavior 
> however does not applied to horizontal view though, my guess is  it takes the 
> max-width instead.
> 
> 
> 
> Max-width/min-width (in (a)), width declared (in (b)):
> 
> The same behavior existed if pixel is used in Width (never mind if it's 
> larger or smaller than the width declared in #container). With em unit, the 
> behavior is gone if the width value is same as max-width, if the width 
> smaller even just 0.5em, the same rendering comes back.
> 
> I see that max/min widths are the supported properties in CSS Mobile Profile 
> 2.0 so is table elements for XHTML Basic 1.1, it's rather bizarre for OM to 
> behavior like that.
> 
> http://www.w3.org/TR/css-mobile/
> http://www.w3.org/2007/07/xhtml-basic-ref.html#elem_table
> 
> 
> Also, If pixel value is used for width, OM loses zooming capability, is it 
> because in other mobile devices, they don't have zooming feature?
> 
> 
> Devices that is 220px or wider from Adobe Device Central all rendered the 
> table correctly, but then I have no knowledge if I can even trust what I see 
> from those emulators. I have CS3, so the  devices rendered in ADC CS3 may not 
> be as up to date as the CS4 or CS5.
> 
> 
> In regard to the poor support of table for mobile devices in general, what do 
> you think about the tabular data?  I would love to hear what you guys think. 
> My thought is that there are data that are best served in tabular format and 
> from semantical point of view  we should never treat tabular data differently 
> just for the sake of supporting mobile devices.  
> 
> tee
> 
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: memberh...@webstandardsgroup.org
> ***
> 



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