Right, but I already practice good semantics and fluid div layouts with separated presentation and content. It's great that mobile devices can handle full-fledged sites, but most of these use zoom to compensate for the small screens of these phones. This is not too bad if you can use pinch zoom gestures on iPhone Safari, but not so great if you have to zoom using, say, Opera Mini on a Blackberry Curve (from actually using both on a regular basis).
I used to serve fluid layout full sites to these devices, but recently, I noticed that many sites try to spare users the zooming trouble by browser sniffing or device sniffing, given that they can predict the viewports and set them accordingly. Is this the best practice? With the browser sniffing method, I now realize it's not ideal. But you see what I was getting at. It's a more common practice than people seem to think. http://apple.com/webapps http://mobileawesomeness.com http://cssiphone.com I actually just discovered an article that tries to address this beyond browser sniffing, and it's from one of my long time respected favorites, A List Apart: http://alistapart.com/articles/returnofthemobilestylesheet On Jan 7, 6:08 pm, "[email protected]" <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
