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

[SharkFarmer]

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

Re:This makes me feel so old and so sad

[Xugumad]

> 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 specify what something is, and leave the client to figure out the rendering.

Although, if you're going to insist on resizing images, can I recommend Scalable Vector Graphics (SVG)? Support isn't quite there yet (I think Firefox 1.5 supports it out of the box, while everything else needs an Adobe plugin), but it's the ideal way to have variable size graphics!

Re:This makes me feel so old and so sad

[joshv]

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.

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

[NanoGator]

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

Re:This makes me feel so old and so sad

[Spy Hunter]

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.

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

Re:This makes me feel so old and so sad

[Simon Brooke]

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.

Re:This makes me feel so old and so sad

[Simon Brooke]

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.

Re:This makes me feel so old and so sad

[narcc]

I've been waiting for native SVG support for a long time. When you had mentioned that it worked in FireFox 1.5+ I immediately went to http://www.adobe.com/svg/viewer/install/svgtest.ht ml to see if it worked. Sadly, it did not. Am I doing something incorrectly?

Re:This makes me feel so old and so sad

[Anonymous Coward]

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

You are so far removed from reality I don't see why you're bothering to participate in this discussion.

The client will get what s/he wants or you don't get the contract. Welcome to the real world!

Re:This makes me feel so old and so sad

[Anonymous Coward]

This isn't flamebait, this is just silly.

There was no version Netscape 3.1.... there was 3.0... 3.01, 3.02, 3.03, 3.04, then it jumped to 4.0.

Is there something i am missing from this comment?

Re:This makes me feel so old and so sad

[urmensch]

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

Re:This makes me feel so old and so sad

[Flwyd]

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.

Re:This makes me feel so old and so sad

[Hurricane78]

> 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 the way: good quality resizing still isn't accaptable for small handheld devices. So if you want it fast you have to go with the uglyness.

By the way: there is ony one pretty simple thing you need to do for webpages that need to be usable on handhelds: add a stylesheet for devices with limited screen size which does no side-by-side stuff, uses other style-images and smaller fonts and dimensions. (not to be confused with content-images.)
if you *must* provide different content-images for different images do it server-side. one example would be the a php-script that you could use like this:
" alt="woah i got auto-resized"/>
which would result in this for small screen media types:

which would call i.php which would load the cached resampled image if avaliable and output it, or resample it on-the-fly and store it in cache before returning it.

I developed an advanced library that did the i.php stuff for a big internet portal and it was used for a long time there. when i left the sinking ship they dropped it because they did not understand it. *g*
the only bottleneck was that php was so slow. i would have recommended to program it as a separate apache module.

Re:This makes me feel so old and so sad

[Hurricane78]

> in comparison to HTML, where you specify what something is,

exactly. i want to stress the point that HTML has NOTHING todo with any of the following:
- design
- layout
- look
- style
or all in one: how it should look

it's ONLY for MARKING UP your content with structure.

If you think about look when you code your html, then you're obviously doing sumthing fundamentally wrong.

I myself needed a long time to see how wrong i got it. I finally came when i used s to structure sections and areas, realized that a width="xxx" does not belong inside an (or anything else for that matter)
and tags are there to define what the content is. that is, a -tag is ONLY for table-data! not for any stupid layouting! (or else go design your webpages in excel! ;)

As a result of this, if you want to *design* a webpage, STAY AWAY FROM (X)HTML until you *finished* your design. (and transform you page to CSS + visual media [images & more])

I can't tell you how important it is to stress this thing! Most of all problems ever seen with webpages happened for that reason. And it still happens...

This is the main reason why i was happy about the coming of firefox...

Re:This makes me feel so old and so sad

[Anonymous Coward]

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

Yes that's certainly true, but I think you missed his point. What he's saying is that if you're going to specify font sizes in points then you should also be specifying image sizes in points. That way the relative proportions of the page will be maintained, regardless of the actual screen resolution of the end-user's device, and the browser will still reserve the required space for the image and render the rest of the page while it's still downloading.

Try laying-out a page on a 110dpi screen using point-size fonts and pixel-size images, then display that same page on a 96dpi (or less) mobile device. Hmm, look like crap?

Re:This makes me feel so old and so sad

[Anonymous Coward]

never -- never -- use absolute (pixel) dimensions for anything other than images.

As per your css page:
.navbox, .sidebar { background: transparent url( ../images/multicomposite5_sm.png) no-repeat top right; float: right; width: 200px; font-size: smaller; margin-left: 4em; margin-bottom: 6em; margin-top: 0; margin-right: 0; /* position: fixed; */ /* overflow: visible; */ /* width: 200px; */ /* height: 550px; */ padding-left: 2em; /* top: 0; */ /* bottom: 50%; */ /* right: 0; */ /* left: 75%; */ }
Emphasis, mine. Glass houses.

Re:This makes me feel so old and so sad

[multipartmixed]

Ah, thanks for pointing out the subtlety I'd missed -- you (and the OP) are right, of course -- everything really should be specified using the same units. I thought he was asking "why specify image size at all".

Now, if only the browsers would do a better job dynamically resizing images in the first darned place...

> Try laying-out a page on a 110dpi screen using point-size fonts and pixel-size images,
> then display that same page on a 96dpi (or less) mobile device.

You don't even need to go the mobile domain to see this issue. I configure my windows boxen for 1024x768 resolution, 125% fonts, because I'm old and blind and don't like 800x600 for graphics work (I suppose I could just buy a 21" monitor and be done with it....) This subtly breaks almost everything on the planet (not just web pages); particularly forms with drop-down boxes and such.

Re:This makes me feel so old and so sad

[Xugumad]

The Adobe test seems to be doing something freaking with JS... try:

http://www.carto.net/papers/svg/samples/shapes.sht ml

for a nice simple example. Googling for "SVG example" is also a good start. Strangely, can't get any of the examples from carto.net that use JS to work...

Re:This makes me feel so old and so sad

[Xugumad]

FreakY with JS, I meant

Re:This makes me feel so old and so sad

[ultranova]

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.

Re:This makes me feel so old and so sad

[ultranova]

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 actualy SNES emulation to run in my 1GHZ Duron sneezepump.

If Firefox has a shitty image scaling algorithm, it is pure laziness on Firefox programmers part, and nothing more, except maybe incompetence.

Re:This makes me feel so old and so sad

[multipartmixed]

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.

Re:This makes me feel so old and so sad

[Spy Hunter]

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-and-egg problem; nobody uses browser image scaling because it sucks. The Firefox-Cairo project is an effort to completely modernize Firefox's graphics drawing code, and as a side-effect it will fix this problem. In fact Firefox may use a GDI backend for Cairo instead of the OpenGL one. Either way, image filtering will be fixed.

Re:This makes me feel so old and so sad

[ultranova]

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 modernize Firefox's graphics drawing code, and as a side-effect it will fix this problem. In fact Firefox may use a GDI backend for Cairo instead of the OpenGL one. Either way, image filtering will be fixed.

Well, I doubt that I ever get to use it, since any version greater than 1.0 keeps on crashing on my computer :(.

Re:This makes me feel so old and so sad

[joshv]

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 specifically ask my clients what their users use and what is the minimum resolution I must support. This is typically 800x600. Wasting my time on making sure the application looks good at smaller resolutions is working on a requirement my clients didn't ask for, and don't want.

Your bridge analogy is false - obviously so.

Re:This makes me feel so old and so sad

[Reziac]

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 remembering what happens when a table structure isn't closed) nor does it cause a reflow.

But specifying image size DOES matter, for three common cases:

1) So you can read the image's ALT text. This is not possible if the image is unsized and therefore shows as the small placeholder.

2) when images are used as menu graphics -- assuming the webmaster included proper ALT text. Here again, if the images are "sized", you can read the ALT text and the menu is still usable without loading its graphics.

3) imagemaps. Properly "sized" imagemaps are generally still usable without loading the image, since you still have the same clickable areas represented on the screen.

(I don't know how any of this affects screen scrapers for the blind.)

Re:This makes me feel so old and so sad

[Anonymous Coward]

God your still using a 486! Give us your paypal, I'll give you $50 to get a newer computer off ebay. What is wrong with you?

Re:This makes me feel so old and so sad

[Anonymous Coward]

On Slashdot only old people use Windows?

Re:This makes me feel so old and so sad

[Reziac]

[laughing] Alas, no, the trusty 486 was murdered by an evil keyboard back in 1998... but I am still using a lowly P3-550. Now, if everyone here donates $50 toward replacing it, think of the shiny new state of the art machine I could have to run NS3 on :)

One really nice thing about using an old browser: I see more of the content and less of the presentation. Sure makes the web easier on the eyes!

Too bad...

[connah0047]

Too bad MS didn't think of this sooner. They would have avoided a lot of problems.

Re:Too bad...

[Anonymous Coward]

You mean too bad they didn't even need to think of something like this, as ASP.NET automatically renders to the proper markup for the client - be it XHTML, WML or cHTML. How's that being problematic? The model is great and it works quite well. If anything it's just simpler.

Re:Too bad...

[Anonymous Coward]

The problem with the idea that ASP.Net renders correct markup to the client is that you're trusting microsoft to make good html that works across browsers...

ASP.Net 1.0-1.1 render TABLE tags to Mozilla-based browsers and DIVs to IE. The label tags are placed in such a way that formatting them causes linebreaks in all browsers but IE. Asp.Net 1.0 and 1.1 couldn't even generate XHTML and it's only 2.0 that finally fixes this.

I've got no problem with the idea of controls, the 3rd party ones are usually good and take a lot more care in their HTML, but all the controls provided encourage IE-only design, and this does not help wireless clients like OpenWave or Opera.

There's no particular way of breaking up content over pages either, due to lower ram in these devices.

(programmer of .Net and ASP.Net since 2001)

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.

Re:Check your results using Opera!

[Anonymous Coward]

here

Re:Check your results using Opera!

[Anonymous Coward]

http://fedora.redhat.com/download/

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.

Re:Just what the world needs ...

[Anonymous Coward]

+10 genius for not even getting the "In Soviet Russia..." joke right.

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?

[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 (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.

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?

[oneiros27]

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.

Re:Eh?

[jZnat]

So does that make 95% of web developpers incompetent?

Yes.

~J

Re:Eh?

[Anonymous Coward]

Too bad I said almost 10 years ago, CSS level 1 was published in Dec 96 which is 9 years ago. Yes, before the publication of the xhtml spec I used to write well formed lowercase html with closed end tags and quoted attributes, basically xhtml1.0. That's going back around 7 years, but we began seperating markup and presentation well before that.

I only do XHTML 1.1 strict w/ CSS myself, but I don't think it makes me superior or more competent than others.

Spare us the false modesty, who are you kidding? You know full well the benefits of xhtml or you wouldn't be serving it.

And as for ASP.Net, then you don't really know how it works it seems.

It doesn't work, that's my point! You might think ecommerce sites would work without the developers expecting to run scripts on my machine? Before the days of ASP.NET I used to look at the page source and figure out the URL manually or reconstruct the form for POST requests (those that needlessly required silly javascript checks). With the advent of viewstate and doPostBack I simply buy from elsewhere when I come across a broken ecommerce site.

the number of users with non-JS browsers today is quite small - under 0.1% of all my visitors

Javascript is the cause of the majority of web browser vulns, it also enables phishing and XSS exploits. It isn't that I don't have browsers with javascript, it's that I know enough to disable it for security reasons.

Re:Eh?

[Anonymous Coward]

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.

Sniff the client ACCEPT header and kick out the required VARY header with a MIME of application/xhtml+xml for anything that supports it and text/html for older browsers. This isn't actually content neg because the document is XHTML, just served incorrectly as text/html to legacy browsers. Not difficult at all, we've been doing this with a simple CGI on all our sites since 2000.

Re:Eh?

[holloway]

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?

[Anonymous Coward]

Funny, considering the specs for XHTML and CSS 1 are only about 5-6 years old.

CSS1 was December 1996, that's 9 years; laugh it up ;-)

IE still doesn't display some CSS correctly

Yes, the box model is completely b0rked and it's held back development of the web. If more developers had written to W3C recs instead of Microsoft's browser, things may be different.

Netscape 4 barely knows what CSS is

This is why stylesheets are imported, NS4 gets unstyled content.

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.

IIRC Google are working on making GMail's basic functionality availiable to the noscript crowd. Maps partly works, local works, base works...

All webpages should work without client script!

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.

I suggest you write to the standards and file bug reports with the vendors, if we'd all done this instead of 'fixing' pages for IE, todays web would be a little more advanced.

Re:Eh?

[handslikesnakes]

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.

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.

Re:Eh?

[Anonymous Coward]

Which guidelines are we talking about?

The XHTML spec itself, http://www.w3.org/TR/xhtml1/ sez, "XHTML Documents which follow the guidelines set forth in Appendix C, "HTML Compatibility Guidelines" may be labeled with the Internet Media Type "text/html" [RFC2854]"

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.

Well try reading the spec next time, bucko.

I agree with the separate issues about XHTML compatibility -- it certainly isn't complete and they have much work to do.

However it's not black and white, and your idea (which by the way isn't backed by any W3C spec) that XHTML compliance is all or nothing is wrong. It's compliant to the level that it's compliant, no more and no less. You don't get to round the result to the nearest whole number and claim any more authority than an op-ed piece. You certainly don't have the W3C behind you on this one.

XHTML and, indeed, HTML were designed to be forward compatible and this nature means partial compatibility.

Get over it, nerd.

Re:Eh?

[holloway]

^^ he isn't me, but he may as well be.

Re:Eh?

[Bogtha]

Which guidelines are we talking about?

The XHTML spec itself

That is talking about what you need to do in order to be a conformant producer of XHTML. It has nothing to do with what you need to do in order to be a conformant consumer of XHTML.

However it's not black and white, and your idea (which by the way isn't backed by any W3C spec) that XHTML compliance is all or nothing is wrong.

I never said that it is all or nothing. But you seem to think that 'nothing' is compliant. Surely Internet Explorer failing at everything that separates XHTML from HTML means that it is not compliant?

It's compliant to the level that it's compliant, no more and no less.

Now that's just silly. This isn't a sliding scale, something is either conformant or not, you can't just say "oh, well it does its best, therefore it's a bit conformant. The specification you just referred to includes a section on what it means to be a conformant user-agent. Internet Explorer is certainly non-conformant. It fails the very first requirement. I quote:

A conforming user agent must meet all of the following criteria:

1. In order to be consistent with the XML 1.0 Recommendation [XML], the user agent must parse and evaluate an XHTML document for well-formedness.

Re:Eh?

[rho]

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 great example of How To Do It Well.) But there will be many, many sites that will flat out fail on a phone or Palm/Treo for a while yet.

Re:Eh?

[jZnat]

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?

Re:Eh?

[jZnat]

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?

[Anonymous Coward]

I never said that it is all or nothing. But you seem to think that 'nothing' is compliant. [...] This isn't a sliding scale, something is either conformant or not,

How do these two sentences not contradict? You are clearly wanting to marginalise IE's support for XHTML by rounding down what compliance it has to zero. This is not a black and white issue, and the W3C do not support your idea that partial compliance means no compliance. Instead they reasonably state what has to be done.

Re:Eh?

[Anonymous Coward]

Try again. CSS1 didn't even have any layout and so it was not capable of meeting your requirements of seperating style from content. (no, css floats don't count)

Re:Eh?

[Baricom]

Am I being naughty if I'm serving XHTML 1.1 with application/xhtml+xml only to browsers that support it?

Yes.

Re:Eh?

[jZnat]

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?

[handslikesnakes]

Well, my biggest problem with that is that it doesn't take q values into account; I could accept application/xhtml+xml, but prefer text/html, a possiblity your script ignores.

The second problem is that you're lying about the page's content. Easily fixed with an s/1.1/1.0 Strict/ (please don't actually use this as there's a bit more to it than that); better fixed with some really simple XSLT (which is what I do on my website).

The third (potential) problem is that there are differences in the way CSS and Javascript work that can trip you up.

Unlike some, I have no objection to serving XHTML 1.0 as text/html (since it's explicitly allowed for if you follow Appendix C), but doing the same with XHTML 1.1 isn't allowed, and seems like nothing more than buzzword compliance. Unless you're using Ruby, the differences are pretty insignificant so you have no reason to anyways.

Re:Eh?

[gaspyy]

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

That's bullshit.

It's 2005; 10 years ago was 1995 - Netscape 2! I don't think CSS was even on the drawing board. Actually, I don't remember if Netscape 2 had the font tag.

XHTML and CSS-based layout have become viable somewhat since IE5 (painful but doable) and actually worth doing since IE6/Mozilla (2001?). (Netscape 4 and IE4 had CSS capabilities but doing a cross-browser table-less layout was not worth the effort).

Re:Eh?

[Anonymous Coward]

You need to send a HTTP VARY header if you're doing that. You don't have to do q vals because this is a workaround for a legacy browser and not content negotiation.

Re:Eh?

[handslikesnakes]

Yeah, forgot to mention Vary. I don't see how your statement about q values makes any sense though; if you're changing your response based on one of the Accept headers that's content negotiation by definition.

Re:Eh?

[jZnat]

I forgot to mention that if the user is served text/html, he is also served the XHTML 1.0 Strict doctype instead. Anyhow, I prefer to use XHTML 1.1 in my program because it enforces valid XML, and it will render according to standards compliance rather than quirks mode. The standards compliance mode for text/html isn't as strict as the one for application/xhtml+xml, so it's possible to introduce weird quirks into the styles when using text/html.

Thanks for the advice regarding the q= bit of the user agent; I never really considered that. I think I'll attribute your statement in the source for it as well. ;)

Also, thanks for the link to hixie.ch's XHTML rant, but I've read that months ago. I already know all the oddities of serving XHTML as application/xhtml+xml (including the background of the document being styled to the root element; I do that on normal text/html pages in the first place). I send JavaScript (the _single_ script I have so far) as application/javascript. I use the business. I'm also looking into what other accessibility or news-feed XML namespaces I might be able to include. I'm used to doing XML stuff, so XHTML is simply just another XML format to me (with its namespace being at http://www.w3.org/1999/xhtml). Since nearly everything is formatted in PHP, I've found that applying XSL[T]'s to my documents would be somewhat pointless. At least MSIE supports client-side XSL, right?

Re:Eh?

[handslikesnakes]

Well then, it's nice to meet someone who knows what he's doing with respect to XHTML. Kudos. (btw, I hope your PHP can guarantee well-formedness. it's one of the nice things about XSLT)

Re:Eh?

[Bogtha]

How do these two sentences not contradict?

You don't have to support everything in the specification in order to be conformant, so it's not "all or nothing". However, the specification lays out specific requirements as to what can be called conformant, and you have to follow all of them in order to be conformant. So it's not as contradictory as you might think.

You are clearly wanting to marginalise IE's support for XHTML by rounding down what compliance it has to zero.

What support for XHTML? What compliance? It doesn't have any! I listed everything I could think of that separates XHTML from HTML, and Internet Explorer fails to do any of them. I linked you directly to the W3C definition of a conformant user-agent, and Internet Explorer clearly fails.

Instead they reasonably state what has to be done.

And Internet Explorer doesn't do it.

Why retrofit?

[Anonymous Coward]

If you create a web page that is clean, well structured and doesn't rely on stupid things like Flash, it should be viewable with wireless devices without any changes.

Re:Why retrofit?

[grolschie]

Actually Homestarrunner.com looks pretty decent on my Pocket PC - and it's 100% Flash website. Some of the print is a little tiny in places though. Now I can check my Strong Bad emails from my Pocket PC.

External CSS?

[TheRaven64]

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

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.

Re:External CSS?

[maximander]

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

Re:External CSS?

[Bogtha]

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 it doesn't work in most browsers.

Re:External CSS?

[Anonymous Coward]

4. Fetch CSS (another long wait).

Long wait?! Maybe if your local cache is stored on a Commodore 1541 floppy drive.

Re:External CSS?

[Dj Offset]

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.

A better fix is XSLT

[ishmalius]

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.

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:How many care? And misleading title

[Matt Perry]

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.

Works fine on my laptop, why modify?

[slashkitty]

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?

Re:Works fine on my laptop, why modify?

[wootest]

Cellphones. PDAs.

Re:Works fine on my laptop, why modify?

[slashkitty]

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.

Re:Works fine on my laptop, why modify?

[wootest]

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 hope that the plethora of very varying mobile browsers can all figure out how to render a complex layout designed for a four to six times wider screen correctly. If you put any effort at all into making your site accessible to mobile browsers, you had better have a grip on how you can tailor it to look good in them specifically, and not just acceptably shrunk down.

Re:Works fine on my laptop, why modify?

[BorgCopyeditor]

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.

Re:Works fine on my laptop, why modify?

[Tony Hoyle]

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.

Re:Works fine on my laptop, why modify?

[wootest]

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 for layout, coincidentally - includes a part on browser display that can be quite telling in this kind of comparison: http://www.alistapart.com/articles/slashdot2/

Re:Works fine on my laptop, why modify?

[Hast]

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.

This site did the same thing not too long ago

[Cytlid]

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

[Kroc]

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.

Re:Except that...

[Anonymous Coward]

WTF are you smoking? All of the Nokia smartphones contain fully capable xhtml browsers, and the CSS support is fine too AFAIK. And the point in making pages for handhelds is not in making the same CSS file work across desktop computers and phones, but instead either making a special CSS file for the handhelds, and/or making sure that the pages work without CSS (which everyone should be doing anyway).

Re:Except that...

[Ksevio]

Many phone/pda devices use the mobile version of Opera which is fully capable of rendering HTML and CSS

wireless or not

[Anonymous Coward]

firefox still displays the content the same on my laptop

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/

In case I'm offtopic...

[ishmalius]

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.

Re:In case I'm offtopic...

[moro_666]

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

Re:In case I'm offtopic...

[Nasarius]

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.

It Was An Itsy Bitsy Teeney weeny....

[rueger]

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.

Re:It Was An Itsy Bitsy Teeney weeny....

[Tony Hoyle]

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

Re:It Was An Itsy Bitsy Teeney weeny....

[mp05]

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

Re:It Was An Itsy Bitsy Teeney weeny....

[Prophet of Nixon]

Frankly, they're only really good for making phone calls, and in a lot of areas around here, they're not even good for that. Just crappy battery powered paperweights. I really can't understand the popularity of the things. Who wants to be chained to a phone anyway?

oh, the irony...

[lampiaio]

couldn't resist...

I just love extreme statements :)

[Stan Vassilev]

"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 things work best flexible (body text, probably fluid column layout etc.). 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 (and we know columns are far from easy to implement with today's browsers). Most images should be stripped for mobile CSS so the rest can be flexible and stretchable, but it's far from a "never" situation now, is it. But of course I confirm that setting fixed page width in a mobile CSS is quite ignorant from the article's author.

Re:I just love extreme statements :)

[martinX]

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

Re:I just love extreme statements :)

