mobile-web : Messages : 771-800 of 881

And has anyone else ever tried to use position:fixed in iOS5 and a scalable viewport at the same time?

�

I started playing around with fixed positioning, scaling and scrollable regions in iOS5. Here's my test:�http://bit.ly/mobilefixed

On the first page I didn't disable scaling, and the result is an odd little parallax effect on the fixed header.�
The second page has a fixed header and disabled scaling. �It behaves like we're used to seeing on a lot of sites out there.
The third page I tested out iOS5's newly supported scrollable regions with scaling enabled. I figure it can accomplish the same sort of fixed effect. �Here's the basic CSS:
.scrollable section{
height: 364px;�
overflow: scroll;
-webkit-overflow-scrolling: touch;
}

I noticed that the scrollable region's gravity is actually quite a bit different than the regular page scroll gravity.�
The fourth page contains a scrollable region with scaling disabled. It behaves as you might expect it to.�

I then went through on a Droid running 2.2.1, Droid Incredible's (2.2), SenseUI browser, Firefox, Opera Mobile and Opera Mini.

Android's browsers running 2.2 and Opera Mini don't seem to support fixed positioning at all. (I know that 2.3 supports it, although I've seen bugs/weirdness there as well)
SenseUI browser allows you to scale page even when you explicitly turn it off (different issue�altogether)�
Firefox and Opera Mobile wait until the page is done scrolling then awkwardly snaps the element to the top of the viewport
For the scrollable regions, all the browsers crop the content off with no way to access below the fold

The unfortunate conclusion is that fixed positioning and scrollable regions do not degrade gracefully in non-iOS browsers. I know this isn't anything groundbreaking, just look at Twitter or Gmail for iOS and Android and you'll see fixed positioning in one but not the other.�

This sad reality is particularly obnoxious because these positioning techniques unlock a whole lot of potential for mobile web experiences. It's a shame it can't be a simple enhancement to the UI.

I'm going to test these on a few more devices and try to do a little more research on them. If you care to view them on your own devices and report back, I'd greatly appreciate it.

Thanks,

Brad

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

On Mon, Oct 31, 2011 at 7:35 PM, James Pearce <jamesgpearce@...> wrote:

�

Hm - I thought I'd said something like 'accessibility aside' in my original message, but apparently edited it out inadvertently. (But then you'll have a go at me for saying that too anyway.)

So, of course.�

Hopefully no-one relies on scalable viewports to assert that their mobile creations are magically accessible.�And has anyone else ever tried to use position:fixed in iOS5 and a scalable viewport at the same time?

James

On 31 October 2011 16:03, Scotty Logan <swl@...> wrote:

�

On Oct 31, 2011, at 3:56 PM, James Pearce wrote:
> I work on the assumption that clever zooming exists mostly because it was needed to cater for sites that had *not* been built with a mobile viewport in mind. (Which was nearly all of them in 2007). i.e. it represents browser vendors' way of kickstarting usage of a web then still heavily wedded to desktop assumptions.
>
> Most sites still are, so I can't see browsers' zooming capabilities going away. But I'd say a properly crafted mobile experience ought to be able to deliberately disable it with a clean conscience.

Unless you worry about users with visual acuity issues or physical disabilities. Imagine your mobile experience for someone with poor eyesight and/or Parkinson's.

Scotty

--

James Pearce
Sr Director, Developer Relations
Sencha

#772

From: "sommsnet@..." <somms@...>
Date: Thu Nov 3, 2011 11:22 pm
Subject: Re: viewport on mobile devices

juliorabadang

Very interesting. Recently I did similar experiments with the same frustrating result. I've read that Android 3 has a real fixed positioning support, like iOS 5. Could somebody with an Android 3 at hand go to this test page and share the results with us?
Thanks

--
Enviado desde mi teléfono Android con K-9 Mail. Disculpa mi brevedad

Brad Frost <frostbd@...> escribió:

And has anyone else ever tried to use position:fixed in iOS5 and a scalable viewport at the same time?

I started playing around with fixed positioning, scaling and scrollable regions in iOS5. Here's my test: http://bit.ly/mobilefixed

On the first page I didn't disable scaling, and the result is an odd little parallax effect on the fixed header.
The second page has a fixed header and disabled scaling. It behaves like we're used to seeing on a lot of sites out there.

The third page I tested out iOS5's newly supported scrollable regions with scaling enabled. I figure it can accomplish the same sort of fixed effect. Here's the basic CSS:
.scrollable section{
height: 364px;
overflow: scroll;
-webkit-overflow-scrolling: touch;
}

I noticed that the scrollable region's gravity is actually quite a bit different than the regular page scroll gravity.
The fourth page contains a scrollable region with scaling disabled. It behaves as you might expect it to.

I then went through on a Droid running 2.2.1, Droid Incredible's (2.2), SenseUI browser, Firefox, Opera Mobile and Opera Mini.
Android's browsers running 2.2 and Opera Mini don't seem to support fixed positioning at all. (I know that 2.3 supports it, although I've seen bugs/weirdness there as well)

SenseUI browser allows you to scale page even when you explicitly turn it off (different issue altogether)
Firefox and Opera Mobile wait until the page is done scrolling then awkwardly snaps the element to the top of the viewport

For the scrollable regions, all the browsers crop the content off with no way to access below the fold
The unfortunate conclusion is that fixed positioning and scrollable regions do not degrade gracefully in non-iOS browsers. I know this isn't anything groundbreaking, just look at Twitter or Gmail for iOS and Android and you'll see fixed positioning in one but not the other.

This sad reality is particularly obnoxious because these positioning techniques unlock a whole lot of potential for mobile web experiences. It's a shame it can't be a simple enhancement to the UI.

I'm going to test these on a few more devices and try to do a little more research on them. If you care to view them on your own devices and report back, I'd greatly appreciate it.

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

On Mon, Oct 31, 2011 at 7:35 PM, James Pearce <jamesgpearce@...> wrote:

Hm - I thought I'd said something like 'accessibility aside' in my original message, but apparently edited it out inadvertently. (But then you'll have a go at me for saying that too anyway.)

So, of course.

Hopefully no-one relies on scalable viewports to assert that their mobile creations are magically accessible. And has anyone else ever tried to use position:fixed in iOS5 and a scalable viewport at the same time?

James

On 31 October 2011 16:03, Scotty Logan <swl@...> wrote:

On Oct 31, 2011, at 3:56 PM, James Pearce wrote:
> I work on the assumption that clever zooming exists mostly because it was needed to cater for sites that had *not* been built with a mobile viewport in mind. (Which was nearly all of them in 2007). i.e. it represents browser vendors' way of kickstarting usage of a web then still heavily wedded to desktop assumptions.
>
> Most sites still are, so I can't see browsers' zooming capabilities going away. But I'd say a properly crafted mobile experience ought to be able to deliberately disable it with a clean conscience.

Unless you worry about users with visual acuity issues or physical disabilities. Imagine your mobile experience for someone with poor eyesight and/or Parkinson's.

Scotty

--

James Pearce
Sr Director, Developer Relations
Sencha

#773

From: Peter-Paul Koch <pp.koch@...>
Date: Fri Nov 4, 2011 2:45 pm
Subject: Scrolling layer conundrum on iOS

ppkwdf

Hello,

I've run into a serious conundrum with a scrolling layer script that
should be pretty simple.

Test page: http://quirksmode.org/mobilismsite/Mobilism.htm
Script: http://quirksmode.org/mobilismsite/scrollscript.js

The problem: scroll the layer with speaker headshots to the right.
This should work, but my old iOS 3.2 device subsequently follows the
link in the headshot you touched. That should NOT happen (and mostly
doesn't happen in the other browsers: Android, Dolfin, BlackBerry, and
Opera).

First of all: if you have an iOS 5 device, please go to the page and
do the test.  Does the iOS5 device always follow the link if you
scroll the layer?

In addition to scrolling the layer I want two other features:

1) If the user touchmoves (mostly) up or down, I want to cancel my own
script and hand over the event to the OS for further action; i.e.
scrolling the entire page.
2) The headshots should be clickable, but only if the user does not scroll.

Separately these two features are easy to implement. Together they
cause a hell of a problem.

I handle feature 1 by reading out the deltaX and deltaY. If deltaY is
larger than deltaX I return true ontouchmove, and thus hand over the
event to the OS. If not I handle it myself and return false
ontouchmove. This works.

However, iOS 3.2 follows the link. The only way of cancelling this is
returning false ontouchstart, but that also cancels the handing over
of the event to the OS.

I have no idea how to cancel the following of the link without
returning false ontouchstart. I tried to return false on a click
event, but it seems that's never fired. Ideally I should copy the true
or false from the touchmove script and return that value ontouchstart,
too, but obviously that's impossible since the touchmove event only
fires after touchstart has been handled completely.

Right now I don't know how to proceed. If iOS5 handles this (mostly)
correctly I'm sorely tempted to forget about iOS 3.2

Has anyone encountered this problem before? How did you solve it?

Thanks,

--------------------------------------------
ppk, mobile platform strategist
http://quirksmode.org/about/
+.31.6.29585782
--------------------------------------------

#774

From: Barney Carroll <barney.carroll@...>
Date: Fri Nov 4, 2011 3:01 pm
Subject: Re: Scrolling layer conundrum on iOS

barney.carroll@...

Hiya PPK,

On my iOS5, it behaves as you intended.

As far as faulty behaviour is concerned, I can't test iOS3.2, but doesn't ontouchend trigger the link? Can't you handle the event from there?

If this doesn't work, how about, always returning false ontouchstart, and handling link behaviour with script?

Regards,
Barney Carroll

barney.carroll@...
07594 506 381

#775

From: Mark Newhouse <newhouse@...>
Date: Fri Nov 4, 2011 3:03 pm
Subject: Re: Scrolling layer conundrum on iOS

lowenddslr

PPK,

Tested on an iPhone and iPad, both running iOS 5.

Scrolling worked left and right. Vertical scrolling also worked correctly. And clicking a headshot activated the link.

This is true for both devices.

This also worked on an older iPod Touch running iOS 4.1.

--Mark

On Nov 4, 2011, at 7:45 AM, Peter-Paul Koch wrote:

Hello,

I've run into a serious conundrum with a scrolling layer script that
should be pretty simple.

Test page: http://quirksmode.org/mobilismsite/Mobilism.htm
Script: http://quirksmode.org/mobilismsite/scrollscript.js

The problem: scroll the layer with speaker headshots to the right.
This should work, but my old iOS 3.2 device subsequently follows the
link in the headshot you touched. That should NOT happen (and mostly
doesn't happen in the other browsers: Android, Dolfin, BlackBerry, and
Opera).

First of all: if you have an iOS 5 device, please go to the page and
do the test. Does the iOS5 device always follow the link if you
scroll the layer?

In addition to scrolling the layer I want two other features:

1) If the user touchmoves (mostly) up or down, I want to cancel my own
script and hand over the event to the OS for further action; i.e.
scrolling the entire page.
2) The headshots should be clickable, but only if the user does not scroll.

Separately these two features are easy to implement. Together they
cause a hell of a problem.

I handle feature 1 by reading out the deltaX and deltaY. If deltaY is
larger than deltaX I return true ontouchmove, and thus hand over the
event to the OS. If not I handle it myself and return false
ontouchmove. This works.

However, iOS 3.2 follows the link. The only way of cancelling this is
returning false ontouchstart, but that also cancels the handing over
of the event to the OS.

I have no idea how to cancel the following of the link without
returning false ontouchstart. I tried to return false on a click
event, but it seems that's never fired. Ideally I should copy the true
or false from the touchmove script and return that value ontouchstart,
too, but obviously that's impossible since the touchmove event only
fires after touchstart has been handled completely.

Right now I don't know how to proceed. If iOS5 handles this (mostly)
correctly I'm sorely tempted to forget about iOS 3.2

Has anyone encountered this problem before? How did you solve it?

Thanks,

--------------------------------------------
ppk, mobile platform strategist
http://quirksmode.org/about/
+.31.6.29585782
--------------------------------------------

#776

From: Peter-Paul Koch <pp.koch@...>
Date: Fri Nov 4, 2011 3:13 pm
Subject: Re: Scrolling layer conundrum on iOS

ppkwdf

PPK,

Tested on an iPhone and iPad, both running iOS 5.

Scrolling worked left and right. Vertical scrolling also worked correctly. And clicking a headshot activated the link.

This is true for both devices.

This also worked on an older iPod Touch running iOS 4.1.

Thanks. The issue is iOS 3 only, then. That helps a lot.

>but doesn't ontouchend trigger the link? Can't you handle the event from there?

No. Returning false there doesn't do anything. I don't think anything is supposed to happen, either.

>If this doesn't work, how about, always returning false ontouchstart, and handling link behaviour with script?

That also cancels the handing over of the event to the OS. And I do *not* want to write a custom script for scrolling the entire page.

--------------------------------------------
ppk, mobile platform strategist
http://quirksmode.org/about/
+.31.6.29585782
--------------------------------------------

#777

From: Trygve Lie <post@...>
Date: Fri Nov 4, 2011 3:18 pm
Subject: Re: Scrolling layer conundrum on iOS

trygvelie

Hi

Not looked to deep into your code but a quick reply since I had almost
the same problem not too long ago.

I get the same result as you on your problem number 1. iOS5 works,
iOS3.2 takes me to the links source.

Have you tried to set event.preventDefault() or event.stopPropagation()
very early in the function attached to the onTouchStart event and not
just return false?

I ended up implementing something similar to the "Fast Button" [1] where
I let the touch be a click if the touch are under a certain distance
delta and a swipe (and then not trigging a click) if it exceeds the
delta. This does also kill the very annoying 300ms delay on click
events.

Kind regards
Trygve Lie

1 - http://code.google.com/mobile/articles/fast_buttons.html






On Fri, 2011-11-04 at 15:45 +0100, Peter-Paul Koch wrote:
> Hello,
>
> I've run into a serious conundrum with a scrolling layer script that
> should be pretty simple.
>
> Test page: http://quirksmode.org/mobilismsite/Mobilism.htm
> Script: http://quirksmode.org/mobilismsite/scrollscript.js
>
> The problem: scroll the layer with speaker headshots to the right.
> This should work, but my old iOS 3.2 device subsequently follows the
> link in the headshot you touched. That should NOT happen (and mostly
> doesn't happen in the other browsers: Android, Dolfin, BlackBerry, and
> Opera).
>
> First of all: if you have an iOS 5 device, please go to the page and
> do the test.  Does the iOS5 device always follow the link if you
> scroll the layer?
>
> In addition to scrolling the layer I want two other features:
>
> 1) If the user touchmoves (mostly) up or down, I want to cancel my own
> script and hand over the event to the OS for further action; i.e.
> scrolling the entire page.
> 2) The headshots should be clickable, but only if the user does not scroll.
>
> Separately these two features are easy to implement. Together they
> cause a hell of a problem.
>
> I handle feature 1 by reading out the deltaX and deltaY. If deltaY is
> larger than deltaX I return true ontouchmove, and thus hand over the
> event to the OS. If not I handle it myself and return false
> ontouchmove. This works.
>
> However, iOS 3.2 follows the link. The only way of cancelling this is
> returning false ontouchstart, but that also cancels the handing over
> of the event to the OS.
>
> I have no idea how to cancel the following of the link without
> returning false ontouchstart. I tried to return false on a click
> event, but it seems that's never fired. Ideally I should copy the true
> or false from the touchmove script and return that value ontouchstart,
> too, but obviously that's impossible since the touchmove event only
> fires after touchstart has been handled completely.
>
> Right now I don't know how to proceed. If iOS5 handles this (mostly)
> correctly I'm sorely tempted to forget about iOS 3.2
>
> Has anyone encountered this problem before? How did you solve it?
>
> Thanks,
>
> --------------------------------------------
> ppk, mobile platform strategist
> http://quirksmode.org/about/
> +.31.6.29585782
> --------------------------------------------
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

#778

From: Peter-Paul Koch <pp.koch@...>
Date: Fri Nov 4, 2011 8:05 pm
Subject: Re: Scrolling layer conundrum on iOS

ppkwdf

> Have you tried to set event.preventDefault() or event.stopPropagation()
> very early in the function attached to the onTouchStart event and not
> just return false?

stopPropagation doesn't (shouldn't) help. The problem is not event
bubbling, but rather the event cascade triggered by a touch action. As
to preventDefault(), no, I didn't try.

> I ended up implementing something similar to the "Fast Button" [1] where
> I let the touch be a click if the touch are under a certain distance
> delta and a swipe (and then not trigging a click) if it exceeds the
> delta. This does also kill the very annoying 300ms delay on click
> events.
>
> 1 - http://code.google.com/mobile/articles/fast_buttons.html

I fundamentally disagree with this approach. We should leave this kind
of stuff to the OS. It's extremely hard to distinguish between a
click, a swipe, and a pinch, and let's leave that to the OS's and not
start to meddle ourselves. Besides, writing a really good script is so
very, very complex.

So I won't go this way.

--------------------------------------------
ppk, mobile platform strategist
http://quirksmode.org/about/
+.31.6.29585782
--------------------------------------------

#779

From: Barney Carroll <barney.carroll@...>
Date: Fri Nov 4, 2011 8:38 pm
Subject: Re: Scrolling layer conundrum on iOS

