JavaScript frameworks are getting powerful and convenient, you can write a production website purely in JavaScript. HTML is moving slowly to behind the scene and getting generated automatically, it gets more and more underrated, more developers ignore learning it seriously.
But I dare you to say bad about HTML or make it optional to learn in public, you’ll get snarled by experienced developers who might barely write a single raw HTML tag in years. They will blame you for not adopting semantic markup and accessibility almost all the time. So certainly it will hurt you in a frontend interview.
The HTML living standard actually defines a lot of things related to CSS, JavaScript and Browser implementation. It’s quite confusing for me to separate them. So if you don’t see something (HTML Parsing, DOM, Web APIs, etc) here, there’s a high chance it will be covered in following parts.
This post is not a how-to on writing HTML or an exhausted list of HTML Q&A for interviews. I’m sure there are tons of HTML references and style guides out there for you to learn HTML in depth. This post only covers some very important topics related to HTML in a sense of what they are and why on earth we need to learn them.
There’s a confusion in term of who controls the HTML standard between W3C and WHATWG. On 28 May 2019, the W3C announced that WHATWG would be the sole publisher of the HTML and DOM standards.
The current HTML Living Standard is developed by WHATWG, which is made up of the major browser vendors (Apple, Google, Mozilla, and Microsoft). HTML5 is the fifth and current major version of HTML, and has following building blocks:
What is semantic markup? It’s simply to use the right elements for the right purposes. HTML5 defined tons of semantics elements for you, your job is to use as many of those as possible instead of polluting your site with div.
Who benefits most from this movement? The robots! Yes you can create a beautiful website without caring about semantics at all. Those semantic elements were created to help automated tools like search engines, web crawlers, screen readers reading your sites easier.
Semantic markup also makes your life easier with readability when reading the source code, debugging html, engaging new projects or crawling the web. No more creative unconventional class names like <div class="nav">, <div class="navbar">, <div class="nav_bar">, <div class="my_nav">, <div class="awesome_nav"> or <div class="leave_me_alone"> (nav to play the hero).
I developed many web crawlers (personal use only) years ago and I really hated sites with unpredictable HTML class naming conventions, dynamic HTML tags or confusing site structures. Thanks to semantic markup, the life of crawler developer is getting better than ever 😅.
I’m talking about metadata on the <head> of HTML document, this is an awesome place to put tons of useful things which will be easily consumed by automated tools. They are not visible to end users but can be inspected by browser developer tools.
Meta tags for web browsers: These are basic tags for browsers to know more about your site and render properly.
<head>
<!-- specify character encoding for HTML document-->
<meta charset="UTF-8" />
<!-- control page's dimensions and scaling -->
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<!-- set base URL for all relative URLs -->
<base href="https://example.com/" target="_blank" />
<!-- define style -->
<style>
body {
background-color: white;
}
h1 {
color: red;
}
p {
color: blue;
}
</style>
<!-- load a stylesheet -->
<link rel="stylesheet" href="style.css" />
<!-- define a client-side script -->
<script>
function myFunction {
document.getElementById("demo").innerHTML = "Hello JavaScript!";
}
</script>
<!--
HTML parsing is paused for normal_script to be fetched and executed
-->
<script src="normal_script.js"></script>
<!--
async_script is fetched asynchronously with HTML parsing.
async_script is executed when ready and blocks HTML parsing
-->
<script async src="async_script.js"></script>
<!--
defer_script is fetched asynchronously with HTML parsing.
defer_script is executed when HTML parsing has finished
-->
<script defer src="defer_script.js"></script>
</head>Meta tags for search engines: Search engine like Google is really smart and powerful, besides server-side rendering pages they claim they can crawl client-side rendering ones. It’s often to use following tags to feed search engines some important info.
<head>
<title>Harry Wilson</title>
<meta name="description" content="Software Engineer" />
<meta name="keywords" content="JavaScript, Fullstack" />
<meta name="author" content="Harry Wilson" />
<meta name="robots" content="index, follow" />
<link rel="canonical" href="http://example.com/" />
</head>Meta tags for social sharing: It’s quite easy and straightforward to have beautiful sharing cards on Facebook, Twitter, LinkedIn, Pinterest. Most of them support Open Graph protocol. Use following tools to test social sharing: Facebook Sharing Debugger, Twitter Card Validator or metatags.io.
<head>
<!--Facebook / Open Graph -->
<meta property="og:type" content="website" />
<meta property="og:url" content="https://example.com/" />
<meta property="og:title" content="Harry Wilson" />
<meta property="og:description" content="Software Engineer" />
<meta property="og:image" content="https://example.com/img/cover.png" />
<meta property="og:site_name" content="example" />
<!--Twitter (also supports Open Graph)-->
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:image:alt" content="Avatar" />
<meta name="twitter:site" content="@example" />
</head>And don’t forget that you can put literally any custom metadata in the <head> for any purposes like analytics, prompt to install apps on mobile browsers, site verifications, tracking, you name it.
Most of frontend developers don’t use microdata which is a part in HTML standard that encourage webmasters adding more indicators on what content is all about.
You only want to do this when you want your site to be understood even more by search engines besides sematic markup and metadata on <head>.
<div itemscope itemtype="http://schema.org/Event">
<div itemprop="name">Spinal Tap</div>
<span itemprop="description"
>One of the loudest bands ever reunites for an unforgettable two-day
show.</span
>
Event date:
<time itemprop="startDate" datetime="2011-05-08T19:30">May 8, 7:30pm</time>
</div>Major search engines use vocabularies from schema.org along with following formats: Microdata, RDFa, or JSON-LD
Search result pages are getting more complicated with carousels, context based, mobile, rich snippets, sponsored results, direct plain text answers, etc. To maximize the chance of your site displayed in these results, you have to feed search engines even more!
Web accessibility is a practice encouraged by HTML standard to help people with disabilities consume the web. It’s an important movement on an effort of providing equal opportunity for everyone in this world.
This is made possible by authoring tools, web content, user agents, assistive technologies and especially you - frontend developers. The Web Content Accessibility Guidelines is long and complicated, I bet not many of you read that but I’m sure you already do a good job if you’re already following semantic markup.
Accessibility is underrated not just by newbie developers but also experienced ones. The main reason is we don’t see the direct benefits or immediate impact if we do follow it. Why? Simply because most of us are perfectly physically normal.
It’s okay to ignore accessibility when you’re developing almost-no-one-use websites, but should take great care of it when developing popular ones. Making this as a habit from the start is even more awesome, many people around the world will be very delighted with what you’re doing.
English only website is fine for individuals and small companies, but i18n is actually a huge deal when you’re developing sites for popular international brands. Knowing this is important when you’re applying for big enterprises.
I18n ensures supports in different character sets, writing directions, different approaches to format and store data, cultural problems and most importantly the design needs to be flexible enough to accommodate local needs.
To support i18n perfectly, most frontend developers use JavaScript frameworks which support i18n. Using only pure HTML to support i18n is extremely painful and not repeatable. JavaScript frameworks will simplify many aspects:
Google announced an open source HTML framework called AMP (Accelerated Mobile Pages) for better and faster experiences on the mobile web (Google said that) in 2015. This was created in an effort to play against Facebook Instant Articles.
AMP can be used in websites, stories, ads and emails with three main restricted building blocks: You must use AMP custom HTML components amp-something instead of standard HTML tags, JavaScript usage is very restricted, and all your site’s resources will be served via AMP’s CDN with many optimizations.
The main benefit of using AMP is to make your site appear on Google Top Story Carousel, it’s a powerful way to boost mobile SEO and CTR of news content.
This AMP is very controversial over the years, people blame it for going against the open web and for Google’s own sake. You should think twice when adopting it and with your own risk because you’re moving to the parallel world which has very unpleasant developer experiences.
We use HTML emails everyday but we normally don’t write it, it is often already integrated by email clients or email marketing services. It’s good know how to write raw HTML emails because it might be useful in some startups when you’re going to develop transactional email templates.
To support wide variety of -not-so-innovative email clients, you can only use a very small set of HTML+CSS with a lot of limitations compares to web HTML.
It’s safe to use static table-based layouts, simple inline CSS, HTML tables and nested tables, web safe fonts. Cautious use with background images, custom fonts and embedded CSS.
Typical email clients aren’t as up-to-date as web browsers. Simply stay away from JavaScript, iframe, Flash, embedded audio/video, forms, and div layering.
HTML is moving slowly to behind the scene. With the rise of JavaScript frameworks, it’s hard to find frontend developers who write vanilla HTML these days. HTML is still there for years to come, but it’s simple and stable to be generated automatically. If you’re using some bootstrap frameworks, you’ll see yourself rarely writing raw HTML tags in years.
You’ll learn a lot when developing a vanilla website. Maybe you don’t have chances to do this in production. But if you actually try it, you’ll realize that many JavaScript and CSS frameworks are doing way too much. I don’t say those complicated frameworks are bad because they cover many features that take you years to implement on your own.
I ignored many basic topics in this post, explore more on your own to have an solid exhausted knowledge about HTML. I recommend following resources to dive deeper on the quest for frontend job: