mobile-web : Messages : 724-753 of 883

Hello list,

I'm working on a project with includes numerous forms and aims for
platform/UA agnosticism, with special responsiveness to tablets and
smartphones.

HTML5 input types specifying input formats such as date, number, email
are incredibly useful on smaller devices where the actual input
interface is restricted, but desktop browsers have been a bit gung-ho
and over-eager in implementing any kind of different GUI for these. In
particular, I wouldn't wish Chrome or Opera's creative approaches to
these on any one.

So my position is that by and wide I don't trust user agents' creative
approach to inputs; but I believe they're invaluable on iOS.

My current approach is to leave all such inputs as @type=text, and
replace them with desired types, when appropriate upon inferring iOS
from the UA string.

Any recommendations, warnings, insights?


Regards,
Barney Carroll

barney.carroll@...
07594 506 381

#725

From: "nashvileric" <NashvilEric@...>
Date: Thu Sep 1, 2011 1:28 pm
Subject: Re: HTML5 inputs and native GUI implementation

nashvileric

Nothing but complete agreement, Barney.

I'm glad I'm not the only one who's been thrown by Chrome, Firefox, and Opera's
"creative implementations" of these input types.

We're developing for webkit mobile and our dev and qa folks have sometimes been
thrown off because of unexpected behavior that's a result of using a desktop
browser that handles these inputs in special ways. eg: popping up an ugly,
incorrectly z-indexed "required" notice when you tab off a field.

I do think it's appropriate to hand most of this behavior over to the browsers,
but the details of interaction and some of the details of visual display need to
be very clearly defined or we won't be able to create a coherent experience
without UA sniffing.

Eric
SimpleAsCouldBe.com

--- In mobile-web@yahoogroups.com, Barney Carroll <barney.carroll@...> wrote:
>
> Hello list,
>
> I'm working on a project with includes numerous forms and aims for
> platform/UA agnosticism, with special responsiveness to tablets and
> smartphones.
>
> HTML5 input types specifying input formats such as date, number, email
> are incredibly useful on smaller devices where the actual input
> interface is restricted, but desktop browsers have been a bit gung-ho
> and over-eager in implementing any kind of different GUI for these. In
> particular, I wouldn't wish Chrome or Opera's creative approaches to
> these on any one.
>
> So my position is that by and wide I don't trust user agents' creative
> approach to inputs; but I believe they're invaluable on iOS.
>
> My current approach is to leave all such inputs as @type=text, and
> replace them with desired types, when appropriate upon inferring iOS
> from the UA string.
>
> Any recommendations, warnings, insights?
>
>
> Regards,
> Barney Carroll
>
> barney.carroll@...
> 07594 506 381
>

#726

From: Brad Frost <frostbd@...>
Date: Thu Sep 1, 2011 1:39 pm
Subject: Re: HTML5 inputs and native GUI implementation

ienjoyhotsoup

Hey Barney,

I too get a bit annoyed with how some of the desktop browsers handle the new input types. I believe they are well-intentioned, but you end up having to hack around them in order to style them properly (in my case often with an anxious-looking visual designer peering over my shoulder O_o).

First off, have you looked at -webkit-appearance? You can fiddle with the appearance of the input using that property in your CSS. http://css-infos.net/property/-webkit-appearance I'm not sure if Opera has a similar property.

I like your idea of switching out text inputs, but I would suggest doing it in reverse. �As much as possible you should have the most semantic markup as your core, which would get served up to everything. Android, iOS and Blackberry (I'm pretty sure even some 5.0 devices pull up the appropriate keyboards, +6.0 definitely does) all take advantage of the customized virtual keyboards while other devices seem to fall back properly.

So maybe detect if the screen width > ~600 and touch events aren't supported (or of course using UA sniffing) to replace the HTML5 input types with more generic text inputs for desktop browsers. �That's of course not bulletproof but might work for this scenario.

Has anyone else come across weird HTML5 input type behavior, either on mobile browsers or even desktop ones? �Any quick tips?

__________________________________
Brad Frost
http://bradfrostweb.com
http://twitter.com/brad_frost

On Thu, Sep 1, 2011 at 7:20 AM, Barney Carroll <barney.carroll@...> wrote:

�

Hello list,

I'm working on a project with includes numerous forms and aims for
platform/UA agnosticism, with special responsiveness to tablets and
smartphones.

HTML5 input types specifying input formats such as date, number, email
are incredibly useful on smaller devices where the actual input
interface is restricted, but desktop browsers have been a bit gung-ho
and over-eager in implementing any kind of different GUI for these. In
particular, I wouldn't wish Chrome or Opera's creative approaches to
these on any one.

So my position is that by and wide I don't trust user agents' creative
approach to inputs; but I believe they're invaluable on iOS.

My current approach is to leave all such inputs as @type=text, and
replace them with desired types, when appropriate upon inferring iOS
from the UA string.

Any recommendations, warnings, insights?

Regards,
Barney Carroll

barney.carroll@...
07594 506 381

#727

From: Barney Carroll <barney.carroll@...>
Date: Thu Sep 1, 2011 2:03 pm
Subject: Re: html 5 forms

barney.carroll@...

Hi Erwin,

I'm familiar with modernizr, and have used it before. Sadly what I'm after is less of a boolean 'do you support inputs of type X?' and more of a qualitative 'do you handle them properly?', the API for which is inexistent.

In an (my) ideal world, browser vendors would limit the effect of HTML5 input specifications to restricting user input: which iOS does brilliantly, and in a way that makes the user's work simpler and faster; sadly Opera and Chrome DO support, for example, date and number inputs — but they do so in a way that pollutes the ghost DOM GUI in ways I find tasteless and unhelpful: making user input more complex than it needs to be, in ways I can't control fully.

Essentially, I'm asking if there are better ways of inferring iOS-style keyboard restriction than UA sniffing, and if the notion of doing so to 'enhance' form elements to their desired HTML5 types is one anybody finds distasteful for any reasons I might not have thought of…

Regards,

Barney Carroll

(+44) 742 9177 278

On 1 Sep 2011, at 14:28, Erwin Heiser <erwin.heiser@...> wrote:

HI,

tried answering through the news group but it keeps failing for some reason.
Here's a list of js polyfills, check the webforms section for useful libraries:

https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills

Also, Modernizr can also test for input types:
http://www.modernizr.com/

Hope it helps,

Erwin Heiser | Stookstudio | ExpressionEngine Pro Network
www.stookstudio.com | erwin.heiser@...
+ 32 (0)4 87 544 302 | skype: stookstudio

#728

From: Stephanie Rieger <steph@...>
Date: Thu Sep 1, 2011 2:25 pm
Subject: Re: HTML5 inputs and native GUI implementation

yiibu_steph

I'm a bit torn on this one. Would tend to agree with Brad to use the most semantic option as default however detecting iOS, then enhancing for it (until such time when the others catch up) is far more foolproof than detecting multiple variants of other browsers and/or device types.

We did something similar recently to swap a doctype. It's not ideal but it's simple to execute, pretty reliable (esp for iOS as it all goes through Apple so UAs are consistent) and easy to maintain.

Steph

Sent from my mobile.

yiibu.com

+44 7957 651 177

On 1 Sep 2011, at 14:39, Brad Frost <frostbd@...> wrote:

Hey Barney,
I too get a bit annoyed with how some of the desktop browsers handle the new input types. I believe they are well-intentioned, but you end up having to hack around them in order to style them properly (in my case often with an anxious-looking visual designer peering over my shoulder O_o).

First off, have you looked at -webkit-appearance? You can fiddle with the appearance of the input using that property in your CSS. http://css-infos.net/property/-webkit-appearance I'm not sure if Opera has a similar property.

I like your idea of switching out text inputs, but I would suggest doing it in reverse. As much as possible you should have the most semantic markup as your core, which would get served up to everything. Android, iOS and Blackberry (I'm pretty sure even some 5.0 devices pull up the appropriate keyboards, +6.0 definitely does) all take advantage of the customized virtual keyboards while other devices seem to fall back properly.

So maybe detect if the screen width > ~600 and touch events aren't supported (or of course using UA sniffing) to replace the HTML5 input types with more generic text inputs for desktop browsers. That's of course not bulletproof but might work for this scenario.

Has anyone else come across weird HTML5 input type behavior, either on mobile browsers or even desktop ones? Any quick tips?
__________________________________
Brad Frost
http://bradfrostweb.com
http://twitter.com/brad_frost

On Thu, Sep 1, 2011 at 7:20 AM, Barney Carroll <barney.carroll@...> wrote:

Hello list,

I'm working on a project with includes numerous forms and aims for
platform/UA agnosticism, with special responsiveness to tablets and
smartphones.

HTML5 input types specifying input formats such as date, number, email
are incredibly useful on smaller devices where the actual input
interface is restricted, but desktop browsers have been a bit gung-ho
and over-eager in implementing any kind of different GUI for these. In
particular, I wouldn't wish Chrome or Opera's creative approaches to
these on any one.

So my position is that by and wide I don't trust user agents' creative
approach to inputs; but I believe they're invaluable on iOS.

My current approach is to leave all such inputs as @type=text, and
replace them with desired types, when appropriate upon inferring iOS
from the UA string.

Any recommendations, warnings, insights?

Regards,
Barney Carroll

barney.carroll@...
07594 506 381

#729

From: Jeff Patzer <jeff.patzer@...>
Date: Thu Sep 1, 2011 3:49 pm
Subject: Re: HTML5 inputs and native GUI implementation

jefeman88

Hi Barney,

Great think and love the caution! I think that Brad brings up a good point that will probably solve a good amount of your headache. You can clear an elements appearance setting and the will allow you to style it as you'd like (in most cases). And if that won't specifically do the trick for a specific browser, you can probably consult the browser documentation to find what property you'll have to set to get what you want.�

What I really recommend though is setting up SASS (http://sass-lang.com/) and using Compass (http://compass-style.org/) to get this all done in a much cleaner, more�manageable�way. If you aren't familiar with it, take a moment to read about it but more or less, you can just import this mixin (http://compass-style.org/reference/compass/css3/appearance/) and it will take care of Mozilla, Webkit, and the future.�

I recommend giving that a try to see if it will cover most of the platforms that you need to cover.�

Good luck on the project�

On Thu, Sep 1, 2011 at 6:39 AM, Brad Frost <frostbd@...> wrote:

�

Hey Barney,
I too get a bit annoyed with how some of the desktop browsers handle the new input types. I believe they are well-intentioned, but you end up having to hack around them in order to style them properly (in my case often with an anxious-looking visual designer peering over my shoulder O_o).

First off, have you looked at -webkit-appearance? You can fiddle with the appearance of the input using that property in your CSS. http://css-infos.net/property/-webkit-appearance I'm not sure if Opera has a similar property.

I like your idea of switching out text inputs, but I would suggest doing it in reverse. �As much as possible you should have the most semantic markup as your core, which would get served up to everything. Android, iOS and Blackberry (I'm pretty sure even some 5.0 devices pull up the appropriate keyboards, +6.0 definitely does) all take advantage of the customized virtual keyboards while other devices seem to fall back properly.

So maybe detect if the screen width > ~600 and touch events aren't supported (or of course using UA sniffing) to replace the HTML5 input types with more generic text inputs for desktop browsers. �That's of course not bulletproof but might work for this scenario.

Has anyone else come across weird HTML5 input type behavior, either on mobile browsers or even desktop ones? �Any quick tips?
__________________________________
Brad Frost
http://bradfrostweb.com
http://twitter.com/brad_frost

On Thu, Sep 1, 2011 at 7:20 AM, Barney Carroll <barney.carroll@...> wrote:

�

Hello list,

I'm working on a project with includes numerous forms and aims for
platform/UA agnosticism, with special responsiveness to tablets and
smartphones.

HTML5 input types specifying input formats such as date, number, email
are incredibly useful on smaller devices where the actual input
interface is restricted, but desktop browsers have been a bit gung-ho
and over-eager in implementing any kind of different GUI for these. In
particular, I wouldn't wish Chrome or Opera's creative approaches to
these on any one.

So my position is that by and wide I don't trust user agents' creative
approach to inputs; but I believe they're invaluable on iOS.

My current approach is to leave all such inputs as @type=text, and
replace them with desired types, when appropriate upon inferring iOS
from the UA string.

Any recommendations, warnings, insights?

Regards,
Barney Carroll

barney.carroll@...
07594 506 381

Jeff Patzer

Moovweb |�510.468.8372 |�http://moovweb.com/�|�212 Sutter St.�2nd Floor�San Francisco, CA�94108

#730

From: Barney Carroll <barney.carroll@...>
Date: Thu Sep 1, 2011 4:16 pm
Subject: Re: HTML5 inputs and native GUI implementation

barney.carroll@...

Thanks all for your insightful responses.

As regards a method for conditionally enhancing elements, it turns out that the type attribute cannot be dynamically modified, so my JS plugin is still in need of a bit of testing ;)

@Brad

You're right about Android, Blackberry and iOS: these are specifically the user agents I'm targeting for enhancement. As it is, I simply can't bring myself to trust anyone else's hare-brained idea of how to implement the spec, so I'm treating HTML5 (as in all circumstances) as an enhancement rather than a default. W3 specification and browser implementation have increasingly been more about getting anything at all on the table and out in the wild ASAP rather than fully thinking through and adequately specifying appropriate behaviour, and as such I find it better to limit recent features to secure implementations.

@Jeff

That's an incredibly cool feature I was unaware of in SASS. Does it go as far as eg destroying Opera's presumptuous calendar widget for type="date" inputs? I'll experiment, but I'm mistrustful of behavioural as well as presentational aspects of advanced inputs.

Mini rant:

As regards semantics, the semi-gnostic idealist's interpretation doesn't travel that far with me. All of these forms will be (as they always have been in my book) adequately described in their labels, and I don't think users will suffer all that much from having, in the worst case scenario, a full keyboard shoved in their face when a specific configuration might have been more convenient. In practice, HTML5 inputs terrify me, since things which by all rights should be defined in scripted behaviour or styled appearance are rushing into an ambiguous place somewhere between markup and UA assumptions. For instance, preventing submission and delivering a white and pink bubble overlay over the first input to fail validation steps very far outside of Chrome's remit. To the best of my knowledge, ALL browsers supporting advanced HTML5 input specifics also support Javascript and CSS which allow us to specify user interaction in a way that makes me far more comfortable. If for whatever reason they don't, then plain old XHTML1 is at least a fully functional known quantity…

Regards,
Barney Carroll

barney.carroll@...
07594 506 381

On 1 September 2011 16:49, Jeff Patzer <jeff.patzer@...> wrote:

Hi Barney,

Great think and love the caution! I think that Brad brings up a good point that will probably solve a good amount of your headache. You can clear an elements appearance setting and the will allow you to style it as you'd like (in most cases). And if that won't specifically do the trick for a specific browser, you can probably consult the browser documentation to find what property you'll have to set to get what you want.

What I really recommend though is setting up SASS (http://sass-lang.com/) and using Compass (http://compass-style.org/) to get this all done in a much cleaner, more manageable way. If you aren't familiar with it, take a moment to read about it but more or less, you can just import this mixin (http://compass-style.org/reference/compass/css3/appearance/) and it will take care of Mozilla, Webkit, and the future.

I recommend giving that a try to see if it will cover most of the platforms that you need to cover.

Good luck on the project

On Thu, Sep 1, 2011 at 6:39 AM, Brad Frost <frostbd@...> wrote:

Hey Barney,
I too get a bit annoyed with how some of the desktop browsers handle the new input types. I believe they are well-intentioned, but you end up having to hack around them in order to style them properly (in my case often with an anxious-looking visual designer peering over my shoulder O_o).

First off, have you looked at -webkit-appearance? You can fiddle with the appearance of the input using that property in your CSS. http://css-infos.net/property/-webkit-appearance I'm not sure if Opera has a similar property.

I like your idea of switching out text inputs, but I would suggest doing it in reverse. As much as possible you should have the most semantic markup as your core, which would get served up to everything. Android, iOS and Blackberry (I'm pretty sure even some 5.0 devices pull up the appropriate keyboards, +6.0 definitely does) all take advantage of the customized virtual keyboards while other devices seem to fall back properly.

So maybe detect if the screen width > ~600 and touch events aren't supported (or of course using UA sniffing) to replace the HTML5 input types with more generic text inputs for desktop browsers. That's of course not bulletproof but might work for this scenario.

Has anyone else come across weird HTML5 input type behavior, either on mobile browsers or even desktop ones? Any quick tips?
__________________________________
Brad Frost
http://bradfrostweb.com
http://twitter.com/brad_frost

On Thu, Sep 1, 2011 at 7:20 AM, Barney Carroll <barney.carroll@...> wrote:

Hello list,

I'm working on a project with includes numerous forms and aims for
platform/UA agnosticism, with special responsiveness to tablets and
smartphones.

HTML5 input types specifying input formats such as date, number, email
are incredibly useful on smaller devices where the actual input
interface is restricted, but desktop browsers have been a bit gung-ho
and over-eager in implementing any kind of different GUI for these. In
particular, I wouldn't wish Chrome or Opera's creative approaches to
these on any one.

So my position is that by and wide I don't trust user agents' creative
approach to inputs; but I believe they're invaluable on iOS.

My current approach is to leave all such inputs as @type=text, and
replace them with desired types, when appropriate upon inferring iOS
from the UA string.

Any recommendations, warnings, insights?

Regards,
Barney Carroll

barney.carroll@...
07594 506 381

--

Jeff Patzer

Moovweb | 510.468.8372 | http://moovweb.com/ | 212 Sutter St. 2nd Floor San Francisco, CA 94108

#731

From: Jeff Patzer <jeff.patzer@...>
Date: Sat Sep 3, 2011 3:44 pm
Subject: Re: HTML5 inputs and native GUI implementation

jefeman88

http://www.opera.com/docs/specs/presto29/css/basicuserinterface/

Hey Barney

Looks like we're a bit out of luck on Opera

I checked a bit more in depth and it appears they don't support the appearance property in presto 2.9

Which means that even compass won't help us here (although if Opera eventually does implement it, then you'll get it for free). Here's the compass source code:

@mixin appearance($ap) {
� $ap: unquote($ap);
� @include experimental(appearance, $ap, -moz, -webkit, not -o, not -ms, not -khtml, official); }

This will compile to�

� -moz-appearance: none;
� -webkit-appearance: none;
� appearance: none;

On Thu, Sep 1, 2011 at 7:25 AM, Stephanie Rieger <steph@...> wrote:

�

I'm a bit torn on this one. Would tend to agree with Brad to use the most semantic option as default however detecting iOS, then enhancing for it (until such time when the others catch up) is far more foolproof than detecting multiple variants of other browsers and/or device types.

We did something similar recently to swap a doctype. It's not ideal but it's simple to execute, pretty reliable (esp for iOS as it all goes through Apple so UAs are consistent) and easy to maintain.

Steph

Sent from my mobile.
yiibu.com
+44 7957 651 177

On 1 Sep 2011, at 14:39, Brad Frost <frostbd@...> wrote:

�

Hey Barney,
I too get a bit annoyed with how some of the desktop browsers handle the new input types. I believe they are well-intentioned, but you end up having to hack around them in order to style them properly (in my case often with an anxious-looking visual designer peering over my shoulder O_o).

First off, have you looked at -webkit-appearance? You can fiddle with the appearance of the input using that property in your CSS. http://css-infos.net/property/-webkit-appearance I'm not sure if Opera has a similar property.

I like your idea of switching out text inputs, but I would suggest doing it in reverse. �As much as possible you should have the most semantic markup as your core, which would get served up to everything. Android, iOS and Blackberry (I'm pretty sure even some 5.0 devices pull up the appropriate keyboards, +6.0 definitely does) all take advantage of the customized virtual keyboards while other devices seem to fall back properly.

So maybe detect if the screen width > ~600 and touch events aren't supported (or of course using UA sniffing) to replace the HTML5 input types with more generic text inputs for desktop browsers. �That's of course not bulletproof but might work for this scenario.

Has anyone else come across weird HTML5 input type behavior, either on mobile browsers or even desktop ones? �Any quick tips?
__________________________________
Brad Frost
http://bradfrostweb.com
http://twitter.com/brad_frost

On Thu, Sep 1, 2011 at 7:20 AM, Barney Carroll <barney.carroll@...> wrote:

�

Hello list,

I'm working on a project with includes numerous forms and aims for
platform/UA agnosticism, with special responsiveness to tablets and
smartphones.

HTML5 input types specifying input formats such as date, number, email
are incredibly useful on smaller devices where the actual input
interface is restricted, but desktop browsers have been a bit gung-ho
and over-eager in implementing any kind of different GUI for these. In
particular, I wouldn't wish Chrome or Opera's creative approaches to
these on any one.

So my position is that by and wide I don't trust user agents' creative
approach to inputs; but I believe they're invaluable on iOS.

My current approach is to leave all such inputs as @type=text, and
replace them with desired types, when appropriate upon inferring iOS
from the UA string.

Any recommendations, warnings, insights?

Regards,
Barney Carroll

barney.carroll@...
07594 506 381

Jeff Patzer

Moovweb |�510.468.8372 |�http://moovweb.com/�|�212 Sutter St.�2nd Floor�San Francisco, CA�94108

#732

From: Luca Passani <luca.passani@...>
Date: Sun Sep 18, 2011 6:31 pm
Subject: relation between Opera Mobile and Presto rendering engine

luca_passani

Hi, I know that there are Opera people hanging out here.

I found this useful page on WikiPedia about how Presto and Opera Mobile relate:

http://en.wikipedia.org/wiki/Presto_(layout_engine)
<http://en.wikipedia.org/wiki/Presto_%28layout_engine%29>

The only problem is that there seems to be a disconnect between the info there
and what developers are observing in the wild (version 2.7 and 2.8 of the Presto
rendering engine should go with version 11 of the browser, while the UA says
9.80:

  Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1105231029; U; sv)
Presto/2.7.81
Version/11.00

  Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1106291546; U; en)
Presto/2.8.149
Version/11.10

  Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1106291546; U; ru)
Presto/2.8.149
Version/11.10

  Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1106291546; U; zh-cn)
Presto/2.8.149
Version/11.10

  Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1107051709; U; da)
Presto/2.8.149 Version/11.10

Is this because of backward compatibility with some website out there?  is the
"Version/" field more reliable than the Opera/9.80 string?

Anyone from Opera who can shed some light?

Thank you

Luca

#733

From: "a_paddy2k" <patrick.oreilly@...>
Date: Mon Sep 19, 2011 4:22 pm
Subject: Re: relation between Opera Mobile and Presto rendering engine

a_paddy2k

Luca,

Opera explained in 2009 that this was due to bad parsing of the UA by many
sites. (Opera 10.0 was interpreted as Opera 1 by some)
http://dev.opera.com/articles/view/opera-ua-string-changes/

Yours,
Paddy

--- In mobile-web@yahoogroups.com, Luca Passani <luca.passani@...> wrote:
>
>
> Hi, I know that there are Opera people hanging out here.
>
> I found this useful page on WikiPedia about how Presto and Opera Mobile
relate:
>
> http://en.wikipedia.org/wiki/Presto_(layout_engine)
> <http://en.wikipedia.org/wiki/Presto_%28layout_engine%29>
>
> The only problem is that there seems to be a disconnect between the info there
> and what developers are observing in the wild (version 2.7 and 2.8 of the
Presto
> rendering engine should go with version 11 of the browser, while the UA says
9.80:
>
>  Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1105231029; U; sv)
> Presto/2.7.81
> Version/11.00
>
>  Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1106291546; U; en)
> Presto/2.8.149
> Version/11.10
>
>  Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1106291546; U; ru)
> Presto/2.8.149
> Version/11.10
>
>  Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1106291546; U; zh-cn)
> Presto/2.8.149
> Version/11.10
>
>  Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1107051709; U; da)
> Presto/2.8.149 Version/11.10
>
> Is this because of backward compatibility with some website out there?  is the
> "Version/" field more reliable than the Opera/9.80 string?
>
> Anyone from Opera who can shed some light?
>
> Thank you
>
> Luca
>