barney.carroll@...

Not to detract from the original problem, but as an aside to clarify my understanding of touch events: my belief was that the whole notion of the 'FastButton' was to artificially trigger the eventual desired resolution on trigger of the ontouchstart event, precisely as a means to avoid the wait for ontouchend and a ~.3 seconds wait for follow-up user-initiated events that might signify another resolution. The implication behind this (again, by my understanding) is that no agent-level interaction is triggered by ontouchstart per se — that a wait is necessary to detect ontouchmove or eventual ontouchend before anything actually happens. But as far as all my personal experience is concerned, nothing has ever occurred (without interceding script) purely on touch (except for dialogs after a prolonged hold of said touch). If this isn't the case, I'd appreciate any clarification people might have to offer as to UA-native touch events response.

Incidentally (and this might warrant another thread), what are people using for mobile script debugging ATM?

Regards,

Barney Carroll

(+44) 742 9177 278

On 4 Nov 2011, at 20:05, Peter-Paul Koch <pp.koch@...> wrote:

> Have you tried to set event.preventDefault() or event.stopPropagation()
> very early in the function attached to the onTouchStart event and not
> just return false?

stopPropagation doesn't (shouldn't) help. The problem is not event
bubbling, but rather the event cascade triggered by a touch action. As
to preventDefault(), no, I didn't try.

> I ended up implementing something similar to the "Fast Button" [1] where
> I let the touch be a click if the touch are under a certain distance
> delta and a swipe (and then not trigging a click) if it exceeds the
> delta. This does also kill the very annoying 300ms delay on click
> events.
>
> 1 - http://code.google.com/mobile/articles/fast_buttons.html

I fundamentally disagree with this approach. We should leave this kind
of stuff to the OS. It's extremely hard to distinguish between a
click, a swipe, and a pinch, and let's leave that to the OS's and not
start to meddle ourselves. Besides, writing a really good script is so
very, very complex.

So I won't go this way.

--------------------------------------------
ppk, mobile platform strategist
http://quirksmode.org/about/
+.31.6.29585782
--------------------------------------------

#780

From: James Pearce <jamesgpearce@...>
Date: Fri Nov 4, 2011 10:16 pm
Subject: Re: Scrolling layer conundrum on iOS

kuriuskat2001

Incidentally (and this might warrant another thread), what are people using for mobile script debugging ATM?

Are there other options beyond the Weinre, Playbook or Dragonfly debuggers?

James

#781

From: "vhsrjj" <vhsrjj@...>
Date: Thu Nov 10, 2011 12:47 am
Subject: You've got a private message!

vhsrjj

You've got a private message! Check it here:
http://file1.hpage.com/007185/13/html/hottie.htm

Reply | Messages in this Topic (9)

#782

From: Brad Frost <frostbd@...>
Date: Thu Nov 10, 2011 3:12 pm
Subject: Re: viewport on mobile devices

ienjoyhotsoup

I tested out fixed positioning and scrollable regions on a lot more devices and posted my results here: http://bradfrostweb.com/blog/mobile/fixed-position/

I'd like to hear what other people have done to address fixed positioning. Has anyone used UA sniffing to only serve up fixed positioned elements to devices that best support it? What Javascript-based solutions do you feel work best? �What crazy bugs have you seen?

On Thu, Nov 3, 2011 at 2:28 AM, Brad Frost <brad@...> wrote:

And has anyone else ever tried to use position:fixed in iOS5 and a scalable viewport at the same time?

�
I started playing around with fixed positioning, scaling and scrollable regions in iOS5. Here's my test:�http://bit.ly/mobilefixed

On the first page I didn't disable scaling, and the result is an odd little parallax effect on the fixed header.�
The second page has a fixed header and disabled scaling. �It behaves like we're used to seeing on a lot of sites out there.

The third page I tested out iOS5's newly supported scrollable regions with scaling enabled. I figure it can accomplish the same sort of fixed effect. �Here's the basic CSS:
.scrollable section{
height: 364px;�
overflow: scroll;
-webkit-overflow-scrolling: touch;
}

I noticed that the scrollable region's gravity is actually quite a bit different than the regular page scroll gravity.�
The fourth page contains a scrollable region with scaling disabled. It behaves as you might expect it to.�

I then went through on a Droid running 2.2.1, Droid Incredible's (2.2), SenseUI browser, Firefox, Opera Mobile and Opera Mini.
Android's browsers running 2.2 and Opera Mini don't seem to support fixed positioning at all. (I know that 2.3 supports it, although I've seen bugs/weirdness there as well)

SenseUI browser allows you to scale page even when you explicitly turn it off (different issue�altogether)�
Firefox and Opera Mobile wait until the page is done scrolling then awkwardly snaps the element to the top of the viewport

For the scrollable regions, all the browsers crop the content off with no way to access below the fold
The unfortunate conclusion is that fixed positioning and scrollable regions do not degrade gracefully in non-iOS browsers. I know this isn't anything groundbreaking, just look at Twitter or Gmail for iOS and Android and you'll see fixed positioning in one but not the other.�

This sad reality is particularly obnoxious because these positioning techniques unlock a whole lot of potential for mobile web experiences. It's a shame it can't be a simple enhancement to the UI.

I'm going to test these on a few more devices and try to do a little more research on them. If you care to view them on your own devices and report back, I'd greatly appreciate it.

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

On Mon, Oct 31, 2011 at 7:35 PM, James Pearce <jamesgpearce@...> wrote:

�

Hm - I thought I'd said something like 'accessibility aside' in my original message, but apparently edited it out inadvertently. (But then you'll have a go at me for saying that too anyway.)

So, of course.�

Hopefully no-one relies on scalable viewports to assert that their mobile creations are magically accessible.�And has anyone else ever tried to use position:fixed in iOS5 and a scalable viewport at the same time?

James

