Pocket-Sized Design: Taking Your Website to the Small Screen

Among the many websites that are out there, few are standards-compliant. Among those few, only a handful sport style sheets adjusted to the needs of handheld devices. Of those which do offer styling for handhelds, not all will fit the smallest, lowest-resolution screens without presenting the user with the ultimate handheld horror: namely, horizontal scrolling.

Article Continues Below

The Opera browser runs on handheld devices of all screen sizes and resolutions, some of them only 120 pixels wide. We work for the company that produces Opera, so we can offer a degree of insight into the functions of Opera for handhelds. In this article, we’ve prepared a set of general suggestions for creating a handheld-friendly style sheet, along with a few Opera-specific pointers that you may find useful.

The Constraints#section2

The main limitation of a handheld device is the small screen, which may also lack a mechanism for horizontal scrolling. Input is often with a stylus, not a mouse. Downloading to the device is likely to be both expensive and slow, the processors are slow, and the memory is limited. A lot of users may therefore choose to turn off in-line image loading.

Now, what do these limitations imply for the designer?

    • Design one column layouts and avoid floats.
    • Optimize your HTML by using efficient, semantic markup and CSS.
    • Minimize the use of decorative images, avoid relying on images or plug-ins for navigation.
    • Write good alternative text for images.
    • Avoid dynamic effects that specifically require a mouse or keyboard for navigating.

Scaling it Down#section3

Even if the screen resolution of devices increases with time, the physical width will not be much wider than your pocket. The most significant implication is that you can’t sensibly fit more than one column of text on the page. You also want that column to be as wide as possible, so that the column of text doesn’t turn into a ragged-right poem.

First off, avoid using pixels for anything larger than 5px (really!). Pixel sizes larger than that will scale badly, so use ems or percentages for larger sizes.

Reduce margins, padding, and border widths to suit the small screens. 3em before a heading is perfectly reasonable on the screen, but it is excessive on a handheld device. Wide borders should be slightly narrowed and the padding adjusted to match. In some layouts it helps to reduce redundant borders and spacing; they will seem squeezed-in on the smaller screens.

Large text looks awkward and eats up a lot of room on small screens. Large type, therefore, should not be larger than twice the size of paragraph text, and there shouldn’t be very much of it. Small type should also be kept closer to paragraph size than on the desktop.

Keep the text blocks as wide as possible by using only small amounts of horizontal spacing. 1em of indentation is a lot on devices with narrow screens, so in most cases, margins and padding in the horizontal direction should be no more than 1em. As percentages scale with the width of the display, specifying a margin in percentages instead of ems will work well on a wide variety of screen sizes.

Linearizing the Layout#section4

Linearizing the page into one column works best when the underlying document structure has been designed for it. Structuring the document according to this logic ensures that the page organization makes sense not only in Opera for handhelds, but also in non-CSS browsers on both small devices and the desktop, in voice browsers, and in terminal-window browsers like Lynx.

Assuming that you are using CSS for your layout, collapsing the layout into one column is fairly simple: just leave out or override the rules that add floating and absolute positioning behavior.  If you are using tables for layout, make the cells behave as a sequence of blocks by using:

table, tbody, tr, td, th { 
display: block; }

The top of the page is prime real estate; you do not want the reader to get bored scrolling to the content. Therefore, minimize the navigation and decoration at the top. A logo and one or two small navigational elements, such as a short navigation list, breadcrumbs, or a search input, should be enough. Long navigation lists, advertisements, and other marginal content should go after the main text. For most layout schemes, this corresponds to putting it in the right sidebar (as opposed to the left) for desktop layouts. A List Apart’s XHTML structure is excellent in this respect.

Inessential navigational elements should be hidden using display: none. For example, if you are using dynamic drop-down menus across the top, make the menu’s title a link to that section of your website and hide the menu of subsection links. This makes the navigation less top-heavy, and if your site is well-organized,  shouldn’t cause much navigational difficulty.

Preventing Overflow#section5

Because their screens are small and the device may not always have a horizontal scrolling mechanism, overflow in the horizontal direction is a major problem on handhelds. In addition to letting content wrap into a single column, you need to make sure wide elements fit the narrow screen.

