HTML notes

14th March, 2013


Want to understand essentials of HTML & CSS, avoid significant mistakes which could affect users, but not waste time that could be spent programming or writing - but understand well enough not to have to worry about each thing for a while.


Use <!DOCTYPE html>. Modern browsers only care that you have a doctype, to avoid running in "quirks mode" (i.e. ancient-HTML-supporting-mode).

<!DOCTYPE html> is sufficient to trigger "standards mode" (i.e. indicate you are using semi-modern HTML). That is why it was chosen for HTML5, as HTML5 was designed to be simple and backward-compatible.

Stack Overflow references: 1, 2, 3, 4.

The HTML tag

<html lang="en" dir="ltr"> specifies language and text direction. Not widely used. Hard to tell how useful they are to non-english users, but can't hurt aside from the few bytes.


<meta charset="utf-8"> - apparently that thing is hard so just stick with this (even though is default anyway, avoid complication). Also, Google says so, and they know about that stuff.


  • files must be saved in UTF-8 encoding without BOM
  • web server must serve files in UTF-8 encoding


Closing tags

Is legal not to close html, head & body (and various others). But may as well close most tags because some browsers may have trouble and cause dev headaches, and besides it'd be unpleasantly unbalanced otherwise. Particularly note that not closing head can cause various issues particularly with javascript.

All that said, leaving off </body> and </html> seems harmless enough (ignoring issues of balance/symmetry).

References: Google style guide, HTML5 spec, Stack Overflow.

HTML 5 semantic tags

header, footer, nav etc.. Not yet used by browsers in any signficant way. Current main function appears to be for people who make the site. May be useful in a capacity similar to comments for developers. Possibly useful for javascripting. Dislike superflous indentation/code. These new semantic tags are wrapped in divs by HTML5 boilerplate. For this project, don't see much use. Do enjoy <section>.

Responsive design

Mobile is a big deal. Media queries seem to work well.

How it works: start with simple small screen design, then progressively add/override for larger screens using media queries. e.g.

thing { display: none; }  /* default hidden for mobile */
@media only screen and (min-width: 768px) {
#thing { display: block; } /* shown for medium screen */

Explanation of 'only screen'.


Mobile devices by default will usually have a viewport (i.e. virtual browser window) with a size of e.g. 980px. The page is then scaled/zoomed out, then the user browses by zooming in and panning around. This is equivalent to:

meta name="viewport" content="width=980"

A reponsive design aims to work with smaller resolutions, so we tell the browser not to do the virtual viewport & scaling thing with:

meta name="viewport" content="width=device-width, initial-scale=1"

Internal anchors

<a name="anchorname"> is depreciated in HTML5, but apparently some browsers (e.g. Safari on IPad) do not support id anchors. So may as well stick with the old way for time being, since it is still widely used and supported.

Alternate stylesheets

Want to offer users the ability to switch style. Browsers support alternate stylesheets like so:

link rel="stylesheet" type="text/css" title="blue" href="blue.css">
<link rel="alternate stylesheet" type="text/css" title="red" href="red.css">

How this works:

  • Stylesheets link'd without a title attribute are never changed.
  • Stylesheets with rel="stylesheet" will load by default.
  • Stylesheets with rel="alternate stylesheet" and a title attribute will not load by default.
  • The user can use the browser to switch between stylesheets, if their browser supports them (implementation vary e.g. menu:view->style).
  • Style switches do not persist across pages in a site. For that you need either Cookies or LocalStorage.


However, as alternate stylesheets are not widely known about, and for this site the only change I want is a few colours, a simpler implementation is to have a second sheet the attribute disabled="true" initially, and use javascript to change disabled as required.

IE Support

Life is too short to worry about anything other than show-stopping issues.


There are opportunities to shave off a few bytes here and there: omit some closing tags, dont surround attribute values with quotes, and so on. Although it'd be fun to have each page occupy the minimum number of bytes, the effort required, and reduction in user-friendliness (for both developers and users), makes it not worth a reduction of (probably) < 5%. Unless you are Google (discussion). Although it is tempting, given mobile, and people with poor internet connections. Worth revisiting.

Though of course this only becomes significant once all lower-hanging fruit have been picked. For this site, since it is so simple, is relevant as there are few (no?) other viable opportunities for speed-ups. Particularly relevant since unable to gzip.


Is funny, juggling conflicting goals, battling the instinct to optimize whichever goal is foremost in my mind:

  • Want to minimize the number of bytes per request.
  • Want to render well for everyone.
  • Don't want to spend time supporting non-compliant browsers.
  • Want good understanding of HTML and what browsers are doing.
  • Want to do things other than read about browser/HTML minutiae.

It never ends. Conclusion: Worse is Better. Probably. Mostly.