#734

From: jim smith <jim.smith@...>
Date: Mon Sep 19, 2011 4:41 pm
Subject: Re: Re: relation between Opera Mobile and Presto rendering engine

jim68000

Breaking the User-Agent even further seems like a poor response to broken browser-detection.

If they'd stuck with Opera/10 all but the most braindead would have eventually update their filters.

Instead they get a brief period of compatibility, followed by more pain as we update our detection routines to deal with the new Version/10 string. That seems like a textbook case of technical debt.

On Sep 19, 2011 5:22 PM, "a_paddy2k" <patrick.oreilly@...> wrote:
> Luca,
>
> Opera explained in 2009 that this was due to bad parsing of the UA by many sites. (Opera 10.0 was interpreted as Opera 1 by some)
> http://dev.opera.com/articles/view/opera-ua-string-changes/
>
> Yours,
> Paddy
>
> --- In mobile-web@yahoogroups.com, Luca Passani <luca.passani@...> wrote:
>>
>>
>> Hi, I know that there are Opera people hanging out here.
>>
>> I found this useful page on WikiPedia about how Presto and Opera Mobile relate:
>>
>> http://en.wikipedia.org/wiki/Presto_(layout_engine)
>> <http://en.wikipedia.org/wiki/Presto_%28layout_engine%29>
>>
>> The only problem is that there seems to be a disconnect between the info there
>> and what developers are observing in the wild (version 2.7 and 2.8 of the Presto
>> rendering engine should go with version 11 of the browser, while the UA says 9.80:
>>
>> Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1105231029; U; sv)
>> Presto/2.7.81
>> Version/11.00
>>
>> Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1106291546; U; en)
>> Presto/2.8.149
>> Version/11.10
>>
>> Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1106291546; U; ru)
>> Presto/2.8.149
>> Version/11.10
>>
>> Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1106291546; U; zh-cn)
>> Presto/2.8.149
>> Version/11.10
>>
>> Opera/9.80 (Android 2.1-update1; Linux; Opera Mobi/ADR-1107051709; U; da)
>> Presto/2.8.149 Version/11.10
>>
>> Is this because of backward compatibility with some website out there? is the
>> "Version/" field more reliable than the Opera/9.80 string?
>>
>> Anyone from Opera who can shed some light?
>>
>> Thank you
>>
>> Luca
>>
>
>

