Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #21553 > unrolled thread

Re: fixed position sidebar and small screen/mobile devices?

Started byDavid Mark <dmark.cinsoft@gmail.com>
First post2011-02-11 12:46 -0800
Last post2011-02-11 15:22 -0800
Articles 3 — 2 participants

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: fixed position sidebar and small screen/mobile devices? David Mark <dmark.cinsoft@gmail.com> - 2011-02-11 12:46 -0800
    Re: fixed position sidebar and small screen/mobile devices? John Stumbles <john.stumbles@ntlworld.com> - 2011-02-11 23:06 +0000
      Re: fixed position sidebar and small screen/mobile devices? David Mark <dmark.cinsoft@gmail.com> - 2011-02-11 15:22 -0800

#21553 — Re: fixed position sidebar and small screen/mobile devices?

FromDavid Mark <dmark.cinsoft@gmail.com>
Date2011-02-11 12:46 -0800
SubjectRe: fixed position sidebar and small screen/mobile devices?
Message-ID<8b7de9fd-89d9-4789-a05c-7166df67d4da@v16g2000vbq.googlegroups.com>
On Feb 11, 11:23 am, John Stumbles <john.stumb...@ntlworld.com> wrote:
> On Fri, 11 Feb 2011 06:26:49 -0800, David Mark wrote:
> >> However on an Android (and possibly other mobile devices, or if one
> >> resizes a conventional desktop-based browser down to a small enough
> >> window) the user can't scroll away from the fixed elements to view the
> >> content.
>
> > Fixed elements or not, they should still be able to scroll the
> > document.  Some mobile devices (e.g. iPhone) show only a portion of
> > the viewport at a time though.
>
> > Perhaps you mean they can't scroll to see the entire vertical sidebar
> > (as the content is not large enough to permit scrolling)?
>
> I don't have a 'droid but someone with an HTC Hero tells me if he scrolls
> sideways to get to the content pane, after a second or so the sidebar
> repositions itself over it. If I resize a desktop-based browser window
> small enough the fixed side and top bars do get in the way so maybe that's
> what he's getting.

Probably.

>
> > You certainly can't browser sniff on the server.
>
> With PHP I can pick up the user agent e.g.
> <?php
>     if (preg_match("/Android/", $_SERVER["HTTP_USER_AGENT"],
>     $matches)) {
>         # do whatever
>     }
> ?>

But that tells you nothing.  Do all UA's (past and future) that send
the string "Android" have this same issue (assuming there is an issue
at all)?

>
> The HTTP_USER_AGENT for the problem unit is:
>
> Mozilla/5.0 (Linux; U; Android 2.1- update1; en-gb; HTC Hero Build/ERE27)
> AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17

See what I mean?  Where in there does it imply anything about fixed
positioning, viewport size, etc?

>
> > It would be OK, but it would be much better if you kept scripting out
> > of your layout.
>
> That's what I'd rather do. Thanks.

Media queries + handheld style sheets.  Use media="all" (not "screen")
for your initial styling and get the layout to the point where it is
working satisfactorily on desktop monitors (and size the window as
small and as large as you can).  Then add a sheet for
media="handheld", which will collapse columns, puncture floats, etc.
That covers the old devices (most of them anyway), which have
extremely small screens.  As mentioned, Opera has a simulator for this
(and some versions of their browsers have a View | Small Screen
command)  Then go read up on media queries as you will need to make
similar (usually less drastic) adjustments for newer devices, which
have larger screens (and higher resolution).

http://www.w3.org/TR/css3-mediaqueries/

I typically use max-device-width as the indicator, but test on the
desktop with max-width so that shrinking the window simulates a device
with a smaller screen.  I just can't stand repetitive testing on
phones (and have never had the need to do it).

Once all seems right, test it on as many devices as you can find to
make sure the desktop simulations translate properly to the small
screens.  Then you have a Web app that is usable almost anywhere (and
can be used as a faux native app as well).  And it won't fall apart in
the future as it won't be tied to bogus inferences based on arbitrary
UA strings.

[toc] | [next] | [standalone]


#21554

FromJohn Stumbles <john.stumbles@ntlworld.com>
Date2011-02-11 23:06 +0000
Message-ID<8rltn7FbvU3@mid.individual.net>
In reply to#21553
On Fri, 11 Feb 2011 12:46:38 -0800, David Mark wrote:

> On Feb 11, 11:23 am, John Stumbles <john.stumb...@ntlworld.com> wrote:

>> Mozilla/5.0 (Linux; U; Android 2.1- update1; en-gb; HTC Hero
>> Build/ERE27) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile
>> Safari/530.17
> 
> See what I mean?  Where in there does it imply anything about fixed
> positioning, viewport size, etc?

The 'HTC Hero' bit tells me it's got a titchy screen.
But I agree 110% that that's a kludge!

> Media queries + handheld style sheets.
...
> http://www.w3.org/TR/css3-mediaqueries/
...
Thanks! Will RTFM ...

-- 
John Stumbles

I'd give my right arm to be ambidextrous

[toc] | [prev] | [next] | [standalone]


#21559

FromDavid Mark <dmark.cinsoft@gmail.com>
Date2011-02-11 15:22 -0800
Message-ID<2a7d0bff-f41b-4990-9166-0ed6aad6a152@s41g2000vbw.googlegroups.com>
In reply to#21554
On Feb 11, 6:06 pm, John Stumbles <john.stumb...@ntlworld.com> wrote:
> On Fri, 11 Feb 2011 12:46:38 -0800, David Mark wrote:
> > On Feb 11, 11:23 am, John Stumbles <john.stumb...@ntlworld.com> wrote:
> >> Mozilla/5.0 (Linux; U; Android 2.1- update1; en-gb; HTC Hero
> >> Build/ERE27) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile
> >> Safari/530.17
>
> > See what I mean?  Where in there does it imply anything about fixed
> > positioning, viewport size, etc?
>
> The 'HTC Hero' bit tells me it's got a titchy screen.

At least one of them has a "titchy screen".  Hard to code to
specifications like that though.  And there's no guarantee it applies
to other browsers that send "HTC Hero" in their UA string.  Browser
sniffing is simply a losing strategy (and always has been).  Doing it
on the server side is even worse than client side as you may be
dealing with a proxy.

> But I agree 110% that that's a kludge!

And, as you mentioned, even if it could be made practical, it would be
a maintenance nightmare.

This stuff was figured out back in the late 90's.  The trouble is
that, even in 2011, there are still "authorities" out there clinging
to the dream of the UA string as some sort of magical browser DNA.
Many of the popular GP libraries and frameworks use it extensively,
including tangling it up with their styling.  So don't feel too bad.

>
> > Media queries + handheld style sheets.
> ...
> >http://www.w3.org/TR/css3-mediaqueries/
>
> ...
> Thanks! Will RTFM ...
>

Good idea.  The only thing you'll find about the UA string in W3C
recommendations is that it is arbitrary and optional.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.javascript


csiph-web