Hi @Jason Knight, still learning and hope to improve. Thanks for the insight.

Eze Bernardine May Well, lemme give you a quick lesson on things that a lot of tutorials and books skip right past.

One of the problems right now -- and it's been a problem for some time -- is that many in web development are stuck in a late 1990's mindset. At that time the browser makers were at war with each-other, each trying to come up with "who can make the shiniest looking sites by adding presentation to HTML".

The problem with this is that the original intent and entire purpose of HTML is not to say what your site looks like. This is a concept that is hard for beginners to even grasp, and for a good while people acted like that was all that matters. It isn't.

See, when Tim Berner's Lee created HTML it was to solve two problems. The first is obvious -- hypertext -- the addition of hyperlinks to documents so that they could refer directly to each-other.

The other problem though was "means of conveyance". Not all devices at that time were screens, or capable of graphics, or capable of different fonts. They came in different sizes, capabilities, resolutions, and so forth. Nothing like today where every computer has the exact same screen size and resolution. For those who missed it, that was a joke.

The markup part of HTML was created so that you could follow grammatical and structural conventions to build a document that the user-agent (UA -- software that turns markup into something the user can follow) could best convey those meanings. This is why HTML tags mean something more than just their default appearance on screen media. It doesn't matter if the device is a teletype, braille, TTY beeping, puffer, handheld, widescreen -- the MEANING of the document can be conveyed by the UA.

UA's are a bit like some terms of ethnicity; a Chinese person is oriental, but not all orientals are Chinese. A browser is a UA, but not all UA's are browsers. Screen readers, braille readers, even search agents are all valid UA's your code should be written for!

It is to this end that if you -- as I've said many times the past decade and a half -- choose your HTML tags based on what you want things to look like, you're choosing all the wrong tags for all the wrong reasons.

Unfortunately with that "browser war" I mentioned -- between Nyetscape and Microshaft Exploder -- they kept adding stuff to make it look pretty to the HTML. Tags and attributes that have no grammatical point. FONT, CENTER, ALIGN, BGCOLOR, and so forth. Being they were the 500 pound gorilla's in the room at the W3C, they managed to force much of this nonsense into the specification, and it was only with HTML 4 Strict and moving such trash out of the HTML that we started to drag markup back to what it's supposed to be for.

So everyone hopped on that 4 Strict bandwagon right? Nope... because people are visually oriented and forget 90%+ of what they should have been taught in grade school grammar. A stop-gap between HTML 3.2 and 4 Strict was created called "4 Transitional" -- the transitional part meaning "in transition from 1997 to 1998 development practices" and the vast majority of people used that -- no matter how stuck in 1997 it was -- right up until HTML 5 came along. This is why much of HTML 5 and what people do with in only proves how far up 1997's backside the majority of dev's have their heads wedged.

Doesn't make it right, or proper, or good... or useful. It certainly doesn't make the result accessible; and accessibility is the core concept of using HTML properly.

... and that's what the term "semantic markup" is, a sick euphemism for "using HTML properly" that came into use so as to not offend the people still using HTML 3.2 style techniques by flat out calling a spade a spade, and upsetting them by saying "Well, what you're doing basically means you've got your cranium wedged up 1997's rectum"

Because Joe forbid we upset anybody in this age of soft limp soothing-syrup words and platitudes. Who cares if the whole world burns, so long as nobody is offended.

In any case, the HTML tags have meanings of what they should be or would be for grammatical/structural reasons. The "would be" part is what confuses some people as some tags -- like B and I -- sound presentational... but that's would be bold or italic for grammatical reasons, such as a proper name / entity in a legal document is bold or a book title that isn't being CITEd or recieving EMphasis would be italic. That does not mean the UA has to show it that way, not all UA's are even capable of showing bold and italic. You do not use those tags just because you want some text bold or italic, you use them when it would be for grammatical reasons.