#735

From: "ggloiu" <ggloiu@...>
Date: Tue Sep 20, 2011 12:16 am
Subject: You've got a private message!

ggloiu

You've got a private message! Check it here:
http://file1.hpage.com/006686/95/html/ottie.htm

Reply | Messages in this Topic (9)

#736

From: "David" <roger.kinlay@...>
Date: Tue Sep 20, 2011 7:37 am
Subject: Re: You've got a private message!

davidkinlay

--- In mobile-web@yahoogroups.com, "rfsffghfds" <rfsffghfds@...> wrote:
>
> You've got a private message! Check it here:
> http://www.weebly.com/uploads/7/9/1/3/7913506/hottie.htm
>No more messages or you'll be banned!

Reply | Messages in this Topic (9)

#737

From: "Bruce Lawson" <bruce@...>
Date: Tue Sep 20, 2011 4:40 pm
Subject: Re: relation between Opera Mobile and Presto rendering engine

lawsonbruce15

Luca wrote

there seems to be a disconnect between the info there
     > and what developers are observing in the wild (version 2.7 and 2.8 of
the Presto
     > rendering engine should go with version 11 of the browser, while the
UA
says 9.8
[...]

> Is this because of backward compatibility with some website out there?
> is the
     > "Version/" field more reliable than the Opera/9.80 string?

Lots of sites had such useless UA sniffing that Opera 10 was being
reported as Opera 1, with predictable results. Our team contacted a lot
who changed their routines. But lots didn't, hence the disparity.

The "Version/" field has the "real" version number.

Bruce Lawson
Opera Developer Relations


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

#738

From: Barney Carroll <barney.carroll@...>
Date: Tue Sep 20, 2011 5:16 pm
Subject: Re: Re: relation between Opera Mobile and Presto rendering engine

barney.carroll@...

Just my two pence: I find that pretty easy to parse.

Regards,

Barney Carroll

(+44) 742 9177 278

On 20 Sep 2011, at 17:40, "Bruce Lawson" <bruce@...> wrote:

Luca wrote

there seems to be a disconnect between the info there
> and what developers are observing in the wild (version 2.7 and 2.8 of
the Presto
> rendering engine should go with version 11 of the browser, while the
UA
says 9.8
[...]

> Is this because of backward compatibility with some website out there?
> is the
> "Version/" field more reliable than the Opera/9.80 string?

Lots of sites had such useless UA sniffing that Opera 10 was being
reported as Opera 1, with predictable results. Our team contacted a lot
who changed their routines. But lots didn't, hence the disparity.

The "Version/" field has the "real" version number.

Bruce Lawson
Opera Developer Relations

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

#739

From: George Paterson <George.Paterson@...>
Date: Tue Sep 20, 2011 5:29 pm
Subject: Re: Re: relation between Opera Mobile and Presto rendering engine

George.Paterson@...

It is easy to parse but that's not the point. Competent developers now have to write additional code due to the incompetence of other developers hence the concept of technical debt.

Ultimately I understand Opera's choice in the matter as not just a technical decision.

On 20 Sep 2011, at 18:17, "Barney Carroll" <barney.carroll@...> wrote:

Just my two pence: I find that pretty easy to parse.

Regards,

Barney Carroll
(+44) 742 9177 278

On 20 Sep 2011, at 17:40, "Bruce Lawson" <bruce@...> wrote:

Luca wrote

there seems to be a disconnect between the info there
> and what developers are observing in the wild (version 2.7 and 2.8 of
the Presto
> rendering engine should go with version 11 of the browser, while the
UA
says 9.8
[...]

> Is this because of backward compatibility with some website out there?
> is the
> "Version/" field more reliable than the Opera/9.80 string?

Lots of sites had such useless UA sniffing that Opera 10 was being
reported as Opera 1, with predictable results. Our team contacted a lot
who changed their routines. But lots didn't, hence the disparity.

The "Version/" field has the "real" version number.

Bruce Lawson
Opera Developer Relations

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Confidentiality notice
This communication is from LBi Ltd, a private limited company registered in Scotland with registered number SC177425 having its registered office at 51 Timberbush, Edinburgh, EH6 6QH.
This electronic message contains information which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail as above immediately.

#740

From: "steve_souders" <steve@...>
Date: Thu Sep 22, 2011 6:08 am
Subject: new post: Making a Mobile Connection

steve_souders

new post: Making a Mobile Connection - the yin & yang of battery life & web
performance over a 3G network
http://www.stevesouders.com/blog/2011/09/21/making-a-mobile-connection/

Mobile carriers aggressively close a phone's radio link to conserve battery
life, but this creates a ~2 second delay the next time the user tries to access
the Web. What's the right tradeoff?

-Steve

#741

From: "crsvenningsen" <csvenningsen@...>
Date: Fri Sep 23, 2011 4:11 pm
Subject: Mobile DNS lookup latency

crsvenningsen

Processing Steve Souders talk "Faster Mobile Anyone?" from Breaking Development
(killer talks, all!), and I'm looking for some data on mobile latency with
regard to DNS lookups over 3G. I'm weighing out the pros and cons of using CDNs
for mobile sites.

Can anyone point me in the right direction?

Steve's slides: http://stevesouders.com/docs/bdconf-20110912.pptx

#742

From: "steve_souders" <steve@...>
Date: Sat Sep 24, 2011 4:46 pm
Subject: Re: Mobile DNS lookup latency

steve_souders

Rajiv's talk from Velocity talks about latency in general (slides 9-12) and DNS
specifically. If the DNS resolution is not cached his data shows it'll be
200-400 ms (slide 12).

Don't forget it'll be 1-2 seconds to ramp up the radio link if it's idle.

Glad you liked my slides!

-Steve

--- In mobile-web@yahoogroups.com, "crsvenningsen" <csvenningsen@...> wrote:
>
> Processing Steve Souders talk "Faster Mobile Anyone?" from Breaking
Development (killer talks, all!), and I'm looking for some data on mobile
latency with regard to DNS lookups over 3G. I'm weighing out the pros and cons
of using CDNs for mobile sites.
>
> Can anyone point me in the right direction?
>
> Steve's slides: http://stevesouders.com/docs/bdconf-20110912.pptx
>

#743

From: "steve_souders" <steve@...>
Date: Wed Sep 28, 2011 1:23 am
Subject: post: App cache & localStorage survey

steve_souders

Looking at the US Alexa Top 10:
   - 5 use localStorage on mobile
   - 2 use localStorage (or sessionStorage) on desktop
   - none use app cache

http://www.stevesouders.com/blog/2011/09/26/app-cache-localstorage-survey/

#744

From: "steve_souders" <steve@...>
Date: Wed Sep 28, 2011 1:24 am
Subject: post: UA Switching: be careful

steve_souders

Growing adoption of responsive web design means we need to be even more wary
about using UA switching to monitor mobile websites.

http://www.stevesouders.com/blog/2011/09/27/ua-switching-be-careful/

#745

From: "jonnyschneider_aus" <schneider.jonny@...>
Date: Sun Oct 9, 2011 11:39 pm
Subject: Mobile speed-test/benchmark sites

jonnyschneid...

Hello,

Anybody know of a decent mobile speed-test or benchmarking service?
I'm familiar with mobiready.com which does the basics, but it looks like  a lot
of the recommendations are a bit out of date.

I've also used firebug/Yslow extension for firefox, but that's obviously not
mobile specific.

What do you use?

Cheers, -Jonny

#746

From: Jared Hirsch <jared@...>
Date: Sun Oct 9, 2011 11:44 pm
Subject: Re: Mobile speed-test/benchmark sites

jared@...

Maybe�http://www.blaze.io/mobile/�is what you're looking for?

Keynote announced a mobile testing product at Velocity this year, and I bet Gomez has something as well, if you're looking to pay somebody.

Good luck!

Jared

On Sun, Oct 9, 2011 at 4:39 PM, jonnyschneider_aus <schneider.jonny@...> wrote:

�

Hello,

Anybody know of a decent mobile speed-test or benchmarking service?
I'm familiar with mobiready.com which does the basics, but it looks like a lot of the recommendations are a bit out of date.

I've also used firebug/Yslow extension for firefox, but that's obviously not mobile specific.

What do you use?

Cheers, -Jonny

#747

From: Caleb Wong <carbon.caleb@...>
Date: Sun Oct 9, 2011 11:44 pm
Subject: Re: Mobile speed-test/benchmark sites

ca1ebo

http://developer.yahoo.com/yslow/mobile

Hi Jonny

There's Yslow for Mobile.

And this.

http://www.blaze.io/mobile/

Caleb

On Mon, Oct 10, 2011 at 10:39 AM, jonnyschneider_aus <schneider.jonny@...> wrote:

�

Hello,

Anybody know of a decent mobile speed-test or benchmarking service?
I'm familiar with mobiready.com which does the basics, but it looks like a lot of the recommendations are a bit out of date.

I've also used firebug/Yslow extension for firefox, but that's obviously not mobile specific.

What do you use?

Cheers, -Jonny

#748

From: Andrew Mattie <amattie@...>
Date: Mon Oct 10, 2011 12:55 am
Subject: Re: Mobile speed-test/benchmark sites

amattie...

http://pagespeed.googlelabs.com/pagespeed/

Google's Page Speed Online also offers a mobile-specific analysis as an option.

Andrew

On Sun, Oct 9, 2011 at 4:39 PM, jonnyschneider_aus <schneider.jonny@...> wrote:

Hello,

Anybody know of a decent mobile speed-test or benchmarking service?
I'm familiar with mobiready.com which does the basics, but it looks like �a lot of the recommendations are a bit out of date.

I've also used firebug/Yslow extension for firefox, but that's obviously not mobile specific.

What do you use?

Cheers, -Jonny

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
� �http://groups.yahoo.com/group/mobile-web/

<*> Your email settings:
� �Individual Email | Traditional

<*> To change settings online go to:
� �http://groups.yahoo.com/group/mobile-web/join
� �(Yahoo! ID required)

<*> To change settings via email:
� �mobile-web-digest@yahoogroups.com
� �mobile-web-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
� �mobile-web-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
� �http://docs.yahoo.com/info/terms/

#749

From: Jo Rabin <jorabin@...>
Date: Mon Oct 10, 2011 11:22 am
Subject: Re: Mobile speed-test/benchmark sites

jorabin

Also take a look at http://validator.w3.org/mobile

and of course the webkit analyses are useful though not mobile specific.

On 10 Oct 2011, at 01:55, Andrew Mattie wrote:

Google's Page Speed Online also offers a mobile-specific analysis as an option.
http://pagespeed.googlelabs.com/pagespeed/

Andrew

On Sun, Oct 9, 2011 at 4:39 PM, jonnyschneider_aus <schneider.jonny@...> wrote:
Hello,

Anybody know of a decent mobile speed-test or benchmarking service?
I'm familiar with mobiready.com which does the basics, but it looks like a lot of the recommendations are a bit out of date.

I've also used firebug/Yslow extension for firefox, but that's obviously not mobile specific.

What do you use?

Cheers, -Jonny

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/mobile-web/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/mobile-web/join
(Yahoo! ID required)

<*> To change settings via email:
mobile-web-digest@yahoogroups.com
mobile-web-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
mobile-web-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

#750

From: "crsvenningsen" <csvenningsen@...>
Date: Wed Oct 12, 2011 8:11 pm
Subject: Using Android x86 instead of Android Emulator

crsvenningsen

I came across this fairly easy-to-follow guide on installing Android x86 in
VirtualBox and thought I'd share:
http://blogs.nuxeo.com/dev/2011/10/speeding-up-the-android-emulator.html

I've always been frustrated by the Android emulator's performance (I'm sure I'm
not alone there) and the x86 project takes care of that, while seemingly
rendering just about as well. For anyone else looking for a speedier solution,
I'd recommend it.

If anyone has more experience with this and can chime in with some downfalls of
going the simulation route (as opposed to emulation), I'd love to hear them.
Connecting via ADB is the one thing I've found to be slightly more annoying.

#751

From: "Alex Desouza" <alexdesouza88@...>
Date: Thu Oct 13, 2011 4:33 am
Subject: Cheap & best Website Development Company

alexdesouza88

When you are starting up your business a cheap website designer may seem the best option for you. So, here we will talk about the low cost website designing services and the best ways to develop cool websites. Among such a huge number of website owners, very few can afford real expensive website development companies or the service providers and so there must be some offering cheap and affordable websites.

If you are looking forward to hire a new website development company or an individual service provider who is just starting up, you will most likely not get a very rich portfolio. But in this stage you might get a competitive rate. Once the website development service professionals become more established, it is quite evident that, they will then no doubt increase their prices.

So, how to find such start up website developers! You can either look for the online directories or explore the forum pages to get start up yet authentic website developers. In fact, chances are there to get scammed with such cheap website designing means.

Once you get the website design anyway, you then need to think about web hosting. It may be worth asking the website developers you have hired if they can recommend a host. Now the time is to think about your website promotion. In some cases the website developers provide with the promotional services at an added cost. However you can hire SEO specialists to give your website a higher page rank and increased number of visitors.

#752

From: Gregers Gram Rygg <gregersrygg@...>
Date: Tue Oct 18, 2011 8:00 pm
Subject: Re: Using Android x86 instead of Android Emulator

gregersrygg

Didn't have time to check it out before today. It is indeed a _lot_ faster!

Thanks for sharing :)

Cheers,

Gregers

On Wed, Oct 12, 2011 at 10:11 PM, crsvenningsen <csvenningsen@...> wrote:

�

I came across this fairly easy-to-follow guide on installing Android x86 in VirtualBox and thought I'd share: http://blogs.nuxeo.com/dev/2011/10/speeding-up-the-android-emulator.html

I've always been frustrated by the Android emulator's performance (I'm sure I'm not alone there) and the x86 project takes care of that, while seemingly rendering just about as well. For anyone else looking for a speedier solution, I'd recommend it.

If anyone has more experience with this and can chime in with some downfalls of going the simulation route (as opposed to emulation), I'd love to hear them. Connecting via ADB is the one thing I've found to be slightly more annoying.

#753

From: "Alex Desouza" <alexdesouza88@...>
Date: Thu Oct 20, 2011 11:23 am
Subject: Make your Site Earn with E-commerce Design

alexdesouza88

A successful ecommerce website can help your business grow with greater prospect. How? Today at the age of globalization, Ecommerce websites are increasingly becoming a popular choice for the business owners especially those want to leverage the internet to sell their product or service to the global market. However, leaving your competitors behind is really not a cake walk. It requires unique approach and clever implementation of advanced marketing strategies to climb atop to the market niche. Ecommerce website is therefore the key to your business success.

An ecommerce website should be dynamic, well maintained and provide with the best access possible. It is essential to hire the best ecommerce service provider so that you can get your views reflected on a corporate platform. Use of advanced technologies is important but the same time it should be simple enough to access and explore, else the visitors will take no time to get away of the maze.

You must always keep the fact in mind that if you are looking forward to selling service or products online, you are going to require your customers use your website to make a purchase. So, usability counts a major role in ecommerce website design. You must ensure the process is easy enough to move forward immediately with the purchasing decision, complete the order placement and payment process and ultimately receive the quality product as been expected.

Apart from all these, you must have a highly encrypted online payment processing which is paramount to your customers. In other words, you should give your potential customers no reason to abandon their shopping cart before completing the online transaction.