Fixed-size elements include images and form controls. Assign them max-width: 100% to keep them within the viewport.

For preformatted blocks (<pre>), either wrap the text very tightly (25-30 characters) or allow long lines to break. You can allow line-wrapping by adding the following CSS rule to your style sheet:

pre { white-space: -pre-wrap; 
    /* Opera CSS Extension */  
      white-space: pre-wrap; 
    /* CSS 2.1 Addition */}

Beware of fixed positioning. A fixed-positioned element that overflows the viewport is completely inaccessible.

Dropping the Dynamic Effects#section6

Opera for handhelds supports the same dynamic effects as Opera for the desktop. However, a lot of dynamic effects that work well for the screen just do not adapt well to the handheld. Features that are a bit annoying on the desktop become even more annoying on handhelds.

Don’t use frames or pop-up windows. Although Opera can display frames on handhelds, they make navigation and display painfully awkward. Multiple windows are also far more unwieldy on a handheld than on a desktop, so keep all links going to the same window.

As with desktop layouts, make sure navigational elements are accessible even without the mouse. Keyboard events don’t necessarily apply, either; interaction on handhelds is often only with a stylus, which does not track keypress or hover events and cannot right-click or double-click.

Reducing the Images#section7

Mobile phone operators delight in charging per kilobyte of transfer, making image-intensive sites both slow and expensive to download. This often causes users to browse with images turned off to save time and money.

You can make your design less image-intensive by:

  • Hiding unnecessary images with display: none so that Opera will not bother to download them.
  • Using real text for navigation labels and headers.
  • Telling Opera to use an image’s alt text instead of loading the image itself:
img.as-text { content: attr(alt); }

For the images you do include, set the width and height attributes so that the page can be laid out in its final form even before the images are loaded. Also, images designed for the desktop often do not scale well to the small screen. Crop, scale down, and/or size-optimize images targetted at handhelds.

Don’t forget to write meaningful alternative text. The idea is to replace the image, not to describe it. If the image is purely ornamental, the alt text should always be the empty string (”“).

Optimizing the HTML#section8

Use efficient, semantic markup and leave the presentation to CSS. CSS is more powerful, more compact, and does not clutter the document with redundant presentational data. Although this is good authoring practice for all media types, it does become even more important when authoring for handheld devices.

  • Don’t overdose on class, <div> and <span>. If there is a more appropriate HTML tag, use that and subclass if necessary. If the element is not actually necessary, take it out. If you can select based on context, do not introduce another class.
  • Choose the tags that best convey the purpose and structure of the content. Semantic HTML tags have universally-recognized meanings, which font changes and author-defined classes don’t. Among other advantages, meaningful markup allows non-CSS browsers, which are more common on small devices than on the desktop, to present the reader with a coherent display of the page content. Semantic tags are also a lot shorter than div+class combinations, leading to smaller file sizes.
  • Create semantic, not presentational, class/id names. If your code explains why you are styling an element rather than how to style it, the markup is not tied down to one particular presentation. The styling and the layout can then be easily and intuitively changed independent of the markup. Code designed this way is usually also much more compact and readable.

Place repeated scripts and styling in external files. This lets the browser cache them, which reduces the download requirements for subsequent pages from the same site.

Making Opera Use Your CSS#section9

Now that you know how to design for a handheld, you have to make sure it is enabled in Opera for handhelds:

Opera works under the assumption that most web pages are not designed for handhelds. If “fit to screen” is enabled, which it is by default on most devices, author styles are ignored and pages are reformatted for the small screen unless the page has a style sheet specifically aimed at handhelds.

To let Opera know that a handheld style sheet is there, specify “handheld” in the media attribute for <link> or <style>, or use an @media or @import rule targetted at handhelds in your in-page CSS:

<!-- --><link rel="stylesheet" href="..." type="text/css"
<!-- -->      media="handheld">
<!-- --><style type="text/css" media="handheld">...</style>
<!-- --><style type="text/css">
<!-- -->  @media handheld { ... }
<!-- --></style>
<!-- --><style type="text/css">
<!-- -->  @import url(...) handheld;
<!-- --></style>