To that end the H1 (singular) is the (singular) heading (singular) that every section of every page is a subsection of. (unless you use HTML 5's idiotic redundant SECTION tag) That's why the site title and/or logo is the best candidate for your H1. An H2 indicates the start of a major content subsection of the page, the first H2 (or HR) meaning the start of the main content! An H3 indicates the *start of a subsection of the H2 preceding it. H4 means the start of a subsection of the H3 preceding it, and so forth down to H6. Even HR means a change in topic/section where heading text is unwanted or unwarranted.

They do not mean fonts in different weights and sizes, or draw a line across the screen! That is just their default appearance in most browsers as a means of conveying that meaning.

Of course if said tags mark the start of sections and subsections, and the first H2/HR marks the start of the main content that can be skipped directly to, what point does HTML 5's silly SECTION, ARTICLE, and MAIN serve?

Because of those grammatical/structural meanings, you don't skip over depths going 'down'. You don't start a page with an H4 (see bootstrap's incompetent examples that prove they have no business telling people how to code websites), you don't skip from a H1 straight to a H3... you don't pair a H1 and a H2 together as title+tagline since what subsection of the page is the h2 starting, that's just one header... and you don't use headings for things that are not the start of a subsection of content.

Likewise what you are building is a form, and FORM's have structure. You should have a FIELDSET to indicate that the inputs inside it are a group that are user-interactable. You don't like how the fieldset gives you a double-border around it, that's CSS' job to fix. The text you place next to your input/select/textarea label what those fields are, which is why you use a LABEL tag... LABEL tags have a FOR attribute which is used to point at the INPUT/SELECT/TEXTAREA it is... well... for. If you wrap one of those form elements inside a LABEL you can skip using FOR, but from a styling standpoint it's often easier to have the two tags side-by-side.

This semantic and grammatical structuring being so that your form is accessible to everyone, not just the

Nice side effect of the LABEL tag? Clicking on it is the same as clicking on the form element it is associated with. This allows them to be leveraged for all sorts of cool effects we used to have to use JavaScript for.

Oh and for the love of Christmas, placeholder is not a LABEL!!!. Using it as such tells non-visual users to sod off, and runs the risk of the "loss of context" aspect of false simplicity... so no matter how many artsy types get all happy in their pants over abusing it that way, don't do it!

Even the HTML 5 specification comes right out and says it:

The placeholder attribute should not be used as a replacement for a label. For a longer hint or other advisory text, place the text next to the control.

They even last year added this big warning next to it.

**!WARNING - Use of the placeholder attribute as a replacement for a label can reduce the accessibility and usability of the control for a range of users including older users and users with cognitive, mobility, fine motor skill or vision impairments. While the hint given by the control’s label is shown at all times, the short hint given in the placeholder attribute is only shown before the user enters a value. Furthermore, placeholder text may be mistaken for a pre-filled value, and as commonly implemented the default color of the placeholder text provides insufficient contrast and the lack of a separate visible label reduces the size of the hit region available for setting focus on the control.

So naturally, everyone and their brother keeps abusing/misusing it anyways, or worse try to replicate the behavior with scripting or CSS because "Wah wah, but having the label there all the time takes up screen space" -- oh noes, nots thatz.

That the core of semantics though, accessibility and good practices. It means P is for grammatical paragraphs and not "oh this is some text" or "I want a double break after this"... a lone image by itself is not a grammatical paragraph. An INPUT and LABEL are not a grammatical paragraph. It means UL/OL are for short grammatical bullet points (as in grammatical bullet point, not "it has a dot before in) of related information or selections, not marking up massive sections of content with headings. It means TABLE is for tabular data, not "I want columns on this".

There are only three meaningless tags that contain content -- as in they apply no meaning to the content they wrap. One -- Anchor -- is behavioral. It applies the behavior of a link to the text it wraps, but it does not change or imply any meaning to that text. It is because of this neutrality that blindly dumping just anchors into tags like (the pointless HTML 5) NAV is treated by non-visual UA's like my braille reader as a run-on sentence. yes, I supplement my failing vision with a braille reader.

The other two, DIV and SPAN exist for the sole purpose of saying "this element may receive style" without saying exactly what that style is. That does not mean you just blindly slap them into a page willy-nilly for the application of style though -- you should first try to exploit your existing semantic tags for styling before you resort to adding extra "markup for nothing"

The same mindset should be used with classes. Try to leverage CSS selectors and your existing semantics before you start throwing classes at anything. There's this really bad practice right now -- based entirely on a falsehood about rendering time and "simplicity" -- of throwing multiple classes at every blasted element on a page. It's bloated, sloppy, hard to maintain, and based entirely on a bald faced LIE. Sad part is that lie is touted as truth by once useful tools like YSLOW and Google PageSpeed, that have begun aging like milk and/or being used by marketers as scam bait. Bloody shame in PageSpeed's case as eight years ago it was a useful tool. Now it just turns people into tools.

... and I bet you 80%+ of the tutorials or books you've read don't mention any of this, did they?

Hence the 'proper' markup for such a form is:

<form action="#" method="post" id="signup">
    <h1>SIGN UP</h1>
    <fieldset>
        <div>
            <input type="text" name="name" id="signup_name" required>
            <label for="signup_name">Name</label>
        </div><div>
            <input type="password" name="pass" id="signup_pass" required>
            <label for="signup_pass">Password</label>
        </div>
        <button>Submit</button>
    </fieldset>
</form>

That H1 being adjusted to the proper depth based on whatever the document structure is. (Real world deployment that is unlikely to be a H1). You aren't doing anything to the H1 to warrant putting a DIV around it, the DIV for the input would be the label behavior that honestly I wouldn't be doing in the first place. Neither of those DIV need classes as they're the only DIV inside #signup, we can use that parent ID as our hook. Same for the H1 or whatever depth heading is appropriate as it too can be styled off the parent ID... and the default value of type on a button is submit, so you don't have to say that. (unless you're hooking it with a specific type of scripting in IE8/earlier -- aka something we no longer have to care about.)

Hoping this helps. HTML actually has a lot of rules that even many so-called "experts" scoff at... and my day job freelancing the past few years has entailed going around and cleaning up after this sort of stuff as with certain types of websites -- banking, health care, government, public utilities -- you can land in court for failing to meet accessibility minimums, of which semantic markup is a big chunk. It's sad but so many dev's parrot the mantra "HTML isn't a real programming language", when it most certainly is, and if people would take it more seriously we wouldn't have the majority of problems with websites we are stuck with. It has rules, it has a purpose... and it's scary how many books and tutorials gloss over both.

Makes it really hard for people like you just starting out. The legalese double-talk of the specification certainly not helping matters.

Nice info. Thanks dear