 |
|
    |
 |
|
 |
The main purpose of a Web or wireless application is to show information to users. For this reason, text is important. Text in the body of your HTML page will show up on the screen of your users:
 Image 1: Plain text Of course, you don't have much space to squander on a mobile device screen, so you must make sure that your prose is short and to the point. Letting text flow uninterrupted on the screen is not always the best way to present information. In most cases you will want to give your document some structure to make the information simpler for the user to interpret. The example above shows some basic ways to influence the flow of your info: <br/>
forces the rendering flow to start from a new line, the 'text-align:right' style attribute forces the Openwave word to squeeze itself against the right border, while
<i>
is the tag that turns your text into italics.
In the rest of the chapter, we will illustrate the usage of tags that let you control the layout and structure of your XHTML MP documents. Preformatted text ( <pre>) and the `nowrap' extensionThe default behavior of plain text on the screen is to collapse all extra white spaces and treat them as a single white space. This default works for most text uses, but when you want to keep the existing text formatting intact, use the <pre> tag:
will produce:  Image 2: Preformatted text Another default behavior of browsers is to wrap text to the next line once it reaches the right border. Again, this is acceptable most of the time, however, there may be times when a sentence should be kept intact on one line and viewed by scrolling horizontally. This is particularly useful in the case of Menus (see chapter 3. WML and HDML programmers may recognize horizontal scrolling by its familiar reference: `times-square mode'). Unfortunately, vanilla XHTML MP does not give you the ability to express "times-square mode," so a small extension was introduced in the form of the " mode='nowrap'" attribute for the
<p> tag, consistent with WML.code Image 3: Non-wrapping text The Openwave browser will let you use mode= "nowrap"
on every block element, but doing so is not recommended.
Headers To organize a document hierarchically you can write headers with different levels.  Image 4: Header Tag It is very important to note that while the Openwave Simulator will render each of the header elements ( <h1>...<h6>) with a variety of font sizes, real devices will not likely be able to render six different font sizes. Therefore, you should use the <hx> tags with caution and test your applications on the target handsets to ensure that your application renders as you would expect.
Emphasis tags One way for authors to add meaning to their text is by emphasizing certain words. Historically, emphasis tags were invented with the assumption that each and every web browser would render the text in the way they saw fit. Accepted practice has changed the semantics to <b> meaning bold,
<i> and <em>
meaning italics and so on.
XHTML MP adds an extra layer of confusion because a wireless browser only deals with the fonts available on the phone. You have no guarantee that a bold, italic or mono-spaced font is available on the device. In short, trying to track the behavior of each and every tag is expensive and mostly pointless. Just refer to Image 5 below for an example of how you can use the most common emphasis tags. It is important to note that when the emphasis tags are used, the user can understand what your application is trying to communicate even if the tags are not rendered visibly. For a more detailed description of each tag, please refer to the XHTML Mobile profile and CSS Reference available at developer.openwave.com...
 Image 5: Examples of the emphasis tags Note: On the Web, the <em> tag is synonymous with <i>.
In the Openwave browser it is rendered as a synonym of <b><i> (bold and italics).
Links (aka <a href=http://somewherenew>)
The most important tag in the history of the Internet is the anchor <a> tag. The common hyperlink is the foundation of navigation for wireless and Web applications alike. The following example is made slightly less banal by juxtaposing the use of CSS for styling (more about CSS later).
 Image 6: Links with style The Color of Links While CSS and the browser can assign arbitrary colors to links, the actual link control is a widget in the domain of the device OS. This means that certain devices may not honor CSS and display the link in their default preset color like blue or white or possibly black for visited links. One important implication of the default color is that you should take care when choosing background colors for your pages and table cells. A page that looks good on one phone may become unusable on another phone because the links are either not visible or not obviously links. In addition, some early versions of XHTML browsers from vendors other than Openwave display links on a line of their own. Lists Lists (both ordered and unordered) are HTML constructs that are unchanged in XHTML MP. Because of XML "well-formedness," always remember to close each and every list item with </li>. If you are familiar with the `type' attribute from HTML, you may want to consider the CSS syntax that's recommended now to obtain the same result.
 Image 7: Nested Lists Tables Tables come directly from HTML. Nothing is new from a syntax perspective, but support has been improved. Tables cannot be nested, as a result of requirements from XHTML Basic. Nevertheless, complex tables can be constructed, as the following example illustrates. Notice that in the example, the properties of cell border and shading are controlled by CSS (more about CSS later).
 Image 8: Table layout While the Openwave browser does a good job at rendering complex tables, a word of caution should be offered about other browsers. An initial analysis of XHTML browser from other vendors has exposed the following glitches: Some browsers actually draw every cell in a table with a thick line. This may not be what you want. Browsers behave differently in terms of wrapping content when the table's size exceeds the screen size. Non Openwave browsers may not be able to apply CSS to table cells and their content. Horizontal Rules Horizontal rules are simple, but should be used judiciously. While it is possible to specify the thickness of an <hr>, it is advisable to not exceed two pixels in thickness since size on the display is limited.
 Image 9: Horizontal Rule While not part of XHTML MP, the legacy HTML `size' and `width' attributes are also supported by the Openwave browser. Cascading Style Sheets (CSS) The use of Cascading Style Sheets has become commonplace with web programmers, but may be new to those who have only dealt with HDML or WML: In 1996, many developers realized that adding more tags and attributes to HTML was not a very scalable approach to improve the graphical capabilities of the web. HTML was knows as tag-soup, browsers were diverging and maintaining sites was becoming tedious. Cascading Style Sheets came as a solution. A CSS file lets you express styling information elegantly and lets you reuse the style across several pages on a site. If you want to know more about CSS for the Web, a good place to start is: www.w3.org/Style/CSS/. In addition, the XHTML and CSS Reference guide from developer.openwave.com has an excellent discussion of the power and features of CSS. WAP 2.0 brings the power of CSS to the wireless world by introducing WCSS, an abridged version of Web CSS for wireless devices. We have leveraged CSS in some of the sample code shown previously in this document, but avoided going into too much detail about it. Our code used CSS in the context of an inline style attribute for clarity. Another, more scalable, approach to using CSS is to place all of the selectors and attributes in a separate CSS file and import this file into your XHTML page. Here is a sample shows you how to import a CSS file:
The <link> element instructs the browser to fetch a file with style information called
style.css. To avoid any possible confusion, style.css is a URL to a file on the Internet. It is normally a relative URL. In this specific case, the browser will figure out it needs to look at
developer.openwave.com/omdtdocs/toolkit_sample/staticSample/movielife/style.css
Style.css contains the following code:
From top to bottom, here is what the style-sheet tells the browser: Rule 1:
The result is:  Image 10: CSS applied to an XHTML Page CSS is by definition very powerful, and the table sample in this chapter is an example of that power in action. However, there is no guarantee that this would work on all browsers (it probably won't). As a general rule, minimizing the use of CSS is probably wise. If you are very serious about WCSS and want to see the spec, follow this link: http://www.wapforum.org/tech/documents/WAP-277-XHTMLMP-20011029-a.pdf When should one use CSS? There are two good reasons to introduce CSS in wireless programming. The first, which we mentioned several times, is convergence with Web programming. The second one is that the introduction of such a powerful framework will make it simple to introduce future extensions to the language while retaining some degree of backwards compatibility. Compatibility is a problem that has plagued wireless development much more than it did on the Web, because of the slowness with which new browsers gain significant market share. Another advantage of CSS is the fact that external CSS can be cached and re-used across multiple pages. This promotes consistency of look across your application. Having said this, there may be a few reasons to minimize the use of CSS in your applications: If you are not coding to the Openwave browser exclusively, you may find that other browsers have limited CSS support. Mobile devices will typically support only a limited amount of fonts (two), which means that you want to use emphasis tags like: <b>bold<b>rather than CSS like: <span style="{font-weight: bold}">bold</span>
The former is shorter, saves bandwidth and will work on all browsers. If your CSS is a separate file, you gain by having to download the file only once, but you loose in terms of initial end user experience. The browser must download the CSS file, parse it and render the page before it makes sense to the user. This delay is usually not justifiable by the end user. When a CSS is rendered, the page snaps back to the first line in case the user has already started scrolling. This is another usability glitch you should avoid. What comes next? Having explored Menus and Text Flow, we will move on to the next core element of XHTML-MP and web programming, Forms. XHTML-MP Style Guide Chapters XHTML-MP Style Guide Index 1. History of XHTML Mobile Profile 2. XHTML MP in practice 3. Menus in XHTML Mobile profile 1.0 4. Text-flow 5. Forms: Collecting User Data 6. Images and Objects 7. Testing Your Applications Appendix A Appendix B |