Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. Other product and company names mentioned herein may be trademarks or trade names of their respective owners.
Disclaimer
The information in this document is provided “as is,” with no warranties whatsoever, including any warranty of merchantability, fitness for any particular purpose, or any warranty otherwise arising out of any proposal, specification, or sample. Furthermore, information provided in this document is preliminary, and may be changed substantially prior to final release. This document is provided for informational purposes only.
Nokia Corporation disclaims all liability, including liability for infringement of any proprietary rights, relating to implementation of information presented in this document. Nokia Corporation does not warrant or represent that such use will not infringe such rights.
Nokia Corporation retains the right to make changes to this specification at any time, without notice.
License
A license is hereby granted to download and print a copy of this specification for personal use only. No other license to any other intellectual property rights is granted herein.
Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 3
Contents
1. Introduction ...... 7 1.1 S60 mobile browser ...... 7 1.2 Chapter topics ...... 7 2. Top guidelines for optimizing mobile XHTML services...... 8 2.1 Make applications for mobile use...... 8 2.2 Keep user task flow fluent and be reasonable with image use...... 8 2.3 Make structure easy for novices but don’t forget power users ...... 8 2.4 Provide sufficient information on a page...... 9 2.5 Provide informative feedback for user actions...... 9 2.6 Minimize amount and size of images...... 9 2.7 Specify image height and width attributes ...... 10 2.8 Use tables carefully...... 10 2.9 Consider options for adding style definitions ...... 10 2.10 Remove unnecessary white space and comments inside code ...... 10 2.11 Enable caching of pages using HTTP header directives ...... 11 2.12 Use Unicode 2.0 character sets for XHTML content ...... 11 2.13 Use correct MIME types and validated XHTML code ...... 11 2.14 Use descriptive page titles and element labels...... 12 2.15 Perform a usability test...... 12 3. Tools for developing browsing applications ...... 13 3.1 SDKs and IDEs ...... 13 3.2 Image tools...... 13 3.3 W3C tools...... 13 3.3.1 HTML/XHTML Validation Tool...... 13 3.3.2 HTML Tidy ...... 13 3.3.3 CSS Validator ...... 13 4. Introduction to the user interface ...... 14 4.1 User interface hardware – keys and display...... 14 4.1.1 Keys in S60 devices ...... 14 4.1.2 Display areas...... 15 4.1.3 Layout and basic principles of the display rotation...... 15 4.2 Scalable UI...... 16 5. Basic structure of an XHTML application ...... 17 5.1 XHTML prologue ...... 17 5.2 Mandatory XHTML elements ...... 17 5.2.1 Root element, ...... 17 5.2.2 Head element,
...... 17
Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 4
5.2.3 Title element,
...... 17 5.2.4 Body element, <body>...... 17 6. XHTML MP elements ...... 19 6.1 Text formatting ...... 19 6.1.1 Zooming...... 20 6.1.2 Paragraph and content alignment ...... 20 6.1.3 Line break...... 21 6.1.4 Pre element ...... 21 6.2 Tables...... 21 6.3 Links...... 23 6.4 Access keys ...... 24 6.5 XHTML MP input processing ...... 25 6.5.1 Input elements ...... 25 6.5.2 Select element...... 27 7. WAP CSS...... 29 7.1 Applying style sheets ...... 29 7.1.1 External style sheets ...... 29 7.1.2 Style element in document head ...... 29 7.1.3 Inline styles...... 29 7.1.4 Cascading rules for style elements ...... 29 7.1.5 Global selectors, class attribute ...... 30 7.2 Borders...... 30 7.2.1 Border style ...... 30 7.2.2 Border width ...... 30 7.2.3 Float...... 30 7.3 Margin ...... 31 7.4 Padding ...... 31 7.5 List style ...... 32 7.5.1 List style image...... 32 7.5.2 List style position ...... 32 7.5.3 List style type...... 32 7.6 Text ...... 32 7.6.1 Text align ...... 32 7.6.2 Text decoration...... 33 7.6.3 Marquee...... 33 8. Additional features...... 34 8.1 TCP/IP...... 34 8.2 Push ...... 34 8.2.1 Service Indication ...... 35 </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 5 </p><p>8.2.2 Service Loading...... 35 8.3 Wireless Telephony Applications Interface (WTAI) public library ...... 36 8.3.1 Making a phone call...... 36 8.3.2 Sending a DTMF tone ...... 36 8.3.3 Adding a phone book entry...... 36 8.4 Content download over WAP...... 37 8.5 Download Manager ...... 37 8.6 Progressive download...... 38 8.7 Large file download ...... 38 8.8 SVG Tiny...... 38 8.9 Macromedia Flash Lite 1.1 Viewer...... 38 8.10 Macromedia Flash 6 browser plug-in...... 38 8.11 Scripts ...... 38 8.12 User Agent Profile ...... 39 8.13 Accept header ...... 39 8.14 Cookies ...... 40 8.15 Segmentation and Reassembly (SAR) ...... 40 8.16 XHTML Mobile Profile 1.1 ...... 40 8.17 ECMAScript Mobile Profile...... 40 8.18 Meta tag ...... 41 8.19 Object tag...... 41 8.20 HTML 4.01...... 41 8.21 SMS schema...... 42 8.22 MMS and MMSto schemes...... 42 8.23 LocalApp scheme...... 42 8.24 Background image ...... 43 8.25 Frames ...... 43 8.26 Content upload...... 43 8.27 Browser full screen mode...... 44 8.28 HTTP digest authentication...... 44 9. Terms and abbreviations...... 45 10. References...... 47 Appendix A. XHTML modules ...... 48 Evaluate this resource...... 54 </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 6 </p><p>Change History </p><p>January 13, 2004 Version 1.0 Initial document release1 </p><p>July 5, 2004 Version 1.1 Section 6.5.1. and Chapter 8 updated. </p><p>August 30, 2004 Version 1.2 Minor updates in Chapter 8. </p><p>March 4, 2005 Version 1.3 Section 8.7 added. </p><p>May 24, 2005 Version 1.4 Sections 4.1.3, 4.2, and 8.5–8.10 added. Sections 4.1, 8.15, and 8.23 updated. Minor terminology updates. </p><p>Revision on April 28, 2006: minor editorial changes including S60 terminology update. </p><p>1 This document replaces “Designing XHTML Mobile Profile Content for Series 60 Browser” and “Anatomy of an XHTML Series 60 Application”. </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 7 </p><p>1. Introduction </p><p>This document provides information and practical examples for developers who want to optimize their Extensible Hypertext <a href="/tags/Markup_language/" rel="tag">Markup Language</a> Mobile Profile (XHTML MP) services for S60 dual-mode browser. In addition to supporting XHTML MP, the browser supports <a href="/tags/Wireless_Markup_Language/" rel="tag">Wireless Markup Language</a> (WML). The audience for the document includes service developers, as well as anyone involved in creating the wireless information society who needs to know more about service creation on mobile devices. </p><p>1.1 S60 mobile browser </p><p>The S60 browser is a dual-mode browser that natively supports both XHTML MP with WAP CSS and WML 1.x. This means that existing browsing applications written in WML 1.x will work in the browser, as well as new XHTML MP services. </p><p>XHTML MP with WAP CSS gives developers much more control over the format and layout of their pages and should be used in preference to WML 1.x. WML 1.x can be used when needed for specialized WML 1.x functionalities, such as WML events or calling WMLScripts. XHTML MP and WML 1.x pages can be seamlessly linked together. History is maintained so that the user can go back, no matter what kinds of content are intermixed. Users need not know whether the page they are currently viewing was written in XHTML or WML 1.x. </p><p>The switch to using the TCP/IP stack is one of the main factors in the development of rich 2.5-3G multimedia services. Compared to the WAP 1.x stack, TCP/IP provides more security and enables access to a wider variety of Internet services. For more information about TCP/IP, see Section 8.1, "TCP/IP.” </p><p>1.2 Chapter topics </p><p>Chapter 2 outlines several recommendations for optimizing mobile XHTML services so that they achieve the best possible usability and performance. Chapter 3 is an overview of the tools available for developing browsing applications. Chapter 4 describes the browser's user interface elements, keys, and display. Chapter 5 introduces the basic structure of an XHTML application. Chapter 6 outlines some general XHTML MP elements supported by the S60 mobile browser. Chapter 7 introduces WAP CSS, and Chapter 8 introduces additional features that are supported in the S60 mobile browser. Supported XHTML modules are presented in Appendix A. </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 8 </p><p>2. Top guidelines for optimizing mobile XHTML services </p><p>2.1 Make applications for mobile use </p><p>When deciding what information to include in the different applications on a mobile device, developers should consider the types of situations where the mobile device will be used. The content of the service should fulfill the needs of the target user group and be optimized for the most common tasks. Because of the mobility of the small display, the user might use the mobile phone primarily when there is no PC access to the Internet and for quick information. Examples include speedy access to flight schedules, short news flashes, and weather information. It is less likely that users will use their mobile phones to surf. </p><p>2.2 Keep user task flow fluent and be reasonable with image use </p><p>Colorful pages look great but may not feel great when images slow down service. According to usability studies2, users are less enthusiastic about services if images disrupt their task flow. In particular, large images aren't appreciated when users are navigating toward the target page. Images that have information value are appreciated, but in many cases users either turn off images to save time and money, or proceed to the next page without waiting for the images to download. It is important to allow users to continue navigation even before all images are downloaded. </p><p>Large tables may cause a similar problem that is, the user is stuck on a page until it is downloaded or can't find the way to proceed before the page is fully downloaded. Because phone displays are different sizes, developers should make sure that data tables are readable even on the smallest displays; often they must be squeezed to fit the display. </p><p>2.3 Make structure easy for novices but don’t forget power users </p><p>In mobile services it often seems that a shallow structure is easier to understand than a deep structure. Links and pages should feature descriptive names to help the user find the information s/he needs. </p><p>It is hard to say how many links should be provided on one link list page. If the links clearly belong together and are easy to browse (one line per link, alphabetical or otherwise logical order so that the user does not have to read through each link), it is better to provide 30 links on a single page rather than five links on six pages. If there are tens of links, it may be a good idea to provide sorting options before showing them. If the link can fit on one row, it makes the selection clear and the page look better. </p><p>There are no <do> elements in WAP 2.0; instead, they have been replaced with access keys. However, most users seem to be unaware of access keys and unable to find them. To help users to understand the concept of access keys, developers should make sure that they are visible on the screen and in a form that resembles phone keys. </p><p>If possible, a search function should be provided. Power users appreciate it, as do novices navigating large sites. </p><p>2 Roto, V., Kaikkonen, A.: Acceptable Download Times in the Mobile Internet. In Stephanidis, C. (ed.): Universal Access in HCI. Volume 4 of the Proceedings of HCI International 2003. </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 9 </p><p>2.4 Provide sufficient information on a page </p><p>Interactive pages should be short; informative pages long.3 It is not recommended to start the site using a doormat page, which serves no other purpose than to greet the visitor and display a logo. It is better if the user can go to the service directly. </p><p>In XHTML, information is downloaded as pages and not as decks as in WML. This means that it is even more important to provide necessary information to users on a single page to support their task flow. Going back and forth between pages may take more time in XHTML, as the pages are downloaded separately. In backwards navigation this applies especially to cases where pages are not cacheable, e.g., in systems related to paying or where private information is provided. </p><p>The first (topmost) screenful of any page is the most important. All often-used navigational links, search fields, login screens, and the bulk of the information should reside there. The user can then navigate forward before the rest of the page has been loaded, and will not have to scroll the page. </p><p>Use of the top of the page for banner advertisements or non-informative graphics should be avoided. It is better to place advertisements at the left or right edge. </p><p>It is difficult to scroll up and down pages, so interactive pages with forms should not be too long, since users may not be sure if they have filled in every field on a long form. Users can easily lose the feeling of control if the form takes more than two screenfuls. </p><p>There should be sufficient information on the destination page to which the user is headed. For example, if the target page contains a story or instructions, the entire contents should be presented on one page. Subtitles that take the user to points within the page help when browsing a long, informative page. </p><p>The fact that information is downloaded as individual pages, not decks, is the biggest individual change that affects navigation and structural differences between WML and XHTML. </p><p>2.5 Provide informative feedback for user actions </p><p>Developers should provide proper feedback for user actions and for error and problem situations. For example, after the user clicks a link, the page title should be the same as the link name. Minimizing steps in navigation should not increase the user's feeling of insecurity, e.g., confirmation pages for user actions may be needed even if they require an extra click. If the confirmation page is missing, the user may feel s/he needs to check to see if the action has taken place — this leads to even more clicks. Users should feel that they are controlling the system. </p><p>If problems arise, users should be informed what to do next. Errors can be prevented by explaining to users the format of expected input, and by marking mandatory fields. </p><p>2.6 Minimize amount and size of images </p><p>The amount and size of images on an XHTML should be considered carefully. Each image on a page causes a separate round trip, which in turn makes the rendering of an entire page slower. Therefore the number of round trips should be minimized. Also it should be noted that each time an image arrives at the mobile device, the entire containing page may be rearranged, which takes time and processor resources. Thus, a page with just a few images may load faster than one with many smaller images. If </p><p>3 Kaikkonen, A., Roto, V.: Navigating in a Mobile XHTML Application. Proceedings of CHI2003 conference </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 10 </p><p> possible, it is recommended to use the same images on various pages throughout the service; then a specific image is downloaded only once and saved to cache. For example, if custom images are used for bullets, the same ones should be used throughout the service. </p><p>TCP/IP connection may result in different download speeds for pages, even though the amount of data is the same. For example, downloading an XHTML page containing four images at 2 KB each is faster than downloading a page with eight images at 1 KB each. </p><p>If the WAP gateway is used, it should be placed close to a Gateway GPRS Support Node (GGSN). “Close” in this instance refers to both latency and the probability of packet loss. Lost messages cause additional delay due to HTTP retransmission. The latency between the WAP gateway and content server should be minimized. </p><p>2.7 Specify image height and width attributes </p><p>It is recommended that content developers explicitly specify the height and width of images in markup to allow the browser to reserve the proper space for the image. If width and height parameters are used in image tags, the XHTML browser is able to reserve the space for images before the images are downloaded. Thus the page is displayed to the user before images are downloaded and images become visible when they are downloaded. This doesn't change the complete download and processing time of the XHTML page, but it improves the user experience substantially because a user can read the page before the images are downloaded. For example: </p><p> </p><p>2.8 Use tables carefully </p><p>The browser supports the use of tables and nested tables in the XHTML page. Developers should be careful when defining cell widths, particularly with nested tables. </p><p>2.9 Consider options for adding style definitions </p><p>Developers can specify their own styles in various ways: in an external style sheet, in a style element in the document head, or by using an inline style attribute in a specific element. Although in general it is a good practice to use external style sheets whenever possible to separate style from markup, it should be noted that there are tradeoffs to consider. Rendering of the XHTML page is faster when style definitions are inside XHTML code, but the use of external style sheets offers a convenient way to change styles throughout the service. The same external style sheet should be used throughout the service to avoid downloading multiple style sheets to the device. The external style sheet is downloaded only once and saved in cache. </p><p>2.10 Remove unnecessary white space and comments inside code </p><p>It is important to make sure that there is no extra white space inside the code. Although white space is not visible on the screen, it is still processed, as the browser parses, formats, applies CSS to, and renders white space. </p><p>The number of comments in XHTML code should be minimized to keep the code as compact as possible. </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 11 </p><p>2.11 Enable caching of pages using HTTP header directives </p><p>The browser places viewed XHTML pages in the cache; however, content developers should not assume that pages are cached by default4. Explicit cache headers should be sent with documents to ensure that pages are cached on the client, if possible. In addition, an expiration time should be set for at least a few days, in order to ensure that content is cached for a suitable time across multiple time zones. </p><p>If placing of cache directives within Meta tags (e.g., using HTTP-EQUIV) is not supported, caching can be controlled using HTTP headers. The "Cache-control: no-cache" HTTP header directive can be set by the HTTP server hosting the pages to define that pages are not cached. </p><p>Cache uses the “least recently used” algorithm, which means that items used least are removed first. It is recommended to reuse images and external CSS in all XHTML pages to ensure that they stay in cache and need not be downloaded each time they are used. </p><p>2.12 Use Unicode 2.0 character sets for XHTML content </p><p>The XHTML browser supports ASCII and Unicode 2.0 character sets. Therefore to ensure the greatest level of interoperability, all XHTML content should be created by using Unicode for non-Latin languages. For Latin languages, ASCII can also be used. Some gateways and proxies can convert local character sets to Unicode, but not all. Therefore the only way to guarantee the device receives Unicode is to create the content in Unicode. More information about Unicode and non-Latin languages can be found in the following books: </p><p> Lunde, Ken. (December 1998) CJKV Information Processing. 1st edition. O’Reilly & Associates. </p><p> Graham, Tony. (March 2000) Unicode: A Primer. John Wiley & Sons. </p><p>2.13 Use correct MIME types and validated XHTML code </p><p>The preferred MIME type for XHTML MP content, specified by OMA, is “application/vnd.wap.<a href="/tags/XHTML/" rel="tag">xhtml</a>+<a href="/tags/XML/" rel="tag">xml</a>”, which should be used for serving XHTML MP documents to XHTML user agents. In addition, “application/xhtml+xml” can also be used. In some S60 browsers the MIME type “application/vnd.wap.xhtml+xml” must be used to ensure the correct XHTML MP content view. The MIME type “text/<a href="/tags/HTML/" rel="tag">html</a>” is available too, but for XHTML, use of this type should be reserved for the purpose of rendering on existing HTML user agents. It should be noted that XHTML documents served as “text/html” will not be processed as XML. This means that, for example, well-formedness errors may not be detected by user agents. Authors who wish to support both XHTML and HTML user agents may utilize content negotiation by serving HTML documents as “text/html” and XHTML documents as “application/vnd.wap.xhtml+xml”. </p><p>It is recommended to use file extension *.xhtml in all XHTML MP content. XHTML code should be validated to avoid any interoperability problems and to enhance performance. XHTML content can be validated for example with the W3C validator at http://validator.w3.org. When creating XHTML content dynamically, the generated code should be valid DTD XHTML MP 1.0. </p><p>4 In S60 phones the content is cached by default, unless requested otherwise in the HTTP header. </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 12 </p><p>2.14 Use descriptive page titles and element labels </p><p>The page title describes the contents of the page being displayed. Use of titles is recommended in WML and mandatory in XHTML. Titles help the user navigate in the application because they remind the user where s/he is within the application. It may be a good idea to start the title with the service’s name and keep the total length of the title short. The item previously selected by the user should determine the header text. For instance, the title “Bookmarks” tells the user that the display contains a list of bookmarks in the application and that the option item previously selected was Bookmarks. </p><p>Proportional fonts are used in header text, and if the header text is too long, it is cut automatically. Cut titles are usually better than abbreviations, because the user may be confused by unfamiliar abbreviations. </p><p>Although short words are recommended for element labels, acronyms that are not well known by the target user group should not be used. The same label should always be used for the same thing, especially with function labels such as Delete, Remove, Erase, Clear, and Destroy. </p><p>2.15 Perform a usability test </p><p>It is always a good idea to perform a usability test for new applications. People who have not been involved in the design or development of an application tend to notice potential usability problems that are often not obvious to those who know the design by heart. Usability tests should be performed as early as possible in the development process. Any necessary changes resulting from the tests can then be implemented within the development timetable. Testers who are representative of the future end users should be used. At the very least, tests should be conducted on a small scale if the schedule does not allow for extensive testing. </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 13 </p><p>3. Tools for developing browsing applications </p><p>3.1 SDKs and IDEs </p><p>Although XHTML documents can be written in any text editor that can save files as plain text, there are many SDKs and IDEs available to aid the development of wireless applications. Some of these also incorporate emulators, for example the Nokia Mobile Internet Toolkit (http://www.forum.nokia.com/), Ericsson WAPIDE (http://www.ericsson.com/), and the Openwave SDK (http://www.openwave.com/). </p><p>3.2 Image tools </p><p>Various companies offer tools for the creation and manipulation of images for wireless applications. For example, ImageMagick http://www.imagemagick.org/ is a collection of tools and libraries that can be used to create, manipulate, and convert images in many image formats. </p><p>3.3 W3C tools </p><p>3.3.1 HTML/XHTML Validation Tool </p><p>W3C provides a free HTML/XHTML validation service. However, it is not able to verify valid XHTML MP. The user submits an HTML/XHTML document, usually by providing a URL for it, and the service provides notification of its validity. The tool can be accessed at http://validator.w3.org/. Several other XML validators can be found on the Internet. </p><p>3.3.2 HTML Tidy </p><p>HTML Tidy is a utility for converting HTML to valid, well-formed XHTML (not XHTML MP). There are various GUI versions or the source as a UNIX filter for processing HTML files. HTML Tidy is available from http://tidy.sourceforge.net/. </p><p>3.3.3 CSS Validator </p><p>The W3C provides a free CSS validation tool that can verify correct CSS but it is not yet able to verify conformance with WCSS. The W3C CSS validator is available at http://jigsaw.w3.org/css-validator. The Nokia Mobile Internet Toolkit contains a CSS editor that can both create and validate CSS files. </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 14 </p><p>4. Introduction to the user interface </p><p>This chapter provides a brief overview of the user interface in S60 devices with an XHTML browser. </p><p>4.1 User interface hardware – keys and display </p><p>4.1.1 Keys in S60 devices </p><p>S60 hardware includes the following keys: </p><p> The Send/talk key initiates a data call. </p><p> The End key exits a data call. </p><p> The two softkeys have assigned actions that let the user manipulate the user interface by making selections and entering, editing, and deleting text. </p><p> o The left softkey is used as a yes/positive key. It contains options that execute commands and go deeper into the menu structure. Example functions are Select, OK, and Options. </p><p> o The right softkey is used as a no/negative key. It contains options that cancel commands and go backwards in the menu structure, such as Back and Exit. </p><p> Navigation key (five-way): </p><p> o Scrolling up/down allows the user to scroll the options or text in the current display in a vertical direction. </p><p> o Scrolling left/right allows the user to scroll the options or text in the current display in a horizontal direction. </p><p> o Pressing the navigation key selects the currently highlighted item. Other keys: Application, Clear, Alpha toggle, Power </p><p> o The Application key allows application swapping without closing the current application. </p><p> o The Clear key clears entered characters/numbers and deletes selected item(s) in certain situations. The Clear key is not used for Back/Exit operations. </p><p> o The Alpha toggle key enables use of a standard 12-key number keypad with alpha printings. </p><p>The S60 UI with side softkeys assumes a hardware that has the softkeys on either side of the display. The product concept for such a case might be, for example, a device optimized for using some specific applications in a 90- (or 270-) degree rotated mode, but not having extra keys for providing the softkey functionality at the bottom of the display in this rotated mode. </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 15 </p><p>4.1.2 Display areas </p><p>The S60 platform has a 176 x 208 display consisting of three areas: the status area, the softkey area, and the main or application area. </p><p>Display sizes 240 x 320 and 352 x 416 apply for S60 2nd Edition, Feature Pack 3 and onwards. </p><p> Status Area The status area displays status information about the current application as well as general information about the device such as signal strength and battery charge level. The status area is further divided into five sub-areas: the battery/universal indicator area, the navi area, the title area, the context area, and the signal area. </p><p>The title area is the only area within the status area that can differ between browsing applications. When an XHTML page/WML card title has been defined, it is displayed in the title area. </p><p> Application/Main Area This is the principal area of the screen where application data can be displayed. In the browser, this area is used for the XHTML page content. </p><p> Softkey Area The softkey area displays the labels associated with the left and right softkeys. </p><p>4.1.3 Layout and basic principles of the display rotation </p><p>This information applies for S60 2nd Edition, Feature Pack 3 and onwards. </p><p>The style for the S60 UI in landscape orientation with side softkeys is based on the following core principles: </p><p> The height of the main pane is maximized by reducing the size of the other panes, with the principle of optimizing for the content rather than for the status information. </p><p> The status pane and control pane are not handled as entities, but they are divided into their sub-panes that may be positioned in different locations of the UI real estate. The assumption in this document is that the panes are located as presented Figure 1. However, the platform supports flexibility for actual product implementations and, therefore, the UI design shall not assume any certain position for the panes. There is no support for a context pane icon in the side softkey style. </p><p> In the side softkey style, the control pane scrolling indicators are always replaced with a scroll bar. In a left-to-right display language, the scroll bar is always located on the right-hand side of the main pane, regardless of where the softkeys are. </p><p> The relationship between the physical softkeys and their label in the SW UI remain in the 90- and 270-degree rotation: the same key that was Options before the rotation is Options also after the rotation, and so on (refer to Figure 1). </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 16 </p><p>Figure 1: S60 UI with side softkeys on the right and the default S60 UI with softkeys below the display </p><p>4.2 Scalable UI </p><p>This information applies for S60 2nd Edition, Feature Pack 3 and onwards. </p><p>S60 enhances the supported display resolutions and offers a framework for adapting applications to the landscape orientation. </p><p>The following resolutions and modes are supported: </p><p> 176 x 208 portrait, with full S60 application adaptation. </p><p> 240 x 320 portrait, with full S60 application adaptation. </p><p> 352 x 416 portrait, with full S60 application adaptation. </p><p> 416 x 352 landscape framework with side softkeys. </p><p>The landscape framework supports dynamic switching between the portrait and landscape orientation at run time. </p><p>S60 offers APIs to query the UI components’ layout information and to set the current orientation (landscape or portrait). For legacy applications, a compatibility mode is offered. That is, when an old application is launched, the system switches to the compatibility mode where all system UI components will use the 176 x 208 resolution. </p><p>When applications are built for the scalable UI architecture, some modifications are needed to support the new architecture, but the benefits are high. The new scalable UI framework allows the developers to easily adapt and migrate their applications to higher resolutions. </p><p> Support for the scalable UI in S60 reduces mobile application development fragmentation, because the single platform can manage a multitude of different UI resolutions. </p><p> Compatibility with 2nd Edition platform base technologies is maintained. </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 17 </p><p>5. Basic structure of an XHTML application </p><p>5.1 XHTML prologue </p><p>The first line of the prologue defines the character encoding for XML; this line is not mandatory but is recommended. A single DOCTYPE declaration is required, prior to the root element, with a public identifier. (This declaration gives a reference to the DTD to which the document should be compared for validation.) </p><p><?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd" > </p><p>5.2 Mandatory XHTML elements </p><p>An open and closed XHTML tag is usually referred to as a XHTML Element. XHTML elements also have attributes that can be set. For example, the <p> element specifies a new paragraph and has alignment and line-wrapping attributes. There are a number of mandatory elements for an XHTML document, and these are described in the following sections. </p><p>5.2.1 Root element, <html> </p><p>Following the DOCTYPE declaration is the root element, <html>, which encloses the rest of the document. </p><p>To strictly conform to the XHTML standard, the XML’s attribute should be defined for the root element. Only one possible value for the XML’s attribute is allowed (xmlns=http://www.w3.org/1999/xhtml) and, therefore, a tacit assumption is made. However, this feature may not be supported in all S60 devices. </p><p>5.2.2 Head element, <head> </p><p>The <head> element contains a document's metadata and can hold key words for search engines as well as style information. The mandatory document title (<title>) must be defined within the <head> element. Other possible child elements are <base>, <link>, and <style>. </p><p>5.2.3 Title element, <title> </p><p>The <title> element is a required child element of <head> and should be used to define a displayed title for the document. </p><p>5.2.4 Body element, <body> </p><p>An XHTML document must contain one body element, <body>. All of the document’s displayed content (text, images, tables, and so forth) is nested within the <body> element. </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 18 </p><p>Attributes: id — An optional attribute used to set a unique ID for the element. class — An optional attribute used to assign one or more classes to the element. Class names are case sensitive. style — An optional attribute that allows a presentation style, defined in terms of CSS, to be applied to the element. </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 19 </p><p>6. XHTML MP elements </p><p>The S60 mobile browser supports all mandatory elements of XHTML MP specification except Object and Meta elements. The following guidelines are for using XHTML MP when designing services for the S60 dual browser. They provide an overview of the XHTML MP elements that are critical from the rendering point of view and the XHTML MP capabilities supported by the browser. This chapter does not include all possible XHTML MP elements and attributes. </p><p>6.1 Text formatting </p><p>The content of an XHTML page is displayed in the application/main area of the display. The order of elements is significant, as they appear on the screen in the same order. </p><p>White space is ignored unless the <pre> element is used. See Section 6.1.4, “Pre element,” for more information on the <pre> element. It is recommended to check that there is no extra white space inside the code. Although white space has a zero size, it is still processed, as the browser parses, formats, applies CSS to, and renders white space. </p><p>Element Formatting </p><p>Abbr Normal </p><p>Acronym Normal </p><p>Address Italic if supported, normal otherwise </p><p>Blockquote Indented normal text (cite is ignored) </p><p>Cite Italics if supported, normal otherwise </p><p>Code Normal </p><p>Defn Italics if supported, normal otherwise em Bold </p><p>H1- h6 Actual font size product dependent </p><p>Kbd Monospace if supported, normal text otherwise strong Bold font b Bold font i Italics if supported, normal otherwise </p><p>Var Italics font </p><p>Pre Monospace </p><p>Span Inline container for text u Underlined font big Font size is set to larger small Font size is set to smaller </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 20 </p><p>Element Formatting </p><p>P, div Block container for text q Normal text, within quotes </p><p>Samp Normal </p><p>Br A line break is inserted in the text </p><p>Table 1: Default styles for text layout formatting elements. These styles may be overridden using style sheets </p><p>6.1.1 Zooming </p><p>Zooming affects the size of the rendered text within the application/main area. The zooming function affects only text font sizes, not images, tables, or the space around text and other elements that are not specified proportional to the size of the text. </p><p>Zooming applies to text even if its size is specified in WCSS. If a font size is specified in CSS, the nearest available font size of the device is to be used. Zooming is applied to the displayed nearest physical font size of the device, not the text size specified in the CSS. This ensures that zooming always makes all text larger (if a bigger font is available for the text in the device). </p><p>The S60 mobile browser has three selectable text sizes that restrict the amount of available zooming in the browser to values. Table 2 displays the zoomed text sizes. </p><p>Document defined text sizes in pixels Zoom level 12 13 17 </p><p>All large 17 17 17 </p><p>Larger text 13 17 17 </p><p>Normal text 12 13 17 </p><p>Smaller text 12 12 13 </p><p>All small 12 12 12 </p><p>Table 2: Zoomed text sizes </p><p>6.1.2 Paragraph and content alignment </p><p>The paragraph element, <p>, enables word wrapping and content alignment. A paragraph always starts on a new line. </p><p>The content inside a paragraph can be aligned to the left, center, or right; by default, alignment is to the left. The alignment is set by using paragraph attributes (see Example 1). The recommended method of specifying alignment in XHTML is by using style sheets. </p><p>A paragraph will always be wrapped unless the content specifies nowrap and the user wrap setting is off. </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 21 </p><p><p align=”center”> Align "center" </p> <p align=”right”> Align "right" </p> <p align=”right”> </p><p>Example 1: Paragraph element and alignment </p><p>6.1.3 Line break </p><p>The <br> element forcibly breaks (ends) the current line of text. The HTML clear attribute specifies how text after the forced line break is wrapped around a floated element, for example, an image. Possible values are left, right, all, and none. The default value is left. Left prevents floated elements from being displayed to the left of the element. Right prevents floated elements from being displayed to the right of the element. All prevents floated elements on either side of the element. In all of these cases, the top margin of the element is increased until the top edge of the element’s border is just below the bottom edge of the floated element. None allows floated elements to appear on either side of the element. </p><p>See also the float property for style sheets in Section 7.2.3, “Float.” </p><p>6.1.4 Pre element </p><p>The pre element, <pre>, causes text to be displayed “preformatted” to the extent possible. Preformatted means that white space is left intact, the font is displayed as plain text, and word wrapping is enabled/disabled according to how the browser is set. </p><p>6.2 Tables </p><p>The table element, <table>, is used together with <tr> and <td> elements to create sets of rows and columns of data, such as text, images, links, and so on. Also, the <caption> element can be used. It is possible to have text, images, and tables on the same page. The cells are shown in bordered rows and columns. The presentation attributes of a table should be defined in a style sheet, for example, the border width, border color, text alignment, etc. </p><p>Automatic width of cells and columns depends on the number of columns and the amount of content inside the cells. For example, if the table contains three or more columns, the width of a table cell plus its border is one third of the display width, and if the table only contains one column, the fixed width of a table cell and its border is the width of the display. If the table cells and columns are narrow (only a small amount of content in cells), it is possible to have more than three columns on the display. The developer can also specify cell sizes in style sheets or by using style elements or style attributes. Cells and columns are sized based on the first row. </p><p>Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 22 </p><p>Figure 2: Example of different tables </p><p><?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd" > </p><p><html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Schedule
Time Schedule
Round
of 16
29 June
Finals
30 June
Example 2: Table element
When using nested tables, content developers should avoid specifying the parent table width as a percentage while the child table widths are expressed explicitly. For example, consider the following content segment:
The parent table is specified as width 100% of the containing box (176 pixels on most S60 devices), while the nested table within it specifies a width of 140 pixels. The width of content within the nested table is set to 140 pixels, but the parent table is constrained to displaying only 70% of the containing box, there by cutting off almost half of the nested content width.
Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 23
It is recommended that absolute widths (pixels) are used for both parent and nested tables, to ensure the content will be rendered properly. Care should be taken to ensure that the total table width is the same as the sum of the individual column widths plus borders and cell spacing. In general, as table nesting levels increase, so do the complexity of the page and the processing time required for displaying the page.
The less nesting there is, the faster the table will load on the target device.
Tables should not have borders that are too thick, since in a device with limited display size the border width can easily consume enough pixels to make the actual content area too small to be useful. " >
The hardware keys 0-9 can be assigned to certain elements in the page. If the # key or the * key are assigned as access keys, they are ignored by the browser. Adding the label of the key to an element indicates to the user which key should be pressed in order to activate that element. For example, if the service provider associates the key 1 with a link, the number 1 can be added to the label of the link.
An access key has an effect on an element even if the element is not highlighted or visible. After an access key has been pressed, the element is highlighted if it was not already highlighted.
6.5 XHTML MP input processing
Input processing enables the user to input requested information to the service. There are two kinds of input elements: input fields created using an element and selection lists created using a
6.5.1 Input elements
The input element is a rectangular editing box. Its size is determined by a size attribute. It also has a type attribute, the allowed values of which are text, password, check box, image, radio, reset, and submit. If text type is used, input is displayed to the user in a readable form, whereas if password type is used, input of each character is obscured. Text is the default type.
When the element is of type check box, a check box is displayed. There is a checked attribute for setting the initial state of the check box; the default state is not checked. No line breaks are inserted before or after the check box. When a check box has focus, it is highlighted.
Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 26
When the element is of type image, a graphical submit button is displayed. No line breaks are inserted before or after a graphical submit button. A graphical submit button is displayed as an image anchor.
When the element is of type file (S60 2nd Edition, Feature Pack 2 and onwards), a rectangular editing box with three dots is displayed. When the element is activated, the "Gallery" of the device is shown and the user can select the content to upload. After the user has made the selection, the XHTML page is displayed again and the name of the selected content is shown on the element.
When the element is of type radio, a radio button is displayed. There is a checked attribute for setting the initial state of the radio button; the default state is not checked. No line breaks are inserted before or after the radio button. When a radio button has focus, it is highlighted. If two or more radio buttons of the same name in the same form have the checked attribute, only the first declared will be preselected. When a radio button is activated, all of the other radio buttons with the same name attribute value in the enclosing element are deactivated.
When the element is of type reset, a reset button is displayed. No line breaks are inserted before or after a reset button. The default label text is Reset.
When the element is of type submit, a submit button is displayed. No line breaks are inserted before or after the submit button. The value attribute is for setting the label text of the button. The default label text is Submit.
Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 27
The size of the textual input boxes (input, textarea) depends on size settings and the text inside the box. If the input box does not fit on the current line without exceeding the display width, a line break is inserted and the input box is drawn on the next line. If the input text is longer than the input box, the text is truncated and an ellipsis is added.
The user can input characters to an element after highlighting it. The user can also open the editing box by pressing the navigation key on the highlighted editing box or by selecting the Options list item Open when the editing box is highlighted.
6.5.2 Select element
Selection lists are elements that specify a list of options for the user to choose from. There are two kinds of selection lists supported: single-choice and multiple- choice lists. The user can select multiple choice if the multiple attribute is set as true (selected items are marked with a selection symbol).
A selection list item on a card is a rectangular box that looks similar to an element item. Inside the selection box, there is an arrow character in link color (default: blue) pointing to the right. This arrow is positioned at the very end of the last line of the selection box. The arrow differentiates the selection box from the editing box, which is used for input elements.
The user can open a selection list when a selection list is highlighted. Selection lists can have a title and a predefined value. The title is used as a label for the list of values from which the user can choose one (single selection list) or more (multi-selection list) values.
Selected values are displayed in the selection box. If more than one value is selected in a multi-select list, the values are separated with commas.
Figure 6: Selection box with default values
The size of the selection box fits the size of the selected value(s). The selection box contents will automatically be truncated if they exceed the screen size (that is, if the selected values do not fit into the space that is available in the box on the current line). The option element specifies a single option in a select element. Options can be grouped with an optgroup element, which specifies a group of choice items in a select element.
Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 28
Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 29
7. WAP CSS
Style sheets enable the content of a page to be separated from its presentation, thus allowing the same content to be targeted to different platforms simply by changing the style sheet. Style sheets also give developers much more control over the way a mobile application looks than was possible with WML. Every aspect of a WAP page's appearance – positioning, fonts, colors, text attributes, borders, margins, and alignment – can be defined in a style sheet.
This chapter offers guidelines for using WAP CSS when designing services for the S60 dual browser. It provides an overview of the WAP CSS properties that are critical from the rendering point of view and the WAP CSS properties and attributes supported by the browser. This chapter does not include all possible WAP CSS properties and attributes.
7.1 Applying style sheets
The S60 XHTML browser has a default style that specifies how all XHTML MP elements will be displayed in the event that developers do not specify their own styles. Developers can specify their own styles in various ways: in an external style sheet, in a style element in the document head, or by using inline style attribute in a specific element.
7.1.1 External style sheets
External style sheets are specified in the head element of a document using a element. More than one external style sheet can be used per document. To define an external style sheet:
7.1.2 Style element in document head
A
7.1.3 Inline styles
A style attribute can be set for a single element anywhere in the document where the element is specified. This is an XHTML MP extension. It allows an application developer to apply style properties to individual elements.
Red will be the font color for just this paragraph:
red
7.1.4 Cascading rules for style elements
Style elements specified first will be overridden by identical style elements defined later. The default style for the browser has the lowest priority in the cascading order, followed by an external style sheet and then a style element in the document head. Inline styles have the highest priority.
Version 1.4 | May 24, 2005 S60 Platform: Designing XHTML Mobile Profile Content 30
7.1.5 Global selectors, class attribute
Global selectors can be used to define style for all elements of a give class. A class containing style properties can be defined in an external CSS or in a document's
