On Jan 7, 8:06 pm, birdofprey <[email protected]> wrote:
> On Jan 7, 2:05 pm, Roger <[email protected]> wrote:
>
> > Can't follow this. Quote properly, please.
>
> Well, I mentioned browser sniffing, and this context, I was asking
> about iPhones as an example, after which I would expand to what ever
> other mobile device that I could, through the Blackberry browser,
> Opera mini browser, Opera mobile browser, and so on. He asked why I
> was only targeting these devices, the iPhones. I'm clarifying that I
> was interested in general browser sniffing, starting with the iPhone
> as an example.
It is very simple to support browsers like Opera mini as they support
handheld style sheets (as did less capable browsers on a lot of older
phones.) Use proper semantics and avoid tables-in-tables layout and
you can rearrange your content into multiple columns (if need be) for
desktop browsers, while handheld devices see a single streamlined
column (perhaps hiding larger images, Flash movies, etc.)
Full-featured HTML browsers like the one in the iPhone will *not* use
the handheld style sheets, which is a good thing as they can typically
do anything that the desktop browsers can (just slightly smaller.)
Use a fluid layout and competently written scripts and your site
should work fine on present and future iPods, iPhones, etc. It won't
look exactly like the current native interface, but it is hard to see
that as a drawback!
>
> I have always made streamlining my sites with dial-up in mind. What
Good.
> I'm saying is that I don't deem even that to be enough for the mobile
> platform. There are also certain UI features, choices for types of
> form elements, and so on, that make sense on a desktop platform, but
Choices for types of form elements?
> not so much with the inputs and displays of mobile devices. Because
> of that, I find it necessary to create a slimmed down, separate mobile
> site with only what it needs.
What do you perceive is the problem with forms on mobile devices? It
is hard to think of a sweeping generalization for those.
>
> This does not mean maintaining content on two different sites, because
> this content in this case would be generated from the server, or
> perhaps from XML. Only the UI itself would be split.
Of course it would be generated by the server, but it is still two
very different sites to the user, testers, support staff and the
search engines.
>
> That's why I was asking about browser sniffing, which is currently one
> of the ways I intend to serve a separate UI (but shared content
> source) to a mobile device.
You are way off in the weeds with that strategy. It's been a decade
since it was even close to viable. Yes, lots of newcomers to Web
development fall into this trap. Hard to believe, but then look at the
state of most Websites.
The idea that you could sniff for the user agent on the server is
particularly ridiculous. Two words: proxy servers.
>
> In any case, what would have been a neutral response was to simply
> point out, "hi, browser sniffing actually isn't a good idea. here's
> how we would normally do it for x and y positive reasons.",
It isn't clear to me what you are doing exactly.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"iPhoneWebDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/iphonewebdev?hl=en
-~----------~----~----~----~------~----~------~--~---
