iPad and this forum

[PenGun]

No, I'm almost sure it's the site checking the user agent provided by the iPad. I really wish sites that did this provided a way to switch back to the full version of the site. This happens a lot on the iPhone as well (but this site works ok on the iPhone).

Web server 101. Webservers take html requests and return appropriate content. That request will include the browser and it's preferred mode of content. Get the iPad's browser to request full pages and that solves your problem.

As I pointed out at the bottom of the page there are style choices including 'mobi' the one I assume you receive on you iPads and iPhones. You can change that there.

[PenGun]

My peeve with browsers is that they're (AFAIK) not 16:9 friendly. I'm tired of constantly scrolling up/down to see the complete page on my netbook, plus when rolling over a hypertext link you can't immediately see the URL because it's at the bottom of a (virtual) 4:3 screen that you have to scroll down to see.

~Joe

The problem is that 16x9 is not text friendly. It's wide and not too tall. I use a 4x5 screen for text, web etc and a 16x9 screen for video and games.

Works well.

[Francisco Disilvestro]

The IPAD has nothing to do. This is something that has to be solved in the website. Usually there is a software that checks what device request a page and it sends back the templates and content for that device. Previous to the IPAD, the common check was if the device used "Safari mobile". Now the software in the websites should be changed to check it the device is "safari mobile" and contains "ipad" in the string that identifies the browser.

[Larry Gebhardt]

Web server 101. Webservers take html requests and return appropriate content. That request will include the browser and it's preferred mode of content. Get the iPad's browser to request full pages and that solves your problem.

As I pointed out at the bottom of the page there are style choices including 'mobi' the one I assume you receive on you iPads and iPhones. You can change that there.

That is not quite right. The browser request specifies what types of data the browser can accept, as well as a user agent string to uniquely identify the browser version. It is up to the web server to determine what gets sent back to the browser based on the request headers. The site is currently thinking the iPad is a mobile browser so it is formatting the page as such. It is also leaving off the option to switch styles. Since the iPhone browser gets the full version I imagine that someone put a special rule into the vBulletin code to treat it as a regular browser. The same needs to be done for the iPad.

[Francisco Disilvestro]

Just some additional info to my previous post. Each device sends an user agent string that identifies itself.

The user agent string used by the iphone is:
"Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3"

The user agent string used by the ipad is:
"Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10"

Note that both have "Mobile" and "safari". An important difference is "Ipad" instead of "Iphone".

Most of the web sites just checked for the words "mobile" and "safari" to send the iphone version.

I think that in the case of this forum, maybe the vbulletin is doing this, so they are the ones to be contacted to change this.

Francisco

[PenGun]

I did say this would be fun.

[Sascha Welter]

Of course web programmers who still do browser ID matching in 2010 should be slapped repeatedly till they wake up. It might be convenient or tempting in the short run, it was all the rage 10 years ago. But it will always break at some point, most likely with the next browser (or gadget) version.

There are better ways, including letting the client more or less decide which content they want/need. For example this method.

[PenGun]

Of course web programmers who still do browser ID matching in 2010 should be slapped repeatedly till they wake up. It might be convenient or tempting in the short run, it was all the rage 10 years ago. But it will always break at some point, most likely with the next browser (or gadget) version.

There are better ways, including letting the client more or less decide which content they want/need. For example this method.

Interesting. So a 404 error is your method? I'm a bit slow it seems.

The client requests the server serves.

[PenGun]

Of course web programmers who still do browser ID matching in 2010 should be slapped repeatedly till they wake up. It might be convenient or tempting in the short run, it was all the rage 10 years ago. But it will always break at some point, most likely with the next browser (or gadget) version.

There are better ways, including letting the client more or less decide which content they want/need. For example this method.

Probably you meant this link:

http://www.bushidodesigns.net/blog/m...ut-user-agent/

Reminds me very much of the crap shoot workarounds needed to get IE, Netscape etc to render properly.

Indeed a similar steaming pile. So sweet to just laugh at it and not have to do it although css makes it quite a bit easier. My sympathies.

[Mike Anderson]

Of course web programmers who still do browser ID matching in 2010 should be slapped repeatedly till they wake up. It might be convenient or tempting in the short run, it was all the rage 10 years ago. But it will always break at some point, most likely with the next browser (or gadget) version.

There are better ways, including letting the client more or less decide which content they want/need. For example this method.

I don't know, sometimes the old fashioned way isn't so bad. There's a typo in your link, but if this

http://www.bushidodesigns.net/blog/m...ut-user-agent/

is what you're referring to that method, while elegant, seems limited. The fact that it worked on 85% of mobile devices at the time it was tested doesn't bode well for future ruggedness.

...Mike