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.

Re:This makes me feel so old and so sad

[Have Blue]

Safari (and possibly other OS X browsers) do what the GP is suggesting, and it looks good up to about 400%.

Re:This makes me feel so old and so sad

[multipartmixed]

> Why should you specify pixel dimensions on images?

The page will render faster if the browser knows the dimensions of the image before downloading it.

This is especially critical for dial-up and wireless (assuming the wireless browser even has images enabled).

Re:This makes me feel so old and so sad

[Total_Wimp]

Safari (and possibly other OS X browsers) do what the GP is suggesting, and it looks good up to about 400%.

Good for Safari. That's a nice touch. Now, back to the topic at hand, making pages that will work well on a variety of OSs, web browsers and devices at a variety of resoultions.

TW

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.

Just what the world needs ...

[anzev]

This is just what we need. Another "temporary solution". The next thing that's going to happen is that everyone will start complaining how a browser doesn't respect some standard. I think that there should be no "intermediate" solution for this. Either you do it like you should have done it, or you don't! P.S: I'm sorry, I had to say this, I'm the first one, I hope :-). In Soviet Union, the web pages retrofit you.

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:Eh?

[jZnat]

So does that make 95% of web developpers incompetent?

Yes.

~J

Re:Eh?

[Bogtha]

The mime type thing is a "should" not a "must" in the guidelines

Which guidelines are we talking about? I'm aware a W3C member published a Note saying that; just because it appears on the W3C domain, it doesn't mean it's the W3C's official position, and the Note states this.

You shouldn't be paying attention to non-normative guidelines and notes. You should be paying attention to the specifications. And the specifications are quite clear - RFC 2616 declares the media type contained in the Content-Type header to be authorative and not ignorable, and RFC 2854 clearly states that the only form of XHTML suitable for transmission as text/html is XHTML 1.0 following the compatibility profile (a.k.a. Appendix C.).

therefore IE has support for XHTML.

No, this is not the case. Just because it displays something, it doesn't mean it supports XHTML. Hey, I can get 'cat' to "display" a JPEG file in an incorrect way - does that mean that it is a JPEG parser?

Does Internet Explorer enforce the mandatory error handling? No. Does it enforce the mandatory lowercase DOM element type names? No. Does it use the XHTML CSS rules? No, it uses the HTML CSS rules. Does it understand xml:lang? No. Does it imply <tbody> elements inside <table> elements? Yes - which is correct for HTML but incorrect for XHTML. Does it support the XHTML content model for <script> and <style> elements? No, it uses the HTML content model.

In every way I can think of in which XHTML differs from HTML, Internet Explorer gets it wrong. No, it doesn't support XHTML.

How many care? And misleading title

[Mowie_X]

Very interesting write-up, but how many webmasters/blogmasters/etc... really care if a webpage is hard to read on a mobile device? Isn't the title also misleading? This has nothing to do with whether the accessing device is "wireless" (my laptop is wireless), but rather if the accessing device is mobile (i.e small screen)

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.

they should practice what they preach.

[scenestar]

http://validator.w3.org/check?verbose=1&uri=http%3 A//www-128.ibm.com/developerworks/wireless/library /wi-css/%3Fca%3Ddgr-lnxw01WirelessPages/

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.

Accessibility is important for many reasons

[JehCt]

A great test of a web site tests is loading on a Blackberry. Sometimes I move blocks of code around and use absolute positioning so the good stuff renders first, to help reduce thumb pain. (/. has too many nav links at the top of the code, so you have to scroll a lot to see the stories.) Googlebot "sees" web pages much the same way as a Blackberry. Indeed, search optimization and accessibility have a lot in common.

I am not sure XHTML is the key to accessibility. XHTML allows tables, which are often misused to control layout. The code flow of a table is different from visual representation, causing loss of semantic information when the page is rendered on alternative browsers or spiders that don't assemble the table the same way.

These common SEO/accessibility strategies provide good results on mobile devices, even with HTML 4.01, and as an additional benefit, make it much easier to manage the site, and may help search visibility:

1. Fix all validation errors and warnings.
2. Replace Javascript menus, or provide alternate text menus wrapped in NOSCRIPT tags.
3. Add alternate plain HTML to any Flash OBJECTS.
4. Strip layout tables and replace with DIVs. Tables with tabular data are fine, but consider adding CAPTION, THEAD, TBODY and TFOOT for better control over appearance.
5. Rip out presentation attributes and replace with CSS formatting. This greatly reduces file size and simplifies the code reducing the potential for errors, speeding page loads, and saving Google some disk space.

Once the above process has been done, the resulting HTML 4.01 can be converted to XHTML with trivial easy.

paper compatibility would be nice too

[moosesocks]

Most of what the article is talking about also can easily be extended to print medium as well. That is, the way a page looks when printed out.

Through a very simple use of CSS, you can rearrange the page to be more friendly for print format by dropping background colors, making the text black, and removing sidebars and navigational elements.

With a little more effort, you can rearrange elements, replace graphics/logos with black & white versions, and rearrange the text so that it's occupying the full width of the page, etc. The driving directions feature on google maps is a great example of this concept.

Even slashdot's CSS redesign sports some of these features by dropping the ads, the top row of topic icons, the sidebar, the "Read More..../Comments?" line below each article, and other assorted navigational elements. Granted, it's still not very pretty compared to most, but it looks a hell of a lot better than the manner in which browsers butcher printed documents without no media attribute set.