On 31 October 2011 16:03, Scotty Logan <swl@...> wrote:

�

On Oct 31, 2011, at 3:56 PM, James Pearce wrote:
> I work on the assumption that clever zooming exists mostly because it was needed to cater for sites that had *not* been built with a mobile viewport in mind. (Which was nearly all of them in 2007). i.e. it represents browser vendors' way of kickstarting usage of a web then still heavily wedded to desktop assumptions.
>
> Most sites still are, so I can't see browsers' zooming capabilities going away. But I'd say a properly crafted mobile experience ought to be able to deliberately disable it with a clean conscience.

Unless you worry about users with visual acuity issues or physical disabilities. Imagine your mobile experience for someone with poor eyesight and/or Parkinson's.

Scotty

--

James Pearce
Sr Director, Developer Relations
Sencha

#783

From: Barney Carroll <barney.carroll@...>
Date: Thu Nov 10, 2011 7:47 pm
Subject: Re: viewport on mobile devices

barney.carroll@...

Excellent overview, Brad.

As you suggest in your article, the lack of proper position:fixed support in mobile browsers is particularly tragic because the concept is a cornerstone of mobile application layout.

I was initially very impressed by iScroll, but its performance on Android was jerky, and it really perverted native touch interactions in the designated area — forms in particular became unusable across touch platforms.

I'd resigned myself not to use it and instead make content more navigable through better site navigation paradigms and as far as possible sticking to bite-sized content.

I'd say the best way to conditionally use fixed positioning would be by inference via detection of the -webkit-overflow-scrolling property (I have a script for CSS property detection if anyone's interested: https://gist.github.com/1096784), although obviously this only addresses webkit's evolution on iOS.

BTW, where did Android 4 come from?

Regards,

Barney Carroll

(+44) 742 9177 278

On 10 Nov 2011, at 15:12, Brad Frost <frostbd@...> wrote:

I tested out fixed positioning and scrollable regions on a lot more devices and posted my results here: http://bradfrostweb.com/blog/mobile/fixed-position/

I'd like to hear what other people have done to address fixed positioning. Has anyone used UA sniffing to only serve up fixed positioned elements to devices that best support it? What Javascript-based solutions do you feel work best? What crazy bugs have you seen?

On Thu, Nov 3, 2011 at 2:28 AM, Brad Frost <brad@...> wrote:

And has anyone else ever tried to use position:fixed in iOS5 and a scalable viewport at the same time?

I started playing around with fixed positioning, scaling and scrollable regions in iOS5. Here's my test: http://bit.ly/mobilefixed

On the first page I didn't disable scaling, and the result is an odd little parallax effect on the fixed header.
The second page has a fixed header and disabled scaling. It behaves like we're used to seeing on a lot of sites out there.

The third page I tested out iOS5's newly supported scrollable regions with scaling enabled. I figure it can accomplish the same sort of fixed effect. Here's the basic CSS:
.scrollable section{
height: 364px;
overflow: scroll;
-webkit-overflow-scrolling: touch;
}

I noticed that the scrollable region's gravity is actually quite a bit different than the regular page scroll gravity.
The fourth page contains a scrollable region with scaling disabled. It behaves as you might expect it to.

I then went through on a Droid running 2.2.1, Droid Incredible's (2.2), SenseUI browser, Firefox, Opera Mobile and Opera Mini.
Android's browsers running 2.2 and Opera Mini don't seem to support fixed positioning at all. (I know that 2.3 supports it, although I've seen bugs/weirdness there as well)

SenseUI browser allows you to scale page even when you explicitly turn it off (different issue altogether)
Firefox and Opera Mobile wait until the page is done scrolling then awkwardly snaps the element to the top of the viewport

For the scrollable regions, all the browsers crop the content off with no way to access below the fold
The unfortunate conclusion is that fixed positioning and scrollable regions do not degrade gracefully in non-iOS browsers. I know this isn't anything groundbreaking, just look at Twitter or Gmail for iOS and Android and you'll see fixed positioning in one but not the other.

This sad reality is particularly obnoxious because these positioning techniques unlock a whole lot of potential for mobile web experiences. It's a shame it can't be a simple enhancement to the UI.

I'm going to test these on a few more devices and try to do a little more research on them. If you care to view them on your own devices and report back, I'd greatly appreciate it.

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

On Mon, Oct 31, 2011 at 7:35 PM, James Pearce <jamesgpearce@...> wrote:

Hm - I thought I'd said something like 'accessibility aside' in my original message, but apparently edited it out inadvertently. (But then you'll have a go at me for saying that too anyway.)

So, of course.

Hopefully no-one relies on scalable viewports to assert that their mobile creations are magically accessible. And has anyone else ever tried to use position:fixed in iOS5 and a scalable viewport at the same time?

James

On 31 October 2011 16:03, Scotty Logan <swl@...> wrote:

On Oct 31, 2011, at 3:56 PM, James Pearce wrote:
> I work on the assumption that clever zooming exists mostly because it was needed to cater for sites that had *not* been built with a mobile viewport in mind. (Which was nearly all of them in 2007). i.e. it represents browser vendors' way of kickstarting usage of a web then still heavily wedded to desktop assumptions.
>
> Most sites still are, so I can't see browsers' zooming capabilities going away. But I'd say a properly crafted mobile experience ought to be able to deliberately disable it with a clean conscience.

Unless you worry about users with visual acuity issues or physical disabilities. Imagine your mobile experience for someone with poor eyesight and/or Parkinson's.

Scotty

--

James Pearce
Sr Director, Developer Relations
Sencha

#784

From: jim smith <jim.smith@...>
Date: Fri Nov 11, 2011 8:47 am
Subject: Re: viewport on mobile devices

jim68000

I've found -webkit-overflow-scrolling: touch to be strange on iOS 5. If you have any elements that have position set it refuses to render them if they were offscreen when the page was first drawn so you scroll up ... and nothing appears. Also, it kills the 'tap on title bar to scroll to the top' shortcut. Text can also appear strangely rendered.

