Slashdot Mirror
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."
Why should you specify pixel dimensions on images? If you specify font sizes in points and image sizes in pixels then your web pages will look different at different screen resolutions. Scaling images is very easy - most graphics hardware (even 10-year old 2D only cards) can do bi-linear interpolation, and many newer ones can do bi-cubic interpolation, allowing very high quality scaling of images without using the CPU, so there's no reason not to expect a browser to be able to scale images (even in software it's hardly processor intensive, compared to decoding a PNG).
I am TheRaven on Soylent News
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.
Safari (and possibly other OS X browsers) do what the GP is suggesting, and it looks good up to about 400%.
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.
Funny, considering the specs for XHTML and CSS 1 are only about 5-6 years old. And considering that IE still doesn't display some CSS correctly I seriously doubt that "competant developers" have been using it "for nearly 10 years" to "display on any media and any UA". Netscape 4 barely knows what CSS is, and 10 years ago, it was one of the top dogs. And I also find it funny that "javascript doesn't work cross-browser" but Google seems to be using it just fine. Seems to me that the main browsers (Mozilla-based and IE) handle the ECMA version of Javascript just fine, and once Apple gets some things taken care of in Safari, it'll work fine too.
I've actually been trying to do some of what TFA has been talking about, but even then I get stymied by buggy wireless browsers that crash if you have a "screen" stylesheet and a "handheld" stylesheet in the same document, or crash if you load more than 8k of text and images, or fail to load the page if you have more than one image. I wish it was as easy as TFA talks about.
... And so it comes to this.
"Have you ever even SEEN an image that's been resized by the browser? They almost always look like crap."
Opera performs nice filtering on images when you magnify the page. Also, the browser that comes with the Palm Pilot also does a really nice job of resizing images. Internet Explorer, as of version 5.5 at least, does not do nice filtering. (i'd be curious to know if 6.0+ was modified since I've discovered it will nicely resize stand-alone images too big for the page.) It's up to the browser.
Somebody else mentioned that pages scale up nicely on the Mac. I need to second this. My cousin has a really nice Apple laptop. He showed us a movie trailer on it. He just magnified the whole desktop (browser and all) to show the trailer, and it worked really really well. People around here bitch about eye candy, but man, I have to give credit to Apple for making it that useful. (Unrelated topic, but I was also pleasantly surprised by how well the speakers on that laptop worked. My Toshiba laptop sounds like a Game Boy in comparison.)
"Derp de derp."
You mean other than the fact that the two most widely used browsers in the world still perform crappy no-interpolation nearest-neighbor image scaling, and yet somehow still manage to suck up gobs of CPU time doing it? (I'm talking here about IE and Firefox, of course.) If you expect a user's browser to have nice image scaling, you will be wrong 99% of the time. It's a ridiculous situation, in this age of dedicated 3D rendering hardware in nearly every PC. A 3D card's *primary function* is drawing scaled and warped images with nice interpolation!
I believe Opera and Safari do perform decent image scaling. I haven't heard if IE7 will, but I doubt it. Firefox 3 is moving to Cairo for graphics, which should allow it to leverage OpenGL-capable graphics hardware for scaling images with nice interpolation. But Firefox 2 will likely still be using the same old terrible image scaling we've been living with for years.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
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.
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.
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:
- Fetch and parse HTML while downloading (this usually makes you wait)
- Retrieve any CSS and frames (pipeline on established connection)
- Parse CSS and request inlines (pipeline on established connection)
- Render & display
- 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.
like the subject says- what about those devices with no CSS support? they're around enough, not all that rare. not everyone has a brand-new Microsoft Smartphone/WM5 phone, with the closer-to-desktop browser, or NetFront, which is even better. All that fancy CSS might look great in a 200x160 sized window on your desktop in trying to emulate a wireless device, but with those non-CSS devices out there it might just look like crap.
just a thought...
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
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:
- Fix all validation errors and warnings.
- Replace Javascript menus, or provide alternate text menus wrapped in NOSCRIPT tags.
- Add alternate plain HTML to any Flash OBJECTS.
- 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.
- 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.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.