First I would suggest you properly learn HTML 4.01 STRICT and/or XHTML 1.0 STRICT (same basic thing, just some minor syntax differences) -- as they are the current RECOMMENDATION doctypes. Once you have that you can add the HTML 5 garbage if you want, but if you learn to use STRICT properly, you'll find out that 95%+ of HTML 5 -- so far as actually writing HTML -- just re-introduces redundancies STRICT was trying to get rid of, introduces all new redundancies, and through the loosening of structural rules seems bound and determined to roll back coding practices to the worst of the late browser wars.
Though that goes with who HTML 5's target audience seems to be; all the people who never extracted their craniums from 1997's rectum, and continue to this day to sleaze out HTML 3.2 or the proprietary garbage that was never part of the specification How exactly do you deprecate something that was never part of the specification anyways?!? -- and until recently were slapping 4 tranny on it. Now they slap the 5 lip-service doctype around the same outdated, outmoded code and slap each-other on the back over how "modern" they are.
I would suggest working one step at a time, since "progressive enhancement" -- adding technologies one at a time to a complete site -- is the core of how one should build a site anyways. You learn to use HTML properly, then you learn to use CSS, then you learn JS -- start out with a static site, then dive into something like PHP to make it 'dynamic' and to make it easier to maintain, then dive into SQL for tracking large amounts of data efficiently.
Now, when I say use HTML properly, I mean "semantic markup" and "separation of presentation from content". They both actually mean the same thing, using the HTML tags for what they MEAN, NOT WHAT THEY LOOK LIKE!!! -- generally speaking in all but the rarest of cases, you have no business saying in your HTML what things should look like; be it your choice of tags, the classes and id's you put on those tags, whatever... does not belong there.
Assuming you at least know how to open and close tags, it's just a matter of learning what they mean. I like this older reference for it's clarity and simplicity:
Go through and learn the tags, pay particular attention to the description of the tag's MEANING, as well as what 'level' the tag is (block or inline) as well as "contents" and "contained in" which give you the rules of what tags can go where.
For example, take UL:
It's not actually block or inline, though it's default behavior is display:block; -- it can be contained only in the tags listed, aka those are the only tags that can be it's direct 'parent', and the ONLY direct child it can have is a LI... which is why this:
<ul><h2>Some text</h2><li>First item</li></ul>
is gibberish, H2 can't be a child of a UL... though it COULD be the grandchild as a child of LI.
Go through and READ ALL THE TAGS. Also pay attention to which ones are 'non-strict' or just tick the button to hide non-strict, as those tags and attributes HAVE NO BUSINESS BEING USED ON WEBSITES WRITTEN AFTER 1997.
One bit that people don't get and is hard to glean from the specification or any online reference is how to use numbered headings -- they are really simple if you know professional writing, but since most people making HTML these days are barely literate TLDR nitwits who can barely make big enough a coherent thought to fill a tweet, it's not a shock few people grasp the concept. I'll outline it quick.
Lower ordered (higher numbered) headings mean the start of a subsection of the higher order (lower numbered) heading preceeding it. Using a H2 means you are starting a subsection of the H1 before it. Using a H3 means you are starting a subsection of the H2 before it... an so forth down to H6. This is why just blindly using H5 or H6 with no H4, H3 or H2 before them is gibberish. At the top is the H1 -- the heading under which EVERYTHING on the page is a subsection. That's why the H1 is best used as the site title or similar. Think of a newspaper -- what's at the top of EVERY page? The title of the paper (and usually the date) -- that's the H1. Sure, it's bigger on the front page, but in terms of structural importance (as opposed to important importance -- there's a difference and people screw that up reading the specification's legalese every time) they're all H1... Some people would say "what about the headline, that's the biggest text on the front page" -- and? STRUCTURALLY you aren't saying that "Woman found dead on Maple Ave" and "K-6 get new building" are subsections of "MAYOR CAUGHT TAKING BILLION DOLLAR BRIBE" -- they're all H2, siblings to each-other and subsections of the paper. Either that or you're in one really screwed up town.. Likewise there's "horizontal rule" -- which people seem to think means "draw a line across the page" -- while that's the default appearance, in professional writing you'd use a horizontal rule to indicate a change in topic where a heading is unwanted or unwarranted. So it is in professional writing, so shall it be in HTML.
...and when you get into HTML 5 you'll find they pissed all over this with the pointlessly redundant SECTION, NAV, ARTICLE and FOOTER tags
Many of the tags that have semantic meanings thanks to their being used as a markup specification people THINK are presentational, when they are not. B and I (bold and Italic) for example do NOT mean "this text must be shown as bold and italic" because when TBL made HTML not every device was even capable of showing bold and italic. They mean "would be bold or italic in a properly written document" -- which is to say for things like proper names, books, etc... you'll often hear ignorant halfwits saying "use STRONG and EM instead" or worse, "B and I are deprecated" -- the former is often bad advice, the latter is 100% grade A farm fresh bull. EM and STRONG mean "emphasis" and "with more emphasis" respectively -- you aren't emphasizing the title of a book, you aren't adding more emphasis just because you mention the name of a company. B and I's semantic meaning of "would be bold or italic in a professionally written document" still has it's place.
more than anything, when you start making a page you should start with what you want on the page in plaintext or IMG links (and I mean content images, not images as text crap like some incompetent fools do with menu buttons and the like); that's your content. Just put it -- or at the very least a reasonable facsimile of future content -- into a normal flat text editor and arrange it into an order that makes sense as if HTML never even existed.
You then go through and add your semantic tags to say what things are... Your headings to break it into sections so you have a logical document structure, A (anchor) around your links, menus being lists of choices get lists, bullet point lists get lists, paragraphs around your actual grammatical paragraphs -- keeping in mind a lone image is NOT a grammatical paragraph, a sentence fragment in the middle of nowhere is NOT a paragraph. These large blocks of text in this post separated by periods and spaces into sentences? THAT'S A BLOODY PARAGRAPH. (It's often shocking where people just throw paragraph and to hell with it's meaning).
This gives you a semantic baseline... which means search engines, screen readers, braille readers, and people who block fancier bits of tech because their connection or bandwidth sucks will have a useful, if rather plain page. That's the first step in what is commonly called "accessibility".
THEN and ONLY THEN do you start worrying about the page's appearance, and that's the job of CSS, sometimes with a bit of assistance from the two semantically neutral tags "DIV" and "SPAN", which are 'block-level' and 'inline-level' respectively. You should at least TRY to style as much as possible without adding extra tags, but at this point you probably will end up adding a good number of DIV and even a few SPAN. Those tags exist to group elements together for styling WITHOUT saying what that style IS...
Which is why HTML 5's SECTION, NAV and FOOTER are also silly, you shouldn't be using tags with "meanings" redundant to existing tags with meanings you should already have on the page just as styling hooks.
.... to be continued (10k post limit is really annoying guys!)