HTML & CSS The Complete Reference Fifth Edition, Slides of Computer Science

Download HTML & CSS The Complete Reference Fifth Edition and more Slides Computer Science in PDF only on Docsity! The Complete Reference Fifth Edition HTML & CSS: The Complete Reference, Fifth Edition Thomas A. Powell New York Chicago San Francisco Lisbon London Madrid Mexico City Milan New Delhi San Juan Seoul Singapore Sydney Toronto viii HTML & CSS: The Complete Reference HTML5: Embracing the Reality of Web Markup . . . . . . . . . . . . . . . . . . . . . . . 62 Presentational Markup Removed and Redefined . . . . . . . . . . . . . . . . . . . . . . 63 Out with the Old Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 In with the New Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Sample of New Attributes for HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . 66 HTML5 Document Structure Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Adding Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Marking Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Indicating Dates and Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Inserting Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Specifying Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 HTML5’s Open Media Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 <video> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 <audio> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Media Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Client-Side Graphics with <canvas> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Drawing and Styling Lines and Shapes . . . . . . . . . . . . . . . . . . . . . . . . 85 Drawing Arcs and Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Scaling, Rotating, and Translating Drawings . . . . . . . . . . . . . . . . . . . . 93 Using Bitmaps in Drawings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Text Support for canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 <canvas> Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 HTML5 Form Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 New Form Field Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Validating Data Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Autocomplete Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Miscellaneous Usability Improvements . . . . . . . . . . . . . . . . . . . . . . . . 105 Emerging Elements and Attributes to Support Web Applications . . . . . . . . 106 menu Element Repurposed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 command Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 meter and progress Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 details Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 output Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 The Uncertain Future of Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 The draggable Attribute and the Drag and Drop API . . . . . . . . . . . . 112 contenteditable Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 spellcheck Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Internationalization Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 HTML5 Metadata Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 data-X Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Microdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 HTML5: Beyond Markup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 defer Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 HTML, JavaScript, and the DOM Renewed . . . . . . . . . . . . . . . . . . . . . 121 Standardizing and Extending Ad Hoc JavaScript Conventions . . . . 125 Major HTML5 Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 HTML5 Today or Tomorrow? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 HTML5 as a Catch-All . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 HTML5: Web Politics as Usual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 HTML5: Imperfect Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 3 HTML and XHTML Element Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Flavors of HTML and XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Core Attributes Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Language Attributes Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 dir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 lang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Other Common Attributes Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 accesskey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 contenteditable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 datafld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 dataformatas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 datasrc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 height . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 hidefocus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 hspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 tabindex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 unselectable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 vspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Common HTML5 Attributes Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 accesskey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 contenteditable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 contextmenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 data-X (Custom Data Attributes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 draggable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 itemid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 itemprop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 itemref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 itemscope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 itemtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 spellcheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 tabindex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Event Attributes Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 HTML5 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Internet Explorer’s Extended Event Attributes . . . . . . . . . . . . . . . . . . 147 HTML Element Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 <!-- ... --> (Comment) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 <!-- .[ ].. --> (Conditional Comment) . . . . . . . . . . . . . . . . . . . . . . . . . . 155 <!DOCTYPE> (Document Type Definition) . . . . . . . . . . . . . . . . . . . 157 <a> (Anchor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 <abbr> (Abbreviation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 <acronym> (Acronym) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 C o n t e n t s ix x HTML & CSS: The Complete Reference <address> (Address) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 <applet> (Java Applet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 <area> (Image Map Area) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 <article> (Article) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 <aside> (Aside) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 <audio> (Audio) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 <b> (Bold) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 <base> (Base URL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 <basefont> (Base Font) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 <bdo> (Bidirectional Override) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 <bgsound> (Background Sound) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 <big> (Big Font) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 <blink> (Blinking Text) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 <blockquote> (Block Quote) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 <body> (Document Body) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 <br> (Line Break) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 <button> (Form Button) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 <canvas> (Canvas for Drawing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 <caption> (Table Caption) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 <center> (Center Alignment) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 <cite> (Citation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 <code> (Code Listing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 <col> (Table Column) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 <colgroup> (Table Column Group) . . . . . . . . . . . . . . . . . . . . . . . . . . 216 <command> (Command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 <comment> (Comment Information) . . . . . . . . . . . . . . . . . . . . . . . . . 220 <datalist> (List of Prefill Data) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 <dd> (Definition Description in a Definition List or Content in Details or Figure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 <del> (Deleted Text) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 <details> (Additional Details) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 <dfn> (Definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 <dir> (Directory List) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 <div> (Division) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 <dl> (Definition List) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 <dt> (Term in a Definition List or Caption in Figure or Details) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 <em> (Emphasis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 <embed> (Embedded Object) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 <fieldset> (Form Field Grouping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 <figure> (Figure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 <font> (Font Definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 <footer> (Footer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 <form> (Form for User Input) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 <frame> (Window Region) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 <frameset> (Frameset Definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 <h1> through <h6> (Headings) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 <head> (Document Head) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 <header> (Header) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 <hgroup> (Header Group) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Document Structure and CSS Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 !important Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470 Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470 Element Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 id Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 class Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 Contextual Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 Attribute Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 Pseudo-Element Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 Pseudo-Class Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 CSS Properties Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 Measurements and Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 CSS and (X)HTML Elements Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . 506 Physical Markup and Overriding Expected Results . . . . . . . . . . . . . . 506 Are <div> and <span> the Most Popular Tags? . . . . . . . . . . . . . . . . . 507 Changing Element Types with display . . . . . . . . . . . . . . . . . . . . . . . . . 508 Controlling White Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512 Major Themes of CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 Separation of Structure and Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514 CSS: More Appropriate and Powerful for Presentation . . . . . . . . . . . 516 Cross-Browser CSS Madness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 Myths and Misconceptions Related to CSS . . . . . . . . . . . . . . . . . . . . . 517 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 5 CSS Syntax and Property Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 CSS Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 CSS Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 Style Inclusion Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 Linked Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 Embedded Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 Imported Styles—@import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 Inline Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527 CSS Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527 CSS Strings and Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529 Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530 CSS Color Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530 CSS Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533 Miscellaneous CSS Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539 /* comments */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539 @charset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 @font-face . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 @media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 @page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 !important . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 CSS1 and CSS 2.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 background-attachment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 background-color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544 background-image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544 background-position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545 C o n t e n t s xiii xiv HTML & CSS: The Complete Reference background-repeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 border . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547 border-bottom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547 border-bottom-color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 border-bottom-style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 border-bottom-width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 border-collapse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549 border-color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549 border-left . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550 border-left-color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551 border-left-style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551 border-left-width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 border-right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 border-right-color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 border-right-style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 border-right-width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 border-spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 border-style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 border-top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 border-top-color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 border-top-style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557 border-top-width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557 border-width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557 bottom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559 caption-side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559 clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560 clip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560 color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561 content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562 counter-increment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 counter-reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565 direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567 display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568 empty-cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570 float . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571 font . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572 font-family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572 font-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573 font-style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574 font-variant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575 font-weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575 height . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576 left . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 letter-spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578 line-height . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578 list-style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 list-style-image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 list-style-position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 list-style-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580 margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581 margin-bottom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582 margin-left . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582 margin-right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583 margin-top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583 max-height . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584 max-width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584 min-height . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585 min-width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585 orphans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586 outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586 outline-color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588 outline-style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 outline-width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590 overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590 padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591 padding-bottom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 padding-left . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 padding-right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594 padding-top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594 page-break-after . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595 page-break-before . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595 page-break-inside . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596 position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596 quotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597 right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598 table-layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598 text-align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599 text-decoration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599 text-indent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600 text-transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600 top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601 unicode-bidi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602 vertical-align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602 visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603 white-space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604 widows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604 width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605 word-spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606 z-index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607 CSS2 and CSS 2.1 Aural Style Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607 6 CSS3 Proprietary and Emerging Features Reference . . . . . . . . . . . . . . . . . . 613 The State of CSS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613 CSS3 Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613 CSS3-Introduced Values and Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621 CSS3 Color Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624 Media Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625 Web Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626 Miscellaneous CSS3 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629 C o n t e n t s xv xviii HTML & CSS: The Complete Reference transform-origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715 transform-style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716 transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717 transition-delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717 transition-duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718 transition-property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719 transition-timing-function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719 user-select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720 word-break . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721 word-wrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722 writing-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722 zoom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724 Part III Appendixes A Character Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727 Encoding Quirks and Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 728 Traditional HTML Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731 HTML 4.x and XHTML 1.x Character Entities . . . . . . . . . . . . . . . . . . . . . . . . . 740 Latin Extended-A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741 Latin Extended-B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741 Spacing Modifier Letters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741 General Punctuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741 Greek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743 Letter-like Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744 Arrows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745 Mathematical Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746 Technical Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747 Geometric Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748 Miscellaneous Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748 Embracing Unicode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748 B Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751 Specifying Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751 Fonts for Windows Platform and Browsers . . . . . . . . . . . . . . . . . . . . . 752 Fonts for Macintosh System and Browsers . . . . . . . . . . . . . . . . . . . . . . 755 PC Mac Font Similarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757 Downloadable Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760 Microsoft’s Dynamic Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760 Standard Downloadable Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761 Cross-Browser Downloadable Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . 761 Font Replacement with Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763 sIFR and Other Text Replacement Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 764 C Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765 (X)HTML Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765 Nonstandard Color Names and Numerical Equivalents . . . . . . . . . . 765 (X)HTML Elements Supporting Color . . . . . . . . . . . . . . . . . . . . . . . . . 772 CSS Color Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773 CSS Color-Related Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776 Browser-Safe Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779 D URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783 Server Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784 Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786 Filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787 Fragment Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788 Other Features of URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789 Data URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791 Other Emerging URL Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794 Relative URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795 Using the <base> Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795 URL Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796 Unclear Case Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797 Unclear Length Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797 Persistence Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797 Long, Dirty URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797 Short, Cryptic URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797 Location, Not Meaning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798 Beyond URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798 New Addressing Schemes: URNs, URCs, and URIs . . . . . . . . . . . . . . 798 E Reading a Document Type Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801 Element Type Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801 Occurrence Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802 Logical Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803 SGML Content Exclusion and Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804 Attribute Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804 SGML and XML Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805 Parameter Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806 The DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809 C o n t e n t s xix Acknowledgments The fifth edition of this book might as well be the first edition of a brand-new book. The HTML5 specification marks a return to past ideas and an explosion of future ideas. It took a great deal of work to put this new edition together. Given the amount of effort required, I want to make sure that all those that helped are given their due. First, I want to acknowledge the numerous fixes and improvements that came from the feedback from both my students at UCSD and readers around the world. I write these books for you, and I am glad you are putting this information to good use. I would also like to show my appreciation to the many staff members at PINT who helped on this book project in some direct or indirect way. I can’t specifically thank and mention the dozens of employees we have at PINT and my other firm Port80 Software who keep the lights on, but I’ll call a few out who warrant some extra kudos. Christie Sorenson once again helped this time with heavy lifting particularly in the CSS effort, and I can safely say that she has learned, relearned, and even forgotten more about Web development than probably anyone I know, besides maybe myself. Looking forward to more project fun in the future, Christie! Plenty of other PINTsters helped. Rob McFarlane, Andrew Simpkins, and Bryan Sleiter helped out with imagery. The project managers, particularly Mine Okano, Robin Nobel, Matt Plotner, and Olivia Chen, gave me moral support and occasional pity as I toiled away upstairs. Glenn Dawson addressed my many server changes and helped debug some annoying aspects of HTML5. Dan Whitworth assisted on a few chapters here and there and probably had nightmares about getting a call to really dive in. Joe Lima listened to some of my verbal nonsense and helped guide me to some deeper insights than I could have ever arrived at on my own. Daisy Bhonsle kept up a very long-standing proofing relationship, and I am very glad she always helps out. The student certainly has become the master. The folks at McGraw-Hill Professional are always a pleasure to work with. Meghan Riley helped guide me along, and Megg Morin didn’t lose faith, at least not completely. Thanks for being my patron the last decade, Megg! My technical editor, James Pence, probably wondered when this project was going to finish, and somehow he finished a nontechnical book of his own during the project. xxi I Core Markup CHAPTER 1 Traditional HTML and XHTML CHAPTER 2 Introducing HTML5 CHAPTER 3 HTML and XHTML Element Reference PART 1 Traditional HTML and XHTML Markup languages are ubiquitous in everyday computing. Although you may not realize it, word processing documents are filled with markup directives indicating the structure and often presentation of the document. In the case of traditional word processing documents, these structural and presentational markup codes are more often than not behind the scenes. However, in the case of Web documents, markup in the form of traditional Hypertext Markup Language (HTML) and its Extensible Markup Language (XML)-focused variant, XHTML, is a little more obvious. These not-so-behind-the-scenes markup languages are used to inform Web browsers about page structure and, some might argue, presentation as well. First Look at HTML and XHTML In the case of HTML, markup instructions found within a Web page relay the structure of the document to the browser software. For example, if you want to emphasize a portion of text, you enclose it within the tags <em> and </em>, as shown here: <em>This is important text!</em> 3 CHAPTER 4 P a r t I : C o r e M a r k u p When a Web browser reads a document that has HTML markup in it, it determines how to render it onscreen by considering the HTML elements embedded within the document: So, an HTML document is simply a text file that contains the information you want to publish and the appropriate markup instructions indicating how the browser should structure or present the document. Markup elements are made up of a start tag, such as <strong>, and typically, though not always, an end tag, which is indicated by a slash within the tag, such as </strong>. The tag pair should fully enclose any content to be affected by the element, including text and other HTML markup. NOTE There is a distinction between an element (for example, strong) and the tags (<strong> and </strong>) that are used by the element. However, you will likely often find the word “tag” used in place of “element” in many if not most discussions about HTML markup. This observation even includes historically relevant documents discussing HTML1 written by Tim Berners-Lee, the founding father of the Web. Fortunately, despite any imprecision of word choice that people may exhibit when discussing markup, meaning is usually well understood and this should not be a tremendous concern. Under traditional HTML (not XHTML), the close tag for some elements is optional because their closure can be inferred. For example, a <p> tag cannot enclose another <p> tag, and thus the closing </p> tag can be inferred when markup like this is encountered: <p>This is a paragraph. <p>This is also a paragraph. Such shortened notations that depend on inference may be technically correct under the specification, but stylistically they are not encouraged. It is always preferable to be precise, so use markup like this instead: <p>This is a paragraph.</p> <p>This is also a paragraph.</p> 1 Historic intro to HTML that clearly uses the term tag instead of element www.w3.org/History/19921103- hypertext/hypertext/WWW/MarkUp/Tags.html C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 7 PART I <p>Soon you will &hearts; using HTML.</p> <p>You can put lots of text here if you want. We could go on and on with fake text for you to read, but let's get back to the book.</p> </body> </html> ONLINE http://htmlref.com/ch1/html5helloworld.html In the case of XHTML, which is a form of HTML that is based upon the syntax rules of XML, we really don’t see many major changes yet in our example: <!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> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Hello XHTML World</title> <!-- Simple hello world in XHTML 1.0 strict example --> </head> <body> <h1>Welcome to the World of XHTML</h1> <hr /> <p>XHTML <em>really</em> isn't so hard either!</p> <p>Soon you will &hearts; using XHTML too.</p> <p>There are some differences between XHTML and HTML but with some precise markup you'll see such differences are easily addressed.</p> </body> </html> ONLINE http://htmlref.com/ch1/xhtmlhelloworld.html The preceding examples use some of the most common elements used in (X)HTML documents, including: • The <!DOCTYPE> statement, which indicates the particular version of HTML or XHTML being used in the document. The first example uses the strict 4.01 specification, the second uses a reduced form for HTML5 the meaning of which will be explained a bit later on, and the final example uses the XHTML 1.0 strict specification. • The <html>, <head>, and <body> tag pairs are used to specify the general structure of the document. The required inclusion of the xmlns attribute in the <html> tag is a small difference required by XHTML. • The <meta> tag used in the examples indicates the MIME type of the document and the character set in use. Notice that in the XHTML example, the element has a trailing slash to indicate that it is an empty element. • The <title> and </title> tag pair specifies the title of the document, which generally appears in the title bar of the Web browser. • A comment is specified by <!-- -->, allowing page authors to provide notes for future reference. 8 P a r t I : C o r e M a r k u p • The <h1> and </h1> header tag pair indicates a headline specifying some important information. • The <hr> tag, which has a self-identifying end tag (<hr />) under XHTML, inserts a horizontal rule, or bar, across the screen. • The <p> and </p> paragraph tag pair indicates a paragraph of text. • A special character is inserted using a named entity (&hearts;), which in this case inserts a heart dingbat character into the text. • The <em> and </em> tag pair surrounds a small piece of text to emphasize which a browser typically renders in italics. There are numerous other markup elements that may be employed, all of which will be explored throughout the book, but for now this sampling is enough to get our first example rendered in a browser. NOTE Examples in the book will generally be presented in HTML5. Syntax specific to particular browsers, older HTML variants, or XHTML will always be noted when used. Viewing Markup Locally Using a simple text editor, type in either one of the previous examples and save it with a filename such as helloworld.html or helloworld.htm; you can choose which file extension to use, .htm or .html, but whichever you pick for development, aim to be consistent. This book uses .html for all of the files. After you save the example file on your local file system, open it in your Web browser by opening the File menu and choosing Open, Open Page, or Open File, depending on your browser: C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 9 PART I Once your browser reads the file, it should render a page like the one shown here: If for some reason you didn’t save your file with the appropriate extension, the browser shouldn’t attempt to interpret the HTML markup. For example, notice here what happens when you try to open the content with a .txt extension: If you want to make a change to the document, you could update the markup, save the file, go back to the browser, and click the Reload or Refresh button. Sometimes the browser will still reload the page from its cache; if a page does not update correctly on reload, hold down the SHIFT key while clicking the Reload button, and the browser should refresh the page. As you write markup, keeping the browser and editor open simultaneously is a very good idea to avoid constantly reopening one or the other. Many Web editors will assist you in loading your Web pages into various browsers or even preview the visualization of the markup directly. Figure 1-1 shows this process in Adobe’s popular Dreamweaver program (www. dreamweaver.com). 12 P a r t I : C o r e M a r k u p On the Web server, you most likely will use the .html or .htm file extension for your files. When HTML files are placed in the appropriate directory, the user would issue a URL in their browser like http://yoursitename/sitepath/helloworld.html and that will then return the file in question. However, note that when a marked-up document is delivered over the network, it is not the file extension that indicates to the browser that the content is HTML, but rather the Content-Type: header found in the network stream: C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 13 PART I The browser then takes the header and maps it to the action of parsing the document as HTML. In some older browsers, the mapping between MIME type or file extension and browser action is obvious: This Preferences dialog box shows that the extension or header is what triggers the action by the browser. The goal here is simply to illustrate that there is something different going on between reading locally and remotely. Before wrapping up this brief introductory example, it should be noted that in some cases when you have configured the wrong file extension or MIME type, some browsers may “sniff out” the content type and parse any HTML found within. For example, in Figure 1-2 you can see that many versions of Internet Explorer2 render a file with a .txt extension as HTML while Firefox does not. We have to pay attention to details even in the simplest examples if we want to avoid headaches from questionable browser practices and plain old bugs. HTML5 will aim to remove such problems in the distant future, but for now let’s get down to the most important details, starting first by enumerating all of the versions of (X)HTML that we might need to know about. 2 Internet Explorer 8 introduces some changes to avoid sniffing; you can set X-Content-Type-Options: nosniff as a response header to disable Internet Explorer’s permissive behavior, though this only works in IE8 and beyond. 14 P a r t I : C o r e M a r k u p HTML and XHTML: Version History Since its initial introduction in late 1991, HTML (and later its XML-based cousin, XHTML) has undergone many changes. Interestingly, the first versions of HTML used to build the earliest Web pages lacked a rigorous definition. Fortunately, by 1993 the Internet Engineering Task Force (IETF) began to standardize the language and later, in 1995, released the first real HTML standard in the form of HTML 2.0. You will likely encounter more than just the latest style of markup for many years to come, so Table 1-1 presents a brief summary of the version history of HTML and XHTML. FIGURE 1-2 Irregularities with browsers handling MIME types and file extensions Internet Explorer reads the txt file, interprets the code in the page, and renders as if it were an html file. Firefox recognizes the file type and renders the text rather than interpret the code as html. C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 17 PART I elements is called the content model. If you further explore the specification to see what that %inline entity maps out to, you will see that it contains numerous other elements, such as EM, STRONG, and so on, as well as regular typed text. The final line defines the attributes for a <P> tag as indicated by the entity %attrs which then expands to a number of entities like %core, %i18n, and %coreevents which finally expand into a variety of attributes like id, class, style, title, lang, dir, onclick, ondblclick, and many more. The full syntax of the P element can be found in the reference in Chapter 3; the aim here is for you to understand the syntax of SGML in a basic sense to support your understanding of how Web browsers treat markup. As another example, look at the HTML 4.01 DTD’s definition of the HR element: <!--=================== Horizontal Rule ================================--> <!ELEMENT HR - O EMPTY -- horizontal rule --> <!ATTLIST HR %attrs; -- %coreattrs, %i18n, %events -- > From this syntax fragment, note that the HR element has a start tag but does not require a close tag. More interestingly, the element does not enclose any content, as indicated by the EMPTY designation. It turns out to have the same set of attributes as the P element, as defined by the %attrs entity. As mentioned in the previous section on the history of HTML, in 1999 the W3C rewrote HTML as an application of XML and called it XHTML. XML, in this situation, serves the same purpose as SGML: a language in which to write the rules of a language. In fact, XML is in some sense just a limited form of SGML. XML and SGML can be used to write arbitrary markup languages, not just HTML and XHTML. These would be called applications or, maybe more appropriately, application languages. Numerous markup languages have been defined with SGML and XML, and you could even define your own if you like. The relationship between the various markup technologies is shown here: Languages Defined by Example Application Languages SGML XML … … … TEI HTML DocBook WML XHTML RSS SOAP The DTD defined in XML for the XHTML language is actually quite similar to the DTD for traditional HTML. For example, consider the XHTML DTD entries for the two elements previously presented: <!--=================== Paragraphs =====================================--> <!ELEMENT p %Inline;> <!ATTLIST p %attrs; > 18 P a r t I : C o r e M a r k u p <!--=================== Horizontal Rule ================================--> <!ELEMENT hr EMPTY> <!ATTLIST hr %attrs; > As you can see, there is some case changing (lowercase elements), a lack of optional close tags, and a general cleanup of syntax, but otherwise things are pretty much the same. Properly constructed (X)HTML documents should reference a DTD of some sort and it is important to know what this means as browsers and Web quality assurance tools actually consult the doctype directives. Hopefully, this brief introduction has given you a sense of the underlying specification of (X)HTML and its degree of detail. Appendix E presents complete coverage of how to read the (X)HTML DTDs. NOTE Interestingly, HTML5 does not use SGML or XML definitions, but instead relies on an English prose specification combined with some formalism. Chapter 3 discusses this change and some other aspects of the HTML5 language and specification that is different from the older markup languages. Document Type Statements and Language Versions (X)HTML documents should begin with a <!DOCTYPE> declaration. This statement identifies the type of markup that is supposedly used in a document. For example, <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> indicates that we are using the transitional variation of HTML 4.01 that starts with a root element html. In other words, an <html> tag will serve as the ultimate parent of all the content and elements within this document. A <!DOCTYPE> declaration might get a bit more specific and specify the URI (Uniform Resource Identifier) of the DTD being used as shown here: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> In the case of an XHTML document, the situation really isn’t much different: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> However, do note that the root html element here is lowercase, which hints at the case sensitivity found in XHTML. There are numerous doctype declarations that are found in HTML and XHTML documents, as shown in Table 1-2. NOTE On occasion you might see other HTML document type indicators, notably one for the 3.0 standard that was never really adopted in the Web community. C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 19 PART I While there are many different versions of (X)HTML, the good news is that the rough document structure defined for each is pretty similar; of course, the bad news is that little details will be different from version to version, so you need to be precise with your syntax. HTML or XHTML Version !DOCTYPE Declaration HTML 2.0 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> HTML 3.2 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> HTML 4.0 Transitional <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> HTML 4.0 Frameset <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd"> HTML 4.0 Strict <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/html4/strict.dtd"> HTML 4.01 Transitional <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> HTML 4.01 Frameset <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd"> HTML 4.01 Strict <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> HTML5 <!DOCTYPE html> XHTML 1.0 Transitional <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> XHTML 1.0 Strict <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> XHTML 1.0 Frameset <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd"> XHTML 1.1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> XHTML 2.0 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml2.dtd"> XHTML Basic 1.0 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> XHTML Basic 1.1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd"> TABLE 1-2 Common HTML Doctype Declarations 22 P a r t I : C o r e M a r k u p a <body> tag should be found for browsers that do not support frames. A visual representation of this idea is shown here: HTML5 does not support standard frames, though it does preserve inline frames. Chapter 2 addresses that HTML5–specific change; for now, we’ll concentrate on a typical document structure and drill into each element until we reach the very characters displayed. Roughly speaking, the structure of a non-framed (X)HTML document breaks out like so: Some <!DOCTYPE> statement HTML HEAD BODY <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4 frameset.dtd"> <html> </html> <head> <meta http-equip="Content-Type" content="text/html; charset=utf-8"> <title>Page Title</title> </head> <frameset> <frame /> <frame /> </frameset> <noframes> <body> </body> </noframes> Doctype statement indicates type of document Head contains info about page Root HTML element encloses entire doc Body Filename: template.html Frameset C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 23 PART I The following sections drill into each of the document structuring markup elements and explore what’s contained inside. The Document Head The information in the head element of an (X)HTML document is very important because it is used to describe or augment the content of the document. The element acts like the front matter or cover page of a document. In many cases, the information contained within the head element is information about the page that is useful for visual styling, defining interactivity, setting the page title, and providing other useful information that describes or controls the document. The title Element A single title element is required in the head element and is used to set the text that most browsers display in their title bar. The value within a title is also used in a browser’s history system, recorded when the page is bookmarked, and consulted by search engine robots to help determine page meaning. In short, it is pretty important to have a syntactically correct, descriptive, and appropriate page title. Thus, given <title>Simple HTML Title Example</title> you will see something like this: When a title is not specified, most browsers display the URL path or filename instead: Only one title element should appear in every document, and most user agents will ignore subsequent tag instances. You should be quite careful about making sure a title element is well formed because omitting the close tag can cause many browsers to not load the document. A recent version of Opera reveals what is likely happening in this situation: Here it appears that the markup and rest of the document are used as the contents of the unclosed title element, and thus nothing is rendered in the browser. It should be noted that this particular rendering may vary because some browsers fix an unclosed title. 24 P a r t I : C o r e M a r k u p A document title may contain standard text, but markup isn’t interpreted in a <title> tag, as shown here: However, character entities such as &copy; (or, alternatively, &#169;), which specifies a copyright symbol, are allowed in a title: <title>Simple HTML Title Example, &copy; 2010 WebMonopoly, Inc.</title> For an entity to be displayed properly, you need to make sure the appropriate character set is defined and that the browser supports such characters; otherwise, you may see boxes or other odd symbols in your title: To set the appropriate character set, you should include a <meta> tag before the page title even though traditionally title is considered the first element. NOTE Beyond character set concerns, think twice before using a special character such as a colon (:), slash (/), or backslash (\) in a document title. An operating system might have a problem with such a title if the document is saved to the local system. For example, the colon isn’t allowed within Macintosh filenames, and slashes generally aren’t allowed within filenames, because they indicate directories. Most modern browsers remove such special characters and reduce them to spaces during the Save process. To be on the safe side, use dashes to delimit items in a page title. <meta>: Specifying Content Type, Character Set, and More A <meta> tag has a number of uses. For example, it can be used to specify values that are equivalent to HTTP response headers. For example, if you want to make sure that your MIME type and character set for an English-based HTML document is set, you could use <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> Because meta is an empty element, you would use the trailing-slash syntax shown here: <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 27 PART I Book: HTML: The Complete Reference Edition: 5 --> Comments can contain just about anything except other comments and are particularly sensitive to – symbols. Thus <!------ THIS ISN'T A SYNTACTICALLY CORRECT COMMENT! ----> NOTE Correct usage of comments goes well beyond syntax, because they may inherently expose security concerns on public-facing sites. You’ll also find that comments are used not only for development notes but also to mask some types of content from browsers. The complete syntax of the markup allowed in the head element under strict (X)HTML is shown here: Following is an example XHTML document with a head element that contains common usage of elements: <!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> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Sample Head Element</title> <!-- Some example meta tags --> <meta name="keywords" content="Fake, Head Example, HTML Ref" /> <meta name="description" content="A simple head example that shows a number of the elements presented in action." /> <meta name="author" content="Thomas A. Powell" /> head title base link style script object meta <!-- --> mandatory single occurrence and generally early 28 P a r t I : C o r e M a r k u p <!-- Set a global URI stem for all references --> <base href="http://htmlref.com/baseexample" /> <!-- Linked and document specific styles --> <link rel="stylesheet" href="screen.css" media="screen" /> <link rel="stylesheet" href="printer.css" media="print" /> <style type="text/css"> <!-- h1 {font-size: xx-large; color: red; font-style: italic;} --> </style> <!-- Embedded and linked scripts --> <script type="text/javascript"> <!-- var globalDebug = true; //--> </script> <script src="ajaxtcr.js" type="text/javascript"></script> <script src="effects.js" type="text/javascript"></script> </head> <body> <p>Some body content here.</p> </body> </html> The various details of the tags within the document head are all presented in the element reference in Chapter 3; the aim here was to show you the organization of the head element and how it supports the body. Now let’s move on to see the content in the document body itself. The Document Body After the head section, the body of a document is delimited by <body> and </body>. Under the HTML 4.01 specification and many browsers, the body element is optional, but you should always include it, particularly because it is required in stricter markup variants. Only one body element can appear per document. Within the body of a Web document is a variety of types of elements. For example, block- level elements define structural content blocks such as paragraphs (p) or headings (h1-h6). Block-level elements generally introduce line breaks visually. Special forms of blocks, such as unordered lists (ul), can be used to create lists of information. Within nonempty blocks, inline elements are found. There are numerous inline elements, such as bold (b), italic (i), strong (strong), emphasis (em), and numerous others. These types of elements do not introduce any returns. C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 29 PART I Other miscellaneous types of elements, including those that reference other objects such as images (img) or interactive elements (object), are also generally found within blocks, though in some versions of HTML they can stand on their own. Within block and inline elements, you will find textual content, unless the element is empty. Typed text may include special characters that are difficult to insert from the keyboard or require special encoding. To use such characters in an HTML document, they must be “escaped” by using a special code. All character codes take the form &code;, where code is a word or numeric code indicating the actual character that you want to put onscreen. For example, when adding a less-than symbol (<) you could use &lt; or &#060;. Character entities also are discussed in depth in Appendix A. Finally, just as in the head, you may include comments in the body element. A visual overview of all the items presented in the body is shown here: Comment Inline Elements Character Entity Block Elements 32 P a r t I : C o r e M a r k u p <hr> <p>HTML <em>really</em> isn't so hard!</p> <p>Soon you will &hearts; using HTML.</p> <p>You can put lots of text here if you want. We could go on and on with fake text for you to read, but let's get back to the book.</p> </body> </html> it builds a parse tree to interpret the structure of the document, possibly like this: DOCTYPE HTML HEAD META TITLE BODY H1 HR P “HTML” EM P P HTML ELEMENT Text Node <!-- comment --> <!-- simple hello world in HTML 4.01 strict example --> “Welcome to the world of HTML” “Really” “isn’t so hard!” “soon you will &hearts; using HTML.” “You could put lots of text here if you want. We could go on and on with fake text for you to read, but let’s get back to the book.” “Hello HTML World” Legend C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 33 PART I These parse trees, often called DOM (Document Object Model) trees, are the browsers’ interpretation of the markup provided and are integral to determining how to render the page visually using both default (X)HTML style and any CSS attached. JavaScript will also use this parse tree when scripts attempt to manipulate the document. The parse tree serves as the skeleton of the page, so making sure that it is correct is quite important, but sadly we’ll see very often it isn’t. NOTE The syntax trees presented earlier look very similar to the parse trees, and they should, because any particular parse tree should be derivable from the particular markup language’s content model. Browsers are actually quite permissive in what they will render. For example, consider the following markup: <TITLE>Hello HTML World</title> <!-- Simple hello malformed world -- example --> </head> <body> <h1>Welcome to the World of HTML</H1> <hr /> <p>HTML <eM>really</Em> isn't so hard! <P>Soon you will &hearts; using HTML. <p>You can put lots of text here if you want. We could go on and on with fake text for you to read, <foo>but</foo> let's get back to the book. </html> This example misses important tags, doesn’t specify encoding types, has a malformed comment, uses inconsistent casing, doesn’t close tags, and even uses some unknown element foo. However, this will render exactly the same visually as the correct markup previously presented, as shown in Figure 1-3. 34 P a r t I : C o r e M a r k u p FIGURE 1-3 Malformed markup works!? Well-formed Markup Malformed Markup C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 37 PART I Simply put, it is quite important to aim for correct markup as a solid foundation for a Web page and to not assume the markup is correct just because it appears to render correctly in your favorite browser. Validation As shown earlier, a DTD defines the actual elements, attributes, and element relationships that are valid in documents. Now you can take a document written in (X)HTML and then check whether it conforms to the rules specified by the DTD used. This process of checking whether a document conforms to the rules of the DTD is called validation. The <!DOCTYPE> declaration allows validation software to identify the HTML DTD being followed in a document, and verify that the document is syntactically correct—in other words, that all tags used are part of a particular specification and are being used correctly. An easy way to validate a document is simply to use an online service such as the W3C Markup Validation Service, at http://validator.w3.org. If the malformed example from the previous section is passed to this service, it clearly shows that the page has errors: 38 P a r t I : C o r e M a r k u p Pass the URL to the service yourself by using this link in the address bar: http://validator.w3.org/check?uri=http%3A%2F%2Fhtmlref.com%2Fch1%2Fmalforme dhelloworld.html By reading the validator’s messages about the errors it detected, you can find and correct the various mistakes. After all mistakes are corrected, the document should validate cleanly: Web developers should aim to start with a baseline of valid markup before trying to address various browser quirks and bugs. Given that so many Web pages on the Web are poorly coded, some developers opt to add a “quality” badge to a page to show or even prove standards conformance: C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 39 PART I Whether users care about such things is debatable, but the aim for correctness is appropriate. Contrast this to the typical effort of testing a page by viewing it in various browsers to see what happens. The thought is, if it looks right, then it is right. However, this does not acknowledge that the set of supported or renderable pages a browser may handle is a superset of those which are actually conforming to a particular specification: It is an unfortunate reality that browsers support a multitude of incorrect things and that developers often use a popular browser as an acceptance engine based upon some page rendering for better or worse. Such an approach to markup testing might seem reasonable in the short term, but it will ultimately lead to significant developer frustration, particularly as other technologies are added, such as CSS and JavaScript, and newer browsers are introduced. Unfortunately, given the browsers’ current method of allowing garbage yet preferring standards, there is little reason for some developers to care until such a price is realized. The Doctype Switch and Browser Rendering Modes Modern Web browsers generally have two rendering modes: quirks mode and standards compliance mode. As their names suggest, quirks mode is more permissive and standards compliance mode is stricter. The browser typically chooses in which mode to parse a document by inspecting the <!DOCTYPE> statement, if there is one. This process typically is Conforming Markup Supported Malformed Markup Unsupported Markup 42 P a r t I : C o r e M a r k u p Attribute Values May Be Case Sensitive Consider <img SRC="test.gif"> and <IMG src="test.gif">. Under traditional HTML, these are equivalent because the <img> tag and the src attribute are not case sensitive. However, given XHTML, they should always be lowercase. However, just because attribute names are not case sensitive under traditional HTML, this doesn’t mean every aspect of attributes is case insensitive. Regardless of the use of XHTML or HTML, the actual attribute values in some tags may be case sensitive, particularly where URLs are concerned. So <img src="test.gif"> and <img src="TEST.GIF"> do not necessarily reference the same image. When referenced from a UNIX-based Web server, where filenames are case sensitive, test.gif and TEST.GIF would be two different files, whereas on a Windows Web server, where filenames are not case sensitive, they would reference the same file. This is a common problem and often hinders the ability to easily transport a Web site from one server to another. (X)HTML Is Sensitive to a Single Whitespace Character Any white space between characters displays as a single space. This includes all tabs, line breaks, and carriage returns. Consider this markup: <strong>T e s t o f s p a c e s</strong><br> <strong>T e s t o f s p a c e s </strong><br> <strong>T e s t o f s p a c e s</strong><br> As shown here, all the spaces, tabs, and returns are collapsed to a single element: However, it is possible to force the whitespace issue. If more spaces are required, it is possible to use the nonbreaking space entity, or &nbsp;. Some consider this the duct tape of the Web—useful in a bind when a little bit of spacing is needed or an element has to be kept from collapsing. Yet using markup such as &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Look, I'm spaced out! would add space to the output, the question is, exactly how far? In print, using spaces to format is dangerous given font size variability, so text rarely lines up. This is no different on the Web. Further note that in some situations, (X)HTML does treat whitespace characters differently. In the case of the pre element, which defines a preformatted block of text, white space is preserved rather than ignored because the content is considered preformatted. It is also possible to use the CSS property white-space to change default whitespace handling. Because browsers will ignore most white space, Web page authors often format their documents for readability. However, the reality is that browsers really don’t care one way or another, nor do end users. Because of this, some sites have adopted a markup optimization idea, often called crunching or minification, to save bandwidth. C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 43 PART I (X)HTML Follows a Content Model All forms of markup support a content model that specifies that certain elements are supposed to occur only within other elements. For example, markup like this <ul> <p>What a simple way to break the content model!</p> </ul> which often is used for simple indentation, actually doesn’t follow the content model for the strict (X)HTML specifications. The <ul> tag is only supposed to contain <li> tags. The <p> tag is not really appropriate in this context. Much of the time, Web page authors are able to get away with this, but often they can’t. For example, in some browsers, the <input> tag found outside a <form> tag is simply not displayed, yet in other browsers it is. Elements Should Have Close Tags Unless Empty Under traditional HTML, some elements have optional close tags. For example, both of the paragraphs here are allowed, although the second one is better: <p>This isn't closed <p>This is</p> However, given the content model, the close of the top paragraph can be inferred since its content model doesn’t allow for another <p> tag to occur within it. HTML5 continues to allow this, as discussed in Chapter 2. A few elements, like the horizontal rule (hr) and line break (br), do not have close tags because they do not enclose any content. These are considered empty elements and can be used as is in traditional HTML. However, under XHTML you must always close tags, so you would have to write <br></br> or, more commonly, use a self-closing tag format with a final “/” character, like so: <br />. Unused Elements May Minimize Sometimes tags may not appear to have any effect in a document. Consider, for example, the <p> tag, which specifies a paragraph. As a block tag, it induces a return by default, but when used repeatedly, like so, <p></p><p></p><p></p> does this produce numerous blank lines? No, since the browser minimizes the empty p elements. Some HTML editors output nonsense markup such as <p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p> to deal with this. If this looks like misused markup to you, you’re right! Elements Should Nest A simple rule states that tags should nest, not cross; thus <b><i>is in error as tags cross</b></i> 44 P a r t I : C o r e M a r k u p whereas <b><i>is not since tags nest</i></b> and thus is syntactically correct. All forms of markup, traditional HTML, XHTML, and HTML5, follow this rule, and while crossing tags may seem harmless, it does introduce some ambiguity in parse trees. To be a well-formed markup, proper nesting is mandatory. Attributes Should Be Quoted Under traditional HTML as well as under HTML5, simple attribute values do not need to be quoted. If the attribute contains only alphanumeric content, dashes, and periods, then the quotes can safely be removed; so, <img src=robot.gif height=10 width=10 alt=robot> would work fine in most browsers and would validate. However, the lack of quotes can lead to trouble, especially when scripting is involved. Quotes should be used under transitional markup forms and are required under strict forms like XHTML; so, <img src="robot.gif" height="10" width="10" alt="robot" /> would be the correct form of the tag. Generally, it doesn’t matter whether you use single or double quotes, unless other quotes are found within the quotes, which is common with JavaScript or even with CSS when it is found in an attribute value. Stylistically, double quotes tend to be favored, but either way you should be consistent. Entities Should Be Used for Special Characters Markup parsers are sensitive to special characters used for the markup itself, like < and >. Instead of writing these potentially parse-dangerous characters in the document, they should be escaped out using a character entity. For example, instead of <, use &lt; or the numeric equivalent &#60;. Instead of >, use &gt; or &#62;. Given that the ampersand character has special meaning in an entity, it would need to be escaped as well using &amp; or &#38;. Beyond escaping characters, it is necessary to insert special characters for special quote characters, legal symbols like copyright and trademark, currency, math, dingbats, and a variety of other difficult-to-type symbols. Such characters are also inserted with entities. For example, to insert the Yen symbol (¥), you would use &yen; or &#165;. With Unicode in play, there is a vast range of characters to choose from, but unfortunately there are difficulties in terms of compatibility, all of which is discussed in Appendix A. Browsers Ignore Unknown Attributes and Elements For better or worse, keep in mind that browsers will ignore unknown elements and attributes; so, <bogus>this text will display on screen</bogus> and markup such as <p id="myPara" obviouslybadattribute="TRUE">will also render fine.</p> C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 47 PART I little to change this thinking, with the latest browser hacks and filters as popular as the pixel tricks and table hacks of the generation before. Developers tend to favor that which is easy and seems to work, so why bother to put more time in, particularly if browsers render the almost right markup with little complaint and notice? Obviously, this “good enough” approach simply isn’t good enough. Without standards, the modern world wouldn’t work well. For example, imagine a world of construction in which every nut and bolt might be a slightly different size. Standards provide needed consistency. The Web needs standards, but standards have to acknowledge what people actually do. Declaring that Web developers really need to validate, use logical markup, and separate the look from the structure of the document is great but it doesn’t get them to do so. Standards are especially pointless if they are never widely implemented. Web technologies today are like English—widely understood but poorly spoken. However, at the same time they are the Latin of the Web, providing a strong foundation for development and intersecting with numerous technologies. Web standards and development practices provide an interesting study of the difference between what theorists say and what people want and do. HTML5 seems a step in the right direction. The specification acknowledges that, for better or worse, traditional HTML practices are here for now, and thus attempts to make them solid while continuing to move technology forward and encourage correct usage. Myths and Misconceptions About HTML and XHTML The amount of hearsay, myths, and complete misunderstandings about HTML and XHTML is enormous. Much of this can be attributed to the fact that many people simply view the page source of sites or read quick tutorials to learn HTML. This section covers a few of the more common misconceptions about HTML and tries to expose the truth behind them. Misconception: WYSIWYG Works on the Web (X)HTML isn’t a specific, screen- or printer-precise formatting language like PostScript. Many people struggle with HTML on a daily basis, trying to create perfect layouts using (X)HTML elements inappropriately or using images to make up for HTML’s lack of screen and font-handling features. Interestingly, even the concept of a visual WYSIWG editor propagates this myth of HTML as a page layout language. Other technologies, such as CSS, are far better than HTML for handling presentation issues and their use returns HTML to its structural roots. However, the battle to make the end user see exactly what you see on your screen is likely to be a futile one. Misconception: HTML Is a Programming Language Many people think that making HTML pages is similar to programming. However, HTML is unlike programming in that it does not specify logic. It specifies the structure of a document. The introduction of scripting languages such as JavaScript into Web documents and the confusing terms Dynamic HTML (DHTML) and Ajax (Asynchronous JavaScript and XML) tacked on may lead many to overestimate or underestimate the role of markup in the mix. However, markup is an important foundation for scripting and should be treated with the same syntactical precision that script is given. Misconception: XHTML Is the Only Future Approaching its tenth birthday, XHTML still has yet to make much inroads in the widespread building of Web pages. Sorry to say, most documents are not authored in XHTML, and many 48 P a r t I : C o r e M a r k u p of those that are, are done incorrectly. Poor developer education, the more stringent syntax requirements, and ultimately the lack of obvious tangible benefit may have kept many from adopting the XML variant of HTML. Misconception: XHTML Is Dead Although XHTML hasn’t taken Web development by storm, the potential rise of HTML5 does not spell the end of XHTML. In fact, you can write XML-style markup in HTML, which most developers dub XHTML 5. For precision, XHTML is the way to go, particularly when used in an environment that includes other forms of XML documents. XHTML’s future is bright for those who build well-formed, valid markup documents. Myth: Traditional HTML Is Going Away HTML is the foundation of the Web; with literally billions of pages in existence, not every document is going to be upgraded anytime soon. The “legacy” Web will continue for years, and traditional nonstandardized HTML will always be lurking around underneath even the most advanced Web page years from now. Beating the standards drum might speed things up a bit, but the fact is, there’s a long way to go before we are rid of messed-up markup. HTML5 clearly acknowledges this point by documenting how browsers should act in light of malformed markup. Having taught HTML for years and having seen how both HTML editors and people build Web pages, I think it is very unlikely that strictly conforming markup will be the norm anytime soon. Although (X)HTML has had rules for years, people have not really bothered to follow them; from their perspective, there has been little penalty for failing to follow the rules, and there is no obvious benefit to actually studying the language rigorously. Quite often, people learn markup simply through imitation by viewing the source of existing pages, which are not necessarily written correctly, and going from there. Like learning a spoken language, (X)HTML’s loosely enforced rules have allowed many document authors to get going quickly. Its biggest flaw is in some sense its biggest asset and has allowed millions of people to get involved with Web page authoring. Rigor and structure is coming, but it will take time, tools, and education. Myth: Someday Standards Will Alleviate All Our Problems Standards are important. Standards should help. Standards likely won’t fix everything. From varying interpretations of standards, proprietary additions, and plain old bugs, there is likely never going to be a day where Web development, even at the level of (X)HTML markup, doesn’t have its quirks and oddities. The forces of the market so far have proven this sentiment to be, at the very least, wishful thinking. Over a decade after first being considered during the writing of this book’s first edition, the wait for some standards nirvana continues. Myth: Hand-Coding of HTML Will Continue Indefinitely Although some people will continue to craft pages in a manner similar to mechanical typesetting, as Web editors improve and produce standard markup perfectly, the need to hand-tweak HTML documents will diminish. Hopefully, designers will realize that knowledge of the “invisible pixel” trick or the CSS Box Model Hack is not a bankable resume item and instead focus on development of their talents along with a firm standards-based understanding of markup, CSS, and JavaScript. C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 49 PART I Myth: (X)HTML Is the Most Important Technology Needed to Create Web Pages Whereas (X)HTML is the basis for Web pages, you need to know a lot more than markup to build useful Web pages (unless the page is very simple). However, don’t underestimate markup, because it can become a bit of a challenge itself. Based on the simple examples presented in this chapter, you might surmise that mastering Web page creation is merely a matter of learning the multitude of markup tags, such as <h1>, <p>, <em>, and so on, that specify the structure of Web documents to browsers. While this certainly is an important first step, it would be similar to believing you could master the art of writing by simply understanding the various commands available in Microsoft Word. There is a tremendous amount to know in the field of Web design and development, including information architecture, visual design, client- and server-side programming, marketing and search engines, Web servers and delivery, and much, much more. The Future of Markup—Two Paths? Having followed markup for well over a decade in writing editions of this book and beyond, it is still quite difficult to predict what will happen with it in the future, other than to say the move towards strict markup will likely be a bit slower than people think and probably not ideal. The sloppy syntax from the late 1990s is still with us and is likely to be so for some time. The desire to change this is strong, but so far the battle for strict markup is far from won. We explore here two competing, or potentially complementary, paths for the future of markup. XHTML: Web Page Markup XML Style A new version of HTML called XHTML became a W3C recommendation in January 2000. XHTML, as discussed earlier in the chapter, is a reformulation of HTML using XML that attempts to change the direction and use of HTML to the way it ought to be. So what does that mean? In short, rules now matter. As you know, you can feed a browser just about anything and it will render. XHTML would aim to end that. Now if you make a mistake, it should matter. Theoretically, a strictly XHTML-conforming browser shouldn’t render a page at all if it doesn’t conform to the standard, though this is highly unlikely to happen because browsers resort to a backward-compatibility quirks mode to display such documents. The question is, could you enforce the strict sense of XML using XHTML? The short answer is, maybe not ideally. To demonstrate, let’s reformulate the xhtmlhelloworld.html example slightly by adding an XML directive and forcing the MIME type to be XML. We’ll then try to change the file extension to .xml to ensure that the server gets the browser to really treat the file as XML data. <?xml version="1.0" encoding="utf-8"?> <!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> <meta http-equiv="Content-Type" content="text/xml; charset=utf-8" /> <title>Hello XHTML World</title> <!-- Simple hello world in XHTML 1.0 strict example --> </head> 52 P a r t I : C o r e M a r k u p HTML5: Back to the Future Starting in 2004, a group of well-known organizations and individuals got together to form a standards body called the Web Hypertext Application Technology Working Group, or WHATWG (www.whatwg.org), whose goal was to produce a new version of HTML. The exact reasons and motivations for this effort seem to vary depending on who you talk to—slow uptake of XHTML, frustration with the lack of movement by the Web standards body, need for innovation, or any one of many other reasons—but, whatever the case, the aim was to create a new, rich future for Web applications that include HTML as a foundation element. Aspects of the emerging specification such as the canvas element have already shown up in browsers like Safari and Firefox, so by 2008, the efforts of this group were rolled into the W3C and drafts began to emerge. Whether this makes HTML5 become official or likely to be fully adopted is obviously somewhat at the mercy of the browser vendors and the market, but clearly another very likely path for the future of markup goes through HTML5. Already we see Google adopting it in various places, so its future looks bright. NOTE While HTML5 stabilized somewhat around October 2009, with a W3C final candidate recommendation goal of 2012, you are duly warned that the status of HTML5 may change. Because of the early nature of the specification, specific documentation of HTML5 focuses more on what works now than on what may make it into the specification later. HTML5 is meant to represent a new version of HTML along the HTML 4 path. The emerging specification also suggests that it will be a replacement for XHTML, yet it ends up supporting most of the syntax that end users actually use, particularly self-identifying empty elements (for example, <br />). It also reverses some of the trends, such as case sensitivity, that have entered into markup circles, so it would seem that the HTML styles of the past will be fine in the future. In most ways, HTML5 doesn’t present much of a difference, as you saw earlier in the chapter’s introductory example, shown again here: <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Hello HTML World</title> <!-- Simple hello world in HTML5 example --> </head> <body> <h1>Welcome to the Future World of HTML5</h1> <hr> <p>HTML5 <em>really</em> isn't so hard!</p> <p>Soon you will &hearts; using HTML.</p> <p>You can put lots of text here if you want. We could go on and on with fake text for you to read, but let's get back to the book.</p> </body> </html> ONLINE http://htmlref.com/ch1/helloworldhtml5.html C h a p t e r 1 : T r a d i t i o n a l H T M L a n d X H T M L 53 PART I All that is different in this example is that the <!DOCTYPE> statement is much simpler. In fact, the specific idea of using SGML and performing validation does not apply to HTML5. However, the syntax checking benefits of validation lives on and is now being called conformance checking and for all intents and purposes is the same. Interestingly, because of the statement in its shortened form, browsers will correctly enter into a standards compliance mode when they encounter an HTML5 document: In the next chapter, we’ll see that HTML5 is quite a bit different than HTML 4 despite what our “hello world” example suggests. There are many new tags and there is a tremendous emphasis on interactivity and Web application development. However, probably the most interesting aspect of HTML5 is the focus on defining what browsers—or, more widely, user agents in general—are supposed to do when they encounter ill-formed markup. HTML5, by defining known outcomes, makes it much more likely that today’s “tag soup” will be parsed predictably by tomorrow’s browsers. Unfortunately, read another way, it provides yet more reasons for those who create such a mess of markup not to change their bad habits. Likely, the future of markup has more than one possible outcome. My opinion is that those who produce professional-grade markup or who write tools to do so will continue to embrace standards, XML or not, while those who dabble with code and have fun will continue to work with little understanding of the rules they break and will have no worries about doing so. The forgiveness that HTML allows is both the key to its popularity and, ultimately, the curse of the unpredictability often associated with it. Summary HTML is the markup language for building Web pages and traditionally has combined physical and logical structuring ideas. Elements—in the form of tags such as <em> and </em>—are embedded within text documents to indicate to browsers how to render pages. The rules for HTML are fairly simple and compliance can be checked with a process called validation. Unfortunately, these rules have not been enforced by browsers in the past. Because of this looseness, there has been a great deal of misunderstanding about the purpose of HTML, and a good portion of the documents on the Web do not conform to any particular official specification of HTML. Stricter forms of HTML, and especially the introduction of XHTML, attempt to impose a more rigid syntax, encourage logical markup, and leave presentational duties to other technologies such as Cascading Style Sheets. While very widespread, use of strict markup has yet to occur on the Web. Web developers should aim to meet standards to future-proof their documents and more easily address all the various issues that will certainly arise in getting browsers to render them properly. 2 Introducing HTML5 The HTML5 specification not only embraces the past, by supporting traditional HTML- and XHTML-style syntax, but also adds a wide range of new features. Although HTML5 moves forward from HTML 4, it also is somewhat of a retreat and an admission that trying to get every Web developer on the Internet to write their markup properly is a futile effort, particularly because few Web developers are actually formally trained in the technology. HTML5 tries to bring order to chaos by codifying common practices, embracing what is already implemented in browsers, and documenting how these user agents (browsers or other programs that consume Web pages) should deal with our imperfect markup. HTML5’s goals are grand. The specification is sprawling and often misunderstood. Given the confusion, the goals of this chapter are not only to summarize what is new about HTML5 and provide a roadmap to the element reference that follows, but to also expose some of the myths and misconceptions about this exciting new approach to markup. NOTE Perhaps just to be new, HTML5 omits the space found commonly between (X)HTML and its version number, as in HTML 4 or XHTML 1. We follow this style generally in the book, but note even the specification has not been stringent on this point. Hello HTML5 The syntax of HTML5 should be mostly familiar. As shown in the previous chapter, a simple HTML5 document looks like this: <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Hello HTML5 World</title> </head> <body> <h1>Hello HTML5</h1> <p>Welcome to the future of markup!</p> </body> </html> 55 CHAPTER 58 P a r t I : C o r e M a r k u p NOTE Given the currently fluid nature of HTML5, developers are warned that, at least for now, HTML5 conformance may be a bit of a moving target. If you are wondering what mode the browser enters into because of the divergent <!DOCTYPE> used by HTML5, apparently it is the more standards-oriented mode: Employing the more standards-oriented parsing mode might seem appropriate, but it is somewhat odd given the point of the next section. Loose Syntax Returns An interesting aspect of HTML5 is the degree of syntax variability that it allows. Unlike its stricter markup cousin, XHTML, the traditional looseness of HTML is allowed. To demonstrate, in the following example, quotes are not always employed, major elements like html, head, and body are simply not included, the inference of close of tags like </p> and </li> is allowed, case is used variably, and even XML-style self-identifying close syntax is used at will: <!DOCTYPE html> <!-- I have no html, head, or body as they are actually optional --> <meta http-equiv=Content-Type content="text/html; charset=utf-8"> <title>HTML5 Tag Soup Test</title> <h1 title="more sloppy markup ahead!">HTML5</H1> <p id=p1>Back to the future of loose markup!? <p>Yes it looks that way <ul> <li>optional elements <LI>case is no problem <li id=noquotes>quotes optional in many cases <li>inferred close tags </UL> <p>Oh my <br> <br /> <p>Intermixing markup styles! <!-- ok that's enough let's stop now --> ONLINE http://htmlref.com/ch2/loosesyntax.html C h a p t e r 2 : I n t r o d u c i n g H T M L 5 59 PART I This example, at least currently, conforms to the HTML5 specification: Do not interpret the previous example to mean that HTML5 allows a markup free-for-all. Understand that these “mistakes” are actually allowed under traditional HTML and thus are allowed under HTML5. To ensure that you conform to the HTML5 specification, you should be concerned primarily about the following: • Make sure to nest elements, not cross them; so <b><i>is in error as tags cross</b></i> whereas <b><i>is not since tags nest</i></b>. • Quote attribute values when they are not ordinal values, particularly if they contain special characters, particularly spaces; so <p id=p1>Fine with no quotes</p> because it is a simple attribute value, whereas <p title=trouble here with no quotes>Not ok without quotes</p> is clearly messed up. • Understand and follow the content model. Just because one browser may let you use a list item anywhere you like, <li>I should be in a list!</li> it isn’t correct. Elements must respect their content model, so the example should read instead as <ul><li>All is well I am in a list!</li></ul> because it follows HTML5’s content model. 60 P a r t I : C o r e M a r k u p • Do not use invented tags unless they are included via some other markup language: <p>I <danger>shouldn't</danger> conform unless I am defined in another specification and use a name space</p> • Encode special characters, particularly those used in tags (< >), either as an entity of a named form, such as &lt;, or as a numeric value, such as &#60;. Appendix A covers this topic in some depth. This brief list of what you should do might seem familiar; it is pretty much the list of recommendations for correct markup from the previous chapter returned to the traditional markup styles of HTML. What this means is that if you have been writing markup correctly in the past, HTML5 isn’t going to present much of a change. In fact, in many cases, just by changing a valid document’s doctype to the new simple HTML5 <!DOCTYPE html>, the result should be an HTML5–conforming document. XHTML5 For those with a heavy investment in a strict XHTML syntax worldview, HTML5 might seem like a slap in the face. However, such a reaction is a bit premature; HTML5 neither makes the clean markup you write non-conforming nor suggests that you shouldn’t author markup this way. If you want to pursue an “XMLish” approach to your document, HTML5 allows it. Consider, for example, a strict XHTML example that is now HTML5: <?xml version="1.0" encoding="UTF-8"?> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Hello XHTML5 World</title> <!-- Simple hello world in XHTML5 --> </head> <body> <h1>Welcome to the World of XHTML5</h1> <hr /> <p>XHTML5 <em>really</em> isn't so hard either!</p> <p>HTML5 likes XML syntax too.</p> <p>Make sure to serve it with the correct MIME type!</p> <!-- IE users you will get a render error. Please read on to learn why. --> </body> </html> ONLINE http://htmlref.com/ch2/xhtml5helloworld.xhtml NOTE When using XML syntax with HTML5 according to HTML5 specification, this should be termed XHTML5. C h a p t e r 2 : I n t r o d u c i n g H T M L 5 63 PART I will likely produce the most good, because obtaining consensus among browser vendors to handle markup problems in a consistent manner is a more likely path to an improved Web than defining some strict syntax and then attempting to educate document authors around the world en masse to write good markup. HTML5’s aim to bring order to the chaos of sloppy markup is but one of the grand aims of the specification. It also aims to replace traditional HTML, XHTML, and DOM specifications, and to do so in a backward-compatible fashion. In its attempt to do this, the specification is sprawling, addressing not just what elements exist but how they are used and scripted. HTML5 embraces the fact that the Web not only is composed of documents but also supports applications, thus markup must acknowledge and facilitate the building of such applications. More of the philosophy of HTML5 will be discussed later in the chapter when addressing some strong opinions, myths, and misconceptions surrounding the specification; for now, take a look at what markup features HTML5 actually changes. Presentational Markup Removed and Redefined HTML5 removes a number of elements and attributes. Many of the elements are removed because they are more presentational than semantic. Table 2-1 presents the elements currently scheduled for removal from HTML5. NOTE Although these elements are removed from the specification and should be avoided in favor of CSS, they likely will continue to be supported by browsers for some time to come. The specification even acknowledges this fact. Looking at Table 2-1, you might notice that some elements that apparently should be eliminated somehow live on. For example, <small> continues to be allowed, but <big> is obsolete. The idea here is to preserve elements but shift meaning. For example, <small> is no longer intended to correspond to text that is just reduced in size, similar to <font size="-1"> or <span style="font-size: smaller;">, but instead is intended to represent the use of small text, such as appears in fine print or legal information. If you think this decision seems a bit preposterous, join the crowd. Some of the other changes to element meaning seem even a bit more preposterous, such as the claim that a <b> tag now represents inline text that is stylistically offset from standard text, typically using a different Removed HTML Element CSS Equivalent <basefont> body {font-family: family; font-size: size;} <big> font-size: larger <center> text-align: center or margin: auto depending on context <font> font-family, font-size, or font <s>, <strike> text-decoration: strike <tt> font-family: monospace <u> text-decoration: underline TABLE 2-1 HTML 4 Elements Removed from HTML5 64 P a r t I : C o r e M a r k u p type treatment. So apparently <b> tags are not necessarily bold, but rather convey some sense that the text is “different” (which likely means bold). Unlikely to be thought of in such a manner by mere markup mortals, we simply say <b> tags live on, as do a number of other presentational elements. Table 2-2 presents the meaning-changed elements that stay put in HTML5 and their new meaning. The meaning of some of these items might not be immediately clear, but don’t worry about that now, because each will be demonstrated later in the chapter and a full reference presented in Chapter 3. Like the strict variants of (X)HTML, HTML5 also removes numerous presentation- focused attributes. Table 2-3 summarizes these values and presents CSS alternatives. Out with the Old Elements A few elements are removed from the HTML5 specification simply because they are archaic, misunderstood, have usability concerns, or have a function that is equivalent to the function of other elements. Table 2-4 summarizes some of the elements that have been removed from the HTML5 specification. NOTE While frames are mostly removed from HTML5, inline frames live on. See the section “The Uncertain Future of Frames,” later in the chapter, for more information. Table 2-4 is not a complete list of non-conforming elements, just the ones that are supported by recent HTML 4 and XHTML 1.x specifications. Discussing the fact that ancient tags like <listing> and <plaintext> continue not to be supported or that all the presentational tags HTML Element New Meaning in HTML5 <b> Represents an inline run of text that is different stylistically from normal text, typically by being bold, but conveys no other meaning of importance. <dd> Used with HTML5’s new details and figure elements to define the contained text. Was also used with a dialog element which was later removed from the HTML5 specification. <dt> Used with HTML5’s new details and figure element to summarize the details. Was also used with a dialog element which was later removed from the HTML5 specification. <hr> Represents a thematic break rather than a horizontal rule, though that is the likely representation. <i> Represents an inline run of text in an alternative voice or tone that is supposed to be different from standard text but that is generally presented in italic type. <menu> Redefined to represent user interface menus, including context menus. <small> Represents small print, as in comments or legal fine print. <strong> Represents importance rather than strong emphasis. TABLE 2-2 HTML 4 Elements Redefined in HTML5 C h a p t e r 2 : I n t r o d u c i n g H T M L 5 65 PART I Attribute Removed Elements Effected CSS Equivalent align caption, col, colgroup, div, iframe, h1, h2, h3, h4, h5, h6, hr, img, input, legend, object, p, table, tbody, td, tfoot, th, thead, tr text-align or in some block element cases float alink body body a:active {color: color- value;} background body background-image or background bgcolor body, table, td, th, tr background-color border img, object, table border-width and/or border cellpadding table padding cellspacing table margin char col, colgroup, table, tbody, td, tfoot, th, thead, tr N/A charoff col, colgroup, table, tbody, td, tfoot, th, thead, tr N/A clear br clear compact dl, menu, ol, ul margin properties frame table border properties frameborder iframe border properties height td, th height hspace img, object margin properties link body body a:link {color: color- value;} marginheight iframe margin properties marginwidth iframe margin properties noshade hr border-style or border nowrap td, th overflow rules table border properties scrolling iframe overflow size hr width text body body {color: color-value;} type li, ol, ul list-style-type and list-style valign col, colgroup, tbody, td, tfoot, th, thead vertical-align vlink body body a:visited {color: color- value;} width col, colgroup, hr, pre, table, td, th width TABLE 2-3 HTML 4 Attributes Removed in HTML5 68 P a r t I : C o r e M a r k u p New Attribute Description accesskey Defines the accelerator key to be used for keyboard access to an element. contenteditable When set to true, the browser should allow the user to edit the content of the element. Does not specify how the changed content is saved. contextmenu Defines the DOM id of the menu element to serve as a context menu for the element the attribute is defined on. data-X Specifies user-defined metadata that may be put on tags without concern of collision with current or future attributes. Use of this type of attribute avoids the common method of creating custom attributes or overloading the class attribute. draggable When specified, should allow the element and its content to be dragged. hidden Under HTML5, all elements may have hidden attribute which when placed indicates the element is not relevant and should not be rendered. This attribute is similar to the idea of using the CSS display property set to a value of none. itemid Sets a global identifier for a microdata item. This is an optional attribute, but if it is used, it must be placed in an element that sets both the itemscope and itemtype attributes. The value must be in the form of a URL. itemprop Adds a name/value pair to an item of microdata. Any child of a tag with an itemscope attribute can have an itemprop attribute set in order to add a property to that item. itemref Specifies a list of space-separated elements to traverse in order to find additional name/value pairs for a microdata item. By default, an item only searches the children of the element that contains the itemscope attribute. However, sometimes it does not make sense to have a single parent item if the data is intermingled. In this case, the itemref attribute can be set to indicate additional elements to search. The attribute is optional, but if it is used, it must be placed in an element that sets the itemscope attribute. itemscope Sets an element as an item of microdata (see “Microdata” later in the chapter). itemtype Defines a global type for a microdata item. This is an optional attribute, but if it is used, it must be placed in an element that sets the itemscope attribute. The value must be in the form of a URL. spellcheck Enables the spell checking of an element. The need for this attribute globally may not be clear until you consider that all elements may be editable at page view time with the contenteditable attribute. tabindex Defines the element-traversal order when the keyboard is used for navigation. TABLE 2-6 Key Attributes Added by HTML5 C h a p t e r 2 : I n t r o d u c i n g H T M L 5 69 PART I HTML5 Document Structure Changes As you have seen, the HTML5 document structure seems pretty much the same as in HTML 4 save a slightly different <!DOCTYPE> statement. However, if you look closer, there are a few important differences in HTML5 that show the document structure has in fact been expanded quite a bit. HTML5 documents may contain a header element, which is used to set the header section of a document and thus often contains the standard h1 to h6 heading elements: <header> <h1>Welcome to the Future World of HTML5.</h1> <h2>Don't be scared it isn't that hard!</h2> </header> Similarly, a footer element is provided for document authors to define the footer content of a document, which often contains navigation, legal, and contact information: <footer> <p>Content of this example is not under copyright</p> </footer> The actual content to be placed in a <footer> tag is, of course, up to you and may be enclosed in div, p, or other block elements, as illustrated by this simple example: <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>HTML5 header and footer example</title> </head> <body> <header> <h1>Welcome to the Future World of HTML5.</h1> <h2>Don't be scared it isn't that hard!</h2> </header> <p>Some body content here.</p> <p>Some more body content here.</p> <footer> <p>Content of this example is not under copyright.</p> </footer> </body> </html> ONLINE http://htmlref.com/ch2/headerfooter.html The HTML5 structural element with the most possible uses is the section element. A particular <section> tag can be used to group arbitrary content together and may contain further <section> tags to create the idea of subsections. Traditionally, we are familiar with sections; just as this book is broken into chapters and various main and secondary sections, 70 P a r t I : C o r e M a r k u p so too could a Web document be structured in this way. The example here illustrates the basic use of HTML5 sections: <section> <h1>Chapter 2</h1> <p>New HTML5 elements.</p> <section> <h2>HTML5's section Element</h2> <p>These elements are useful to create outlines.</p> <section> <h3>Nest Away!</h3> <p>Nest your sections but as you nest you might want to indent.</p> </section> </section> <p>Ok that's enough of that.</p> </section> ONLINE http://htmlref.com/ch2/section.html It may not be obvious but a section element may contain header and footer elements of its own: <section> <header> <h1>I am Section Heading</h1> </header> <h2>I am outside the section header I'm just a plain headline.</h2> <p>Some more section content might go here.</p> <footer> <p>Hi from the footer of this section.</p> </footer> </section> HTML5 uses headings and newly introduced elements like the section element for outlining purposes. For example, the expanded example here shows a number of sections with headers, footers, headlines, and content: <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>HTML5 expanded section example</title> </head> <body> <header> <h1>Welcome to the Future World of HTML5</h1> <h2>Don't be scared it isn't that hard!</h2> </header> C h a p t e r 2 : I n t r o d u c i n g H T M L 5 73 PART I A complete example to explore can be found online, though you may find that a browser does not do anything of interest and that you need an outline simulator to see the difference between using <hgroup> tags or not. ONLINE http://htmlref.com/ch2/hgroup.html Given these semantics, it is clear that HTML5 sectioning elements are not just a formalization of <div> tags with appropriate class values. For example, you might consider <div class="header"> <!-- header here --> </div> <div class="section"> <div class="header"> <h2>Section Heading</h2> </div> <p>Content of section.</p> </div> <div class="footer"> <!-- footer here --> </div> to be roughly the same as the previously introduced elements. To some degree this is true, but clearly the names of the class values aren’t defined by a standard nor is any outlining algorithm defined. Beyond sectioning, HTML5 introduces a number of other structural elements. For example, the article element is used to define a discrete unit of content such as a blog post, comment, article, and so on. For example, the following defines a few individual blog posts in a document: <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>HTML5 article example</title> </head> <body> <header> <hgroup> <h1>Welcome to the Future World of HTML5 Blog</h1> <h2>Don't be scared it isn't that hard!</h2> </hgroup> </header> <section id="articleList"> <h2>Latest Posts</h2> <article id="article3"> <h2>HTML5 Here Today!</h2> <p>Article content here...</p> </article> 74 P a r t I : C o r e M a r k u p <article id="article2"> <h2>HTML5 Widely Misunderstood</h2> <p>Article content here...</p> </article> <article id="article1"> <h2>Discovering the article element</h2> <p>Article content here...</p> </article> </section> <footer> <p>This fake blog example is not real.</p> </footer> </body> </html> ONLINE http://htmlref.com/ch2/article.html The idea of defining these discrete content units specially is that you might wish to extract them automatically, so again, having defined elements as opposed to some ad hoc use of class names on <div> tags is preferred. NOTE Under early HTML5 drafts, the article element provided for cite and pubdate attributes, which may make the usage of the content more meaningful by outside sites; however, these were later dropped and use of <time> tags was encouraged. HTML5 also introduces an aside element, which may be used within content to represent material that is tangential or, as the element name suggests, an aside: <p>Here we explore the various HTML5 elements. I would write some real content here but you are busy reading the book anyway. </p> <aside> <h2>Pointless Aside</h2> <p>Oh by the way did you know that the author lives in San Diego? It is completely irrelevant to the discussion but he seems to like the weather there as opposed to rainy New Zealand.</p> </aside> <p>So as we continue to discuss the various HTML5 elements we must remember to stay focused as there is much to learn. </p> ONLINE http://htmlref.com/ch2/aside.html C h a p t e r 2 : I n t r o d u c i n g H T M L 5 75 PART I You may have noted that an <h2> tag was used in the aside. While not required, it is useful as a reminder to readers that aside elements serve as outline sectioning elements, as shown here: NOTE If a heading is not provided in an aside, you may see an outline mechanism add “Untitled Section” or potentially even make up one based upon the start of the element content. Adding Semantics Many of the elements that HTML5 adds that can be used right away are semantic in nature. In this sense, HTML5 continues the appropriate goal of separating structure from style. In this section, you will see a number of repurposed elements as well as some that are all new. At first you won’t see much value in using them other than to add semantics, but toward the end of the chapter we will explore how to make the elements understandable to most modern browsers and how to apply some simple styling for end users. Marking Text The new HTML5 element mark was introduced for highlighting content similarly to how a highlighter pen might be used on important text in a book. The following example wraps a few important words: <p>Here comes <mark>marked text</mark> was it obvious?</p> Unfortunately, you won’t necessarily see anything with such an example: You would need to apply a style. Here, inline styles are used just to show the idea: <p>The new HTML5 specification is in the works. While <mark style="background-color: red;">many features are not currently implemented or even well defined</mark> yet, <mark style="background-color: green;">progress is being made</mark>. Stay tuned to see more new HTML elements added to your Web documents in the years to come.</p> ONLINE http://htmlref.com/ch2/mark.html 78 P a r t I : C o r e M a r k u p HTML5’s Open Media Effort An interesting aspect of HTML5 that is reminiscent of the previous efforts of Netscape and Microsoft is the support for tag-based multimedia in HTML documents. Traditionally, multimedia has been inserted with the embed and object elements, particularly when inserting Adobe Flash, Apple QuickTime, Windows Media, and other formats. However, there was a time when tags specifically to insert media were supported; interestingly, some of those features, such as the dynsrc attribute for <img> tags, lived on until just recently. HTML5 brings this concept of tag-based multimedia back. <video> To insert video, use a <video> tag and set its src attribute to a local or remote URL containing a playable movie. You should also display playblack controls by including the controls attribute, as well as set the dimensions of the movie to its natural size. This simple demo shows the use of the new element: <video src="http://htmlref.com/ch2/html_5.mp4" width="640" height="360" controls> <strong>HTML5 video element not supported</strong> </video> C h a p t e r 2 : I n t r o d u c i n g H T M L 5 79 PART I NOTE If you are using XHTML5, given that controls is an occurrence style attribute, use controls="controls" to be conforming. You should note the included content in the tag that nonsupporting browsers fall back to. The following shows Internet Explorer displaying the alternative content: However, even if a browser supports the video element, it might still have problems displaying the video. For example, Firefox 3.5 won’t load this particular media format directly: HTML5 open video has, as it currently stands, brought back the madness of media codec support that Flash solved, albeit in a less than stellar way. To address the media support problem, you need to add in alternative formats to use by including a number of <source> tags: <video width="640" height="360" controls poster="loading.png"> <source src="html_5.mp4" type="video/mp4"> <source src="html_5.ogv" type="video/ogg"> <strong>HTML5 video element not supported</strong> </video> 80 P a r t I : C o r e M a r k u p Also note in the preceding snippet the use of the poster attribute, which is set to display an image in place of the linked object in case it takes a few moments to load. Other video element– specific attributes like autobuffer can be used to advise the browser to download media content in the background to improve playback, and autoplay, which when set, will start the media as soon as it can. A complete example of the video element in action is shown here: <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>HTML5 video example</title> </head> <body> <h1>Simple Video Examples</h1> <video src="http://htmlref.com/ch2/html_5.mp4" width="640" height="360" controls> <strong>HTML5 video element not supported</strong> </video> <br><br><br> <video width="640" height="360" controls poster="loading.png"> <source src="http://htmlref.com/ch2/html_5.mp4" type="video/mp4"> <source src="http://htmlref.com/ch2/html_5.ogv" type="video/ogg"> <strong>HTML5 video element not supported</strong> </video> </body> </html> ONLINE http://htmlref.com/ch2/video.html The reference section in Chapter 3 shows the complete list of attributes for the video element supported as of late 2009. Be warned, though, that if the various media markup efforts of the late 1990s repeat themselves, it is quite likely that there will be an explosion of attributes, many of which may be specific to a particular browser or media format. <audio> HTML5’s audio element is quite similar to the video element. The element should support common sound formats such as WAV files: <audio src="http://htmlref.com/ch2/music.wav"></audio> In this manner, the audio element looks pretty much the same as Internet Explorer’s proprietary bgsound element. Having the fallback content rely on that proprietary tag might not be a bad idea: <audio> <bgsound src="http://htmlref.com/ch2/music.wav"> </audio>