Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
The Internet Programming Wireless Networking IT Technology Hardware

Retrofit Your Web Pages For Wireless Compatibility 142

Posted by Zonk 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."
This discussion has been archived. No new comments can be posted.

Retrofit Your Web Pages For Wireless Compatibility More

Retrofit Your Web Pages For Wireless Compatibility

Comments Filter:

  • This makes me feel so old and so sad (Score:5, Informative)

    by Simon Brooke ( 45012 ) * <stillyet@googlemail.com> on Sunday December 18, 2005 @05:29PM (#14287061) Homepage Journal

    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 (Score:5, Interesting)

      by TheRaven64 ( 641858 ) on Sunday December 18, 2005 @05:44PM (#14287142) Journal
      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 (Score:4, Insightful)

        by Musteval ( 817324 ) on Sunday December 18, 2005 @05:46PM (#14287152)
        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 (Score:4, Interesting)

          by Have Blue ( 616 ) on Sunday December 18, 2005 @06:02PM (#14287228) Homepage
          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 (Score:4, Insightful)

            by Total_Wimp ( 564548 ) on Sunday December 18, 2005 @06:54PM (#14287463)
            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
          • Yes, we understand that recent Apple products do graphics very, very nicely, and can do things that IE and Firefox can't always do. I don't really know what graphics horsepower my new cellphone has for its 128x128 color screen, but it's probably not much, and my Palm 7x has a 20 MHz Dragonball and grayscale 160x160 screen. Some of the Treo-like devices friends of mine have are better, but you still can't assume that there's a lot of real estate or horsepower. Lots of this stuff is pretty low-powered.
        • "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 e
          • > Opera performs nice filtering on images when you magnify the page.

            Why does everybody always talk about magnifying images when it's up to displaying them on *smaller* screens?

            Because on bigger ones ther always will be blank space. but on smaller ones it *must* be smaller to be usable.

            The problem is: in Firefox (and of course IE) you get a hell of a crap of image quality in *any* resizing. Just compare it to an image that got resized in photoshop or with another good filter like "lanczos resampling".

            By t
        • Looks good on Safari.
          live image resizing in-browser [agilepartners.com]
      • > If you specify font sizes in points and image sizes in pixels then your web pages will look different at different screen resolutions.

        That's not necessarily a bad thing. Web pages are meant to be designed to look good at a variety of resolutions (ideally, all, but in reality it's very hard not to have a minimum workable resolution around 100x100-ish). The problem is that a lot of web page designers are used to mediums where they specify how something is rendered, in comparison to HTML, where you specif

      • Re:This makes me feel so old and so sad (Score:4, Informative)

        by multipartmixed ( 163409 ) on Sunday December 18, 2005 @06:32PM (#14287345) Homepage
        > 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).

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

          No. What will happen is that the browser will guess that the image is really really small, and then re-render the page when it downloads the image and can check the real dimensions. This makes it impossible to read the text content without either hitting stop or waiting all of the images to load, because the text will be reflowed every time an image gets loaded.

          • Specific instances of "render slowly" will vary from browser to browser. NS3 would display nothing at all from the image point onward; in your brower's case, it makes the text reflow awkwardly.

            Regardless of the behaviour, specifying the image size will allow the page to be rendered more quickly.

            Rendered, in this case, has a binary meaning. Either the page is fully rendered, or isn't.
            • I still use NS3 every day, and I don't load images because I'm on very slow dialup, and I've come to prefer the web that way :)

              Anyway, what you say isn't true of NS3 at all (nor of NS2 for that matter). If image dimension isn't specified, NS3 just shows a small placeholder, instead of a placeholder of the correct size. Even on a slow machine (and I used NS3 on a 486 for years, so I know!) it makes no *practical* difference in rendering time, and does not affect the rest of the page (I think you're rememberi
      • 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

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

          You don't need OpenGL to do interpolated rescaling. ZSnes, for example, does it in realtime (30FPS), while still leaving enough CPU for the

          • It isn't exactly laziness on Firefox's part, more like inertia. Remember, the Firefox codebase is *old*. The image resizing code was likely written long before CPUs had enough power to consider filtering images on the fly, and before 3D hardware came built in to everybody's motherboard. Today it is feasible even on CPUs (though slow; it would still be a noticable performance hit), and trivial for graphics hardware. It's just that nobody has bothered to update the drawing code yet; there is a chicken-an

            • It's just that nobody has bothered to update the drawing code yet; there is a chicken-and-egg problem; nobody uses browser image scaling because it sucks.

              Except that Firefox will automatically resize large images that are viewed alone (direct link to the image file) so they fit the browser window - you can switch between the full and resized images by clicking on it. This is a nice feature, but the image quality of scaled image is horrible.

              The Firefox-Cairo project is an effort to completely moderniz

      • Why should you specify pixel dimensions on images?

        Well, according to the HTML standard you should.

        However if you want scalable images you should go for SVG. Both Opera (8.0+) and Firefox (1.5+) supports this natively. Konqueror has a nice KPart, and IE users can use Adobe's plugin.

      • Why should you specify pixel dimensions on images?

        Personally, I wouldn't (except perhaps in special cases where I was trying to get a complex page to lay out faster); but I don't consider it wrong to do so. I look forward to the day when most Web images are scalable vector graphics and, uhhmmm, scale. Nicely, and on all devices then in common use.

      • 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 probab
    • IANAWD. Is this why a Blackberry has such a difficult time w/ most web pages? Slashdot displays OK but its a limited, stripped down version without most links. 5 comments per article only. I must have missed a FAQ somewhere......
    • 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.

      • 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

        • Either you're just lazy, or you're too gutless to tell the management/customer that they're wrong.

          Yes, I can see it now. "You are wrong not to waste money making sure your web application works on a cell phone. I don't care if a cell phone could only show 2 of the 50 required fields at a time. I don't care if none of your users use cell phones to access the application. You are dead wrong. You MUST spend money on this."

          I make sure my web application look good at all reasonable resolutions. I specific
    • "never -- never -- use absolute (pixel) dimensions for anything other than images." never - NEVER - say never. BTW, "except images" - quite an exempt right? given that it's actually images that we use to style lots of the design elements in web pages (menu backgrounds, buttons etc.). Of course except on straight barely formatted "academic" pages teaching is what to never do with our site's code. Thing is some things work best in pixels (images, certain menus, elements, buttons, heading text) and some thi
      • >>If you think otherwise, try reading a "fluid columns" layout on a high resolution screen (1600x1200 for ex.). The paragraphs become so wide, since they stretch of course, that you can't follow to the next text line

        You can use "max-width" to limit how wide the column goes. Of course, one particular browser doesn't understand it. (hint: it begins with 'internet explorer')
        • "You can use "max-width" to limit how wide the column goes. Of course, one particular browser doesn't understand it. (hint: it begins with 'internet explorer')".

          Oh yea, buggers. Forgot. Well that'd be just 80-90% of the web population then, big deal :)
    • You mean crippled browser and/or small screen instead, don't you? How about 16 color support, too?

      What I want to know is how do your graphics look on a green screen with a hurcules (HGA) monocrome graphics card?

      I don't refer to the internet as "the web". There are more protocols than http, really.. have a look..

  • Check your results using Opera! (Score:5, Informative)

    by e2mtt ( 629911 ) on Sunday December 18, 2005 @05:36PM (#14287099) Homepage
    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 ... (Score:3, Informative)

    by anzev ( 894391 ) on Sunday December 18, 2005 @05:37PM (#14287109)
    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? (Score:4, Insightful)

    by Anonymous Coward on Sunday December 18, 2005 @05:43PM (#14287138)
    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? (Score:2, Interesting)

      by Anonymous Coward
      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 (a

      • Re:Eh? (Score:4, Insightful)

        by jZnat ( 793348 ) on Sunday December 18, 2005 @07:06PM (#14287550) Homepage Journal
        So does that make 95% of web developpers incompetent?

        Yes.

        ~J
        1. There's no such thing as XHTML 1.1 Strict
        2. You're being naughty if you're using XHTML 1.1 and not serving it with the application/xhtml+xml mimetype.
        • Am I being naughty if I'm serving XHTML 1.1 with application/xhtml+xml only to browsers that support it? I mean, who gives a damn if MSIE gets it as text/html since it doesn't have the damnedest clue what application/xhtml+xml is?
          • Am I being naughty if I'm serving XHTML 1.1 with application/xhtml+xml only to browsers that support it?

            Yes [webstandards.org].
            • What's wrong with this then?
              if (strpos($_SERVER['HTTP_ACCEPT'], 'application/xhtml+xml') > -1) header('Content-Type: application/xhtml+xml; charset=utf-8');
              else header('Content-Type: text/html; charset=utf-8');

    • Re:Eh? (Score:5, Interesting)

      by kwalker ( 1383 ) on Sunday December 18, 2005 @06:16PM (#14287291) Journal
      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? (Score:3, Insightful)

      by oneiros27 ( 46144 )

      Competant developers haven't been developing in xhtml and css -- because there's no support for it in IE [wikipedia.org] ... 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 co

      • Re:Eh? (Score:2, Informative)

        by holloway ( 46404 )
        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.

        • Re:Eh? (Score:4, Insightful)

          by Bogtha ( 906264 ) on Sunday December 18, 2005 @09:04PM (#14288145)

          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 [ietf.org] declares the media type contained in the Content-Type header to be authorative and not ignorable, and RFC 2854 [ietf.org] 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.

          • ^^ he isn't me, but he may as well be.
          • Since you mention cat decoding JPEG images, I'm sure that less already does or will support transcoding JPEG images to ASCII art sometime soon. Jesus, man, that thing does everything! Who needs to whip out xpdf when less will show you the textual information from a PDF? Sure, it's only good for quick checking of the document, but you still get all that fancy search capabilities less has.

    • Re:Eh? (Score:2)

      by rho ( 6063 )
      By "competent developers" I assume you mean "people who have to answer to nobody". Making Web pages that only work well in modern browsers is a side effect of clients who ask for it. Sometimes you can educate them differently. Often you cannot. And nobody is willing to pay to develop an alternative site for people who visit the site from a phone.

      I'm sensitive to the issue, really. I browse regularly from a Palm, both over WiFi and GPRS. I would really appreciate more work in this area. (See Google for a g

    • Competant developers have been using xhtml and css for 10 almost years

      Ignoring for a second how these standards haven't been out that long, hardly anyone is currently supporting XHTML strict properly anyway: using the correct MIME type [hixie.ch]. In short, if it works in Internet Explorer, it's the wrong MIME type, even if w3.org's validator says it's fine. No company is yet happy with the idea of their web site not working in IE, so they use the incorrect MIME type.

      Incidentally, there's a version of XHTML inte

  • External CSS? (Score:2, Informative)

    by TheRaven64 ( 641858 )
    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

    • Re:External CSS? (Score:5, Informative)

      by Bogtha ( 906264 ) on Sunday December 18, 2005 @06:07PM (#14287240)

      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.

      • Actually, the initial display of unstyled content does happen, see this article: http://www.bluerobot.com/web/css/fouc.asp [bluerobot.com]

        • I'm well aware of FOUC. I call your attention to this part of the document:

          Because this quirk seems to affect only MS Internet Explorer, we're tempted to conclude that IE is just plain wrong.

          So it's not nearly as common a problem as the OP made it seem.

          In actual fact, while the quoted statement might have been true at the time of writing, Gecko also has a FOUC problem. It only arises when you use the HTTP Link header to link to your external stylesheet though, which virtually nobody does because

          • Can you elaborate on that? I've had no problems with it. I agree with your other statements, though.

            • See that's the trouble with not learning proper terminology and calling everything "tag" :). I'm not talking about the bit in your documents that looks like:

              <link rel="stylesheet" href="/stylesheets/default/screen.css">

              I'm talking about information your browser receives when requesting those documents, that looks like:

              Link: </stylesheets/default/screen.css>; REL=stylesheet

              The former is called an element. The latter is called an HTTP header. You might also refer to the former as a

    • Re:External CSS? (Score:2, Interesting)

      by Dj Offset ( 260006 )
      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 [opera.com] in small screen rendering mode (Shift+F11) you only apply handheld stylesheet (if found), in print preview mode (shift+P) only the print

  • A better fix is XSLT (Score:3, Interesting)

    by ishmalius ( 153450 ) on Sunday December 18, 2005 @05:58PM (#14287209)
    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.
    • You can also filter your existing output via XSLT. It is quite easy using servlet or Apache filters.. or whatever you have. For normal pages, just do a copy. For limited devices, convert and/or trim data. Be sure to turn off XML validation, since most content engines generate bad XML.
      • yup, filter and transform everything live all the time. caching transformations in the first place is for complete losers.

        real programmers use no data caching or invocation/processing caching, they just waste cpu power everywhere they can!


        are you really that mad at you cpu's that you want to transform them each time a dummy client makes a request ? there are much better ideas out there for a while already, take a good look around ;-)
        • I don't know about all of the big webservers, but I do know that at least Apache, WebSphere, JBoss, and ColdFusion have caching built in, so you don't need to supply these yourself. If you XSLT a page and you either have a static page or the content engine somehow marks it as having no deps, it will be cached. The first web page hitter might wait an extra 1ms, but the rest will view it as a static page.

          I don't see the problem. Why avoid tech? You can be the hottest web artist and/or editor, but stil

        • yup, filter and transform everything live all the time. caching transformations in the first place is for complete losers.

          Do you really think that the GP doesn't understand this? Caching the files generated is blatantly obvious. If you can write decent XML-handling code, I don't know how you could not understand caching. Don't assume that people are stupid just because they didn't mention an implementation detail.

  • How many care? And misleading title (Score:3, Insightful)

    by Mowie_X ( 600765 ) on Sunday December 18, 2005 @06:02PM (#14287227) Homepage
    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)

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

      And to split that hair the other way, my laptop is mobile. So what's your point again? Where I come from people refer to Blackberries and mobile phones as wireless devices. It looks like where you come from people refer to them as mobile devices. It's all the same and was very clear from reading the article what was being talked about.

  • Pretty much all the websites work about the same on my mobile wireless laptop. Why would people need to modify how they make the sites for them to work right?
      • Well, it was sorta a joke... But really, isn't it only time till cells & pdas catch up and can display most pages normally? I think that changing the site for small layouts is a waste for most sites at this time. Of course, a well engineered site would be flexible enough to support different designs, but extensive tranformations necessary for cell phones is just too costly for most sites.
        • No, it's not a matter of time until they "catch up". Far from everything is about bandwidth of connection or capability of the browser - it's also about the size and quality of the screen, and the facts that there's always going to be a demand for small phones with comparatively narrow screens and that you can only make the text so small.

          You're right that it's a waste for lots of sites, but some sites can really take advantage of being available for cellphones and PDAs, in which case you should not just hop
          • 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.
            • I agree with the fact that poor browsers (or WML-only browser) is a case of catching up. However, there's a line between where browsers are not good enough and where your site could use retooling to better suit mobile browsers. (Some browsers are *very* smart about converting 'real' sites to mobile sites, but you can't assume that every single browser is going to work that way, or even in the same way.)

              This article on A List Apart - detailing what could be done to improve Slashdot before it switched to CSS
            • That's why there is a WAP-HTTP gateway on your mobile providers network. If you request a HTML page the gateway can reformat the page to WML and make it easier for the phone to render.

              BTW this is basically how the new Opera Mini browser works as well. Only they have their own intermediary language which they convert the HTML to.
    • Mod parent up. This story is titled and worded poorly. It should describe what needs to be done to make sites compatible with small, mobile devices, not "wireless" devices.
  • It wasn't long ago that /. changed to a mobile-aware CSS. Which was a good thing for my smartphone, but bad thing for my PDA. It looked pretty decent to begin with on the PDA.

    But overall, this is really a good idea. Where I work, we have some monitor/reporting/utility pages, and I've already requested mobile-device css for them.

    If I go somewhere (and am on call) I don't need a PDA or laptop, just a smartphone or something similar... all set.
  • Except that almost all phone/pda browsers can only handle HTML 3.2 at best and bork at the slighest bit of CSS. This article is day dreaming at best. We're a long way off ever serving the same page to mobile browsers as desktop browsers.
  • I am alone in thinking that the 'net on a 1 1/2 inch phone screen is almost pointless? Slow, ugly, and frustrating to the extreme.

    Accessing the 'net on my Motorola is almost always something done while stuck in a boring lineup, and the local weather report is the only thing that I've bothered to bookmmark.

    • 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 cent
    • No your not alone, wireless interfaces are just too frustrating for surfing the web in my opinion. With computer monitors getting bigger, the websites alos seem to be getting bigger, and a small screen just can't display the info.

      MP
      Try our software for timesheets [sphericaltech.com]

  • With a lot of useful tips on how things work in the real world: Mobile Web Design: The Series [cameronmoll.com].

  • practical yes, good no ... (Score:5, Insightful)

    by Lazy Jones ( 8403 ) on Sunday December 18, 2005 @07:09PM (#14287566) Homepage Journal
    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?

    • CSS already allows for only transferring the necessary stylesheet. In your HTML document you can specify which media types a given referenced stylesheet apply to and the browser can then determine which stylesheets are relevant to it. You still need to transfer the HTML document, but there shouldn't be any extraneous crap in the HTML document if the presentation is properly confined to the stylesheets anyway. (In practice there is usually a bit of "leakage" due to limitations of CSS2, but in most cases it's

  • Wireless device browser compatibility isn't easy. (Score:4, Interesting)

    by ramakant ( 256472 ) on Sunday December 18, 2005 @07:52PM (#14287784)
    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 [4info.net]), we use the WURFL [sourceforge.net] 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 [4info.net] site to render on most mobile phone browsers.
    • I've been looking at WURFL and the Wall JSP tags in particular. I'd be interested to know what extensions you needed to make to the tag library and how you got on in general.

      The updates to the device database are a fact of life I guess (especially given that the WURFL guys seem to be Europe based and you seem to be US based - I assume there are some differences in the devices available).

      [pnee] [at] [toombeola.com]

  • but what about devices w/ no CSS support? (Score:3, Interesting)

    by RevAaron ( 125240 ) <revaaron AT hotmail DOT com> on Sunday December 18, 2005 @09:43PM (#14288290) Homepage
    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...

  • Accessibility is important for many reasons (Score:3, Interesting)

    by JehCt ( 879940 ) * on Sunday December 18, 2005 @10:10PM (#14288401) Homepage Journal

    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.

  • Developing for Mobile Devices (Score:1, Interesting)

    by Anonymous Coward
    1.) Hire a good editorial team
    2.) Build effective tools that allow that editorial team to repurpose your web content for mobile devices.

    The reason for point 1 is this: when using a mobile device users typically want to read less. They're busy, they're also doing something else, they're utilizing a snatched bit of time to get some facts. Very few of them want to read the same amount of content they would on a web browser. Until we have AI you'll need a good human sub-editor to trim away the fat and leave usa

  • You should listen (Score:3, Informative)

    by dada21 ( 163177 ) * <adam.dada@gmail.com> on Monday December 19, 2005 @12:44AM (#14289021) Homepage Journal
    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 [blogspot.com] 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.

  • paper compatibility would be nice too (Score:4, Insightful)

    by moosesocks ( 264553 ) on Monday December 19, 2005 @02:00AM (#14289265) Homepage
    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.
  • The first thing I noticed when using Opera shift+f11 was that the adds on slashdot and my websites are gone. If people can't see the ads then i'm not going to bend over backwards so they can view my website on their tiny screen. I have no idea if this applies to all mobile devices or if this is something that google, amazon, ect. just don't care to address.

    Besides having no ads, who wants to view great photos and hd video on a tiny screen. About the only websites that would be worth viewing are forums an

Slashdot Top Deals

One way to make your old car run better is to look up the price of a new model.

Close