[Stan Vassilev]

"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 :)

How about some common sense instead, Brainiac?

[Anonymous Coward]

- don't use frames...

- text-only on main page...

- don't get fancy...

- most Web pages nowadays suck the big one...

- keep it simple...

- keep it PDA-friendly...

- Flash? Fahgehtaboutit!

- whatever happened to WAP?

Cameron Moll did a great series on 'mobile' design

[ubernostrum]

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

take a look for yourself:

[YesIAmAScript]

Looks good on Safari.
live image resizing in-browser

Use SVG

[Dj Offset]

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.

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?

Re:practical yes, good no ...

[Nurgled]

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 just a few extra DIVs and SPANs.

Wireless compatibility?

[davygrvy]

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

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.

but what about devices w/ no CSS support?

[RevAaron]

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

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

Cellphones don't have that much capability

[billstewart]

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.

Basically, if you want to support mobile browsers, you need to get rid of Flash, Javascript, and frames, and put the main navigation into brief text at the top of the page, and try not to be too wordy about it. In other words, make pages that Netscape 1.0 and Lynx could have rendered well, and you're off to a very good start.

Developing for Mobile Devices

[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 usable content that works.

The reason for point 2 is this: phones suck. They do. They have small buffers, in some cases less than 30k. They may also have 80mb of onboard flash for mp3 ringtones, photos and videos - but the browser buffer is still 30k. So I don't care if you've "hidden" some of your page using CSS - it's still taking up "space" in the downloaded file size. XSLT can be your friend here - both WML and XHTML-MP are sensible mark-up formats to mash around with XSLT.

Maybe this is more of an issue in Europe than in the US - but certainly in the UK, where I am, you can't just quickly repurpose your site - the content needs modifying to be servicable and the mark-up needs to be kept trimmed right down. Hell even 02 with their fancy new i-mode service are setting a 10k page size limit for content providers.

Caching

[ishmalius]

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 still only be a Luddite empirical black-box person. Oooh, the mystery of tech.

You should listen

[dada21]

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.

Re:You should listen

[denebola]

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.

Re:You should listen

[denebola]

The link doesn't like the trailing slash.

Try
http://www.internetworldstats.com/top20.htm

Re:You should listen

[matfud]

Have you tried wap.google.com?
Yahoo is reputed to be launching a site that will convert all serach result web pages into something more suitable for your phone. Not just wap phones either.

Re:I used server-side PHP to generate pages...

[__aaitqo8496]

Clearly you haven't been to CSS Zen Garden. The main page isn't that terribly exciting, but if you check out the designs it showcases, you might think differently [about CSS].

It's amazing what just a change in CSS can do (as CZG articulates). Go ahead and test it in different platforms.

Good page design is about a good designer.

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.

800x600 is good enough

[twistedcain]

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 and news. To post to a forum with your phone you will need a separate keyboard (unless you want carpal tunnel) and if your going to carry around a separate keyboard, then you might as well buy a laptop. Since I can't compete with google news and don't run a forum, I see no reason to bother. They can still view my website, it just doesn't look very good, but what really looks good on a tiny screen anyway. I have yet to see a huge demand for the new line of 13" home LCD monitors.

Re:800x600 is good enough

[ModMeFlamebait]

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.

don't worry, we aren't gonna bend over to watch your fucking ads either.

Re:800x600 is good enough

[Anonymous Coward]

You must be one of those people who work for free, I suppose you used honey and trinkets to buy the computer to type your message. It is wrong of people to want any type of compensation for their work, you are correct, we should all work for free.

Re:800x600 is good enough

[geminidomino]

I have to agree with GP. If it's that all important for them to get paid by the viewers, then they can very well make a pay site or ask for donations. If their business model is flawed enough that adblock can break them, that's not our fault.

Re:Wireless device browser compatibility isn't eas

[PaschalNee]

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]