If the style sheet also applies to other media (or to all media), list all of the media types in a comma-separated list and make sure to include handheld explicitly. For example:

<link rel="stylesheet"

As long as at least one style sheet has handheld among its list of applicable media types, Opera will disable SSR and use all style sheets targetted at handhelds (including style sheets without a specified media or with media=“all”). Opera will not download external style sheets to check for @media or @import rules for handhelds before deciding whether or not to disable “fit to screen”. You must declare the existence of a handheld style sheet in the HTML page itself.

When your design is finished, be sure to test it. If you do not have access to a device running Opera, you can make the desktop version emulate a handheld device by pressing Shift+F11.

Looking Good#section10

To illustrate the above approach to adapting a site design to handhelds, we have made an annotated ALA style sheet for the “handheld” media type. It is available from https://alistapart.github.io/code-samples/pocket/handheld.css. You an see it in action by viewing https://alistapart.github.io/code-samples/pocket/ with a handheld-mode browser.

Opera has found a way of dealing with the fact that only a tiny fraction of the web is adapted to the devices that an increasing number of people carry around in their pockets and purses. On an ideal web, Opera might not have to pull all these tricks to make pages fit. However, we hope that more and more web authors will gain an interest in pulling their own tricks to make great designs for the “handheld” media type. It is hard, but hardly impossible, for a website to look fantastic on small screens.

Related articles#section11

Making Small Devices Look Great by Jonny Axelsson

A Touch of Class by Tantek Çelik

Designing for Context with CSS by Joshua Porter

Going to Print by Eric Meyer

