-
Notifications
You must be signed in to change notification settings - Fork 8
/
Copy pathindex.html
688 lines (639 loc) · 30.3 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
<!DOCTYPE html>
<!--[if IE 7 ]> <html lang="en" class="no-js ie7"> <![endif]-->
<!--[if IE 8 ]> <html lang="en" class="no-js ie8"> <![endif]-->
<!--[if IE 9 ]> <html lang="en" class="no-js ie9"> <![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--> <html lang="en" class="no-js non-ie"> <!--<![endif]-->
<head>
<link href="css/main.css" media="screen" rel="stylesheet" />
<meta charset="utf-8" />
<meta content="" name="keywords"/>
<meta content="" name="description"/>
<title>Interactive Development Best Practices</title>
<link rel="icon" href="/favicon.ico" type="image/x-icon" />
<script src="js/modernizr.js"></script>
<script src="js/curl.js"></script>
<script>
define.amd.jQuery = true;
curl(
{
baseUrl: "js",
paths: {
"jquery" : "http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min"
}
},
[
"jquery",
"jquery.easing.1.3",
"domReady!",
"rainbow",
"main"
]
);
</script>
</head>
<body>
<div class="main-container">
<header>
<hgroup>
<h1>Interactive Development Best Practices</h1>
<h2><time datetime="20012-04-29">April 29, 2012</time></h2>
</hgroup>
<p>
Documenting best practices for interactive development is an exhaustive task, and is one that, if done effectively, would fill the pages of
several books. The purpose of this guide is not to provide an all-encompassing list of best practices, but to highlight many of the most
important components of a stable, high performance web page.
</p>
</header>
<nav>
<h1>Navigate This Document</h1>
<ul>
<li class="active">
<a class="top-level" href="#HTML" title="HTML">HTML</a>
<ul class="second-level">
<li><a href="#doctype" title="Doctype">Doctype</a></li>
<li>
<a href="#HTML5" title="HTML5">HTML5</a>
<ul>
<li><a href="#HTML5-shim" title="Making HTML5 Work">Making HTML5 Work</a></li>
<li><a href="#HTML5-friends" title="HTML5 and Friends">HTML5 and Friends</a></li>
</ul>
</li>
<li><a href="#XHTML-syntax" title="XHTML Syntax">XHTML Syntax</a></li>
<li><a href="#validation" title="HTML Validation">HTML Validation</a></li>
<li><a href="#deprecated" title="Avoid Deprecated Elements">Avoid Deprecated Elements</a></li>
<li>
<a href="#semantics" title="Semantics">Semantics</a>
<ul>
<li><a href="#document-outline" title="Document Outline">Document Outline</a></li>
<li><a href="#header-tags" title="Header Tags in HTML5 and XHTML">Header Tags in HTML5 and XHTML</a></li>
<li><a href="#tables-for-data" title="Use Tables for Tabular Data">Use Tables for Tabular Data</a></li>
<li><a href="#avoid-unnecessary-elements" title="Avoid Unnecessary Elements">Avoid Unnecessary Elements</a></li>
</ul>
</li>
<li><a href="#unnecessary-classes" title="Unnecessary Classes and IDs">Unnecessary Classes and IDs</a></li>
<li><a href="#image-tags" title="Image Tags">Image Tags</a></li>
<li><a href="#miscellaneous-guidelines" title="Miscellaneous Guidelines">Miscellaneous Guidelines</a></li>
</ul>
</li>
<li>
<a class="top-level" href="images.html" title="Images">Images</a>
<ul class="second-level">
<li><a href="#image-size" title="Image Size">Image Size</a></li>
<li><a href="#image-format" title="Image Formats">Image Formats</a></li>
<li><a href="#CSS-sprites" title="Leverage CSS Sprites">Leverage CSS Sprites</a></li>
</ul>
</li>
<li>
<a class="top-level" href="css.html" title="CSS">CSS</a>
<ul class="second-level">
<li><a href="#inline-styles" title="Inline Styles">Inline Styles</a></li>
<li><a href="#external-css" title="Place All CSS Within the <head>">Place All CSS Within the <code><head></code></a></li>
<li><a href="#combine-stylesheets" title="Combine CSS Files">Combine CSS Files</a></li>
<li><a href="#link-vs-import" title="Use <link> to Include CSS, Not @import">Use <code><link></code> to Include CSS, Not <code>@import</code></a></li>
<li><a href="#reset" title="Use a CSS Reset">Use a CSS Reset</a></li>
<li><a href="#font-sizes" title="Specifying Font Sizes">Specifying Font Sizes</a></li>
<li><a href="#writing-good-selectors" title="Writing Good Selectors">Writing Good Selectors</a></li>
<li><a href="#shorthand" title="Shorthand">Shorthand</a></li>
</ul>
</li>
<li>
<a class="top-level" href="javascript.html" title="JavaScript">JavaScript</a>
<ul class="second-level">
<li><a href="#use-external-js" title="Restrict JavaScript to External Files">Restrict JavaScript to External Files</a></li>
<li>
<a href="#place-external-js" title="Placement of External JavaScript Files">Placement of External JavaScript Files</a>
<ul>
<li><a href="#end-of-page" title="Include JavaScript near the end of the page">Include JavaScript near the end of the page</a></li>
<li><a href="#js-loader" title="Use a JavaScript loader">Use a JavaScript loader</a></li>
</ul>
</li>
<li><a href="#use-jquery" title="Use jQuery">Use jQuery</a></li>
<li><a href="#organize-code" title="Organize Your Code">Organize Your Code</a></li>
<li><a href="#general-js" title="General Coding Practices">General Coding Practices</a></li>
</ul>
</li>
<li>
<a class="top-level" href="about.html" title="About">About</a>
<ul class="second-level">
<li><a href="#summary" title="Purpose">Purpose</a></li>
<li><a href="#goals" title="Goals">Goals</a></li>
<li><a href="#contributors" title="Contributors">Contributors</a></li>
</ul>
</li>
</ul>
</nav>
<section id="HTML">
<h1>HTML</h1>
<ul class="recs">
<li>
<h2 id="doctype">Doctype</h2>
<p>
The doctype is how a browser makes sense of the HTML content of a page. Over the years, there have been many different doctypes. They are usually long and cumbersome:
</p>
<figure>
<figcaption class="code-label">XHTML transitional doctype</figcaption>
<pre><code data-language="html"><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> </code></pre>
</figure>
<p>
Here are some points to remember when dealing with doctypes:
</p>
<ul>
<li>
The doctype must be the first thing that a browser reads; this means that it should usually be present on line 1 of an HTML document
<ul>
<li>
<p>
If this is not the case, older versions of IE will go into quirks mode, which can cause many strange and difficult to troubleshoot issues
</p>
</li>
<li>
<p>
If a server-side language is rendering the page, code may show up above the doctype (as with a PHP page that does a server-side
include at the top of the page), as long as this code does not render anything in the final HTML output
</p>
</li>
</ul>
</li>
<li>
<p>
The doctype must be valid and well formed
</p>
</li>
</ul>
<p>
<strong>It is becoming a standard practice to use the HTML5 doctype, even if other HTML5 features aren't being used. It is simply:</strong>
</p>
<figure>
<figcaption class="code-label">HTML5 doctype</figcaption>
<pre><code data-language="html"><!DOCTYPE html> </code></pre>
</figure>
<p>
This doctype is easy to remember and is recognized by all modern browsers (including Internet Explorer 6). It is flexible in the sense that
both HTML and XHTML syntax is valid under this doctype, and it is also necessary to use this doctype for HTML5 features to work correctly.
</p>
</li>
<li>
<h2 id="HTML5">HTML5</h2>
<p>
HTML5 is <del>the new hotness</del> <del>a new</del> the lastest version of HTML and XHTML. The HTML5 draft specification defines a single language that can be written in HTML and XML.
It attempts to solve issues found in previous iterations of HTML and addresses the needs of Web Applications, an area previously not adequately
covered by HTML.
</p>
<h3 id="HTML5-shim">Making HTML5 Work</h3>
<p>
The new semantic elements available in HTML5 are helpful—they make markup more readable, both by humans and machines—but there's one major issue to fix before you can use them:
Internet Explorer (below version 9) won't display unrecognized elements correctly.
</p>
<p>
Luckily, if you create an unknown element with JavaScript, even without inserting it into the DOM, this problem
magically goes away. Many small JavaScript utilities exist that do this, among many other things.
<a href="http://www.modernizr.com/" target="_blank" title="Modernizr">Modernizr</a>, which uses <a href="https://github.com/aFarkas/html5shiv#readme" target="_blank" title="HTML5 Shiv">HTML5 Shiv</a>
under the hood, is the most popular example.
</p>
<p>
Mark Pilgrim of Dive Into HTML5 goes into
<a href="http://diveintohtml5.info/semantics.html#unknown-elements" target="_blank" title="Dive Into HTML5 on unknown elements">some detail about all of this here</a>.
</p>
<h3 id="HTML5-friends">HTML5 and Friends</h3>
<p>
When people talk about HTML5, they are usually referring to the 75 or so related features and specifications that make
up the "modern web" movement. A comprehensive list of these technologies (along with browser support and usage recommendations) can be found at
<a href="http://html5please.com/" target="_blank" title="HTML5 Please">html5please.com</a>.
</p>
<p>
While the adoption of new technologies is encouraged, the recommendation is to do what makes sense for your project. If your team wants to explore
the possibility of leveraging the <code><canvas></code> element (for example) to do some rich animations and interactions, that's awesome. Just make sure
of the following:
</p>
<dl>
<dt>Capability</dt>
<dd>
<p>
Don't agree to something that is totally beyond your skill set; creating a quick proof of concept to ensure that the solution is feasible can help
keep you from getting in over your head
</p>
</dd>
<dt>Flexibility of the experience</dt>
<dd>
<p>
Most clients require us to support browsers that don't yet handle HTML5 technologies; make sure that everyone knows that there will be a
baseline experience for these browsers, with additional functionality for those browsers that can handle it (this is called progressive enhancement)
</p>
</dd>
<dt>Collaboration</dt>
<dd>
<p>
Having different experiences for different browsers requires increased collaboration between the development team and the design team; make
sure that the creative and project leadership are aware of this fact
</p>
</dd>
<dt>Budget and Deadlines</dt>
<dd>
<p>
Increased technical complexity, multiple versions of one experience, and increased back-and-forth with designers all take time; ensure that
all of this is baked into your estimates regarding level of effort and confidence in meeting deadlines
</p>
</dd>
</dl>
</li>
<li>
<h2 id="XHTML-syntax">XHTML Syntax</h2>
<p>
Generally speaking, it is a good idea for your markup to conform to the XHTML syntax rules. This is obviously necessary when using an XHTML
doctype (syntax errors will cause your page to fail validation, and can cause rendering issues). It is wise to use the XHTML syntax even when
using the HTML5 doctype mentioned above, for a number of reasons. Markup conforming to XHTML syntax rules is:
</p>
<ul>
<li>
<p>
highly readable
</p>
</li>
<li>
<p>
flexible and stable—HTML5 allows XHTML syntax, but XHTML does not allow HTML syntax; this means that the doctype can be changed between
the two types without worry of causing syntax-related issues
</p>
</li>
<li>
<p>
familiar—both to interactive developers and to back-end developers who are used to working with XML
</p>
</li>
</ul>
<p>
So what are these rules?
</p>
<ul>
<li>
<p>
Make all your tags lower case (<code><p></code> instead of <code></P></code>)
</p>
</li>
<li>
<p>
Close all your tags, even empty ones (<code><br /></code> and <code><hr /></code> instead of <code><br></code> and <code><hr></code>)
</p>
</li>
<li>
<p>
Make all attribute names lower case and quote all attribute values; for example, <code><td colspan="2"></code> instead of <code><TD COLSPAN=2></code>
</p>
</li>
<li>
<p>
Give empty attributes a value, such as <code><input type="checkbox" checked="checked" /></code> instead of <code><INPUT TYPE=checkbox CHECKED></code>
</p>
</li>
<li>
<p>
Nest all your tags correctly
</p>
</li>
</ul>
</li>
<li>
<h2 id="validation">HTML Validation</h2>
<p>
Validating the correctness of your HTML markup can be one of the easiest ways of finding otherwise difficult to explain issues. Validation can identify
errors that, if left uncorrected, can have negative impacts on page performance, accessibility, and search engine optimization. The W3C validator can
be found <a href="http://validator.w3.org/" target="_blank" title="W3C Validator">here</a>.
</p>
</li>
<li>
<h2 id="deprecated">Avoid Deprecated Elements</h2>
<p>
This is related to the note on validation, above, as including deprecated elements in your markup can potentially cause validation errors.
</p>
<p>
Many elements are no longer part of the HTML specification and should be avoided (this text is taken directly from the specification).
</p>
<p>
The following elements are not in HTML5 because their effect is purely presentational and their function is better handled by CSS:
</p>
<ul>
<li>
<p>
<code><font></code>
</p>
</li>
<li>
<p>
<code><basefont></code>
</p>
</li>
<li>
<p>
<code><big></code>
</p>
</li>
<li>
<p>
<code><center></code>
</p>
</li>
<li>
<p>
<code><strike></code>
</p>
</li>
<li>
<p>
<code><tt></code>
</p>
</li>
<li>
<p>
<code><u></code>
</p>
</li>
</ul>
<p>
The following elements are not in HTML5 because using them damages usability and accessibility:
</p>
<ul>
<li>
<p>
<code><frame></code>
</p>
</li>
<li>
<p>
<code><frameset></code>
</p>
</li>
<li>
<p>
<code><noframes></code>
</p>
</li>
</ul>
<p>
The following elements are not included because they have not been used often, created confusion, or their function can be handled by
other elements:
</p>
<ul>
<li>
<p>
<code><acronym></code> is not included because it has created a lot of confusion. Authors are to use <code>abbr</code> for abbreviations
</p>
</li>
<li>
<p>
<code><applet></code> has been made obsolete in favor of <code><object></code>
</p>
</li>
<li>
<p>
<code><isindex></code> usage can be replaced by usage of form controls
</p>
</li>
<li>
<p>
<code><dir></code> has been made obsolete in favor of <code><ul></code>
</p>
</li>
<li>
<p>
Finally the <code><noscript></code> element is only conforming in the HTML syntax. It is not included in the XML syntax
as its usage relies on an HTML parser (so don't include it if you're using an XHTML doctype)
</p>
</li>
</ul>
</li>
<li>
<h2 id="semantics">Semantics</h2>
<h3 id="document-outline">Document Outline</h3>
<p>
It is important that your HTML document be well organized and contain elements that follow a formal structure. This makes it readable
both to humans who aren't necessarily seeing the visual experience of the page (such as a blind user who is using a screen reader),
and to the machines that read every page on the internet (like the bots employed by Google to determine search results).
</p>
<h4 id="header-tags">Header Tags in HTML5 and XHTML</h4>
<p>
Regardless of the doctype being used, one of the best ways to make sure that your document has a correct outline is to properly use header tags.
</p>
<p>
The <code><h1></code> tag is the most important of the semantic tags, and its contents are weighted heavily by search bots when
determining page relevance.
</p>
<p>
In XHTML, there can be only one <code><h1></code> tag on the page (often the company name/logo, or the title of an article for blogs).
Subsections are each headed by <code><h2></code> elements and may be subdivided further by using headings of the subsequent level
(all the way to <code><h6></code>). Heading levels should not be skipped.
</p>
<p>
When using an HTML5 document structure, you can check the outline of your document by using something like
<a href="http://code.google.com/p/h5o/downloads/detail?name=outliner.0.5.0.62.html&can=2&q=" target="_blank" title="HTML5 Outliner Bookmarklet">this HTML5 outliner bookmarklet</a>.
To use it, simply download the page and open it, then bookmark the link shown. When you click the bookmark, the outline of the page
you are visiting will be shown.
</p>
<p>
HTML5 introduces the concept of "sections" in documents, and each section can have an <code><h1></code> element, followed by the rest of the headers.
For a fantastic explanation of semantics in HTML5, and the header elements in particular, see
<a href="http://diveintohtml5.info/semantics.html#header-element" target="_blank" title="Header element discussed">this article by Mark Pilgrim</a> over at
<a href="http://diveintohtml5.info" target="_blank" title="diveintohtml5.info">diveintohtml5.info</a>.
</p>
<h3 id="tables-for-data">Use Tables for Tabular Data (Only)</h3>
<p>
For years, HTML tables had been used to visually lay out elements on a page. This was necessary at first, as there was no other way of creating
many common page layouts. The practice continued even after CSS made table-less layout possible because developers were used to tables, and
it can be difficult to get the hang of using CSS for complex layouts.
</p>
<p>
Using modern techniques, there are no layouts that can't be built by using CSS. Unless you need to display tabular data in rows and columns,
<strong>tables should not be used</strong>. This is for a number of reasons:
</p>
<ul>
<li>
<p>
Tables are not good for accessibility; in order to describe a set of tabular data, screen readers have to wade through numerous
bodies, rows, headers, and cells; imagine listening to a screen reader saying "table cell" over and over again when you're just
trying to read the content of a page
</p>
</li>
<li>
<p>
All of the aforementioned elements can take a toll on a webpage; Excess markup can hurt a page's search engine ranking (which is best
expressed as relevant content vs. page weight), JavaScript performance, page download time, and page render time
</p>
</li>
<li>
<p>
Tables negatively impact page render time beyond simply adding markup to be parsed; because table width is dictated by a sum of column widths,
and column widths can be influenced by the width of all contained elements, tables must go through multiple render cycles before the browser can
move on to the rest of the document
</p>
</li>
</ul>
<h3 id="avoid-unnecessary-elements">Avoid Unnecessary Elements</h3>
<p>
<code><div></code> tags are useful block level elements for organizing sections of code (especially when something like a <code><section></code>
or <code><article></code> wouldn't really make sense), but too often developers moving away from table-based layout think that divs do something more
than that–they don't.
</p>
<p>
If your markup has divs within divs within divs, take a step back and ask yourself what you're really trying to accomplish with these elements. There may
be a more semantically appropriate way to meet your needs.
</p>
<p>
Back in 2009, Smashing Magazine (which is a great resource for all aspects of web design and development)
<a href="http://www.smashingmagazine.com/2009/04/08/from-table-hell-to-div-hell/" target="_blank" title="Smashing Magazine">posted an article</a>
that dives deeply into the topic of "divitis".
</p>
<p>
More generally speaking, keeping the number of elements on a page to a minimum is a good practice for optimizing the page's performance.
Read about this in <a href="http://developer.yahoo.com/performance/rules.html#min_dom" target="_blank" title="Yahoo! developer docs">Yahoo!'s developer documentation</a>.
</p>
</li>
<li>
<h2 id="unnecessary-classes">Unnecessary Classes and IDs</h2>
<p>
It is sometimes tempting to add <code>class</code> attributes to any element that needs to be styled. When taken to the extreme, each element ends up with its own <code>class</code>.
This can not only make the source of the page difficult to read, but all of those extra characters need to be downloaded by the browser, resulting in slower page loads.
</p>
<p>
As a best practice, wait to assign a <code>class</code> or <code>id</code> to an element until you know that you need it. This isn't to say not to use them at all, of course.
Appropriate usage of classes is fundamental to writing modular CSS, and the CSS parser has an easier time applying rules to class-based ancestral
selectors than to generic tag names. So don't be stingy with classes when it makes sense to use them.
</p>
<p>
A case can be made for avoiding the use of <code>id</code> attributes altogether, since they are difficult to override in the cascade.
See <a href="css.html#writing-good-selectors" title="Writing good selectors">writing good selectors</a> for more information.
</p>
</li>
<li>
<h2 id="image-tags">Image Tags</h2>
<p>
When using image tags, always specify <code>alt</code>, <code>height</code>, and <code>width</code> values. <code>alt</code> is required for accessibility,
and specifying <code>height</code> and <code>width</code> attributes improves page performance.
</p>
<p>
The reason for the latter is that a browser, when it encounters an <code><image></code> tag, will initiate the download of the image, and then
move on to the next element in the HTML page. If the <code>height</code> and <code>width</code> attributes were specified in the HTML, the browser
knows what size placeholder to put in for the image as it is downloading and doesn't have to look back.
</p>
<p>
If <code>height</code> and <code>width</code> are not specified in the markup, the browser has to wait until the image finishes downloading, then go
back to check its dimensions, and adjust the layout of the entire page accordingly (this causes what are known as reflow and repaint cycles, which
are costly in terms of page performance).
</p>
<p>
Lastly, never use spacer images. If you know what spacer images are, then you should enough by now not to use them.
</p>
</li>
<li>
<h2 id="miscellaneous-guidelines">Miscellaneous Guidelines</h2>
<ul>
<li>
<p>
All markup should be delivered as UTF-8, as its the most friendly for internationalization. It should be designated in both the HTTP header
and the head of the document.
</p>
<figure>
<figcaption class="code-label">Setting the character set using a <code><meta></code> tag</figcaption>
<pre><code data-language="html"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> </code></pre>
</figure>
<figure>
<figcaption class="code-label">In HTML5, this became simpler</figcaption>
<pre><code data-language="html"><meta charset="utf-8"> </code></pre>
</figure>
</li>
<li>
<p>
Make use of <code><dl></code> (description list) and <code><blockquote></code> elements, when appropriate.
</p>
</li>
<li>
<p>
Items in list form should always be contained within a <code><ul></code>, <code><ol></code>, or <code><dl></code>, never a
set of <code><div></code> or <code><p></code> elements.
</p>
</li>
<li>
<p>
Use <code><label></code> elements to label each form field. The <code>for</code> attribute of the <code><label></code> should match
the ID of the associated input field, so that users can click on labels to bring focus to text inputs, toggle checkboxes, etc; You should also
set the <code>cursor</code> CSS property of the label to "<code>pointer</code>", to give a visual cue that this interaction is possible
</p>
</li>
<li>
<p>
Do not use the <code>size</code> attribute on input fields. The <code>size</code> attribute is relative to the font-size of the text inside the input; Instead use the CSS
<code>width</code> property; It is often best to use CSS <code>width</code> and <code>height</code> for <code><textarea></code> elements, as well,
since it can be difficult to match the dimensions of the design while using the <code>cols</code> and <code>rows</code> attributes
</p>
</li>
<li>
<p>
Place an html comment on some closing <code><div></code> tags to indicate which element you're closing. This helps with readability when
there are a lot of nested elements
</p>
<figure>
<figcaption class="code-label">Example of commented closing tags</figcaption>
<pre><code data-language="html"> ...
<ul>
<li><a href="/terms.html">Terms & Conditions</a></li>
<li><a href="/privacy.html">Privacy Policy</a></li>
<li><a href="/contact.html">Contact Us</a></li>
</ul>
</div> <!-- class="content-module footer-module" -->
</div> <!-- id="footer" --> </code></pre>
</figure>
</li>
<li>
<p>
Use <a href="http://en.wikipedia.org/wiki/Microformat" target="_blank" title="Microformats">microformats</a> where appropriate, specifically <code>hCard</code>
and <code>adr</code>
</p>
</li>
<li>
<p>
Make use of <code><caption></code> <code><thead></code>, <code><tbody></code>, and <code><th></code> elements (and the
<code>scope</code> and <code>summary</code> attributes) when appropriate
</p>
<figure>
<figcaption class="code-label">Example table markup</figcaption>
<pre><code data-language="html"><table summary="Blenders available in store">
<caption>Blenders available in the store, by price and wattage</caption>
<thead>
<tr>
<th scope="col">Brand</th>
<th scope="col">Price</th>
<th scope="col">Wattage</th>
</tr>
</thead>
<tbody>
<tr>
<td scope="row">Vitamix</td>
<td>$399.95</td>
<td>1100</td>
</tr>
<tr>
<td scope="row">Cuisinart</td>
<td>$99.99</td>
<td>600</td>
</tr>
<tr>
<td scope="row">Black & Decker</td>
<td>$39.95</td>
<td>400</td>
</tr>
</tbody>
</table></code></pre>
</figure>
</li>
<li>
<p>
Always use title-case for headers and titles. Do not use all caps or all lowercase titles in markup, instead apply the CSS property
<code>text-transform:uppercase/lowercase</code>
</p>
</li>
</ul>
</li>
</ul>
</section>
</div>
</body>
</html>