On 7/15/2011 9:26 AM, Jordan Dobson wrote:
>
>
> Also I would say start with dumb phone styles first as the catch all and
> enhance as you go.
>
> I really recommend using Base64 encoded images in your CSS for UI elements as
> much as possible. That way you ensure when your CSS is loaded and ready that
> your images are as well. Nothing looks worse than seeing your app with no
> icons... and then they flash/trickle in.
>

WURFL has a capability called 'image_inlining' that tracks the DATA URI Scheme
(the Base64 trick you just mentioned).

Basically, you can conditionally do stuff like:

if (device.getCapability("image_inlining")) {
      write( <img src="data:image/png Util.base64("my_pic.png")" ..>
} else {
      write( <img src="my_pic.png" ..>
}

this is being used successfully by a major social network provider to enhance UX
on devices that support the feature.

Luca

Hello group,

I'm in the process of creating a mobile site for a client and i was wondering
what best pratices exist and you would recommend declaring fonts in css?
I'm thinking of em vs. px, etc...

Any hint is *greatly* appreciated!

Thanks.

  Ulrich

Hello Group, Hello Ulrich,

It depends a bit on the targeted devices/range.
But nowadays I'd recommend to declare a font-size in the body(prefer percentage) and then em everywhere.

Regards
Stefan

***
Stefan Hanke
mail@... || pazifikwelle@...
+491724264228
This mail was sent using my Nexus Phone. I apologize for brevity and misspellings.
***

As regards inline encoding of images in situ with regards to a smooth loading UX
for graphics-dependent UIs:

Any conscientiously integrated front end would surely use sprites for
significantly better image data byte-size and a load-once-all-accounted-for
approach … I believe this is a fairly well-established standard in front-end
optimisation… At which point having said sprite loaded via a visually hidden
image element near the top of the page and referenced as and when necessary in
the CSS both ensures the image will be loaded before rendering and avoids
bloated heavily-fringe-case-targetted CSS code — while happily leaving the
image out of the resource-loading process if, by whatever means, the user agent
is set not to load or display images.

Quite apart from issues of flexibility and avoiding hard-to-maintain incredibly
use-case specific code forking, not to mention heavy inference dependence, I
struggle to imagine realistic use-case scenarios where this option is not
massively lighter — with fall-back built in via more reliable traditional
methods.

As I say this, I'm sure I'm missing a trick — can someone point me to
resources describing the case for base-64 encoding as a routine byte-saving
procedure in more detail?


Regards,

Barney Carroll
(+44) 742 9177 278

On 15 Jul 2011, at 08:48, Luca Passani <luca.passani@...> wrote:

>
> On 7/15/2011 9:26 AM, Jordan Dobson wrote:
>>
>>
>> Also I would say start with dumb phone styles first as the catch all and
>> enhance as you go.
>>
>> I really recommend using Base64 encoded images in your CSS for UI elements as
>> much as possible. That way you ensure when your CSS is loaded and ready that
>> your images are as well. Nothing looks worse than seeing your app with no
>> icons... and then they flash/trickle in.
>>
>
> WURFL has a capability called 'image_inlining' that tracks the DATA URI Scheme
> (the Base64 trick you just mentioned).
>
> Basically, you can conditionally do stuff like:
>
> if (device.getCapability("image_inlining")) {
>     write( <img src="data:image/png Util.base64("my_pic.png")" ..>
> } else {
>     write( <img src="my_pic.png" ..>
> }
>
> this is being used successfully by a major social network provider to enhance
UX
> on devices that support the feature.
>
> Luca
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

this one should take you there:

http://en.wikipedia.org/wiki/Data_URI_scheme

as you can imagine, some device/browser combinations support data uri. Some
don't.

Luca

On 7/15/2011 10:25 AM, Barney Carroll wrote:
>
>
> As regards inline encoding of images in situ with regards to a smooth loading
> UX for graphics-dependent UIs:
>
> Any conscientiously integrated front end would surely use sprites for
> significantly better image data byte-size and a load-once-all-accounted-for
> approach … I believe this is a fairly well-established standard in front-end
> optimisation… At which point having said sprite loaded via a visually hidden
> image element near the top of the page and referenced as and when necessary in
> the CSS both ensures the image will be loaded before rendering and avoids
> bloated heavily-fringe-case-targetted CSS code — while happily leaving the
> image out of the resource-loading process if, by whatever means, the user
> agent is set not to load or display images.
>
> Quite apart from issues of flexibility and avoiding hard-to-maintain
> incredibly use-case specific code forking, not to mention heavy inference
> dependence, I struggle to imagine realistic use-case scenarios where this
> option is not massively lighter — with fall-back built in via more reliable
> traditional methods.
>
> As I say this, I'm sure I'm missing a trick — can someone point me to
> resources describing the case for base-64 encoding as a routine byte-saving
> procedure in more detail?
>
> Regards,
>
> Barney Carroll
> (+44) 742 9177 278
>
> On 15 Jul 2011, at 08:48, Luca Passani <luca.passani@...
> <mailto:luca.passani%40gmail.com>> wrote:
>
> >
> > On 7/15/2011 9:26 AM, Jordan Dobson wrote:
> >>
> >>
> >> Also I would say start with dumb phone styles first as the catch all and
> >> enhance as you go.
> >>
> >> I really recommend using Base64 encoded images in your CSS for UI elements
as
> >> much as possible. That way you ensure when your CSS is loaded and ready
that
> >> your images are as well. Nothing looks worse than seeing your app with no
> >> icons... and then they flash/trickle in.
> >>
> >
> > WURFL has a capability called 'image_inlining' that tracks the DATA URI
Scheme
> > (the Base64 trick you just mentioned).
> >
> > Basically, you can conditionally do stuff like:
> >
> > if (device.getCapability("image_inlining")) {
> > write( <img src="data:image/png Util.base64("my_pic.png")" ..>
> > } else {
> > write( <img src="my_pic.png" ..>
> > }
> >
> > this is being used successfully by a major social network provider to
enhance UX
> > on devices that support the feature.
> >
> > Luca
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
>

Since the client wants to sell something, the targeted browsers are pretty much
every mobile browser known to man...

But i guess, if we can target android/iOs, blackberry and nokia devices like the
n95 we're good to go.

Thanks again fo the heads-up!

--- In mobile-web@yahoogroups.com, Jordan Dobson <jordandobson@...> wrote:
>
> Also - You should use rem instead of em to make your life much simpler if
> your targeted browsers support it. I'm pretty sure most do.
>
> Otherwise Stefan is spot on.
>
> On Fri, Jul 15, 2011 at 1:14 AM, Stefan Hanke
> <pazifikwelle@...>wrote:
>
> > **
> >
> >
> > Hello Group, Hello Ulrich,
> >
> > It depends a bit on the targeted devices/range.
> > But nowadays I'd recommend to declare a font-size in the body(prefer
> > percentage) and then em everywhere.
> >
> > Regards
> > Stefan
> >
> > ***
> > Stefan Hanke
> > mail@... || pazifikwelle@...
> > +491724264228
> > This mail was sent using my Nexus Phone. I apologize for brevity and
> > misspellings.
> > ***
> > Am 15.07.2011 10:01 schrieb "ulrich.steffens" <ulrich@...>:
> >
> >
> >
>
>
>
> --
> Jordan Dobson • Designer / Developer • 425-444-8014 • JordanDobson.com
>

the total size gets bigger, but the number of HTTP connections required drops
dramatically. And in mobile HTTP requests are very slow and expensive (and they
typically won't happen with the same level of concurrency as is normal with
fully-fledged web browsers)

in short, the perceived download time is a lot better with Data URI,
particularly when the network is not WiFi.

Luca

On 7/15/2011 10:44 AM, Jordan Dobson wrote:
>
>
> I have to admit... I never use sprites since nearly all my UI is CSS and if
> you are going Base64 encoded route It really doesn't mater.
>
>
> I wouldn't say it saves bytes... I believe it actually bloats the size by 20%
> so it should be used sparingly.
>
> On Fri, Jul 15, 2011 at 1:25 AM, Barney Carroll <barney.carroll@...
> <mailto:barney.carroll@...>> wrote:
>
>
>
>     As regards inline encoding of images in situ with regards to a smooth
>     loading UX for graphics-dependent UIs:
>
>     Any conscientiously integrated front end would surely use sprites for
>     significantly better image data byte-size and a
>     load-once-all-accounted-for approach … I believe this is a fairly
>     well-established standard in front-end optimisation… At which point having
>     said sprite loaded via a visually hidden image element near the top of the
>     page and referenced as and when necessary in the CSS both ensures the
>     image will be loaded before rendering and avoids bloated
>     heavily-fringe-case-targetted CSS code — while happily leaving the image
>     out of the resource-loading process if, by whatever means, the user agent
>     is set not to load or display images.
>
>     Quite apart from issues of flexibility and avoiding hard-to-maintain
>     incredibly use-case specific code forking, not to mention heavy inference
>     dependence, I struggle to imagine realistic use-case scenarios where this
>     option is not massively lighter — with fall-back built in via more
>     reliable traditional methods.
>
>     As I say this, I'm sure I'm missing a trick — can someone point me to
>     resources describing the case for base-64 encoding as a routine
>     byte-saving procedure in more detail?
>
>     Regards,
>
>     Barney Carroll
>     (+44) 742 9177 278 <tel:%28%2B44%29%20742%209177%20278>
>
>

 

I have to admit... I never use sprites since nearly all my UI is CSS and if you are going Base64 encoded route It really doesn't mater.

I wouldn't say it saves bytes... I believe it actually bloats the size by 20% so it should be used sparingly. 

On Fri, Jul 15, 2011 at 1:25 AM, Barney Carroll <barney.carroll@...> wrote:

 

As regards inline encoding of images in situ with regards to a smooth loading UX for graphics-dependent UIs:

Any conscientiously integrated front end would surely use sprites for significantly better image data byte-size and a load-once-all-accounted-for approach … I believe this is a fairly well-established standard in front-end optimisation… At which point having said sprite loaded via a visually hidden image element near the top of the page and referenced as and when necessary in the CSS both ensures the image will be loaded before rendering and avoids bloated heavily-fringe-case-targetted CSS code — while happily leaving the image out of the resource-loading process if, by whatever means, the user agent is set not to load or display images.

Quite apart from issues of flexibility and avoiding hard-to-maintain incredibly use-case specific code forking, not to mention heavy inference dependence, I struggle to imagine realistic use-case scenarios where this option is not massively lighter — with fall-back built in via more reliable traditional methods.

As I say this, I'm sure I'm missing a trick — can someone point me to resources describing the case for base-64 encoding as a routine byte-saving procedure in more detail?

Regards,

Barney Carroll
(+44) 742 9177 278

On 15 Jul 2011, at 08:48, Luca Passani <luca.passani@...> wrote:

>
> On 7/15/2011 9:26 AM, Jordan Dobson wrote:
>>
>>
>> Also I would say start with dumb phone styles first as the catch all and
>> enhance as you go.
>>
>> I really recommend using Base64 encoded images in your CSS for UI elements as
>> much as possible. That way you ensure when your CSS is loaded and ready that
>> your images are as well. Nothing looks worse than seeing your app with no
>> icons... and then they flash/trickle in.
>>
>
> WURFL has a capability called 'image_inlining' that tracks the DATA URI Scheme
> (the Base64 trick you just mentioned).
>
> Basically, you can conditionally do stuff like:
>
> if (device.getCapability("image_inlining")) {
> write( <img src="data:image/png Util.base64("my_pic.png")" ..>
> } else {
> write( <img src="my_pic.png" ..>
> }
>
> this is being used successfully by a major social network provider to enhance UX
> on devices that support the feature.
>
> Luca
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

--
Jordan Dobson â€˘ Designer / Developer â€˘ 425-444-8014 â€˘ JordanDobson.com

Bing, Google, and I’m pretty sure Yahoo all use inline images and assets on
their mobile sites in order to increase the speed of first page load.

Bing has the most advanced techniques in this regard putting everything
inline--one big 200k file for first page load--then stuffing assets in local
storage with version numbers on them.

A cookie is set declaring what versions of what assets are stored locally which
allows the server to figure out what assets it needs to send. This means
subsequent page loads are < 20k.

If the server receives a request with a cookie that indicates an outdated
version of an asset, the server then delivers builds a different page containing
that asset inline to replace the one stored locally.

If you’re interested in this stuff, I highly recommend following Steve Souders.
The Velocity conference covered a lot of mobile this year. And I saw Nicholas
Zakas speak at Web Directions Unplugged this year. He was part of Yahoo’s
performance team. His slides are here:
http://www.slideshare.net/nzakas/mobile-web-speed-bumps

-Jason

On Jul 15, 2011, at 2:19 AM, Barney Carroll wrote:

>
> Inline image encoding saves ~20% byte-size? That is pretty significant. Do you
have any test cases to back this up?
>
> My experience is that if you have several images, concatenating them into one
file will save a large chunk of what I'll call instantiation metadata from being
redefined. I can imagine that if you have one image, used once (say for a logo),
inline encoding would be your best bet. For any other scenario, I'm still
struggling to imagine genuine byte-saving via this method. Some test cases would
definitely help — I may set some up.
>
> Regards,
>
> Barney Carroll
> (+44) 742 9177 278
>
> On 15 Jul 2011, at 09:44, Jordan Dobson <jordandobson@...> wrote:
>
>>
>> I have to admit... I never use sprites since nearly all my UI is CSS and if
you are going Base64 encoded route It really doesn't mater.
>>
>>
>> I wouldn't say it saves bytes... I believe it actually bloats the size by 20%
so it should be used sparingly.
>>
>> On Fri, Jul 15, 2011 at 1:25 AM, Barney Carroll <barney.carroll@...>
wrote:
>>
>> As regards inline encoding of images in situ with regards to a smooth loading
UX for graphics-dependent UIs:
>>
>> Any conscientiously integrated front end would surely use sprites for
significantly better image data byte-size and a load-once-all-accounted-for
approach … I believe this is a fairly well-established standard in front-end
optimisation… At which point having said sprite loaded via a visually hidden
image element near the top of the page and referenced as and when necessary in
the CSS both ensures the image will be loaded before rendering and avoids
bloated heavily-fringe-case-targetted CSS code — while happily leaving the image
out of the resource-loading process if, by whatever means, the user agent is set
not to load or display images.
>>
>> Quite apart from issues of flexibility and avoiding hard-to-maintain
incredibly use-case specific code forking, not to mention heavy inference
dependence, I struggle to imagine realistic use-case scenarios where this option
is not massively lighter — with fall-back built in via more reliable traditional
methods.
>>
>> As I say this, I'm sure I'm missing a trick — can someone point me to
resources describing the case for base-64 encoding as a routine byte-saving
procedure in more detail?
>>
>> Regards,
>>
>> Barney Carroll
>> (+44) 742 9177 278
>>
>>
>>
>> On 15 Jul 2011, at 08:48, Luca Passani <luca.passani@...> wrote:
>>
>> >
>> > On 7/15/2011 9:26 AM, Jordan Dobson wrote:
>> >>
>> >>
>> >> Also I would say start with dumb phone styles first as the catch all and
>> >> enhance as you go.
>> >>
>> >> I really recommend using Base64 encoded images in your CSS for UI elements
as
>> >> much as possible. That way you ensure when your CSS is loaded and ready
that
>> >> your images are as well. Nothing looks worse than seeing your app with no
>> >> icons... and then they flash/trickle in.
>> >>
>> >
>> > WURFL has a capability called 'image_inlining' that tracks the DATA URI
Scheme
>> > (the Base64 trick you just mentioned).
>> >
>> > Basically, you can conditionally do stuff like:
>> >
>> > if (device.getCapability("image_inlining")) {
>> > write( <img src="data:image/png Util.base64("my_pic.png")" ..>
>> > } else {
>> > write( <img src="my_pic.png" ..>
>> > }
>> >
>> > this is being used successfully by a major social network provider to
enhance UX
>> > on devices that support the feature.
>> >
>> > Luca
>> >
>> >
>> >
>> > ------------------------------------
>> >
>> > Yahoo! Groups Links
>> >
>> >
>> >
>>
>>
>>
>>
>> --
>> Jordan Dobson • Designer / Developer • 425-444-8014 • JordanDobson.com
>>
>
>

--

Jason Grigsby
+1 (503) 290-1090 o
+1 (503) 502-7211 m
jason@...
http://cloudfour.com

Hi,

Does anyone have an emulator for NetFront browser pre 4? Ideally versions 3.3 or
3.5 that were shipped with many Sony Ericsson phones.

ACCESS website only allows to download latest version of NetFront for Windows
Mobile.

I guess emulators for older versions were available there too, but were removed
some time ago. Maybe, by any chance, someone here has downloaded them or knows
if they've been mirrored somewhere?

Cheers,
Bartek

Hi Friends,

I am developing a Mobile Web Application and I am new to this.

I am aware of that we need to create a fluid layout to match different mobile
screen sizes and resolutions.

How to handle font size for various resolutions like a devices with a resolution
of 240x 320, 320x 480, 480 x 800 and 768x104(IPAD).

I am just using predefined html tags like Header tags(h1 to h6) to display font.
I am not using font tag's size attribute.

Also I am using few images for icons, buttons will these have an impact, if so
how to handles this?.

Am I on right track...?  Please guide me.

Thanks,
- Bharath

Jason,

Thanks a lot for the technical explanation and examples: the missing pieces of
the puzzle were local storage for dynamic resource definition and cookies for
flagging outdated components to the server-side logic. That certainly explains
how a cleverly conceived web app could be safely extensible with an all-at-once
overhead and internal logic to define re-use. Just to be clear, this is a mobile
webkit only web app we are talking about here, right? I still can't imagine the
data-URI includes making sense in the vast majority of scenarios for anything
without the local storage API…

In the meantime, I'll be digging into Bing. Out of interest, how did you come
about the Bing analysis? Will UA string spoofing allow me to use, say Chrome dev
tools to peer at the innards of the mechanisms you're describing, or would that
leave me looking at something else?


Regards,

Barney Carroll
(+44) 742 9177 278

On 15 Jul 2011, at 17:13, Jason Grigsby <jason@...> wrote:

> Bing, Google, and I’m pretty sure Yahoo all use inline images and assets on
their mobile sites in order to increase the speed of first page load.
>
> Bing has the most advanced techniques in this regard putting everything
inline--one big 200k file for first page load--then stuffing assets in local
storage with version numbers on them.
>
> A cookie is set declaring what versions of what assets are stored locally
which allows the server to figure out what assets it needs to send. This means
subsequent page loads are < 20k.
>
> If the server receives a request with a cookie that indicates an outdated
version of an asset, the server then delivers builds a different page containing
that asset inline to replace the one stored locally.
>
> If you’re interested in this stuff, I highly recommend following Steve
Souders. The Velocity conference covered a lot of mobile this year. And I saw
Nicholas Zakas speak at Web Directions Unplugged this year. He was part of
Yahoo’s performance team. His slides are here:
> http://www.slideshare.net/nzakas/mobile-web-speed-bumps
>
> -Jason
>
> On Jul 15, 2011, at 2:19 AM, Barney Carroll wrote:
>
>>
>> Inline image encoding saves ~20% byte-size? That is pretty significant. Do
you have any test cases to back this up?
>>
>> My experience is that if you have several images, concatenating them into one
file will save a large chunk of what I'll call instantiation metadata from being
redefined. I can imagine that if you have one image, used once (say for a logo),
inline encoding would be your best bet. For any other scenario, I'm still
struggling to imagine genuine byte-saving via this method. Some test cases would
definitely help — I may set some up.
>>
>> Regards,
>>
>> Barney Carroll
>> (+44) 742 9177 278
>>
>> On 15 Jul 2011, at 09:44, Jordan Dobson <jordandobson@...> wrote:
>>
>>>
>>> I have to admit... I never use sprites since nearly all my UI is CSS and if
you are going Base64 encoded route It really doesn't mater.
>>>
>>>
>>> I wouldn't say it saves bytes... I believe it actually bloats the size by
20% so it should be used sparingly.
>>>
>>> On Fri, Jul 15, 2011 at 1:25 AM, Barney Carroll <barney.carroll@...>
wrote:
>>>
>>> As regards inline encoding of images in situ with regards to a smooth
loading UX for graphics-dependent UIs:
>>>
>>> Any conscientiously integrated front end would surely use sprites for
significantly better image data byte-size and a load-once-all-accounted-for
approach … I believe this is a fairly well-established standard in front-end
optimisation… At which point having said sprite loaded via a visually hidden
image element near the top of the page and referenced as and when necessary in
the CSS both ensures the image will be loaded before rendering and avoids
bloated heavily-fringe-case-targetted CSS code — while happily leaving the
image out of the resource-loading process if, by whatever means, the user agent
is set not to load or display images.
>>>
>>> Quite apart from issues of flexibility and avoiding hard-to-maintain
incredibly use-case specific code forking, not to mention heavy inference
dependence, I struggle to imagine realistic use-case scenarios where this option
is not massively lighter — with fall-back built in via more reliable
traditional methods.
>>>
>>> As I say this, I'm sure I'm missing a trick — can someone point me to
resources describing the case for base-64 encoding as a routine byte-saving
procedure in more detail?
>>>
>>> Regards,
>>>
>>> Barney Carroll
>>> (+44) 742 9177 278
>>>
>>>
>>>
>>> On 15 Jul 2011, at 08:48, Luca Passani <luca.passani@...> wrote:
>>>
>>>>
>>>> On 7/15/2011 9:26 AM, Jordan Dobson wrote:
>>>>>
>>>>>
>>>>> Also I would say start with dumb phone styles first as the catch all and
>>>>> enhance as you go.
>>>>>
>>>>> I really recommend using Base64 encoded images in your CSS for UI elements
as
>>>>> much as possible. That way you ensure when your CSS is loaded and ready
that
>>>>> your images are as well. Nothing looks worse than seeing your app with no
>>>>> icons... and then they flash/trickle in.
>>>>>
>>>>
>>>> WURFL has a capability called 'image_inlining' that tracks the DATA URI
Scheme
>>>> (the Base64 trick you just mentioned).
>>>>
>>>> Basically, you can conditionally do stuff like:
>>>>
>>>> if (device.getCapability("image_inlining")) {
>>>> write( <img src="data:image/png Util.base64("my_pic.png")" ..>
>>>> } else {
>>>> write( <img src="my_pic.png" ..>
>>>> }
>>>>
>>>> this is being used successfully by a major social network provider to
enhance UX
>>>> on devices that support the feature.
>>>>
>>>> Luca
>>>>
>>>>
>>>>
>>>> ------------------------------------
>>>>
>>>> Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jordan Dobson • Designer / Developer • 425-444-8014 • JordanDobson.com
>>>
>>
>>
>
> --
>
> Jason Grigsby
> +1 (503) 290-1090 o
> +1 (503) 502-7211 m
> jason@...
> http://cloudfour.com
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

To be clear, I didn’t conduct the Bing research. Just pointing out what others
have found.

Google and Yahoo are using data URI without storage in order to reduce the
number of http connections for the reasons mentioned earlier. The slight
increase in file size from the data URI doesn’t equal the amount of time saved
from reducing the http requests.

One other thing to consider is optimization for first page load which is a lot
of what Google and the others plan for. They may ultimately decide to have
resources inline so they load quickly and then in the background download
duplicate assets. The first page load is fast and the subsequent ones are fast
because the content is cached.

All of these things are just tools. There are a lot of tweaking that can be done
to gain the best performance possible, but the only way to know what will make a
difference is to have a specific use case and see what you need to speed up.

-Jason

On Jul 15, 2011, at 9:42 AM, Barney Carroll wrote:

> Jason,
>
> Thanks a lot for the technical explanation and examples: the missing pieces of
the puzzle were local storage for dynamic resource definition and cookies for
flagging outdated components to the server-side logic. That certainly explains
how a cleverly conceived web app could be safely extensible with an all-at-once
overhead and internal logic to define re-use. Just to be clear, this is a mobile
webkit only web app we are talking about here, right? I still can't imagine the
data-URI includes making sense in the vast majority of scenarios for anything
without the local storage API…
>
> In the meantime, I'll be digging into Bing. Out of interest, how did you come
about the Bing analysis? Will UA string spoofing allow me to use, say Chrome dev
tools to peer at the innards of the mechanisms you're describing, or would that
leave me looking at something else?
>
> Regards,
>
> Barney Carroll
> (+44) 742 9177 278
>

Hi everybody,

I'm new here and new to optimizing websites for mobile.

I have the Opera Mobile emulator installed to check my progress in that browser
and I've noticed that Opera Mobile automatically converts set of numbers into a
link. It thinks that it is a telephone number while it's not.

Is there a way to stop Opera Mobile from doing that to every set of numbers
except of course when it's a telephone number.
<a href="tel:00301234567890">+30-1234567890</a>

On 7/26/2011 2:42 PM, gentle_media wrote:
>
>
> Hi everybody,
>
> I'm new here and new to optimizing websites for mobile.
>
> I have the Opera Mobile emulator installed to check my progress in that
> browser and I've noticed that Opera Mobile automatically converts set of
> numbers into a link. It thinks that it is a telephone number while it's not.
>
> Is there a way to stop Opera Mobile from doing that to every set of numbers
> except of course when it's a telephone number.
> <a href="tel:00301234567890">+30-1234567890</a>
>

Not sure whether this helps, but with the iphone you fix the problem with:

<meta name="format-detection" content="telephone=no">

on RIM

<meta http-equiv="x-rim-auto-match" content="none" />

Luca

Hi

Opera Mobile does this. It does in a way "assume" that number with 5
numbers in it or more are telephone numbers.

A test case can be seen here:
http://files.trygve-lie.com/tests/css_mobile_extra_a/

As fare as I know there are no way to prevent this. If it is I would
love to know it also...

I've already reported a bug on it at Opera. It has the bug number:
ANDMEX-1291

I do not know if the bug is closed or not since Operas bug tracker are
closed but the response I've got from Opera are that its a "unfortunate
side-effect": https://twitter.com/#!/divya/status/85708856746983424

I find this quite annoying and I would much rather have a way to set
something as a phone number instead of having the browser trying to
"assume" and actually injecting DOM elements I never asked for.

Trygve



On Tue, 2011-07-26 at 12:42 +0000, gentle_media wrote:
> Hi everybody,
>
> I'm new here and new to optimizing websites for mobile.
>
> I have the Opera Mobile emulator installed to check my progress in that
browser and I've noticed that Opera Mobile automatically converts set of numbers
into a link. It thinks that it is a telephone number while it's not.
>
> Is there a way to stop Opera Mobile from doing that to every set of numbers
except of course when it's a telephone number.
> <a href="tel:00301234567890">+30-1234567890</a>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

> <meta name="format-detection" content="telephone=no">
>
> on RIM
>
> <meta http-equiv="x-rim-auto-match" content="none" />


None of these meta tags fixes the problem in Opera:
http://files.trygve-lie.com/tests/css_mobile_extra_a/fix.html

Trygve