Slashdot Mirror

← Back to Stories (view on slashdot.org)

Retrofit Your Web Pages For Wireless Compatibility

Posted by Zonk on from the sunday-project dept.

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."

35 of 142 comments (clear)

  1. This makes me feel so old and so sad by Simon+Brooke · · Score: 5, Informative

    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.

    --
    I'm old enough to remember when discussions on Slashdot were well informed.
    1. Re:This makes me feel so old and so sad by TheRaven64 · · Score: 4, Interesting

      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).

      --
      I am TheRaven on Soylent News
    2. Re:This makes me feel so old and so sad by Musteval · · Score: 4, Insightful

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

      --
      Note to mods: I'm probably being sarcastic.
    3. Re:This makes me feel so old and so sad by Have+Blue · · Score: 3, Interesting

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

    4. Re:This makes me feel so old and so sad by multipartmixed · · Score: 3, Informative

      > 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).

      --

      Do daemons dream of electric sleep()?
    5. Re:This makes me feel so old and so sad by NanoGator · · Score: 2, Interesting

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

      Opera performs nice filtering on images when you magnify the page. Also, the browser that comes with the Palm Pilot also does a really nice job of resizing images. Internet Explorer, as of version 5.5 at least, does not do nice filtering. (i'd be curious to know if 6.0+ was modified since I've discovered it will nicely resize stand-alone images too big for the page.) It's up to the browser.

      Somebody else mentioned that pages scale up nicely on the Mac. I need to second this. My cousin has a really nice Apple laptop. He showed us a movie trailer on it. He just magnified the whole desktop (browser and all) to show the trailer, and it worked really really well. People around here bitch about eye candy, but man, I have to give credit to Apple for making it that useful. (Unrelated topic, but I was also pleasantly surprised by how well the speakers on that laptop worked. My Toshiba laptop sounds like a Game Boy in comparison.)

      --
      "Derp de derp."
    6. Re:This makes me feel so old and so sad by Spy+Hunter · · Score: 2, Interesting
      there's no reason not to expect a browser to be able to scale images

      You mean other than the fact that the two most widely used browsers in the world still perform crappy no-interpolation nearest-neighbor image scaling, and yet somehow still manage to suck up gobs of CPU time doing it? (I'm talking here about IE and Firefox, of course.) If you expect a user's browser to have nice image scaling, you will be wrong 99% of the time. It's a ridiculous situation, in this age of dedicated 3D rendering hardware in nearly every PC. A 3D card's *primary function* is drawing scaled and warped images with nice interpolation!

      I believe Opera and Safari do perform decent image scaling. I haven't heard if IE7 will, but I doubt it. Firefox 3 is moving to Cairo for graphics, which should allow it to leverage OpenGL-capable graphics hardware for scaling images with nice interpolation. But Firefox 2 will likely still be using the same old terrible image scaling we've been living with for years.

      --
      main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
    7. Re:This makes me feel so old and so sad by Total_Wimp · · Score: 3, Insightful

      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

    8. Re:This makes me feel so old and so sad by Simon+Brooke · · Score: 2, Insightful
      I'm glad that you've always had the luxury of design web sites that look good no matter how big (or small) the browser viewport is. I don't.

      Yes you do. Either you're just lazy, or you're too gutless to tell the management/customer that they're wrong. Seriously, not a flame. If an engineer who was designing a bridge let the customer talk them into removing some vital support on the basis that '... it looks ugly with that girder there...', you wouldn't call that engineer very professional. You are just as unprofessional when you let your manager or customer talk you into a design which looks good on their screen, but you know won't work well on others.

      --
      I'm old enough to remember when discussions on Slashdot were well informed.
    9. Re:This makes me feel so old and so sad by urmensch · · Score: 2, Informative

      Yes, that's an Adobe plugin test. Try this.

    10. Re:This makes me feel so old and so sad by Flwyd · · Score: 2, Informative

      I'm not sure if browsers have gotten smarter about this, but if you specify pixel sizes on images, the browser can leave the apropriate amount of space open so the page text doesn't jump wildly while modem users are reading it. Back in the day, some browsers wouldn't even render the page until they knew how big each image was going to be.

      And while I've never surfed the web on a cell phone, I'll bet my webpages look just fine in them. They looked pretty good in lynx last I checked. And most of them probably work well in an aural browser. That's because they're almost all text. Coincidentally, there's a very high content-to-bandwidth correlation.

      --
      Ceci n'est pas une signature.
  2. Check your results using Opera! by e2mtt · · Score: 5, Informative

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

  3. Just what the world needs ... by anzev · · Score: 3, Informative

    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.

  4. Eh? by Anonymous Coward · · Score: 4, Insightful
    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...

    1. Re:Eh? by Anonymous Coward · · Score: 2, Interesting

      Too bad XHTML and CSS weren't even W3C specs 10 years ago? You're over-exagerating. Hell, a HUGE portion of the web STILL uses HTML 4 and tables for layout - including TONS of HUGE sites by webmasters making a decent living. So does that make 95% of web developpers incompetent? I only do XHTML 1.1 strict w/ CSS myself, but I don't think it makes me superior or more competent than others.

      And as for ASP.Net, then you don't really know how it works it seems. It'll use whatever the browser is compatible with (and quite frankly the number of users with non-JS browsers today is quite small - under 0.1% of all my visitors). It'll render WML or cHTML for phones too.

    2. Re:Eh? by kwalker · · Score: 4, Interesting

      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.

      --
      ... And so it comes to this.
    3. Re:Eh? by oneiros27 · · Score: 2, Insightful

      Competant developers haven't been developing in xhtml and css -- because there's no support for it in IE ... serve it w/ the correct MIME type, or specify the correct doctype, and you're asking for problems.

      HTML 4 and CSS is still the best solution for the general masses. If you're working on an intranet, or some other place where you can tell people to get a different browser, you might be able to pull off xhtml, but you can't be sure it's going to get interpreted correctly, so what's the point?

      The concept of xhtml was good, but with flawed implementations, it's completely useless.

      Competent designers know that the only thing you can count on in web browsers are problems, so you either have to use the bare minimum of features, test to the point where it's not cost effective to ever make changes, or just plan on crap breaking constantly.

      --
      Build it, and they will come^Hplain.
    4. Re:Eh? by jZnat · · Score: 3, Insightful

      So does that make 95% of web developpers incompetent?

      Yes.

      ~J

      --
      'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
    5. Re:Eh? by holloway · · Score: 2, Informative
      The mime type thing is a "should" not a "must" in the guidelines, therefore IE has support for XHTML.

      It's a myth that not being able to handle the mime-type means the client doesn't understand XHTML as the guidelines clearly state it's recommended but unnecessary.

      --
      -Docvert converts MSWord to OpenDocument, clean HTML
    6. Re:Eh? by Bogtha · · Score: 3, Insightful

      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.

      --
      Bogtha Bogtha Bogtha
  5. External CSS? by TheRaven64 · · Score: 2, Informative
    On a mobile device, you often have a minute amount of bandwidth and a huge amount of latency. If you move your CSS into separate files then displaying the page uses the following steps:
    1. Fetch HTML (long wait).
    2. Parse HTML.
    3. Render preliminary (no-CSS) view.
    4. Fetch CSS (another long wait).
    5. Fetch inline images (again, a long wait, but slightly overlapped with the previous step).
    6. Render final view.
    It is also worth noting that your readers are likely to be paying for bandwidth on mobile devices - if you use a lot of small CSS files then you will not only make it take a long time for people to view your site, you will also make it expensive (that HTTP request overhead adds up a lot faster than you might think).
    --
    I am TheRaven on Soylent News
    1. Re:External CSS? by Bogtha · · Score: 4, Informative

      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.

      --
      Bogtha Bogtha Bogtha
    2. Re:External CSS? by Dj+Offset · · Score: 2, Interesting
      You obviously haven't worked much with CSS?

      On a handheld device, rendering (displaying) is a bottleneck for mobile browsers, simply because the CPU is much slower. So you will skip any preliminary heavy rendering job before you have all CSS in place.

      The CSS fundamentaly affects what needs to be downloaded, and what will actually be displayed.

      For example using Opera in small screen rendering mode (Shift+F11) you only apply handheld stylesheet (if found), in print preview mode (shift+P) only the print stylesheet is applied, and in fullscreen mode (F11) the projection stylesheet is applied.

      The actual order would be:

      1. Fetch and parse HTML while downloading (this usually makes you wait)
      2. Retrieve any CSS and frames (pipeline on established connection)
      3. Parse CSS and request inlines (pipeline on established connection)
      4. Render & display
      5. Update as images and objects are retreived until finished
      Browsers can do some work on prioritizing pipelined requests, and of course set up multiple connections.

      On handheld, cache is king.
      The CSS will be cached for the next page.

  6. A better fix is XSLT by ishmalius · · Score: 2, Interesting

    A much more generic solution would be for the content manager to generate only XML, and for XSL (client side) or XSLT (server side) to do the customization. Then the possibilities for fitting onto any client device would be endless. CSS only affects existing classes and elements. XSLT generates whatever elements and styles them as it pleases.

  7. How many care? And misleading title by Mowie_X · · Score: 3, Insightful

    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)

  8. they should practice what they preach. by scenestar · · Score: 3, Funny

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

    --
    perpetually dwelling in the -1 pits
  9. Re:Works fine on my laptop, why modify? by Tony+Hoyle · · Score: 2, Interesting

    Most cellphones are WAP which needs WML - no amount of CSS or XHTML will make a page display on these, so it is really to do with when they 'catch up'.

    On more expensive devices (mostly PDAs) pages tend to display anyway, sometimes with scrollbars (which sucks, but it's no different to a computer with low resolution). It's a non-problem for them. The gap in the middle with dodgy browsers is just catchup too.

  10. Re:It Was An Itsy Bitsy Teeney weeny.... by Tony+Hoyle · · Score: 2, Informative

    I must admit I gave up on the net on cellphones ages ago... GPRS slows to about 1k/sec in cities and a lot of the time stalls altogether, so it's really not a practical method of web browsing.

    3G holds promise, where it's available.. which is practically nowhere (the providers are good at showing maps with '100% coverage' of 3G, but when you get down to it the coverage is at best a weak signal that keeps dropping out.. even in cities... and out in the sticks it's just not there. I live 2 miles from the centre of the second largest city in the UK - and there's no 3G here at all).

  11. practical yes, good no ... by Lazy+Jones · · Score: 4, Insightful
    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?

    --
    "I love my job, but I hate talking to people like you" (Freddie Mercury)
  12. Wireless device browser compatibility isn't easy. by ramakant · · Score: 4, Interesting

    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.

  13. but what about devices w/ no CSS support? by RevAaron · · Score: 2, Interesting

    like the subject says- what about those devices with no CSS support? they're around enough, not all that rare. not everyone has a brand-new Microsoft Smartphone/WM5 phone, with the closer-to-desktop browser, or NetFront, which is even better. All that fancy CSS might look great in a 200x160 sized window on your desktop in trying to emulate a wireless device, but with those non-CSS devices out there it might just look like crap.

    just a thought...

    --

    Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
  14. Accessibility is important for many reasons by JehCt · · Score: 3, Interesting

    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.
  15. You should listen by dada21 · · Score: 2, Informative

    I read EVERYTHING on my PDA phone. 99% of my browsing, posting and e-mail is performed there. Sites that don't support me don't get viewed, and as time goes on, there will be more like me.

    I've spent thousands annually subscribing to websites that support my PDA. Slashdot was actually one of the first. Google does it as well. I can't wait to see what happens as mobile browsers become more available.

    I just picked up the Samsung t809 phone and can browse the web via Mini Opera (or my PDA synced via Bluetooth). Getting 150kbps downloads through T-Mobile's EDGE, so most websites are instantaneous even on the road (yeah, it's safe, sure it is).

    There are webmasters that have e-mailed me back saying they'd never support a tiny screen. I don't see how you can ignore the amount of phones that read more than just WAP -- many are HTML compliant with just a little software addition. Give it time and I bet we'll see popular sites getting more than 5% of their users from tiny screens.

    1. Re:You should listen by denebola · · Score: 2, Informative


      IMHO you are 100% correct.

      I notice with interest that we are approaching 1 billion users on the Internet.
      http://www.internetworldstats.com/top20.htm/

      How many people will have browser equipped phones in 1,2 and 5 years?

      Mobile/PDA/Small Screen Internet will be HUGE.

  16. paper compatibility would be nice too by moosesocks · · Score: 3, Insightful

    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.

    --
    -- If you try to fail and succeed, which have you done? - Uli's moose