Retrofit Your Web Pages For Wireless Compatibility

An anonymous reader writes "You probably don't want to maintain Web and wireless versions of the same site or take on the overhead of Extensible Markup Language (XML) transformations. This article shows you a more practical approach to wireless compatibility. With some well-designed XHTML, a bit of CSS, and the media attribute, you can do wonders. Create more flexible, Mobile device ready, Web pages with XHTML and CSS."

Comments

This makes me feel so old and so sad

[Simon Brooke]

If you weren't writing flexible web design ten years ago, you should have been. There's nothing new in it; and indeed, much of what is being suggested in this article is still bad old inflexible design, which will still break badly on devices which you did not expect.

never — never — use absolute (pixel) dimensions for anything other than images. You don't know how many pixels wide the screen you're addressing is. The browser at the far end does, though, and if you get out of its way and let it do it's job intelligently, it will.

Re:This makes me feel so old and so sad

[TheRaven64]

Why should you specify pixel dimensions on images? If you specify font sizes in points and image sizes in pixels then your web pages will look different at different screen resolutions. Scaling images is very easy - most graphics hardware (even 10-year old 2D only cards) can do bi-linear interpolation, and many newer ones can do bi-cubic interpolation, allowing very high quality scaling of images without using the CPU, so there's no reason not to expect a browser to be able to scale images (even in software it's hardly processor intensive, compared to decoding a PNG).

Re:This makes me feel so old and so sad

[Musteval]

Have you ever even SEEN an image that's been resized by the browser? They almost always look like crap.

Check your results using Opera!

[e2mtt]

FWIW, you can check out your site in Opera using Small Screen Rendering (shift+F11) for an easy preview. It follows css rules nicely.

Eh?

[Anonymous Coward]

Competant developers have been using xhtml and css for 10 almost years, creating sites that display fine on any media in any UA. I suggest that before the pro (pfft!) web application developers start doing this, they review HTML lesson 1 on the anchor tag. Javascript doesn't work cross-browser which means that it's useless for anything other than bells and whistles atop the basic functionality. Hence, ASP.NET sites relying on viewstate and doPostBack are broken by design.

As for applets, macromedia flash and other proprietry media formats, well...

Re:Eh?

[kwalker]

Funny, considering the specs for XHTML and CSS 1 are only about 5-6 years old. And considering that IE still doesn't display some CSS correctly I seriously doubt that "competant developers" have been using it "for nearly 10 years" to "display on any media and any UA". Netscape 4 barely knows what CSS is, and 10 years ago, it was one of the top dogs. And I also find it funny that "javascript doesn't work cross-browser" but Google seems to be using it just fine. Seems to me that the main browsers (Mozilla-based and IE) handle the ECMA version of Javascript just fine, and once Apple gets some things taken care of in Safari, it'll work fine too.

I've actually been trying to do some of what TFA has been talking about, but even then I get stymied by buggy wireless browsers that crash if you have a "screen" stylesheet and a "handheld" stylesheet in the same document, or crash if you load more than 8k of text and images, or fail to load the page if you have more than one image. I wish it was as easy as TFA talks about.

Re:External CSS?

[Bogtha]

That's a very distorted description of what actually happens. Yes, with the initial page view, you need to make an extra request for the external stylesheet. However, for all subsequent page views, the stylesheet doesn't need to be downloaded. So, if you compare embedded <style> elements with external stylesheets, then you are downloading very slightly more data on the initial page view, but then lots less for each subsequent page view.

Basically, so long as most of your visitors load more than one page, you come out ahead by using external stylesheets. This also costs your visitors less, as less data is transferred overall. The idea that external stylesheets use more bandwidth is a very superficial analysis that is the exact opposite of the truth once you look beyond a single page view.

I'm also highly suspect of your assertion that external stylesheets render the document twice; in most implementations I am aware of, rendering is delayed, so step 3 that you describe doesn't happen.

practical yes, good no ...

[Lazy Jones]

Solving these issues with XHTML and CSS may be a viable solution compatible with current standards, but it is not a good solution from a technical point of view. Why? Because it's silly to transfer large amounts of XHTML to a wireless device and then hide all the stuff that doesn't fit or look good on a small device using CSS. It's much better to have only the HTML that the device is actually going to display transferred to the device.

But hey, everything is bloated today, so why not web pages, eh?

Wireless device browser compatibility isn't easy.

[ramakant]

This is a great article from the standpoint that it gets people thinking about standards compliance and web pages that validate. However, if you actually want your web pages to be correctly renderable on many browsers, you need to be able to send different markup based on the target browser. This is particularly painful for mobile phone browsers, where the specs supported are all over the map. The phone/browser manufacturer may claim XHTML-MP 1.0 compliance, but only support a subset of the actual spec.
In order to make our site compatible with as many mobile phone browsers as possible (I work for 4INFO), we use the WURFL Wall JSP tag library. This matches the browser user-agent, against a database of known devices and capabilities, and renders the appropriate markup. Only after extending that library and updating its device database have wee been able to get our WAP site to render on most mobile phone browsers.