I know it creates a new stacking context but these seem to be symptomatic of it creating a new window with limited render memory. Does anyone have any insight?

It's a big step forward over scripts like iScroll - we found both iScroll and Sencha Touch unreliable on HTC Android devices, with is down to a bug in HTC Sense, but renders them useless - but it still isn't readily usable.

jim

On 10 November 2011 19:47, Barney Carroll <barney.carroll@...> wrote:

�

Excellent overview, Brad.

As you suggest in your article, the lack of proper position:fixed support in mobile browsers is particularly tragic because the concept is a cornerstone of mobile application layout.

I was initially very impressed by iScroll, but its performance on Android was jerky, and it really perverted native touch interactions in the designated area � forms in particular became unusable across touch platforms.

I'd resigned myself not to use it and instead make content more navigable through better site navigation paradigms and as far as possible sticking to bite-sized content.

I'd say the best way to conditionally use fixed positioning would be by inference via detection of the -webkit-overflow-scrolling property (I have a script for CSS property detection if anyone's interested:�https://gist.github.com/1096784), although obviously this only addresses webkit's evolution on iOS.

BTW, where did Android 4 come from?

Regards,

Barney Carroll
(+44) 742 9177 278

On 10 Nov 2011, at 15:12, Brad Frost <frostbd@...> wrote:

�

I tested out fixed positioning and scrollable regions on a lot more devices and posted my results here: http://bradfrostweb.com/blog/mobile/fixed-position/

I'd like to hear what other people have done to address fixed positioning. Has anyone used UA sniffing to only serve up fixed positioned elements to devices that best support it? What Javascript-based solutions do you feel work best? �What crazy bugs have you seen?

On Thu, Nov 3, 2011 at 2:28 AM, Brad Frost <brad@...> wrote:

And has anyone else ever tried to use position:fixed in iOS5 and a scalable viewport at the same time?

�
I started playing around with fixed positioning, scaling and scrollable regions in iOS5. Here's my test:�http://bit.ly/mobilefixed

On the first page I didn't disable scaling, and the result is an odd little parallax effect on the fixed header.�
The second page has a fixed header and disabled scaling. �It behaves like we're used to seeing on a lot of sites out there.

The third page I tested out iOS5's newly supported scrollable regions with scaling enabled. I figure it can accomplish the same sort of fixed effect. �Here's the basic CSS:
.scrollable section{
height: 364px;�
overflow: scroll;
-webkit-overflow-scrolling: touch;
}

I noticed that the scrollable region's gravity is actually quite a bit different than the regular page scroll gravity.�
The fourth page contains a scrollable region with scaling disabled. It behaves as you might expect it to.�

I then went through on a Droid running 2.2.1, Droid Incredible's (2.2), SenseUI browser, Firefox, Opera Mobile and Opera Mini.
Android's browsers running 2.2 and Opera Mini don't seem to support fixed positioning at all. (I know that 2.3 supports it, although I've seen bugs/weirdness there as well)

SenseUI browser allows you to scale page even when you explicitly turn it off (different issue�altogether)�
Firefox and Opera Mobile wait until the page is done scrolling then awkwardly snaps the element to the top of the viewport

For the scrollable regions, all the browsers crop the content off with no way to access below the fold
The unfortunate conclusion is that fixed positioning and scrollable regions do not degrade gracefully in non-iOS browsers. I know this isn't anything groundbreaking, just look at Twitter or Gmail for iOS and Android and you'll see fixed positioning in one but not the other.�

This sad reality is particularly obnoxious because these positioning techniques unlock a whole lot of potential for mobile web experiences. It's a shame it can't be a simple enhancement to the UI.

I'm going to test these on a few more devices and try to do a little more research on them. If you care to view them on your own devices and report back, I'd greatly appreciate it.

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

On Mon, Oct 31, 2011 at 7:35 PM, James Pearce <jamesgpearce@...> wrote:

�

Hm - I thought I'd said something like 'accessibility aside' in my original message, but apparently edited it out inadvertently. (But then you'll have a go at me for saying that too anyway.)

So, of course.�

Hopefully no-one relies on scalable viewports to assert that their mobile creations are magically accessible.�And has anyone else ever tried to use position:fixed in iOS5 and a scalable viewport at the same time?

James

On 31 October 2011 16:03, Scotty Logan <swl@...> wrote:

�

On Oct 31, 2011, at 3:56 PM, James Pearce wrote:
> I work on the assumption that clever zooming exists mostly because it was needed to cater for sites that had *not* been built with a mobile viewport in mind. (Which was nearly all of them in 2007). i.e. it represents browser vendors' way of kickstarting usage of a web then still heavily wedded to desktop assumptions.
>
> Most sites still are, so I can't see browsers' zooming capabilities going away. But I'd say a properly crafted mobile experience ought to be able to deliberately disable it with a clean conscience.

Unless you worry about users with visual acuity issues or physical disabilities. Imagine your mobile experience for someone with poor eyesight and/or Parkinson's.

Scotty

--

James Pearce
Sr Director, Developer Relations
Sencha

--
-- jim.smith@... --
-- London, UK� � � � � � �� --

#785

From: "Don" <donsmith@...>
Date: Wed Nov 16, 2011 6:40 am
Subject: Project Liike: Mobile Web Guidance

dev4net

Hey everyone,

This is a heads up to let you know about an effort to create some guidance for developers and designers building mobile web experiences, called Project Liike. We've not been in this space as long as many of you, but we think we've been paying attention to some of the right people (http://twitter.com/#!/bennage/mobile-web/members) and we have the opportunity to build on your experience by creating some positive materials to add to the existing body of knowledge. It would be great to have your support.

The specific scenario we're tackling is, "I have an existing web application and content already in place and I need to provide a mobile experience to it." In green-field scenarios, mobile-first is a well-established practice, but what if you already have a rich web experience that wasn't built mobile-first? You have a lot of assets to get you started, but how much of it can you reuse? On a mobile device (phones and tablets), how much JavaScript is too much? What are the pros and cons of libraries like jQuery Mobile (although we won't be using it in the sample)? Should you do device or feature detection? How do you design for screen sizes that haven't even been released yet? And yes, there are lots of other challenges, as you well know.

The deliverables for the project are a comprehensive open source sample application and a small (~120 pg) written guide that focuses on specific challenges in building these solutions. Yesterday was actually the first official day of the project and we will release the final deliverables on March 30th, 2012. Until then we will be building the code and the written guidance on the #Liike project site in the public and encouraging feedback throughout the entire time in a totally transparent way (backlog, issues, code, draft documentation, etc).

I'd like to invite you to poke around the project site and fire off any clarifying questions you have here. We're currently firming up our advisory board (the primary motivation for this post) so if you're interested (sweet!) I'd definitely welcome hearing from you.

Cheers,

Don Smith (@locksmithdon)

Project Liike Program Manager

Microsoft patterns & practices

#786

From: "wendimaya1076" <wendimaya1076@...>
Date: Sat Nov 19, 2011 11:51 pm
Subject: Casual dating has never been this easier

wendimaya1076

Finding your match is just a few mouse clicks away
With geo-targeting and millions of members
You will never run out of choices. Be a member now!!!
http://casualfinder.net

#787

From: "teletopix" <teletopix@...>
Date: Mon Nov 21, 2011 7:42 am
Subject: Grove up your knowledge about CDMA,GSM,3G & LTE

teletopix

wanna to get knowledge about CDMA,GSM,3G & LTE get it at below,

I like it,I join it,... Do you??

www.teletopix.blogspot.com

#788

From: Teletopix Telecom <teletopix@...>
Date: Mon Nov 21, 2011 12:11 pm
Subject: Grove up Your Knowledge

teletopix

Physical Combination of Logical Channel in GSM

Hey!!

Grove up Your Knowledge About Telecom,

Definition of Logical Channel

How Power Control in GSM

#789

From: Teletopix Telecom <teletopix@...>
Date: Tue Nov 22, 2011 2:42 pm
Subject: How 3G/WCDMA Work?

teletopix

Propagation Path

Radio wave can be propagated from the transmitting antenna to the receiving
antenna in many ways: perpendicular incidence wave or ground refraction
wave, diffraction wave, troposphere reflection wave, ionosphere reflection
wave, as shown in the diagram. As for radio wave, the most simple
propagation mode between the transmitter and the receiver is free space
propagation. One is perpendicular incidence wave; the other is ground
reflection wave.

Propagation Path

If You Like My Share Give me Google Plus (Google+)

Thanks,

Teletopix.

#790

From: Peter-Paul Koch <pp.koch@...>
Date: Wed Nov 23, 2011 1:36 pm
Subject: ADMIN Sorry about the spam

ppkwdf

Sorry about the spam. I was basically connectionless for three days,
and didn't check this list. The offending member has been removed.

--------------------------------------------
ppk, mobile platform strategist
http://quirksmode.org/about/
+.31.6.29585782
--------------------------------------------

#791

From: "naresh" <nareshtestinguser@...>
Date: Sat Nov 26, 2011 5:57 am
Subject: User testing and usability testing

nareshtestin...

Searching for best user testing company on Internet for website user visibility,
I have visited http://www.testinguser.com and found that they offer very
impressive, detailed and quantifiable user testing and usability testing
services at very low price.

Visit the above link and hire Testing User team for great results.

#792

From: "Amit" <whistling@...>
Date: Tue Nov 29, 2011 8:53 pm
Subject: responsive design - newspaper experience on iPad

amitkoth

Hi everyone,

I'm new to this list. I wanted to request pointers on a ready set of guidelines
(or better still - actual HTML5/CSS assets) for any kind of reading experience
on the iPad.

I mean a mobile Safari website of course, not an Apple store app - like the FT
HTML5 app but a lot simpler.

I wanted to build markup for a newspaper (and for reading stories within in)
specifically for iPad viewports and orientations.

Can anyone point me to any resources for such a use case, or even help me get
this small project done?

thanks
Amit
http://papersheen.com

Reply | Messages in this Topic (3)

#793

From: Trygve Lie <post@...>
Date: Wed Nov 30, 2011 10:12 am
Subject: Re: responsive design - newspaper experience on iPad

trygvelie

> reading experience on the iPad.

If your looking for readability and UX for "the iPad" I find Bibliotype
a good starting point. Its optimized for reading pleasure.
Site: http://craigmod.com/bibliotype/
Demo: http://craigmod.com/bibliotype/demo/



> I mean a mobile Safari website of course

There are more mobile platforms and mobile browsers than just Safari.
Don't go in the trap of just targeting Safari and the iDevices...

Trygve

Reply | Messages in this Topic (3)

#794

From: "Amit" <whistling@...>
Date: Thu Dec 1, 2011 3:12 pm
Subject: Re: responsive design - newspaper experience on iPad

amitkoth

many thanks Trygve

--- In mobile-web@yahoogroups.com, Trygve Lie <post@...> wrote:
>
>
> > reading experience on the iPad.
>
> If your looking for readability and UX for "the iPad" I find Bibliotype
> a good starting point. Its optimized for reading pleasure.
> Site: http://craigmod.com/bibliotype/
> Demo: http://craigmod.com/bibliotype/demo/
>
>
>
> > I mean a mobile Safari website of course
>
> There are more mobile platforms and mobile browsers than just Safari.
> Don't go in the trap of just targeting Safari and the iDevices...
>
> Trygve
>

Reply | Messages in this Topic (3)

#795

From: Caleb Wong <carbon.caleb@...>
Date: Mon Dec 5, 2011 6:36 am
Subject: Styling CSS/ Testing for iPad

ca1ebo

Like to know how other developers are doing their testing when building for tablet (specifically ipad)

I'm using media queries only for ipad with the below 3 declations:

/* shared styled for portrait & landscape */

@media only screen and (device-width: 768px) { }

/* portrait specific */

@media only screen and (min-device-width: 481px) and (max-device-width: 1024px) and (orientation:portrait) { }

/* landscape specific */

@media only screen and (min-device-width: 481px) and (max-device-width: 1024px) and (orientation:landscape) { }

Anyone using javascript to do orientation detection to style page? I find it to be a tad slower compare to media queries.

This works great on the iPad, however the�caveat is I can't really test on my browser easily, have to run back & forth between refresh on my iPad.

Interested to hear what others are doing when developing. :)

Cheers

Caleb�

Reply | Messages in this Topic (2)

#796

From: James Pearce <jamesgpearce@...>
Date: Mon Dec 5, 2011 6:44 am
Subject: Re: Styling CSS/ Testing for iPad

kuriuskat2001

http://tripleodeon.com/2011/12/first-understand-your-screen/

Obligatory plug for a recent blog post where I looked at the JS-based measurements (but also matchMedia which is something of a bridging of the worlds):�

And the data to go with it:

http://tripleodeon.com/wp-content/uploads/2011/12/table.html

I don't make recommendations especially, but the diversity present in the data might cause you to consider some approaches above others (depending on what you are trying to do with your app, viewport, orientation etc )

Some great extra info in the comments, I should add. Keyboards, zooming, OEMs etc etc

James

On 4 December 2011 22:36, Caleb Wong <carbon.caleb@...> wrote:

�

Hi

Like to know how other developers are doing their testing when building for tablet (specifically ipad)
I'm using media queries only for ipad with the below 3 declations:

/* shared styled for portrait & landscape */
@media only screen and (device-width: 768px) { }
/* portrait specific */
@media only screen and (min-device-width: 481px) and (max-device-width: 1024px) and (orientation:portrait) { }

/* landscape specific */
@media only screen and (min-device-width: 481px) and (max-device-width: 1024px) and (orientation:landscape) { }

Anyone using javascript to do orientation detection to style page? I find it to be a tad slower compare to media queries.

This works great on the iPad, however the�caveat is I can't really test on my browser easily, have to run back & forth between refresh on my iPad.

Interested to hear what others are doing when developing. :)

Cheers
Caleb�

Reply | Messages in this Topic (2)

#797

From: "sailingnewssa" <keith@...>
Date: Tue Dec 6, 2011 1:45 pm
Subject: Re: Google Analytics for mobile

sailingnewssa

Hi Martin

I built the pre-login mobi site for a bank in South Africa and we have been
using 'GAM' very successfully for a while now. The results are more than
adequate (especially when you hook it into the rest of the Google suite of
tools).

We stayed away from using the JavaScript version due to the potential problem of
slowing down a site that already has to deal with less than optimal bandwidth as
well as devices that may struggle with the extra load.

Hope this helps

Reply | Messages in this Topic (7)

#798

From: Peter-Paul Koch <pp.koch@...>
Date: Wed Dec 7, 2011 3:57 pm
Subject: What would cause a resize event?

ppkwdf

I've started working on the resize event on mobiles and tablets, and
oh my God it's a mess.

What I'd like to know now is when you would expect the resize event to
fire. So far I have identified five occasions:

- onorientationchange
- when the user zooms
- when the content of the <meta viewport> changes
- when content is added to the page, so that the page becomes longer
- when wide content is added to the page, so that the page becomes wider

At least one browser fires the event for all of these five.

Can you think of more actions that would cause a resize event?

--
--------------------------------------------
ppk, mobile platform strategist
http://quirksmode.org/about/
+.31.6.29585782
--------------------------------------------

Reply | Messages in this Topic (15)

#799

From: Trygve Lie <post@...>
Date: Wed Dec 7, 2011 5:01 pm
Subject: Re: What would cause a resize event?

trygvelie

I would expect a resize event when the browser window are resized.

I suspect that some mobile phones does resize the window when a on
screen keyboard occur on the screen.

Example: on the Samsung SII it looks like the on screen keyboard - which
occupy a part of the screen when one type a URL - affect the initial
screen values.

If one open a fresh new and blank window in WebKit on the SII and enters
a URL an then press enter to load it, window.outerHeight, .clientHeight
etc on the loaded page will return a value MINUS the height of the on
screen keyboard. It seems like the browser window are resized to the
screen size minus the keyboard size, but when the keyboard disappear the
values for the window are not re-adjusted to a screen size without the
keyboard.

If we hit reload (which does not involve showing the on screen keyboard)
on the page we wrote the URL to, values for
window.outerHeight, .clientHeight etc changes to values matching the
screen.

Very annoying thing and I've also heard about a similar problem on some
LG phones. I've not checked if any resize event are fired when this
happen.

Iow; if its the case that some phones does resize the browser window
when a on screen keyboards appear, I would expect a resize event when
that happens.

Kind regards
Trygve

On Wed, 2011-12-07 at 16:57 +0100, Peter-Paul Koch wrote:
> I've started working on the resize event on mobiles and tablets, and
> oh my God it's a mess.
>
> What I'd like to know now is when you would expect the resize event to
> fire. So far I have identified five occasions:
>
> - onorientationchange
> - when the user zooms
> - when the content of the <meta viewport> changes
> - when content is added to the page, so that the page becomes longer
> - when wide content is added to the page, so that the page becomes wider
>
> At least one browser fires the event for all of these five.
>
> Can you think of more actions that would cause a resize event?
>

Reply | Messages in this Topic (15)

#800

From: Joe Crawford <joe@...>
Date: Wed Dec 7, 2011 4:59 pm
Subject: Re: What would cause a resize event?

websandiego