Post 1
I like HTML so much!
<div><div><div><div></div></div></div></div>
I've been a webmistress since 2014, and this website took on many different shapes and forms throughout years. My first encounter with HTML was in middle school, where we had to markup a basic HTML page for an IT class. As per the manual, we've been using tags like <h1>, <p>, <article>, <header> and so on. After i started doing stuff on my own, i quickly discovered that real webdevs just use <div>isions for everything, maybe with a few <p>aragraphs sprinkled in, and solve all the styling issues with class and ID tag attributes - and went with it. But, what do you know, 10 years later i want to take 90% of the webmxters out there by the shoulders and scream about how my old lady the boring IT teacher was actually right, and how modern webdev has taken itself to absolute absurdity.
Semantic HTML has a whole bunch of upsides, while the general sentiment of it being too rigid to be styled in whimsical ways is entirely pulled out of thin air. In fact, this website's pages all share the exact same tag structure, and the landing index page uses literally a single class for its styling, all else done with semantic tag matching! If you are accessing auberylis.moe in full mode, you likely noticed the highly variative and chaotic styling of the pages - doing so was simpler with a rigid semantic structure. And if you are using the calm mode for accessibility or visual decluttering - it only works because all the pages are structured precisely the same way. In this article, i'm going to briefly cover the advantages of a semantic layout.
HTML clarity
There's an entire everlasting debacle over if HTML (and XML by proxy) is a type of code. While calling it a "programming language" is indeed debatable, since HTML does not exactly specify a program, i think it can definitely be called "code" - since the word basically means a set of symbols and words that go on top of the usual human language that are designated and understood only by a chosen few; in this case, you and the browser's rendering engine. And if codes that spies exchange should be as obfuscated as possible, the code you the webmxter are maintaining should be the opposite: as clear as possible. The main reason for that is that you should be able to quickly realise what's going on a couple years after not touching your project just by looking at its code. Usually, cleaner basic code structure also implies easier enhancements, in case of HTML this means easier styling and dynamic page response via CSS and JS respectively. Semantic HTML is one of the ways that can easily help achieve markup clarity.
Styling it
In addition to making your pages self-descriptive, semantic layout makes styling pages a breeze. I cannot overestimate how much more streamline my CSS work has been ever since i adopted semantic HTML. Because if we stick to our divs, the only way we can differentiate between all of them is with classes and IDs, all typed out as HTML attributes.
Blog
Post 2
I also like when it's readable!
I don't know about you, but my eyes get a bit of a ripple effect from all these letters that spawned in. And now, we style it like so - keeping in mind all the class names and IDs we came up with while CSSing:
#mainWrapper {
...
}
#title {
...
}
.post {
...
}
Have we used semantic tags, we would've typed less stuff in the HTML, which always keeps the HTML less cluttered. Likewise, styling would've been simpler, as we no longer have to remember the id and class names, and instead just dish out the usual run-of-the-mill self-descriptory tag names:
main {
...
}
header {
...
}
section {
...
}
This also leaves the class property for something that makes more sense using it for - unusual situations. Say, we finished styling our semantically laid out blog, and now we want to be able to add styling to posts according to their content. The default styling would be the neutral one, but we want to add special styling to longread posts. In HTML, we now would use a class and say <section class="longread">, and in CSS it is addressed as section.longread - a fast, efficient, and self-explanatory way to add styling on top of the existing section style.
Semantic layout has another advantage for styling: it really makes the stylesheets cascading! Say, we want <p>aragraphs to be styled in such-and-such way everywhere on the page, but inside the <footer> the font should be italic on top of that. With a non-semantic layout and classes, we have to style two classes in CSS - one for the default paragraph, the other with footer additions. Then assign the footer paragraph both of those classes in the HTML document. Semantic layout allows us to instead do like so: no need to add anything at all to the markup itself, since its semantic-ness already did everything for us.
p {
... (usual paragraph styling) ...
}
footer p {
font-style: italic;
}
By styling footer p, we apply some style to any paragraph that's inside a footer - as simple as that! When i found out how easy this technique makes styling, i really understood the reason CSS is called that way. And let's not forget that there are other operators that allow more precise matching: for example, footer > p matches a para that is exactly a direct child node of a footer, but not levels deep inside footer's other child elements. This allows us to quickly and precisely target elements in semantic constructions without having to drench them in class attributes.
Coding it
Javascript, who does not like it! Alright, alright - JS speed and safety debate aside, this is our only option to make pages highly interactive for now, so we may as well use it efficiently. JS is where i see a lot of people carelessly generate stacks of divs if the page is dynamically created. I can see how that happens: in JS, we assign variables to new elements, so to us the programmers, they are actually semantic inside the script.
var section = document.createElement("div");
var heading = document.createElement("div");
var content = document.createElement("div");
section.append(heading);
section.append(content); // as semantic as can be innit!
The resulting HTML sturcture, not so much:
Now the screenreader is unhappy and the person writing CSS (likely the same one who wrote the script) is also unhappy. Without classes, it's impossible to easily match these elements in CSS. So, in JS, we slap on a fix by adding classes to whatever we generate.
var section = document.createElement("div");
section.classList.add("post");
This is an additional line of code in the script, an additional attribute to the HTML tag - no fun, only clutter! If we stick to the semantics, we simply have to var section = document.createElement("section"), and boom - if the section tag is styled in CSS, it will just pick up the style. And in the example of a paragraph inside a footer, if JS creates a paragraph and appends it to a footer, it saves you two class assignation lines!
The idea of using classes to represent unusual situations then comes naturally. Imagine our blog has a lot of posts now, and we made a pagination system which basically hides all the blog posts, then shows them in chunks of 10, with some javascript handling which chunk is currently visible by somehow hiding all other posts.
We could make some spaghetti code that messes with elements' inline styling and whatnot, but a much simpler solution would be to give whichever post <section>s we don't have to display a hidden class, and then styling section.hidden with display: none; in the CSS file. Note how the hidden class remains free to be reused for other elements, and other effects can be styled for them. Over years, using classes to represent states and IDs as relevant unique element pointers proved much more convenient and effective than using them as match keywords for CSS!
Conclusion
Most CSS/JS web tutorials demonstrate their workings on an HTML structure made almost entirely of <div> elements, with an occasional <p> sprinkled in as a treat. While this fulfils the demos' intents and seems to be working in corporate web's autogenerated websites, this practice has drawbacks in general, and is especially ineficcient for user-made websites. Adopting semantic HTML helps the webmxter keep a consistent self-explanatory layout they will understand instantly years after being done with a page, style their websites much faster, generate documents and use class and id attributes in JS more efficiently, all while keeping the websites more likely to be correctly parsed by accessibility technologies. I encourage everyone running a <div><div><div><div></div></div></div></div> style website to adopt semantic HTML today!