56 Reader Comments

  1. Great write up. I have been using a handheld browser for a month or so and have noticed that standards-based sites are easier to load and read. I use webPro used on Palm.

    My only concern is that I have read that some handheld browser developers are looking to make their products render a page so it would render like it would on your computer, using your screen css files, instead of the handheld css. Anyone else seen that?

  2. I’ve been looking for a good article to point people to when it comes to handheld design, and I think this is a great starter. Nice work.

    Blake (above), I believe that Microsoft is doing just what you proposed with PocketIE on the PocketPC. I don’t have access to a PPC though, so I wouldn’t know exactly how it works.

  3. Great article. Would be nice to see accompanying screenshots grabbed from a handheld for those of us without connected handheld devices.

  4. Good article indeed and I hope to see even more on subject of handheld devices.

    Blake, I once tried Nokia 6220 for web browsing and this phone used the first css file found in the code. The layout, some colors, some backgrounds looked like in the browser of the computer — just narrow browser window and see what it looks like. Besides some text overlapped. In a word it was a mess 🙂 If phone sometimes failed to load css file, the page looked OK.

  5. The CSS rule to linearize layout tables is a good one (Do any regular readers of ALA still use layout tables though?) but, what about complex data tables? Using that rule would be disastrous for comprehension of the table.

    Seems to me that the handheld user faces the same problem as blind users: linearizing data tables in a manner that makes sense. Seems to me that this is an issue that transcends CSS. HTML4 and XHTML have markup that, if properly supported, would aid greatly with this problem.

  6. these handheld machines are going to follow the same path laptops did 15 or 20 years ago. first the screens were not compatible with desktops available at the same time, and special workarounds were required to display data on the smalkler resolution screens. they sold a few laptops like that to early adopters, but laptops really took off only after they got 640×480 resolution, which DID match what was available in standard displays.

    the same thing is going to happen with these handhelds. in my opinion it is a waste of time to design special code for smaller than usual screens. (unless you work for a company that makes them or uses them — and then you have to.) Simply wait for them to acquire 640×480. that is the solution.

  7. While it is not in question that the technology will improve, there are still concerns with handheld devices that need addressed. A handheld device, by definition, will always be relatively small. If you try to display a 640×480 screen designed for a monitor at 2 inches wide, the text would be much too small to read. Handhelds need special consideration for this and I think this article does a good job of expressing them.

  8. ‘media=”handheld,all”>’

    I’m tempted to disagree with this method. Surely by simply declaring “all”, this should include handhelds as well. Why do we need to specifically include “handheld”?

  9. Chris Hester – “I’m tempted to disagree with this method. Surely by simply declaring “all”, this should include handhelds as well. Why do we need to specifically include “handheld”?”

    I assume Opera did this because a lot of sites use media=”all” when what they really mean is media=”screen, projection, print”.

  10. …sadly most handheld devices I come across don’t support the handheld media.

    That is… most phones, and some pda’s.

    However, ignoring the practicalities for a moment – great tips, and good advice, hopefully the technology will catch up with the standards some day.

  11. Does anyone know if there’s a way of serving up an unstyled version of a site to handheld devices? It seems to me that if a site is semantically coded, it should look and work just fine without ANY style sheet at all.

  12. “I believe that Microsoft is doing just what you proposed with PocketIE on the PocketPC.”


    If you declare your screen CSS as @media screen{), it will not be rendered by the PPC. If there is no media declared, Pocket IE will attempt to render it. Or so has been my experience.

  13. The page with the handheld stylesheet is a nice demo and looks great on my PPC, but why isn’t the rest of ALA using this stylesheet as well? I have to put up with Pocket IE’s vain attempts to ‘fit to screen’ a site that simply isn’t designed for it.

    Guess I’ll continue reading ALA on my desktop for a while yet.

  14. Thanks for including a sample CSS file, which gives a lot of clues. A very useful pointer to start working on a handheld stylesheet.

    Can anyone confirm that the iPaq emulator pointed at in one of the previous comments is indeed an emulator that is close to what happens on an iPaq?

  15. It would be good if there were more emulators or others ways to see how a site design would look on a handheld when you don’t have one to test against.

    There was one handheld emulator available before which turned out to give inaccurate renderings, i’m not sure if that’s the same one mentioned above. Maybe browsercam.com can add handheld devices to their website preview tool.

  16. Like the article a lot!

    However, I’d like to warn everyone that the W3 CSS validator currently has a bug that causes it to claim all your CSS intended for handheld media (as indicated by the media attribute in the tag or @media in the CSS) is invalid when it is in fact valid.

    They seem to be aware of the bug:

    Hopefully it will get fixed soon. Until then don’t panic! 🙂

    Btw, I’ve got a Nokia 6600 (a Symbian Series 60 phone) and it’s built-in Series60 browser seems to find and use handheld stylesheets correctly. However it seems to omit any background images that you specify. Hope that info is of use to y’all.


  17. Great idea. I think every ALA page should have a style switcher, CSS for handhelds, a rotating image, a better rotating image, sliding doors, highlighted search terms, horizontal drop down menus, suckerfish dropdowns, dynamic text replacement, zebra tables, references to “Oz” and four kinds of drop shadows!


    Seriously though, practical enhancements like CSS for handhelds usually make it into the main ALA design, but they are not usually available the second an article goes live.

  18. The so called pocket PC emulator, to which John Ivanoff refered, is not a real emulator. It uses the rendering engine of the browser it is viewed with and doesn’t apply handheld stylesheets at all.
    OpenWave browser (used on a lot of Japanese cell phones) emulator download: via http://odn.openwave.com/downloadManager.ow?softwareId=3 (registration required) or else http://developer.openwave.com/ja/tools_and_sdk/openwave_mobile_sdk/SDK62K/ (for the Japanese version, click the link under the export declaration, no registration required).

  19. I have to agree with a the posts here that state trying to style stuff on handhelds it near pointless. I have to get my sites working on Blackberry devices and they at least make it a sort of easy by plainly not supporting CSS at all. Generally I’ll say that relying on style to get things working on a handheld is a bad idea, since so few handheld browsers support it properly.

    I also agree that we don’t have long till these things get reasonable res screens which will also resolved most issues.

  20. I dont’t believe stylesheet is enough to solve this. You have to simplify your content a lot, by offering not only alternate (media=’handheld’) stylesheet, but by complete re-write of your website. With some CMSs, this is easily possible, you may see e.g. regular demo version of BLOG:CMS ( http://demo.blogcms.com/ ) and it’s mobile version ( http://demo.blogcms.com/wap.php ). Quite a difference, right?

    Btw, BLOG:CMS is one of very few systems that ship with “mobile” skin in a default package.

  21. Great article, but is it really worthwhile to go through all that work for the small number of people that will use it?
    I just specify a stylesheet for screen, and a stylesheet for print. Anyone else gets no stylesheet. This gives a very basic, no-frills, page to other devices, which is what I assume a handheld user is looking for.

  22. In response to the various posts saying that handheld style sheets are not worth it:

    If you code your HTML cleanly and with proper semantics, your page will display just fine in a handheld browser. It will know how to interpret the markup and can display the content in a way that reflects those semantics. This is why standards-compliant sites render better: they’re marked up properly.

    Most pages out there are designed for desktops only and/or still use tag-soup coding methods. (Think table layouts with spacer gifs and text marked up with only tags and
    .) Opera has special modes like SSR (“Small Screen Rendering”) that use heuristics to make sense of the tag soup and display something reasonable. This involves collapsing columns, shrinking images, dropping images, overriding font sizes and colors, ignoring fixed widths and heights, and using other tricks to adapt screen-targetted web page designs for a handheld device. It’s a good educational tool: you can compare SSR’s version to your own work and see what makes a design easy to read on a handheld. However, although Opera’s SSR usually does a good job of making the page comfortable to read, it won’t preserve the original page design elements. As a designer, you can leave the job of doing the small-screen adaptation to the handheld browser, which is often sufficient to make it browsable — or you can take control yourself by writing a handheld style sheet.

    Opera’s site has a some tips on coding for web designers who don’t want to spend the effort to design a handheld style sheet. (Much of that advice is just common sense for ALA’s readers.) Instead, we thought it would be more interesting for this audience to include tips on how to design a good handheld style sheet. If you want to put in the extra effort to make a handheld style sheet, this article explains how to do it right. If you don’t, you can skip the sections on CSS and take a few pointers on other things.

    The CSS rule to linearize layout tables is a good one but,what about complex data tables? Using that rule would be disastrous for comprehension of the table.

    The CSS rule in the article would indeed be inappropriate to use straight out of the text; it should be adapted to select only the table elements used in layout tables.


    That post is inaccurate. The ‘name’ attribute can also be used on anchor elements that have no ‘href’ attribute and thus are not links. (The ‘A’ in the element name stands for “anchor”, not “hyperlink”.) This is how HTML defined target anchors before ‘id’ was introduced or well-supported,
    and it is still common practice. ( See Tantek’s post “Anorexic Anchors” for notes on good practice: http://tantek.com/log/2002/11.html#L20021128t1352 )

    Furthermore, the ‘name’ attribute is defined only on a handful of HTML elements, and only as a link target on .

  23. Nice Article.

    One thing I have to say though – I spent many hours about 12 months back creating a handheld css profile for my site. Once Igot it looking OK I started testing it on various phones. What i found is that a lot of phones won’t even load the page as the combination of the CSS, XHTML and images was too large.

    The display:none tag is useless as all the XHTML and images load into the phone anyway. So, I have to go back to a server based option, which requires me to keep on updating user browser strings – painful.

    And then there the IE version on the Smartphone 2002 O/S…

  24. Hi Dan

    “Does anyone know if there’s a way of serving up an unstyled version of a site to handheld devices? It seems to me that if a site is semantically coded, it should look and work just fine without ANY style sheet at all.”

    PHP is one way – I am sure there are many other server based solutions…

  25. I disagree that it is a waste of time to work on making our pages work properly on handhelds now instead of waiting for the technology to catch up.

    Two reasons:

    1) Download requirements – wireless connections available on handhelds sometimes experience spotty network connections, making it even more important to minimize download times.

    2) The technology hasn’t caught up yet – It’s bad business to just write off the folks not possessing the cutting edge technology. Pages should be as accessible to as many people as possible within reasonable limits.

  26. k, I don’t have a PDF to browse websites with but I did take a look at the emulators mentioned in the previous responses and it seems to me that the only place where PDA’s and their browsers are falling short is in displaying font styles. When you look at at http://relay5.yospace.com/ipaqbrowser/ipaqbrowser.html?http://www.alistapart.com/
    you’ll notice that we’ve lost the font styles and we’re getting ugly text. Really if the text were the same as what one usually see’s on the AListApart.com website then I’d be happy knowing that I’m getting all the content that’s on the page effectively. Once can even see the background image in the header for a touch of visual branding. That’s really all you need for a website being viewed through a screen of such small dimension.

    Great read, and enjoyable discussion.

    One suggestion about the format in which the responses to your articles are displayed. I think it would be really nice to see them in a heirarchical format so people can respond directly to a particular response, as in a message board. I guess linking to an automatically generated topic in an existing forum would work perfectly, especially if you could integrate it’s look into the rest of your website.

    Sorry tangental rambling. 🙂

  27. It’s fair to say that a lot of designers don’t design for the future, take the many that ignore standards and will only code for IE. I personally prefer to code once but to take handhelds into consideration when doing so. None of my sites are viewed on handhelds so it’s not high priority at present.

  28. Yeah, well, Opera is not the only browser able to render a web page on a small screen, degrading nicely the contents. Any CSS-aware browser, with a good level of CSS support, can do it using the stylesheet I have written for Mozilla, Mozilla Firefox, and Mozilla Minimo. It is available at http://lxr.mozilla.org/mozilla/source/embedding/minimo/smallScreen.css

    Opera invented SSR, and “Small Screen Rendering” is now a trademark. They have a de facto monopoly on cell phones.
    Elika spent the summer working for Opera, that probably explains why only Opera is quoted in her article.

    But a stylesheet is a stylesheet is a stylesheet 🙂 Only a stylesheet.

    About the article itself, I think it is a very bad approach to ask web authors to write with small screens in mind. The right approach, IMHO, is “make your web site as usual, and let us, the browser vendors, do our job so your web site appears readable on a cell phone; you really should not care about that, it’s our duty.”. Browser vendors employees reading this paragraph may change this “duty” to “burden” 😉

  29. Am using a Sony Clie SJ33 PDA running Palm OS4. Is there any browser which supports XHTML & CSS? I design websites following standards. I’d like to make mine compatible with handhelds too, since I happen to own one also.

  30. The title of the article could be clearer. You’re designing for Opera UA.

    There is *much* more popular Nokia UA. Using the Nokia UA on the series 40 say is dangerous. It’s best turned off. How do I do this? Make the handheld.css last and try clean up the mess caused by the earlier style sheet.




    Also put content first, and silly menus last.

    My site works with almost all Nokia phones. Some phones have a size limit which does not work with some of my longer blogs.

  31. Just tried the the stuff out and made myself a handheld css. Worked great. Too bad that there is not many telephones out there that include a good browser (Opera/Mozilla).

    Just wanted to say thnks alot.

  32. I modified a local development site and used the ‘shift+F11’ preview in Opera7. It worked and displayed perfectly. But when I copied the site to a DELL AXIM Pocket PC running Internet Explorer, it does not display correctly. It seems to pick up some aspects of the pda CSS and then other aspects of the standard style sheet. The result is a melange. Is this a known problem with IE on pocket PCs?

  33. If you’re going to disable all images from loading then we’re just talking about text, correct? In the case of email, who has a computer hooked to the Internet, but no phone? What practical application is there for someone with a cell phone, or other device, to access aside from looking up movie listings while driving to the theater? You know who does love this stuff is the cell phone providers. It gives the users more reasons to have to mess with their phones and more ways for them to blow minutes when they are bored. It is a novelty currently but shortly will fade away and become a topic on one of those VH1 shows in the next 5 to 10 years.

  34. Hi,

    I have downloaded and installed NetNewsWire 2.0 beta 3 on my Mac and I really like this Mac news reader as it has a built in support to display not only the site feeds but to actually jump to the site and view the article internally. Now, certainly you could enlarge the NetNewsWire window for as large as you would with your web browser. I however like to keep it small as I only jump to the original article when something really got me interested.

    Now, I just thought that as news readers become more and more smart – also thinking about Mozilla’s side bar at this moment – I think there is a bit more than just the hend held when alternative web views might come handy…

  35. The only way I know of is to either not specify ‘handheld’ in the media or use Javascript. Let’s assume that the handheld screen is 200 pixels. I know this is probably wrong but I’m just using 200 as an example. If the screen width is equal or less to 200, lose the stylesheet. This script assumes the stylesheet link is the first link element in the page.

    if (self.screen.height<=200) document.getElementsByTagName('head')[0].removeChild(document.getElementsByTagName('link')[0]) I'm not saying this is the best way, this is just the way I would do it.

  36. As far as I know Nokia’s XHTML browser still does not support Javascript. I’m still looking for a way to disable CSS for Nokia’s browser.

    The biggest problem is that many of the existing Nokia phones with XHTML browser ignore the media attribute for the link tag. Even that I specify a stylesheet for media=”screen”, it appeared on the Nokia’s browser as well and caused some big problems; part of the text on the page are out of the page and cannot be viewed; even if I scroll, the text are hidden, overflowed the viewable area.

    I hope somebody can have a fix on disabling CSS for the Nokia’s XHTML browser without using any server side language.

    I’m still working on getting a fix myself.

  37. tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt

  38. Just in case it helps anyone, I have run Damon Cool’s ( http://www.htmldog.com/test/handheld.html – see page 2 of this discussion ) handheld media type test on my Orange SPV C500 Smartphone which is running Windows Mobile 2003 with Internet Explorer.

    The browser applies all the stylesheets irrespective of media specified. I haven’t tried this but I’m guessing that so long as you declare your handheld stylesheet last you should be able to override the css already applied from the media=screen stylesheet.

  39. I tested some webpages including ALA on Siemens CX65. Everything just fine. Siemens uses browser from Openwave which ignores CSS. Links like “Skip navigation”, “Top of the page” are really useful. I think that link skipping main content to menus on the right on ALA would be useful too.

  40. I’ll be honest- I’m hugely excited about the fact that more and more handheld devices are managing to deal with XHTML and CSS.

    Being a Nokia 6600 owner (symbian operating system with Opera installed) I have already managed to experince the joys ahead.

    But I’ll tell you one thing (two actually…):

    1. Surfing the internet wirelessly on my laptop with gfx@full resolution, XP Pro, latest I.E. and plug-ins, is quite a difference experience to the slugginsh, boring looking days of even as recent as 1998.
    The handheld devices will go through a similar perdios of maturity, and most of our work won’t even need special mark-up, just GOOD mark-up (like ANYTHING viewing it needs!)

    2. I just hope the likes of V0d4F0n£ et. al. don’t lock the Internet down to their poor services too tightly. (If I’m honest, I haven’t even managed to try out Opera on my handset yet because the V0d4F0n£ ‘L1V£’ settings don’t seem to allow me to bypass their bespoke (and comparitively poor) software)

    Oh well, that’s my two cents worth, I’d appreciate your thoughts 🙂

    I’m off to install the Managed Fax Service on MS SBS 2003, and then it’s back to php, MySQL and XHTML/CSS 😀

    Best wishes,

    Mark Clulow

    [ http://www.cooscreations.com ]
    [ http://www.pulsemarketing.org ]
    [ http://www.annabuckley.com ]

  41. I’ve been using Opera for desktop since long. I badly need a version for my Palm OS4 handheld and I’m sure there are many others around who’d want a standards based browser for the palm. The only one that comes close is the Xiino3 and is still far from it though it is the best around. Blazer and iPanel lag far behind.
    A word of advise though. Make it for OS4 and add compatibility for OS5 as majority of Palm users are still on 4. You can’t just upgrade your software but need to upgrade your hardware too

  42. Embracing standards in Web Design is the right way to go, after readind this article I noticed that a lot of sites developed using standards are already Pocket-Sized friendly.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA