Images XHTML - PART VI

XHTML
XHTML is a markup language for Web pages from theW3C(World Wide Web Consortium). XHTML combines HTMLand XML into a single format (HTML 4.0 and XML 1.0). LikeXML, XHTML can be extended with proprietary tags. Also like XML,XHTML must be coded more rigorously than HTML. Over the years,HTML coders have become sloppy, because Web browser software was originally written to tolerate many variations in HTML coding, but, with XHTML, coders must conform to the XML rules.
In one sentence we can say that XHTML is a superset of HTML, but unlike HTML it is stricter to rules and requires a document to follow XML rules.Whereas HTML is an application of SGML, a very flexible markup language, XHTML is an application of XML, a more restrictive subset of SGML.
Designing Web Sites Site Structure Whether you are developing Web pages for personal use or you become involved in commercial Web ventures the point arrives where you need to become conscious of Web site design. You will need to bring organization and logic to the proliferation of pages. Site design is not an exacting science; still, there are organizing principles and design strategies that can help you produce a more manageable site that assists your visitors in navigating its pages to find the information they desire or that you intend. Web Site Goals It should go without saying, but a Web site should have a purpose. There are few Web activities as frustrating as navigating a site that is a hodge-podge a pages with no apparent focus. You probably have visited sites that contain one very long Web page intermixed with content and links that seemingly have little relationship to one another; or you have encountered sites at the other extreme, with tiny content pages within a labyrinth of links that leave you isolated at its farthest reaches, staring at irrelevant content, and with no apparent way to get back to where you came from. Both of these extremes show a lack of foresight and planning. The site designer probably had no notion of its intent other than to create a Web presence. Therefore, the site evolved in helter-skelter fashion, creating an unpleasant navigational journal for visitors. A key factor in site design, then, is to have a clear idea of its purpose. That purpose can be modest or elaborate. In either case, you should be able to frame its purpose verbally or in writing. Even for a personal Web site it is helpful to produce a statement of intent. Consider, for instance, the following statements of purpose: • To present a personal resume of education, experience, and work portfolio for reference by prospective employers. • To create a family Web site to summarize current activities of family members. • To create a Web site to document vacation travels. • To maintain a geneology of the family. • To manage classwork related to my Web development. Each of these statements brings focus to the site while permitting it to grow within reasonable bounds. You avoid the risk of creating a single site that tries to incorporate all aspects of your personal life in a conglomeration of unrelated pages and links. If you are, or become, a professional Web developer, then the statement of purpose is usually easier to define. It often derives from an organization's vision statement or mission statement, the guiding purpose for the organization. In a commercial enterprise, for example, common Web site purposes include • To market and sell the primary product line of the company. • To provide technical support services to customers. • To increase public awareness of the company and its products. • To lower business costs through electronic transactions with suppliers and distributors. • To enhance in-house communications of company directions and activities. Like the personal goals described above, these objectives set the boundaries of the site. It becomes clearer whether or not particular content or links contribute to the purpose. Web Site Content Being able to define the purpose of a Web site also helps to determine the type of content to be presented and its organization. The process of structuring the content of a Web site is not unlike the process of designing a database. You can, in fact, think of a Web site as a database of information composed of pages of content arranged by their linked relationships. In database parlance, your task is to create "entity-relationship" models of the information to be presented; in Web parlance the task is to create "content-link" models of the information. A good statement of purpose for your Web site will help you determine items of content appropriate to the site. In the same way that database designers identify the major entities -- the objects of informational interest -- to be included in a database, you need to identify the major objects of informational interest in your Web site. Taking the example above of a personal site to manage classwork for a course you are taking, the major items of interest might be • textbook reading summaries • lecture notes • assignment solutions • projects • grades • calendar Although you may think of other informational entities related to a class, this list presents a good start in breaking down the purpose of the site into those content areas related to its purpose -- and only those areas related to its purpose. At this point it is not necessary to know all the informational details about your site. It is important only to identify the major topics around which the site will be developed. Analogous to writing a report, you need to outline your topic to determine the main headings that will be expanded later into paragraphs, sentences, and words. Web Site Structure The topics, or informational entities, that comprise a Web site are logically related in some fashion. At least they should be related since they are derived from a common purpose. Further, these topics eventually need to be physically packaged as Web pages with links between them; plus, the physical arrangment of pages and links needs to parallel their logical relationships. There are three primary ways in which to organize topics and their container Web pages -- hierarchical, linear, and mixed. Any of these structures, or their combinations, are devised for your content to become Web accessible. Hierarchical Structure A hierarchical, or tree, structure of topics is the most common arrangement of Web pages. A tree structure arranges topics from general to specific -- or from summary to detail -- from the top to the bottom of the hierarchy. Hierarchical arrangement of Web pages. The top page in the hierarch is usually the "home" page providing an overview of the site, with links to the main topical subdivisions. Each of these subdivisions, in turn, link to pages containing more detail about the topic. Navigation, then, tends to be down the hierarchy with returns links up the hierarchy that retrace the same downward path. There can be occasional crosslinks between topics at the same level of the tree, but not usually. This structure brings logical organization to a site and permits visitors to find information in a rational top-down fashion. Linear Structure A linear, or sequential, structure of Web pages is most appropriate where the topical information needs to be accessed in a particular order. Linear arrangement of Web pages. In presenting a story, a time-line of events, or the steps in a process, a linear sequence of Web pages probably works best. The links are from one page to the next with return links retracing the sequence. If necessary, additional links can be made between the opening page and each of the detail pages for jumping into and out of the sequence. Still, the basic structure is linear. Mixed Structure Most likely, a Web site is not exclusively hierarchical or linear, although one of the structures dominates. It is common to find an overall hierarchical structure with linear sequences of pages at the detail level. Mixed arrangement of Web pages The above organizational structures are not meant to imply that Web content must be shoe-horned into these arrangements. They are presented as conceptual schemes only; you will need to determine the best arrangement of pages for presenting your content in an organized fashion. By keeping them in mind, however, you are forced to think about how the information itself is structured and to devise compatible linkage structures for offering it in the clearest and most logically consistent manner. Designing Web Sites Storyboarding As you develop the structural layout of your Web site you also begin packaging its content as individual Web pages with specified links between them. A common way of modeling the content and links between Web pages is called storyboarding. This technique visually maps Web content to Web pages and describes the links that implement the logical relationships between topics. Storyboarding forces you to flesh out your topics and refine their relationships. Content Packaging Consider the following illustration of a portion of the structure of this XHTML tutorial. This diagram represents the layout of the first section of tutorials with topics identified along with menu links to the associated pages. Structure of portion of XHTML tutorial Since the pages appear inside frames there is no need for return links. The menu is always accessible for direct linkage to any page. Although additional linear links between pages would be an option, these extra links would be redundant. Design Drawings You shouldn’t pay a lot of attention to the format and symbols used in the high-level storyboard. There are no formal graphical standards for storyboarding. You might, in fact, draw your layout in crayon on the back of a grocery bag and accomplish your purpose just as well. Sometimes professional developers become overly committed to using formal graphical tools to make design drawings and lose sight of their purpose, which is to construct mental models, or abstractions, of designs in order to manipulate them intellectually. The purpose is not to produce pretty drawings. Pick the symbols and techniques that work best for you. Of course, if you work professionally as a site designer, there may be in-house architectural standards for design drawings. However, you can always reproduce your conceptual drawings as design documentations when that time comes. With this structural layout in hand the next step is to elaborate the content appearing on each page. One way to do this is with a text outline of topics, subtopics, and "talking points," much like you would do for a written report. For instance, the first page of this tutorial can be outlined as follows. Internet History and Usage 1. Introduction 2. ARPANET a. Origins of ARPA b. Purposes of ARPANET c. Distributed packet switching (Leonard Kleinrock) d. ARPA network growth e. TCP/IP 3. NSFNET a. Origins and purpose b. Defunding implications c. Internet definition 4. WWW a. Hypertext concept (Ted Nelson) b. World Wide Web beginnings (Tim Berners-Lee) c. Browser development 5. Technical Convergence a. Protocols b. Formatting language 6. Internet Usage Statistics a. Country ranking by usage b. Regional ranking 7. Internet Technologies a. Connection speeds b. Browser version c. Screen resolution d. Color depth Outline of first page of XHTML tutorial. Since a Web page can be as much a visual experience as a textual one, some Web page authors utilize graphical storyboarding in addition to text outlines to indicate page content. This technique roughs out the main formatting characteristics of the page as well as organizes the content. The following illustration is one way to graphically characterize the first portion of the opening page of this tutorial. Storyboard for a Web page. Although it is shown here as a graphic image, the storyboard for a page can be a hand drawing or an XHTML layout of the page. You might wish to use WYSIWYG editors such as FrontPage or Dreamweaver to produce "quick and dirty" layouts. The purpose is not to generate specific content but to indicate some beginning page design thoughts. You might wish to note the main headings that appear on the page, any graphics or tables that need to be included, a rough estimate of the amount of space to be devoted to different topics, and any links to internal pages or external sites. You should, though, at this point begin to firm up the basic, common design that will be used across all pages. In order to visually and operationally tie your pages together with a common "look and feel" it is appropriate to settle on design considerations such as page margins and paragraph styles, color schemes, heading sizes and colors, text fonts and sizes, link formats, and other general design characteristics that will be common to your pages. One of the advantages of using HTML editors at this point is that you can experiment with different designs. As you settle these overall design issues you also can begin constructing the Cascading Style Sheets that will be applied to your pages. Use a linked style sheet for overall design and formatting with embedded or in-line style sheets to alter or enhance styles for particular pages. Page Sizes One major design issue relates to the appropriate size for a Web page. The width of the page needs to take into account the width of the browser window which, in turn, is determined by the user's screen resolution. The three common horizontal and vertical screen resolutions are 640 x 480, 800 x 600, and 1024 x 768 pixels. Currently, 800 x 600 is the most common screen resolution. Unless you have reason to do otherwise -- knowing, for example, that your population of visitors uses other resolutions -- then it makes sense to target your pages to 800 x 600 screens. The browser window, though, contains borders, menu bars, status bars, scroll bars, and other trappings that reduce the amount of space within which a Web page is displayed. The following table gives the dimensions of the effective sizes of browser display windows under different screen resolutions. Screen Resolution Browser Window Size   640 x 480 600 x 300   800 x 600 760 x 420 1024 x 768 955 x 600 Monitor creen resolutions and browser window sizes. Horizontal Sizing The browser word-wraps free-flowing text so that it always stays within page margins. Other page elements, however -- such as graphics or text containers that are of fixed sizes -- may not fit within these boundaries. The problem that is caused is a horizontal scroll bar on the browser window, something that should be avoided on all Web pages. There are few things more irritating, or unproductive for that matter, than having to scroll back and forth to view Web page content. The following browser window illustrates the problem and the solution. The first shaded division has a width setting of 760 pixels, proper for a screen resolution of 800 x 600. However, when displayed in a browser on a 640 x 480 screen, the division extends beyond the page margin and introduces a horizontal scroll bar to view its entire width. Page Widths Here is a text paragraph. By default the browser word wraps text to keep it within the boundaries of the browser window. Other page elements, however, can extend beyond the margins of the page. <div style="width:760px; height:75px"> </div> <div style="width:100%; height:75px"> </div> Managing page widths. The best solution for sizing text blocks is to use a percentage measure as is done in the second division. The width shown here is 100%. Therefore, the division will extend only to the width of the page margins irrespective of screen resolution. When displaying graphics, horizontal sizing is a little more problematic since adjusting widths may distort the picture or cause pixelization when forced to widths larger than its original size. It is always best to size the picture itself rather than adjusting it with style settings. Pick a size that fits within a 600 x 400 window to ensure that it fits properly within any other browser window. Vertical Sizing Obviously, there's not a lot that can be done about the vertical sizes of Web pages. They expand to encompass the amount of content. Of course, you can always subdivide your content into separate, shorter pages with links between them. The trade-off becomes one of vertical scrolling versus link clicking, neither of which has particular priority for user friendliness. Design Mythologies You may encounter page design guidelines that recommend nonscrolling pages in all cases -- that all pages should fit within the browser window without even vertical scrolling. Not only does this guideline make it difficult for the designer to find physical page breaks where none my logically exist, it introduces excessive clicking and linking that can disrupt the reader's flow of thought. It is best never to let physical containers dictate the flow of their content. Use reasoned judgement to determine how best to package your information. Page Organization Recognize that the reader's first impression is produced by what is seen at the top of the page when it first loads. In newspaper parlance this is the page area "above the fold" which provides the first clues about page content. This is the most important real estate on the page when it comes to serving the browsing needs of visitors. Visitors arrive at a Web page looking for information. The initial page load should either provide that information or quickly direct visitors to it. A typical design for the top of each page includes, • A common identity -- a banner, logo, and/or headings -- to tie the page visually to other pages of the site. • The most important information on the page or a summary, possibly with links down-page to sections of detail information. • A common menu of links to other major sections of the site. • A menu of links pertinent to the content of the page. Readers should know at first glance whether this page contains the information they are looking for. If so, they can scroll down to find it; if not, they can immediately navigate to other pages. Designing Web Sites Page Colors Colors draw attention to a Web page. They focus interest on page elements and help to highlight important information. Colors can also be distractive. Improperly used they can draw attention to themselves and away from central page content. One of the most important choices you make as a page designer, then, is a color scheme to complement or enhance information appearing on a Web page. Color Wheel A color wheel is a chart that shows how colors are related to make it easier to choose harmonious color combinations that attract attention to page content. The color wheel is divided into three categories of colors. Color wheel Tints and shades The primary colors are red, yellow, and blue. These are the foundation colors from which all other colors derive. They are called primary colors because no other colors can be mixed to create these colors. They are evenly spaced around the color wheel. Secondary colors are produced by combining any two of the primary colors. The three secondary colors are orange (red + yellow), green (yellow + blue), and violet (red + blue). Tertiary colors are produced by mixing a primary color and an adjacent secondary color. The six tertiary colors are red-orange, red-violet, yellow-green, yellow-orange, blue-green, and blue-violet. The purest value of a color is its hue. A color's tint is a lighter value of the hue made by adding white; a color's shade is a darker value of the hue made by adding black. Picking Colors When choosing colors for a Web site it is best to select only a few colors. You do not want to overpower and detract from the information contained on the page; you want to complement or emphasize it. Generally, you will pick a dominant color along with other colors that are analogous to it or that contrast with it. There are standard color-matching schemes that can be followed in picking these colors. Monochromatic Monocromatic colors. A monochromatic color scheme uses a single hue with various tints and shades for contrast. Normally you will pick darker colors for text presentation and lighter colors for backgrounds. The various tints and shadings range from bold to subtle, and you need to choose the combination that works well for the message you are trying to get across and the mood you are trying to set. Monochromatic Table Colors Section Hue Hex Value RGB Value Header Red (dark) #CC6666 204,102,102 Column Red (light) #FAC8C8 250,200,200 Background Red (light) #F6E1E1 246,225,225 Examples of monocromatic colors Analogous Analogous colors An analogous color scheme uses adjacent hues and their tints and shadings. All of the colors share a common hue, for example, red-violet, red, and red-orange. The presentation and feeling is similar to a monochromatic scheme with a larger assortment of hues from which to choose. Analogous Table Colors Section Hue Hex Value RGB Value Header Red-Violet (dark) #C4028F 196,2,143 Column Red-Orange (light) #FEB7B3 254,183,179 Background Red (light) #FFCCCC 255,204,204 Examples of analogous colors Complementary Complementary colors A complementary color scheme uses a hue on the opposite side of the color wheel from the dominant color. This color combination provides the greatest contrast and makes both colors more intense and brighter than when they are used alone. Complementary Table Colors Section Hue Hex Value RGB Value Header Red (dark) #C4028F 196,2,143 Column Green (dark) #02D0BF 2,208,191 Background Green (light) #D0F2E0 208,242,224 Examples of complementary colors Split-Complementary Split-complementary colors A split-complementary color scheme uses a hue along with two colors that are adjacent to its complement. For example, if the dominant color is red, then split-complementary hues are yellow-green and blue-green. Split-Complementary Table Colors Section Hue Hex Value RGB Value Header Red (light) #FF6666 255,102,102 Column Blue-Green (dark) #25EADA 37,234,218 Background Yellow-Green (light) #E6FBC6 230,251,198 Examples of split-complementary colors Triadic Triadic colors A triadic color scheme uses three hues that are evenly spaced from each other on the color wheel. For example, if the dominant color is red, then blue and yellow hues are the triadic complements. Like the complementary color scheme, this one also emphasize the colors through their contrasts. Triadic Table Colors Section Hue Hex Value RGB Value Header Red (light) #FF7575 255,117,117 Column Blue (light) #7676FB 118,118,251 Background Yellow #FFFF99 255,255,153 Examples of triadic colors Achromatic Although they do not appear in the color wheel, don't forget about black, white, and the range of gray tints that can be applied to highlight or emphasize page content. These achromatic tones can offer high contrast or subtle shading. Achromatic Table Colors Section Hue Hex Value RGB Value Header 50% Gray #818181 255,117,117 Column 25% Gray #C1C1C1 193,193,193 Background 5% Gray #F6F6F6 246,246,246 Examples of achromatic colors Designing Web Sites Typography Usually, Web pages are meant to be read rather than viewed. This means that you need to devote thought to the text styling that can make your pages most legible and readable while fitting in with other design considerations. Typography is this relationship between letterforms on a page, playing a dual role in the visual design of the page and in enhancing its readability. The term font has become the catch-all term to denote text characteristics employed on a page. More accurate, the term typeface refers to a consistent visual design for the symbols of the alphabet; a font family is a related set of typefaces, including their rendering in bold, italic, and other typographical off-shoots. The following illustration shows some common terminology used in describing text styling. Typographic terminology Outline Fonts Rasterizing outline fonts. Most digital fonts -- such as Microsoft TrueType and Adobe PostScript -- are stored as character outlines using mathematical descriptions of the characters. Use of these outline fonts means that only one outline per character is needed to produce all the sizes of that character; it can be scaled to different sizes and even skewed and rotated without losing its characteristic shape. In order to be displayed on a computer screen or on printed paper, the outlines need to be "filled in," or rasterized as pixel points. Rasterizing software performs this function as shown in the accompanying illustration. Font Families It is important to remember that a Web page can only display those fonts that are installed on the user's PC. Therefore, nonstandard fonts should be avoided. The core fonts that are installed on Windows computers along additional fonts installed with Windows XP and Office that can be rendered in the browser are shown in the accompanying table. MS Core Fonts XP Fonts MS Office Fonts Typical core fonts installed on desktop computers Of course, most users have other software installed on their systems which come with additional fonts to support those applications. Those fonts may or may not be accessible for browser display. Fonts can be classified as serif and sans-serif (without-serif) styles. Serifs are the small "tick marks" at the end of character strokes. You can see this difference in the Times New Roman (serif) and Arial (sans-serif) fonts shown below: Serif Sans-Serif Serif and non(sans)-serif type faces Generally one serif font for text and one sans serif font for headings (or vice-versa) are a good combination. A page should contain no more than two different typefaces or four different type variations such as type size and bold or italic style. Font Size Readability is affected by font sizes. Type is traditionally measured in points, which is 1/72 of an inch (on paper). However, computer screens are based on pixels, rather than points, so rendering software must translate point sizes to pixels units taking into account screen resolution. You can see from the two lines below how 12-point type size equates to approximately 16-pixel type size on the screen. 12pt Times New Roman (print) 16px Times New Roman (screen) Point and pixel type sizes. A type size of 10 or 12 point makes for comfortable reading by most people. If smaller sizes are necessary, then choose fonts with wider spacing and larger x-heights. The x-height is the height of lower-case letters measured from the baseline. The following two lines are displayed at 8-pt size in Arial and Verdana type faces. The latter line is not as crowded at that size and is easier to read. A quick brown fox jumps over the lazy dog. A quick brown fox jumps over the lazy dog. Comparison of type faces and type size Incidentally, Verdana is becoming a popular Web font because it is designed to map accurately to pixel positions on a screen. Also, a non-serif font such as Arial or Verdana is easier to read on screen, while a serif font such as Times New Roman is easier to read on paper. Line Size Readability also depends on line height and line length. In general, default spacing in the browser provides decent spacing between lines. A line length of approximately 60 to 80 characters permits good tracking of the eyes from the end of one line to the beginning of the next. The following lines contain approximately 75 Verdana characters at 9-pt size. Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry? standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. Typical font size, line length, and line spacing. White Space A prevelant mistake of page authors is to crowd too much information between tiny margins. It can be monotonous and tiring reading line after line of text from border to border without breaks. Make sure you leave plenty of white space in the margins and that sufficient numbers of headings and graphics break up the monotony of the page. Text Color Color can be used for text variety. As in the case with graphic images, choose a small number of coordinated colors and be consistent in their use. Readers tend to see colors, as they do text sizes, as visual clues with logical meaning. For instance, you will normally use different font sizes for different levels of headings. The size of the font comes to mean a certain type of topical change in content. By the same token, colors take on expected meanings. Be consistent in the color cues you give to readers. ecorative Fonts One way to introduce nonstandard fonts on a Web page is to use graphic images of letterforms like the character "D" in the previous heading. This technique ensures that the font will be displayed irrespective of the visitor's installed fonts, and it introduces variety to the page. Use graphic letters selectively, though, since they increase page download times and they increase the risk of cluttering the page with hard-to-read characters. Designing Web Sites Accessibility Web technologies are forever forging ahead. Each day brings new gadgetry and wizardry to the browsing experience, opening up reams of electronic information and entertainment at an accelerating pace for those with the technical where-with-all to access it. Yet, many Web citizens are not in a postion to reap the advantages because of both technical deficiencies and physical disabilities for experiencing the content as originally conceived and presented. Web accessibility issues pertain to page design for users who: • may not be able to see, hear, move, or may not be able to process some types of information easily or at all. • may have difficulty reading or comprehending text. • may not have or be able to use a keyboard or mouse. • may have a text-only screen, a small screen, or a slow Internet connection. • may not speak or understand fluently the language in which the document is written. • may be in a situation where their eyes, ears, or hands are busy or interfered with (e.g., driving to work, working in a loud environment, etc.). • may have an early version of a browser, a different browser entirely, a voice browser, or a different operating system. Web developers should consider these situations during page design. Granted, there may be situations where it is impractical or unwise to compromise a design for accessibility purposes. A Web site that features inaccessible technologies need not apologize for lack of presentation alternatives if none are truly available to duplicate the experience in other ways. There are also cost and marketing considerations. It may be resource-prohibitive to create a parallel site for a small population of users and a competitive disadvantage to delay available until it is completed. Still, the search for presentation alternatives should continue. In some cases there are technical solutions to accessibility problems. In other cases there are page coding remedies. Assistive Technologies Assistive technologies provide mechanical and software means to overcome physical or cognitive disabilities. Examples include • Eye movement mouse. A camera mounted on the computer monitor focuses on the user's eye. The mouse cursor is positioned where the user is looking and mouse clicks are performed with an eye blink. • Foot control mouse. A foot control mouse uses two pedals, one for cursor movement and the other for mouse clicks. • Head tracking mouse. A signal from atop the computer monitor tracks a reflector placed on the user's head or eyeglasses. Movement of the user's head controls the direction and distance of cursor movement. • Touch sensitive keyboard/mouse. The keyboard works with the slightest touch of a hand-held wand or mouth stick requiring no force of pressure. The mouse function works like a standard mouse but requires no hand dexterity. • Mouth controlled joy stick. A pointer controls cursor movement on the screen; "sipping" or "puffing" on the mouth stick simulates mouse clicking. • Touch screen. Screen overlays are sensitive to finger and wand touch to track cursor movement and activate mouse clicks. • Screen and text readers. Software reads aloud or converts to brail information appearing on the monitor screen or speaks text entered through the keyboard or appearing in documents such as text files, email messages, or word processing documents. • Screen magnification. Software enlarges screen display to as high as 16x magnification. • Sign language communicator. Converts text or speech to video sign language or computer-generated voice. • Speech recognition. Devices and software to control computers through spoken words and phrases; assistive writing by coverting speech into text without use of pencil and paper. • Cognitive planners/reminders. Assist users in accessing and remembering information; provides on screen cueing and planning assistance for people with memory and attention disorders, keeping them on schedule with graphic displays, selection menus, and personalized verbal and audio signals. Most of these solutions take place on the end-user side. They must be purchased and installed on individual computers. The Web developer has little or no impact on whether Web content may be accessible by these methods. The developer can, however, assist many of these assistive technologies by following compatible site design and coding practices when creating Web pages. W3C Accessibility Guidelines The World Wide Web Consortium (W3C) produces a set of Web Content Accessibility Guidelines (http://www.w3.org/TR/WCAG10/) on how to make Web content accessible to people with disabilities. By following these guidelines content developers can create pages that remain accessible despite the constraints of physical, sensory, and cognitive disabilities. Some general keys to designing such pages include: • Separate structure from presentation. Recognize that the information content of a Web page is different from, and usually separate from, its visual appearance. • Provide text alternatives to audio and video content. Text can be rendered in ways that are available to almost all browsing devices and accessible to almost all users. • Create documents that do not rely on one type of hardware. Pages should be usable by people without mice, with small screens, low resolution screens, black and white screens, no screens, and with only voice or text output. The W3C provides fourteen guidelines under three priority levels commensurate with their impact on accessibility. Some of these guidelines refer to technologies or techniques that are not covered in this tutorial. Priority 1 guidelines must be satisfied; otherwise, one or more groups will find it impossible to access information in the document. Priority 2 guidelines should be satisfied; otherwise, one or more groups will find it difficult to access information in the document. Priority 3 guidelines may be satisfied; otherwise, one or more groups will find it somewhat difficult to access information in the document. The following discussion summarizes these guidelines. You should visit the W3C accessibility site for complete details. Guideline 1. Provide equivalent alternatives to auditory and visual content. This guideline emphasizes the importance of providing text equivalents of non-text content (images, pre-recorded audio, video). The power of text equivalents lies in their capacity to be rendered in ways that are accessible to people from various disability groups using a variety of technologies. Text can be readily output to speech synthesizers and braille displays, and can be presented visually in a variety of sizes on computer displays and paper. Coding Practices: • Provide a text equivalent for every non-text element. For example, use alt text for the <img> tag. For complex content where alt text does not provide a complete text equivalent, provide a link to a text description. For image maps use the alt attribute withtags. [Priority 1] • Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. [Priority 1] • For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. [Priority 1] • Until user agents render text equivalents for image map links, provide redundant text links for each active region of a client-side image map. [Priority 3] Guideline 2. Don't rely on color alone. Ensure that text and graphics are understandable when viewed without color. If color alone is used to convey information, people who cannot differentiate between certain colors and users with devices that have non-color or non-visual displays will not receive the information. When foreground and background colors are too close to the same hue, they may not provide sufficient contrast when viewed using monochrome displays or by people with different types of color deficits. Coding Practices: • Ensure that all information conveyed with color is also available without color, for example from text context or markup. [Priority 1] • Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2]. Guideline 3. Use markup and style sheets properly. Mark up documents with the proper and intended use of XHTML elements, that is, as information structuring devices rather than styling techniques. Control presentation with style sheets rather than with attributes. Using markup improperly hinders accessibility. Coding Practices: • When an appropriate markup language exists, use markup rather than images to convey information. Avoid using images to represent text -- use text and style sheets instead. [Priority 2] • Create documents that validate to published XHTML standards. [Priority 2] • Use style sheets rather than deprecated attributes to control layout and presentation. [Priority 2] • Use relative measurement units (percentages) rather than absolute units (pixels) in markup attribute values and style sheet property values. [Priority 2] • Use header elements to convey document structure, not for style effects. For example, use H2 to indicate a subsection of H1, not because of size differences in the fonts. [Priority 2] • Nest OL, UL, and DL list items properly. [Priority 2] Guideline 4. Clarify natural language usage Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text. When content developers code natural language in a document, speech synthesizers and braille devices can automatically switch to the new language, making the document more accessible to multilingual users. Also, natural language markup allows search engines to find key words and identify documents in a desired language. Coding Practices: • Clearly identify changes in the natural language of a document's text and captions. For example, use "xml:lang" in page prologs. [Priority 1] • Specify the expansion of each abbreviation or acronym in a document where it first occurs. [Priority 3] Guideline 5. Create tables that transform gracefully. Ensure that tables have necessary markup to be transformed by accessible browsers and other user agents. Tables should be used to mark up truly tabular information ("data tables") and should be avoided to lay out pages ("layout tables"). Tables for any use present special problems to users of screen readers. Coding Practices: • For data tables, identify row and column headers. Use <td> to identify data cells and <th> to identify headers. [Priority 1] • For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. Use <thead>, <tbody>, and <tfoot> to group rows and use <col/> and <colgroup> to group columns. [Priority 1] • Do not use tables for layout unless the table makes sense when presented in a linear (across rows and down columns) fashion. Otherwise, provide an alternative presentation. [Priority 2] • If a table is used for layout, do not use any structural markup for the purpose of visual formatting -- do not use the <th> element to cause the content of a (non-table header) cell to be displayed centered and in bold. [Priority 2] • Provide text summaries for tables where practical. [Priority 3] Guideline 6. Ensure that pages featuring new technologies transform gracefully. Ensure that pages are accessible even when newer technologies are not supported or are turned off. Although content developers are encouraged to use new technologies, they should know how to make their pages still work with older browsers and people who choose to turn off features. Coding Practices: • Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. [Priority 1] • Ensure that equivalents for dynamic content are updated when the dynamic content changes. [Priority 1] • Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1] • Ensure that dynamic content is accessible or provide an alternative presentation or page. [Priority 2] Guideline 7. Ensure user control of time-sensitive content changes. Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped. Some people with cognitive or visual disabilities are unable to read moving text quickly enough or at all. Movement can also cause such a distraction that the rest of the page becomes unreadable for people with cognitive disabilities. Screen readers are unable to read moving text. People with physical disabilities might not be able to move quickly or accurately enough to interact with moving objects. Coding Practices: • Until user agents allow users to control flickering, avoid causing the screen to flicker. [Priority 1] • Until user agents allow users to control blinking, avoid causing content to blink [Priority 2] • Until user agents allow users to freeze moving content, avoid movement in pages. [Priority 2] • Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages. [Priority 2] • Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. [Priority 2] Guideline 8. Ensure direct accessibility of embedded user interfaces. Ensure that the user interface follows principles of accessible design: device-independent access to functionality, keyboard operability, self-voicing, etc. When an embedded object has its "own interface", the interface -- like the interface to the browser itself -- must be accessible. If the interface of the embedded object cannot be made accessible, an alternative accessible solution must be provided. Coding Practices: • Make programmatic elements such as scripts directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.] Guideline 9. Design for device-independence. Use features that enable activation of page elements via a variety of input devices. Device-independent access means that the user may interact with the user agent or document with a preferred input (or output) device -- mouse, keyboard, voice, head wand, or other. Coding Practices: • Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape. [Priority 1] • Ensure that any element that has its own interface can be operated in a device-independent manner. [Priority 1] • For scripts, specify logical event handlers rather than device-dependent event handlers. [Priority 2] • Create a logical tab order through links, form controls, and objects. [Priority 3] • Provide keyboard shortcuts to important links, form controls, and groups of form controls. [Priority 3] Guideline 10. Use interim solutions. Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly. For example, changing the current window or popping up new windows can be very disorienting to users who cannot see that this has happened. Note. The following checkpoints apply until user agents (including assistive technologies) address these issues. These checkpoints are classified as "interim", meaning that the Web Content Guidelines Working Group considers them to be valid and necessary to Web accessibility as of the publication of this document. However, the Working Group does not expect these checkpoints to be necessary in the future, once Web technologies have incorporated anticipated features or capabilities. Coding Practices: • Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2] • Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned immediately precedits its control on the same line. [Priority 2] • Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns. [Priority 3] • Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3] • Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. [Priority 3] Guideline 11. Use W3C technologies and guidelines. Use W3C technologies and follow accessibility guidelines. Where it is not possible to use a W3C technology, or doing so results in material that does not transform gracefully, provide an alternative version of the content that is accessible. Coding Practices: • Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported. [Priority 2] • Avoid deprecated features of W3C technologies. [Priority 2] • Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.) [Priority 3] • If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. [Priority 1] Guideline 12. Provide context and orientation information. Provide context and orientation information to help users understand complex pages or elements. Grouping elements and providing contextual information about the relationships between elements can be useful for all users. Complex relationships between parts of a page may be difficult for people with cognitive disabilities and people with visual disabilities to interpret. Coding Practices: • Title each frame to facilitate frame identification and navigation. [Priority 1] • Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone. [Priority 2] • Divide large blocks of information into more manageable groups where natural and appropriate. [Priority 2] • Associate labels explicitly with their controls. [Priority 2] Guideline 13. Provide clear navigation mechanisms. Provide clear and consistent navigation mechanisms -- orientation information, navigation bars, a site map, etc. -- to increase the likelihood that a person will find what they are looking for at a site. Clear and consistent navigation mechanisms are important to people with cognitive disabilities or blindness, and benefit all users. Coding Practices: • Clearly identify the target of each link. Link text should be meaningful enough to make sense when read out of context -- either on its own or as part of a sequence of links. Link text should also be terse.[Priority 2] • Provide metadata to add semantic information to pages and sites. For example, indicate the document's author, the type of content, etc.[Priority 2] • Provide information about the general layout of a site (e.g., a site map or table of contents). [Priority 2] • Use navigation mechanisms in a consistent manner. [Priority 2] • Provide navigation bars to highlight and give access to the navigation mechanism. [Priority 3] • Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. [Priority 3] • If search functions are provided, enable different types of searches for different skill levels and preferences. [Priority 3] • Place distinguishing information at the beginning of headings, paragraphs, lists, etc. [Priority 3] • Provide information about document collections (i.e., documents comprising multiple pages.). Another way to create a collection is by building a zipped archive of the multiple pages. [Priority 3] • Provide a means to skip over multi-line ASCII art. [Priority 3] Guideline 14. Ensure that documents are clear and simple. Ensure that documents are clear and simple so they may be more easily understood. Consistent page layout, recognizable graphics, and easy to understand language benefit all users. They help people with cognitive disabilities or who have difficulty reading. Ensure that images have text equivalents for people who are blind, have low vision, or for any user who cannot or has chosen not to view graphics. Coding Practices: • Use the clearest and simplest language appropriate for a site's content. [Priority 1] Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page. [Priority 3] Create a style of presentation that is consistent across pages. [Priority 3] It is impossible in this tutorial to give examples of all of the above coding techiques to assist in Web page accessability. A comprehensive set of example XHTML code, however, is provided at the W3C Web site: Techniques for Web Content Accessibility Guidelines. There are a number of Web sites that provide software for testing pages against accessibility guidelines. For example, bobby.watchfire.com permits you to enter the URL of your page and receive a report on its compatibility with W3C and other guidelines. Section 508 Requirements(US) Under the US Federal law, U.S. agencies must make their Web sites accessible to people with vision and hearing impairments, with limited dexterity, and with other disabilities. Section 508, an amendment to the Rehabilitation Act of 1973, mandates that people with disabilities be given comparable access to Web-accessible government information as other users; the Act also pertains to organizations which receive funds from the federal government. There are sixteen general rules for accessible Web pages in the Section 508 Standards. In brief, the rules for accessible Web pages are: • Text Tags: A text equivalent for every non-text element shall be provided. • Multimedia Presentations: Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation. • Color: Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup. • Readability: Documents shall be organized so they are readable without requiring an associated style sheet. • Server-Side Image Maps: Redundant text links shall be provided for each active region of a server-side image map. • Client-Side Image Maps: Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape. • Data Tables 1: Row and column headers shall be identified for data tables. • Data Tables 2: Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. • Frames: Frames shall be titled with text that facilitates frame identification and navigation. • Flicker Rate: Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz. • Text-Only Alternatives: A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes. • Scripts: When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology. • Applets and Plug-Ins: When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet. • Forms: When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. • Navigation Links: A method shall be provided that permits users to skip repetitive navigation links. • Time: When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required. There exist no such guidelines from Indian federal government to address accessibility related issues. Events OnBlur Event The OnBlur event is called whenever a user leaves an element and looses the focus. This can be useful if you want to check whether the user has entered any value in the textfield or not. If the user didn’t enter anything, then you can set the focus on the textfield again, so that the user is forced to enter a value. The following example demonstrates the usage. Example <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <script type="text/javascript"> function CheckValue(FieldValue) { if(FieldValue == "") { alert("Please enter your name."); document.myform.firstname.focus(); } } </script> <title>XHTML Events [OnBlur]</title> </head> <body> <form name="myform"><fieldset style="width:270px"> <legend>Personal Information</legend> First Name: <input type="textfield" name="firstname" on Blur="CheckValue(this.value)"/><br/> Last Name: <input type="textfield" name="lastname"/> </fieldset> </form> </body> </html> Output: Click here to view the file. Events Onchange Event The OnChange event can be used if you want to know when a value in a control changes. This can be a textfield, a drop down list, a textarea field or anything else. The following example demonstrates this event with a drop down list. Whenever the user selects another value from the list then it will display a message box with the selected value. Example <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <script type="text/javascript"> function GetValueFromDropDown(value) { var Output = document.getElementById("Output") Output.innerHTML = "Your Current Select is <b>" + value + "</b> "; document.frm.val.value=value } </script> </script> <title>XHTML Events[OnChange]</title> </head> <body> <div> <form name="frm"> <select name="setect " onchange="javascript:GetValueFromDropDow n(this.options(this.options.selectedIndex).value);"> <option value="XML">XML</option> <option value="XPath">XPath</option> <option value="XSL">XSL</option> </select> <br /> Your Current selection is: <input type="text" size="25" name="val" /> </form> <span name="span" id="Output" style="color:blue"></span> </div> </body> </html> Click here to view the file. Events OnClick Event The OnClick is called whenever the user presses the button over an element. Usually it is used in a form to send some data from the form to the server; however you can also use it out of a form. The following example demonstrates the usage of a button event. Example <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <script type="text/javascript"> function ChangeButtonName() { if (document.myform.mybtn.value== " You clicked me !!") { document.myform.mybtn.value = " Click me !!" } else document.myform.mybtn.value = " You clicked me !!"; } </script> <title>XHTML Event[OnClick]</title> </head> <body> <form method="post" action="" name="myform"> <input type="button" value="Click Me!" name="mybtn" onclick="javascript:ChangeButtonName();"> </form> </body> </html> Click here to view the file. Events OnFocus Event The OnFocus event is called whenever a control retrieves focus. The following example demonstrates a small example. In that example you will see two textboxes and whenever the focus is in the textfield, you will see the changes . Example: <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <script type="text/javascript"> function CheckFocus(FocusField) { if (FocusField=="FirstName") { if (document.myfrm.fname.va lue=="Type Your First name") { document.myfrm.fname.value=""; } } else { if (document.myfrm.lnam e.value=="Type Your Last name") { document.myfrm.lname.value=""; } } } function lostFocus(FocusField) { if (FocusField=="FirstName") { if (document.myfrm.fname.value=="") document.myfrm.fname .value="Type Your First name"; } else { if (document.myfrm.lname.value=="") document.myfrm.lname .value="Type Your Last name"; } } </script> <title>OnFocus Demonstration</title> </head> <body> <form name="myfrm"> First Name: <input size="25" name="fname " onBlur=" javascript:lostFocus('FirstName');" onFocus=" javascript:CheckFocus('FirstName');" value="Type Your First name"/><br/> Last Name: <input size="25" name="lname" onBlur=" javascript:lostFocus('LastName');" onFocus=" javascript:CheckFocus('LastName');" value="Type Your Last name"/><br/> </form> </body> </html> Click here to view the file. Events OnKeydown Event The onkeydown event is always called whenever the user presses any key down while the element has the focus. The following example will demonstrate these two-textarea fields. The user can enter some value in the first textarea and this text will be shown in the second textarea in uppercase. Example <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <script language="JavaScript"> function ChangeText(strValue) { document.myform.mytextarea.value= strValue.toUpperCase(); } </script> <style type="text/css"> textarea { border:outset 5px #FFCC33; background-color:#F0F0F0; color: #336666; font-family:comic sans ms; font-size:10pt; padding:7px; font-weight:bold } </style> <title>XHTML Event[OnKeyDown ]</title> </head> <body> <form name="myform"> Original Text:<br/><textarea cols="50" rows="5" onKeyDown="javascript:ChangeText(this.value);"></textarea><br/> Modified Text:<br/><textarea name="mytextarea" cols="50" rows="5" readonly="true"></textarea> </body> </html> Output Try it yourself Events OnLoad Event The “OnLoad” event is called whenever the page is loaded. It can be used for example to greet the user. The following example demonstrates the OnLoad event. You can even call multiple functions. Example <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <script type="text/javascript"> function WelcomeMsg() { alert('eBIZ education team welcomes you'); alert('You are currently reading our XHTML tutorial.'); } </script> <title>XHTML Events[OnLoad]</title> </head> <body onload="javascript:WelcomeMsg();"> </body> </html> Output Click here to view the file. Events OnMouseDown Event The OnMouseDown event is called whenever the mouse button is pressed over an element. The following example demonstrates the usage of the event. Example <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <script type="text/javascript"> function MouseDown() { alert('You pressed the mouse down'); } </script> <title>XHTML Event[OnMouseDown]</title> </head> <body> <a href="" onMouseDown="javascript:MouseDown();">Click me</a> </body> </html> Output Try it yourself Events OnMouseMove Event The OnMouseMove event is called whenever the mouse is moved over an element. This can be sometimes useful if you want to get the coordinates of the mouse position on the image. Example <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title> XHTML Event[onMouseMove] </title> <meta name="generator" content="jNote-iT" /> <meta name="author" content="" /> <meta name="keywords" content="" /> <meta name="description" content="" /> <script type="text/javascript"> //var msg=''; function moveMouse() { eX=event.clientX; eY=event.clientY; CC.style.left=eX+8; CC.style.top=eY; di='<span style="background-color:#99CCFF; width:260"> Welcome to <font color=red>eBIZ.com</font> Pvt Ltd.'; eHc='</span></B>'; diC='<br />Current Mouse Postion : '; if (event.srcElement.id=='D') { eH='<B>'; } else { eH=''; eHc=''; } CC.innerHTML=eH+di+''+diC+eX+':'+eY+eHc; var msg=''; msg+=eX+':'+eY; show(msg ); } function show(msg) { document.frm.val.value=msg; } </script> </head> <body onmousemove="javascript:moveMouse();" bgcolor="#0099FF"> <div id="D" style="BACKGROUND-COLOR: #00CCFF; HEIGHT: 200px; LEFT: 100px; POSITION: absolute; TOP: 100px; WIDTH: 300px"> <form name="frm"> Current Mouse Position:<input type="text" name="val" size="30" /> </form> </div> <p id="CC" style="POSITION: absolute"></p> </body> </html> Click here to view the example Events OnMouseOut Event The OnMouseOut event is called whenever the mouse is not over an element. The following example demonstrates a small example. It displays some text and whenever the user moves his mouse over the text it will change to some another text and when the mouse is out the will change again to the original text. Example <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>OnMouseOut Demonstration</title> </head> <body> <p onMouseover="this.innerHTML='I am in :)'" onMouseOut="this.innerHTML='Move the mouse over this text.'"> Move the mouse over this text.</p> </body> </html> Output Click here to view the example Events OnMouseOver Event The OnMouseOver event is called whenever the mouse is over an element. The following example demonstrates a small example. It displays some text and whenever the user moves his mouse over the text it will change to some another text. Example <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>OnMouseOver Demonstration</title> </head> <body> <p onMouseover="this.innerHTML='I am in :)'; javascript:alert('Welcome to eBIZ.com');"> Move the mouse over this text.</p> </body> </html> Output:Try it yourself. Events UnLoad Event The OnUnLoad event is always when the user leaves your website either by closing the browser or by entering another URL in the address bar. This is can be useful if you want to clean up some resources or if you want to say thanks to the visitor. The following example shows demonstrates the usage. Example <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>XHTML Event [OnUnLoad]</title> </head> <body OnUnload="javascript:alert('Thank you for visiting education.ebizelindia.com.\nHave a nice day!');"> </body> </html> Output Click here to view the example XHTML DTD XHTML 1.0 DTD Reference The following is the DTD for the XHTML 1.0 Strict Definition. <!-- Extensible HTML version 1.0 Strict DTD This is the same as HTML 4.0 Strict except for changes due to the differences between XML and SGML. Namespace = http://www.w3.org/1999/xhtml For further information, see: http://www.w3.org/TR/xhtml1 Copyright (c) 1998-2000 W3C (MIT, INRIA, Keio), All Rights Reserved. This DTD module is identified by the PUBLIC and SYSTEM identifiers: PUBLIC "-//W3C//DTD XHTML1.0 Strict//EN" SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" $Revision: 1.1 $ $Date: 2000/01/26 14:08:56 $ --> Character mnemonic entities <!ENTITY % HTMLlat1 PUBLIC "-//W3C//ENTITIES Latin 1 for XHTML//EN" "xhtml-lat1.ent"> %HTMLlat1; <!ENTITY % HTMLsymbol PUBLIC "-//W3C//ENTITIES Symbols for XHTML//EN" "xhtml-symbol.ent"> %HTMLsymbol; <!ENTITY % HTMLspecial PUBLIC "-//W3C//ENTITIES Special for XHTML//EN" "xhtml-special.ent"> %HTMLspecial; Imported Names <!ENTITY % ContentType "CDATA"> <!-- media type, as per [RFC2045] --> <!ENTITY % ContentTypes "CDATA"> <!-- comma-separated list of media types, as per [RFC2045] --> <!ENTITY % Charset "CDATA"> <!-- a character encoding, as per [RFC2045] --> <!ENTITY % Charsets "CDATA"> <!-- a space separated list of character encodings, as per [RFC2045] --> <!ENTITY % LanguageCode "NMTOKEN"> <!-- a language code, as per [RFC1766] --> <!ENTITY % Character "CDATA"> <!-- a single character from [ISO10646] --> <!ENTITY % Number "CDATA"> <!-- one or more digits --> <!ENTITY % LinkTypes "CDATA"> <!-- space-separated list of link types --> <!ENTITY % MediaDesc "CDATA"> <!-- single or comma-separated list of media descriptors --> <!ENTITY % URI "CDATA"> <!-- a Uniform Resource Identifier, see [RFC2396] --> <!ENTITY % UriList "CDATA"> <!-- a space separated list of Uniform Resource Identifiers --> <!ENTITY % Datetime "CDATA"> <!-- date and time information. ISO date format --> <!ENTITY % Script "CDATA"> <!-- script expression --> ; <!ENTITY % StyleSheet "CDATA"> <!-- style sheet data --> <!ENTITY % Text "CDATA"> <!-- used for titles etc. --> <!ENTITY % FrameTarget "NMTOKEN"> <!-- render in this frame --> <!ENTITY % Length "CDATA"> <!-- nn for pixels or nn% for percentage length --> <!ENTITY % MultiLength "CDATA"> <!-- pixel, percentage, or relative --> <!ENTITY % MultiLengths "CDATA"> <!-- comma-separated list of MultiLength --> <!ENTITY % Pixels "CDATA"> <!-- integer representing length in pixels --> <!-- these are used for image maps --> <!ENTITY % Shape "(rect|circle|poly|default)"> <!ENTITY % Coords "CDATA"> <!-- comma separated list of lengths --> Generic Attributes <!-- core attributes common to most elements id document-wide unique id class space separated list of classes style associated style info title advisory title/amplification --> <!ENTITY % coreattrs "id ID #IMPLIED class CDATA #IMPLIED style %StyleSheet; #IMPLIED title %Text; #IMPLIED" > <!-- internationalization attributes lang language code (backwards compatible) xml:lang language code (as per XML 1.0 spec) dir direction for weak/neutral text --> <!ENTITY % i18n "lang %LanguageCode; #IMPLIED xml:lang %LanguageCode; #IMPLIED dir (ltr|rtl) #IMPLIED" > <!-- attributes for common UI events onclick a pointer button was clicked ondblclick a pointer button was double clicked onmousedown a pointer button was pressed down onmouseup a pointer button was released onmousemove a pointer was moved onto the element onmouseout a pointer was moved away from the element onkeypress a key was pressed and released onkeydown a key was pressed down onkeyup a key was released --> <!ENTITY % events "onclick %Script; #IMPLIED ondblclick %Script; #IMPLIED onmousedown %Script; #IMPLIED onmouseup %Script; #IMPLIED onmouseover %Script; #IMPLIED onmousemove %Script; #IMPLIED onmouseout %Script; #IMPLIED onkeypress %Script; #IMPLIED onkeydown %Script; #IMPLIED onkeyup %Script; #IMPLIED" > <!-- attributes for elements that can get the focus accesskey accessibility key character tabindex position in tabbing order onfocus the element got the focus onblur the element lost the focus --> <!ENTITY % focus "accesskey %Character; #IMPLIED tabindex %Number; #IMPLIED onfocus %Script; #IMPLIED onblur %Script; #IMPLIED" > <!ENTITY % attrs "%coreattrs; %i18n; %events;"> Text Elements <!ENTITY % special "br | span | bdo | object | img | map"> <!ENTITY % fontstyle "tt | i | b | big | small"> <!ENTITY % phrase "em | strong | dfn | code | q | sub | sup | samp | kbd | var | cite | abbr | acronym"> <!ENTITY % inline.forms "input | select | textarea | label | button"> <!-- these can occur at block or inline level --> <!ENTITY % misc "ins | del | script | noscript"> <!ENTITY % inline "a | %special; | %fontstyle; | %phrase; | %inline.forms;"> <!-- %Inline; covers inline or "text-level" elements --> <!ENTITY % Inline "(#PCDATA | %inline; | %misc;)*"> Block level elements <!ENTITY % heading "h1|h2|h3|h4|h5|h6"> <!ENTITY % lists "ul | ol | dl"> <!ENTITY % blocktext "pre | hr | blockquote | address"> <!ENTITY % block "p | %heading; | div | %lists; | %blocktext; | fieldset | table"> <!ENTITY % Block "(%block; | form | %misc;)*"> <!-- %Flow; mixes Block and Inline and is used for list items etc. --> <!ENTITY % Flow "(#PCDATA | %block; | form | %inline; | %misc;)*"> Content models for exclusions <!-- a elements use %Inline; excluding a --> <!ENTITY % a.content "(#PCDATA | %special; | %fontstyle; | %phrase; | %inline.forms; | %misc;)*"> <!-- pre uses %Inline excluding img, object, big, small, sup or sup --> <!ENTITY % pre.content "(#PCDATA | a | br | span | bdo | map | tt | i | b | %phrase; | %inline.forms;)*"> <!-- form uses %Block; excluding form --> <!ENTITY % form.content "(%block; | %misc;)*"> <!-- button uses %Flow; but excludes a, form and form controls --> <!ENTITY % button.content "(#PCDATA | p | %heading; | div | %lists; | %blocktext; | table | %special; | %fontstyle; | %phrase; | %misc;)*"> Document Structure <!-- the namespace URI designates the document profile --> <!ELEMENT html (head, body)> <!ATTLIST h6 %attrs; > Document Head <!ENTITY % head.misc "(script|style|meta|link|object)*"> <!-- content model is %head.misc; combined with a single title and an optional base element in any order --> <!ELEMENT head (%head.misc;, ((title, %head.misc;, (base, %head.misc;)?) | (base, %head.misc;, (title, %head.misc;))))> <!ATTLIST head %i18n; profile %URI; #IMPLIED > <!-- The title element is not considered part of the flow of text. It should be displayed, for example as the page header or window title. Exactly one title is required per document. --> <!ELEMENT title (#PCDATA)> <!ATTLIST title %i18n;> <!-- document base URI --> <!ELEMENT base EMPTY> <!ATTLIST base href %URI; #IMPLIED > <!-- generic metainformation --> <!ELEMENT meta EMPTY> <!ATTLIST meta %i18n; http-equiv CDATA #IMPLIED name CDATA #IMPLIED content CDATA #REQUIRED scheme CDATA #IMPLIED > <!-- Relationship values can be used in principle: a) for document specific toolbars/menus when used with the link element in document head e.g. start, contents, previous, next, index, end, help b) to link to a separate style sheet (rel="stylesheet") c) to make a link to a script (rel="script") d) by stylesheets to control how collections of html nodes are rendered into printed documents e) to make a link to a printable version of this document e.g. a PostScript or PDF version (rel="alternate" media="print") --> <!ELEMENT link EMPTY> <!ATTLIST link %attrs; charset %Charset; #IMPLIED href %URI; #IMPLIED hreflang %LanguageCode; #IMPLIED type %ContentType; #IMPLIED rel %LinkTypes; #IMPLIED rev %LinkTypes; #IMPLIED media %MediaDesc; #IMPLIED > <!-- style info, which may include CDATA sections --> <!ELEMENT style (#PCDATA)> <!ATTLIST style %i18n; type %ContentType; #REQUIRED media %MediaDesc; #IMPLIED title %Text; #IMPLIED xml:space (preserve) #FIXED 'preserve' > <!-- script statements, which may include CDATA sections --> <!ELEMENT script (#PCDATA)> <!ATTLIST script charset %Charset; #IMPLIED type %ContentType; #REQUIRED src %URI; #IMPLIED defer (defer) #IMPLIED xml:space (preserve) #FIXED 'preserve' > <!-- alternate content container for non script-based rendering --> <!ELEMENT noscript %Block;> <!ATTLIST noscript %attrs; > Document Body <!ELEMENT body %Block;> <!ATTLIST body %attrs; onload %Script; #IMPLIED onunload %Script; #IMPLIED > <!ELEMENT div %Flow;> <!-- generic language/style container --> <!ATTLIST div %attrs; > Paragraphs <!ELEMENT p %Inline;> <!ATTLIST p %attrs; > Headings <!-- There are six levels of headings from h1 (the most important) to h6 (the least important). --> <!ELEMENT h1 %Inline;> <!ATTLIST h1 %attrs; > <!ELEMENT h2 %Inline;> <!ATTLIST h2 %attrs; > <!ELEMENT h3 %Inline;> <!ATTLIST h3 %attrs; > <!ELEMENT h4 %Inline;> <!ATTLIST h4 %attrs; > <!ELEMENT h5 %Inline;> <!ATTLIST h5 %attrs; > <!ELEMENT h6 %Inline;> <!ATTLIST h6 %attrs; > Lists <!-- Unordered list --> <!ELEMENT ul (li)+> <!ATTLIST ul %attrs; > <!-- Ordered (numbered) list --> <!ELEMENT ol (li)+> <!ATTLIST ol %attrs; > <!-- list item --> <!ELEMENT li %Flow;> <!ATTLIST li %attrs; > <!-- definition lists - dt for term, dd for its definition --> <!ELEMENT dl (dt|dd)+> <!ATTLIST dl %attrs; > <!ELEMENT dt %Inline;> <!ATTLIST dt %attrs; > <!ELEMENT dd %Flow;> <!ATTLIST dd %attrs; > Address <!-- information on author --> <!ELEMENT address %Inline;> <!ATTLIST address %attrs; > Horizontal Rule <!ELEMENT hr EMPTY> <!ATTLIST hr %attrs; > Preformatted Text <!-- content is %Inline; excluding "img|object|big|small|sub|sup" --> <!ELEMENT pre %pre.content;> <!ATTLIST pre %attrs; xml:space (preserve) #FIXED 'preserve' > Block-like Quotes <!ELEMENT blockquote %Block;> <!ATTLIST blockquote %attrs; cite %URI; #IMPLIED > Inserted/Deleted Text <!-- ins/del are allowed in block and inline content, but its inappropriate to include block content within an ins element occurring in inline content. --> <!ELEMENT ins %Flow;> <!ATTLIST ins %attrs; cite %URI; #IMPLIED datetime %Datetime; #IMPLIED > <!ELEMENT del %Flow;> <!ATTLIST del %attrs; cite %URI; #IMPLIED datetime %Datetime; #IMPLIED > The Anchor Element <!-- content is %Inline; except that anchors shouldn't be nested --> <!ELEMENT a %a.content;> <!ATTLIST a %attrs; charset %Charset; #IMPLIED type %ContentType; #IMPLIED name NMTOKEN #IMPLIED href %URI; #IMPLIED hreflang %LanguageCode; #IMPLIED rel %LinkTypes; #IMPLIED rev %LinkTypes; #IMPLIED accesskey %Character; #IMPLIED shape %Shape; "rect" coords %Coords; #IMPLIED tabindex %Number; #IMPLIED onfocus %Script; #IMPLIED onblur %Script; #IMPLIED > Inline Elements <!ELEMENT span %Inline;> <!-- generic language/style container --> <!ATTLIST span %attrs; > <!ELEMENT bdo %Inline;> <!-- I18N BiDi over-ride --> <!ATTLIST bdo %coreattrs; %events; lang %LanguageCode; #IMPLIED xml:lang %LanguageCode; #IMPLIED dir (ltr|rtl) #REQUIRED > <!ELEMENT br EMPTY> <!-- forced line break --> <!ATTLIST br %coreattrs; > <!ELEMENT em %Inline;> <!-- emphasis --> <!ATTLIST em %attrs;> <!ELEMENT strong %Inline;> <!-- strong emphasis --> <!ATTLIST strong %attrs;> <!ELEMENT dfn %Inline;> <!-- definitional --> <!ATTLIST dfn %attrs;> <!ELEMENT code %Inline;> <!-- program code --> <!ATTLIST code %attrs;> <!ELEMENT samp %Inline;> <!-- sample --> <!ATTLIST samp %attrs;> <!ELEMENT kbd %Inline;> <!-- something user would type --> <!ATTLIST kbd %attrs;> <!ELEMENT var %Inline;> <!-- variable --> <!ATTLIST var %attrs;> <!ELEMENT cite %Inline;> <!-- citation --> <!ATTLIST cite %attrs;> <!ELEMENT abbr %Inline;> <!-- abbreviation --> <!ATTLIST abbr %attrs;> <!ELEMENT acronym %Inline;> <!-- acronym --> <!ATTLIST acronym %attrs;> <!ELEMENT q %Inline;> <!-- inlined quote --> <!ATTLIST q %attrs; cite %URI; #IMPLIED > <!ELEMENT sub %Inline;> <!-- subscript --> <!ATTLIST sub %attrs;> <!ELEMENT sup %Inline;> <!-- superscript --> <!ATTLIST sup %attrs;> <!ELEMENT tt %Inline;> <!-- fixed pitch font --> <!ATTLIST tt %attrs;> <!ELEMENT i %Inline;> <!-- italic font --> <!ATTLIST i %attrs;> Object <!-- object is used to embed objects as part of HTML pages. param elements should precede other content. Parameters can also be expressed as attribute/value pairs on the object element itself when brevity is desired. --> <!ELEMENT object (#PCDATA | param | %block; | form | %inline; | %misc;)*> <!ATTLIST object %attrs; declare (declare) #IMPLIED classid %URI; #IMPLIED codebase %URI; #IMPLIED data %URI; #IMPLIED type %ContentType; #IMPLIED codetype %ContentType; #IMPLIED archive %UriList; #IMPLIED standby %Text; #IMPLIED height %Length; #IMPLIED width %Length; #IMPLIED usemap %URI; #IMPLIED name NMTOKEN #IMPLIED tabindex %Number; #IMPLIED > <!-- param is used to supply a named property value. In XML it would seem natural to follow RDF and support an abbreviated syntax where the param elements are replaced by attribute value pairs on the object start tag. --> <!ELEMENT param EMPTY> <!ATTLIST param id ID #IMPLIED name CDATA #IMPLIED value CDATA #IMPLIED valuetype (data|ref|object) "data" type %ContentType; #IMPLIED > Images <!-- To avoid accessibility problems for people who aren't able to see the image, you should provide a text description using the alt and longdesc attributes. In addition, avoid the use of server-side image maps. Note that in this DTD there is no name attribute. That is only available in the transitional and frameset DTD. --> <!ELEMENT img EMPTY> <!ATTLIST img %attrs; src %URI; #REQUIRED alt %Text; #REQUIRED longdesc %URI; #IMPLIED height %Length; #IMPLIED width %Length; #IMPLIED usemap %URI; #IMPLIED ismap (ismap) #IMPLIED > <!-- usemap points to a map element which may be in this document or an external document, although the latter is not widely supported --> Client-side image maps <!-- These can be placed in the same document or grouped in a separate document although this isn't yet widely supported --> <!ELEMENT map ((%block; | form | %misc;)+ | area+)> <!ATTLIST map %i18n; %events; id ID #REQUIRED class CDATA #IMPLIED style %StyleSheet; #IMPLIED title %Text; #IMPLIED name NMTOKEN #IMPLIED > <!ELEMENT area EMPTY> <!ATTLIST area %attrs; shape %Shape; "rect" coords %Coords; #IMPLIED href %URI; #IMPLIED nohref (nohref) #IMPLIED alt %Text; #REQUIRED tabindex %Number; #IMPLIED accesskey %Character; #IMPLIED onfocus %Script; #IMPLIED onblur %Script; #IMPLIED > Forms <!ELEMENT form %form.content;> <!-- forms shouldn't be nested --> <!ATTLIST form %attrs; action %URI; #REQUIRED method (get|post) "get" enctype %ContentType; "application/x-www-form-urlencoded" onsubmit %Script; #IMPLIED onreset %Script; #IMPLIED accept %ContentTypes; #IMPLIED accept-charset %Charsets; #IMPLIED > <!-- Each label must not contain more than ONE field Label elements shouldn't be nested. --> <!ELEMENT label %Inline;> <!ATTLIST label %attrs; for IDREF #IMPLIED accesskey %Character; #IMPLIED onfocus %Script; #IMPLIED onblur %Script; #IMPLIED > <!ENTITY % InputType "(text | password | checkbox | radio | submit | reset | file | hidden | image | button)" > <!-- the name attribute is required for all but submit & reset --> <!ELEMENT input EMPTY> <!-- form control --> <!ATTLIST input %attrs; type %InputType; "text" name CDATA #IMPLIED value CDATA #IMPLIED checked (checked) #IMPLIED disabled (disabled) #IMPLIED readonly (readonly) #IMPLIED size CDATA #IMPLIED maxlength %Number; #IMPLIED src %URI; #IMPLIED alt CDATA #IMPLIED usemap %URI; #IMPLIED tabindex %Number; #IMPLIED accesskey %Character; #IMPLIED onfocus %Script; #IMPLIED onblur %Script; #IMPLIED onselect %Script; #IMPLIED onchange %Script; #IMPLIED accept %ContentTypes; #IMPLIED > <!ELEMENT select (optgroup|option)+> <!-- option selector --> <!ATTLIST select %attrs; name CDATA #IMPLIED size %Number; #IMPLIED multiple (multiple) #IMPLIED disabled (disabled) #IMPLIED tabindex %Number; #IMPLIED onfocus %Script; #IMPLIED onblur %Script; #IMPLIED onchange %Script; #IMPLIED > <!ELEMENT optgroup (option)+> <!-- option group --> <!ATTLIST optgroup %attrs; disabled (disabled) #IMPLIED label %Text; #REQUIRED > <!ELEMENT option (#PCDATA)> <!-- selectable choice --> <!ATTLIST option %attrs; selected (selected) #IMPLIED disabled (disabled) #IMPLIED label %Text; #IMPLIED value CDATA #IMPLIED > <!ELEMENT textarea (#PCDATA)> <!-- multi-line text field --> <!ATTLIST textarea %attrs; name CDATA #IMPLIED rows %Number; #REQUIRED cols %Number; #REQUIRED disabled (disabled) #IMPLIED readonly (readonly) #IMPLIED tabindex %Number; #IMPLIED accesskey %Character; #IMPLIED onfocus %Script; #IMPLIED onblur %Script; #IMPLIED onselect %Script; #IMPLIED onchange %Script; #IMPLIED > <!-- The fieldset element is used to group form fields. Only one legend element should occur in the content and if present should only be preceded by whitespace. --> <!ELEMENT fieldset (#PCDATA | legend | %block; | form | %inline; | %misc;)*> <!ATTLIST fieldset %attrs; > <!ELEMENT legend %Inline;> <!-- fieldset label --> <!ATTLIST legend %attrs; accesskey %Character; #IMPLIED > <!-- Content is %Flow; excluding a, form and form controls --> <!ELEMENT button %button.content;> <!-- push button --> <!ATTLIST button %attrs; name CDATA #IMPLIED value CDATA #IMPLIED type (button|submit|reset) "submit" disabled (disabled) #IMPLIED tabindex %Number; #IMPLIED accesskey %Character; #IMPLIED onfocus %Script; #IMPLIED onblur %Script; #IMPLIED > Tables <!-- Derived from IETF HTML table standard, see [RFC1942] --> <!-- The border attribute sets the thickness of the frame around the table. The default units are screen pixels. The frame attribute specifies which parts of the frame around the table should be rendered. The values are not the same as CALS to avoid a name clash with the valign attribute. --> <!ENTITY % TFrame "(void|above|below|hsides|lhs|rhs|vsides|box|border)"> <!-- The rules attribute defines which rules to draw between cells: If rules is absent then assume: "none" if border is absent or border="0" otherwise "all" --> <!ENTITY % TRules "(none | groups | rows | cols | all)"> <!-- horizontal placement of table relative to document --> <!ENTITY % TAlign "(left|center|right)"> <!-- horizontal alignment attributes for cell contents char alignment char, e.g. char=':' charoff offset for alignment char --> <!ENTITY % cellhalign "align (left|center|right|justify|char) #IMPLIED char %Character; #IMPLIED charoff %Length; #IMPLIED" > <!-- vertical alignment attributes for cell contents --> <!ENTITY % cellvalign "valign (top|middle|bottom|baseline) #IMPLIED" > <!ELEMENT table (caption?, (col*|colgroup*), thead?, tfoot?, (tbody+|tr+))> <!ELEMENT caption %Inline;> <!ELEMENT thead (tr)+> <!ELEMENT tfoot (tr)+> <!ELEMENT tbody (tr)+> <!ELEMENT colgroup (col)*> <!ELEMENT col EMPTY> <!ELEMENT tr (th|td)+> <!ELEMENT th %Flow;> <!ELEMENT td %Flow;> <!ATTLIST table %attrs; summary %Text; #IMPLIED width %Length; #IMPLIED border %Pixels; #IMPLIED frame %TFrame; #IMPLIED rules %TRules; #IMPLIED cellspacing %Length; #IMPLIED cellpadding %Length; #IMPLIED > <!ENTITY % CAlign "(top|bottom|left|right)"> <!ATTLIST caption %attrs; > <!-- colgroup groups a set of col elements. It allows you to group several semantically related columns together. --> <!ATTLIST colgroup %attrs; span %Number; "1" width %MultiLength; #IMPLIED %cellhalign; %cellvalign; > <!-- col elements define the alignment properties for cells in one or more columns. The width attribute specifies the width of the columns, e.g. width=64 width in screen pixels width=0.5* relative width of 0.5 The span attribute causes the attributes of one col element to apply to more than one column. --> <!ATTLIST col %attrs; span %Number; "1" width %MultiLength; #IMPLIED %cellhalign; %cellvalign; > <!-- Use thead to duplicate headers when breaking table across page boundaries, or for static headers when tbody sections are rendered in scrolling panel. Use tfoot to duplicate footers when breaking table across page boundaries, or for static footers when tbody sections are rendered in scrolling panel. Use multiple tbody sections when rules are needed between groups of table rows. --> <!ATTLIST thead %attrs; %cellhalign; %cellvalign; > <!ATTLIST tfoot %attrs; %cellhalign; %cellvalign; > <!ATTLIST tbody %attrs; %cellhalign; %cellvalign; > <!ATTLIST tr %attrs; %cellhalign; %cellvalign; > <!-- Scope is simpler than headers attribute for common tables --> <!ENTITY % Scope "(row|col|rowgroup|colgroup)"> <!-- th is for headers, td for data and for cells acting as both --> <!ATTLIST th %attrs; abbr %Text; #IMPLIED axis CDATA #IMPLIED headers IDREFS #IMPLIED scope %Scope; #IMPLIED rowspan %Number; "1" colspan %Number; "1" %cellhalign; %cellvalign; > <!ATTLIST td %attrs; abbr %Text; #IMPLIED axis CDATA #IMPLIED headers IDREFS #IMPLIED scope %Scope; #IMPLIED rowspan %Number; "1" colspan %Number; "1" %cellhalign; %cellvalign; >