This is a document written using ReMarkable, a shorthand syntax for generating HTML.

{	"date"		:	200811131935,
	"updated"	:	200811131935,
	"licence"	:	"cc-by",
	"tags"		:	["code-is-art", "web-dev"]

# How to Learn HTML5 #

|	Hi Kroc,
|	I stumbled on your website today and was quite impressed with quite a few different things about it
|	(the design, the tone of your writing, {&c.|et cetera}).
|	The one thing in particular, and something I wanted to question you on, was your reference to HTML5.
|	Something I know nothing about. […] I’m really interested in using no IDs and/or classes,
|	but know nothing about HTML5.
|	So here’s my question, […] do you recommend any other resources or tutorials for someone like me?
|	I rely very heavily on classes and my stuff is sloppy for the most part.
|	I’d love to convert my site but have no idea where to start.
|	Any advice or words of wisdom would be _greatly_ appreciated. Thanks in advance.
| <Joe Holst (//>

*Hello Sir,* _
You only require one thing, and then to do three things in order to succeed in your goals here.

Firstly, you need to get some willpower. You already seem to have that, as you’ve taken interest to email me to ask about where to start. Without the want to write better code, no learning in the world can help!

It should be noted that absolutely nothing I’m doing is undocumented; in that fact none of the code on my website is even special—all it is, is the representation of my personal drive for quality, as I measure it.

I don’t think willpower is going to be a problem for you if you already twig that HTML5 and cleaner code is the direction you might want to go. Some people don’t ever progress beyond writing Internet Explorer-only junk, and that’s not down to skill level, it’s a willpower problem.
Secondly, you need to do three things:

#	revise,
#	revise,
#	revise.

I proof-read and break my code over and over again, to chip away what niggles me here and there. Getting rid of classes is a one-by-one process, because each class has a use that may be totally unrelated to the other classes in the document. Each class is its own problem, some big, some small—some requiring a complete rewrite even.

I’m quite happy to break my entire codebase for a week—rewriting and reorganising everything—just to get one tiny annoyance out of sight and out of mind.

If you proof read your codebase you’ll spot various things that could be better, all of varying difficulty levels, some maybe without a clear solution. Start by picking something that annoys you, that you know could be done better, and fix it… even if it’s just tidying up a comment so that it looks nicer. Polish your code.

That is how I work. I scan through my code and look at it objectively. I think about where I can make it cleaner, tidier, less complicated, better documented, easier for others to understand; anything that catches my eye.

I pick something that I personally feel motivated toward (I have no boss on my personal site, so I only have to fix what I care about; and in that, the quality, through passion, is maintained) and I set about fixing it. Sometimes that’s a big problem—like what I’m working on right now: a Markdown clone, so as to reduce the amount of HTML I’m writing for minor things like abbreviations, links and citations [<ReMarkable (/code/remarkable)>]—or sometimes it’s a small thing like shaving a few lines off here and there. I do whatever my heart feels capable of doing that day. I try never strain myself by doing work I’m not interested in—that’s for secular work.

Once I’ve made my fix, I go through the whole process again. Often whilst I’m implementing one fix it unearths other annoyances that I want to solve and I’ll either get distracted and go off and fix those or wait until I’ve finished the thing I started on and be well set with another task to do afterwards—with a much stronger understanding of the problem to drive me forward with the design issues.

O, the design issues. 

I am a slave to my code sometimes. I will not accept a sloppy solution. I pace around a lot. I wrestle with the architectural design of the code in my mind for days. I spend a hundred hours writing <29 lines of code (/code/asp-templating)>. Because to me, good code is not about how {l33t|leet} your programming knowledge is, good code is about how much you rethink what you’re trying to do. What cohesive statement are you trying to make with your code?

|	Sometimes your code is not just about trying to solve a problem,¬
|	it’s trying to solve a problem _using your personality_.
| Kroc Camen

But getting back to HTML5…

Before you learn HTML5, first learn HTML 4. I know that sounds stupid, you may very well think you already know HTML 4. In learning HTML5, I first referred to <this list (//>. Apart from the depreciated ones, do you know how to use all of them? I found that there were a number of HTML 4 tags that I rarely used, that could easily replace sloppy ``<div>``s and classes.

I see this often, and it really annoys me.

~~~ HTML ~~~>
<div id="header">

*Elements that are not ``<div>``s can be styled just the same as a ``<div>``. A ``<h1>`` is not somehow magically unable to have borders or backgrounds or margins or padding or anything a ``<div>`` can.*

People seem to get this mindset that only ``<div>``s can be used as boxes. _
Here’s a list of elements you can use instead of ``<div>``s.

``P``, ``BLOCKQUOTE`` (with ``P`` inside), ``H1``/``H2``/``H3``…, ``ADDRESS``, ``DL``/``DT``/``DD``, ``UL``/``OL``/``LI``, ``HR``

(((Note: You can’t put a block level element in another. {i.e.|that is,} you can’t have a ``H1`` inside a ``P`` or vice-versa)))

All of these can be styled with any effect—meaning that you can get rid of a ``<div>`` and/or class, by just referring to the element directly, or by it’s parent.
For example:

~~~ HTML ~~~>
<h1>Website Title</h1>
<ol id="menu">
	<li>menu 1</li>
	<li>menu 2</li>
<h2>Article title</h2>

Is better than

~~~ HTML ~~~>
<div id="title">Website Title</div>
<div id="menu">
	<div class="menuitem">menu 1</div>
	<div class="menuitem">menu 2</div>
<div class="title2">Article title</div>

And for that matter, why would you have a class for a menu item, when the menu is perfectly identifiable? Even in this bad example, you could still get rid of the ``menuitem`` class, and just refer to them with ``#menu div {...}``.

An ``<ol>`` makes a perfect menu. It is after all, an Ordered List. Get to know what each of the element names means, how you would think of that in a standard word processor document, and then how that can be applied to your site, imagining your site as a word processor document without any CSS. Your menu would be a table of contents of sorts, and therefore would obviously be an Ordered List.
Here’s a different example I helped someone with:

~~~ HTML ~~~>
<div id="leftcol">
	<h2 class="blue">Recent Project</h2>
<div id="rightcol">
	<h2 class="green">News Updates</h2>

He wanted the headings on the left blue, and the headings on the right, green. Which is fair enough. _
However, could you not just select the column, and do away with the need for the classes?

~~~ CSS ~~~>
/* as a rough example */
#leftcol h2	{color: blue;}
#rightcol h2	{color: green;}

Knowing, and using more elements, instead of resorting to ``<div>``s all the time, allows you to use CSS to select those elements more widely as well as specifically. Here, both of these are ``<h2>``s. Now if they were ``<div>``s, we would have to use classes, because there would likely be yet more ``<div>``s in the columns and you couldn’t say ``#leftcol div`` without turning many things blue or green instead of just what you wanted.

Getting rid of ``<span>``s with classes requires knowing the meaning of the many inline elements. Google them.

<``ABBR`` (/code/abbr_redux)>, ``ACRONYM``, ``BIG``, ``CITE``, ``CODE``, ``DEL``, ``DFN``, ``EM``, ``INS``, ``KBD``, ``Q``, ``SAMP``, ``SMALL``, ``STRONG``, ``SUB``, ``SUP``, ``VAR``

Think of these elements outside of the browser, on a printed piece of paper. You can then bombard them with CSS to make them look like anything—even if they don’t look anything like what they’re supposed represent—but their use will be semantically sound, having the right _meaning_ in your website.

                                                            * * *

*Learn* the <selectors (//>.

If you know the selectors and the the tags well enough, then you only need a class (or ID) when you cannot differentiate two elements from each other with the browser you are supporting. Since I’m using CSS3 and not supporting IE at all, I don’t need any classes because I’ve made the right choice of elements, and can differentiate all of them with the right CSS selectors.

If you want clean code using few, if any, classes then right away ditch IE6. Stop supporting it, tell people to upgrade. Without {``+``|sibling} and {``>``|descendant} selectors, IE6 is too frightened to go anywhere that isn’t within sight of a class or ID.

IE7 does support {``+``|sibling} and {``>``|descendant selectors}, and whilst it lacks in many other areas, it has the necessary basics to write good HTML/CSS. <Check (//> what your targeted browsers support.

                                                            * * *

*Once* you have made a decent HTML 4 site, then you will look at the HTML5 specification, and it will make sense—you will know what to do with it.
Here are some links to refer to in your adventures:

•	<W3Schools’ «HTML5 Reference» (//>
•	<«HTML5 Differences from HTML 4» (//>
•	<The current HTML5 specification (//>
•	<«The Web Developer’s Guide to HTML5» (//>