mcgrew's Journal: A suggestion to mobile browser makers and the W3C

There are an awful lot of pages on my web site, and I've been busy making them all "mobile-friendly". Most of them are little or no problem making them look good on all platforms, but there are three that are especially problematic.

I jumped this hurdle (well, sort of stumbled past it) by making two of each of the pages with a link to the mobile page from the index.

Ideally, I could just check to see if it was a phone or not and redirect phones to the mobile page, but there's no way to make this 100% successful*. Each brand of phone has a different user agent, there are a lot of installable phone browsers. On top of that, is it an Android phone or an Android tablet? With the minimum typeface size and viewport set, those pages are fine on the PC version but the phone version looks like crap.

Apple should have thought of this when they made the first iPhone, and Google should have thought of this when developing Android. The answer is simple, but it can only be implimented by browser makers and perhaps the W3C.

From the beginning of the World Wide Web, browsers looked for index.html, the default front page in any directory. This worked fine before smart phones, but no longer.

Phone browsers should look first for mobile.html, and if it exists display that, and display index.html if it isn't there. Tablets and computers would behave as they always have.

It doesn't have to be mobile.html, it could be any name as long as everyone agreed that it was the standard, like they did with index.html.

Maintaining a web site would be much easier if they did this. What do you guys think?

* A reader tipped me to the Apache Mobile Filter. It looks promising, especially since my host uses Apache. I'm looking into it.

Aaaaactually

[Qzukk]

The selection of index.html for URLs ending in "/" is handled server-side (that's how we can have index.php index.cfm, index.pl and so on).

Really, what was needed was for display-size to become a standardized request header so that the server can select a default based on the display size.

Not a great idea ...

[BarbaraHudson]

What about m.sitename.extension? That's frequently used as well, and means that html, php, perl, whatever can still be parsed properly by the server.

Re:

[mcgrew]

If you do that you have to double the used web space, and that can be expensive. I'm already almost at the upper limit for my site and will have to go to the next tier of hosting soon. As it is, only three of the well over a hundred pages on my site need a special mobile version, and I would imagine a lot of other folks are the same way.

Having it first look for m.sitename, falling back to mobile.html if it exists and m.sitename doesn't, then index.html if there are neither m.sitename or mobile.html might be

Re:

[BarbaraHudson]

No you don't. If your script looks at the headers, the same source file can determine which of the 3 is being requested, and include the appropriate css file. The rest of the includes (html, php, pl, whatever) can the same. Of course, if your site isn't able to parse scripts, then you'd have to do it via javascript, which is a pita.