The XHTML MIME type and XHTML Basic

[zoeblade]

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. 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 intended specifically to make sites easy for mobile devices and such to swallow: XHTML Basic. From W3's site:

It is designed for Web clients that do not support the full set of XHTML features; for example, Web clients such as mobile phones, PDAs, pagers, and settop boxes.

I've never felt a need to use regular XHTML for my home projects, as XHTML Basic is more than enough, but I use the latter at work. Oddly enough, the article doesn't even seem to mention XHTML Basic.

Ambiguous story title

[innit]

"Wireless" in the United Kingdom means wifi - wireless networks, whereas "Mobile" means cellular phones. It's damned confusing when mobile phones are referred to using the single word "wireless". My initial instincts were to question what differences there would be between a web page received over a wireless connection versus a normal wired connection.

Opera's site has more useful tips

[menesis]

In Opera's site there are more useful tips for developers, see Authoring for Small-Screen Rendering (SSR) and linked pages. Not a lot, but much more than in this article which still assumes web developers don't know the benefits of XHTML, CSS and how to make the stylesheet external, and doesn't go much beyond hiding images and document order.

link tag doesn't work?

[subtropolis]

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

Re:link tag doesn't work?

[Bogtha]

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 tag, but that's focusing on it as a detail of syntax, where most of the time people want to talk about structure, in which case, element is the correct term to use. Rferring to the latter as a tag is completely incorrect though.

PS: it seems Opera 9 pays attention to this HTTP header now too, although it doesn't suffer from the FOUC bug that Gecko does.