subject:"\[WSG\] Opera"

Re: [WSG] Opera Mini fontsize settings

2011-10-14 Thread 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

2011-10-13 Thread 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

2011-10-13 Thread 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
***

[WSG] Opera Mini fontsize settings

2011-10-13 Thread tee

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 rendering issue with HTML5 doctype

2010-09-08 Thread 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

2010-09-05 Thread 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

2010-09-05 Thread 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

2010-09-05 Thread 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

2010-09-05 Thread 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

2010-09-05 Thread 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

2010-09-05 Thread 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] Opera Mini

2010-08-25 Thread 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

2010-08-24 Thread 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

2010-08-24 Thread 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

2010-08-24 Thread 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

2010-08-24 Thread 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

2010-08-24 Thread 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

2010-08-23 Thread 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
***

[WSG] Opera Mini

2010-08-23 Thread tee

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. 

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


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


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

1 2 3 >

1 - 100 of 288 matches

Mail list logo