The Cornerstones of HTML
Older Article
This article was published 7 years ago. Some information may be outdated or no longer applicable.
I’ve recently finished studying the basics of HTML, and I want to highlight some of its pillars here. We won’t be covering how to create paragraphs or how to stack elements one after the other. Instead, we’ll look at some of the cornerstones of the markup language that’s defined the web for over a decade.
Throughout the article, I’ll flag things that tripped me up at first. These points mostly correlate with features where developers don’t see the direct effect of their changes, or where the results aren’t immediately visible.
These “invisible” elements matter later. They help you understand the correspondence of the code and they let you add small details that make any web product more user-friendly and accessible. These details might look unnecessary, but they’re required. Having a strong grip on these fundamentals is the same as attending every lecture at university: you could skip a few and still pass a test, but if you want to truly master the skill, you sit through all of them and do all the homework. Coming back later to patch the gaps is always harder. With HTML, we need to understand why certain elements were created, spaced out and designed the way they are.
HTML isn’t a programming language, but I consider it the basis for applying logic and structure to a website. So let’s see what I, as a beginner, found notable.
Block-level and inline elements
To understand the building blocks of a webpage, you need to grasp the difference between block-level and inline elements.
A block-level element takes the full width of the page, spanning multiple lines. (Hence the name “block”.) An inline element doesn’t cause a line break. It can sit inside a block-level element and only occupies the space between its opening and closing tags. Combining block-level and inline elements together is what produces the content flow of any webpage.
The most common block-level elements: <p>, <h1>, <div>, <ol> and <ul>, to mention a few.
The most common inline elements: <b>, <i>, <im>, <label> and <img>, amongst others.
Another key distinction: block-level elements refer to larger structures, while inline elements apply to shorter structures (even within block-level elements).
<b> or <strong>? <i> or <em>?
HTML gives you different options to mark up text and draw the user’s attention. You can make text bold, or display it in italics. Both visualisations can be achieved with different tags, and on the surface, these elements produce similar results.
For bold text there’s <b> and <strong>. For italic text there’s <i> and <em>.
They’re used for presentational purposes, but they also carry semantic meaning. Since the visual output is identical, the difference sits deeper.
A standard web browser (Chrome, Safari) displays the text the same way. A screen reader, on the other hand, recognises the difference between <strong> and <b>, and between <i> and <em>. Both will add a “style” to the text (changing how it’s displayed), but these tags act as a differentiator in highlighting emphasis. (Adding styles like colour is still possible for both using CSS, of course.)
Two examples for italic text:
“There <em>were</em> some errors.” Here, the screen reader would pronounce “were” with emphasis.
“Everyone in the group visited the Mars factory.” No emphasis here, but the software recognises that “Mars” is different from the planet Mars.
To sum this up: if the text has a semantic meaning, use <i> and <b>. If you want a screen reader to pronounce the text with a different tone, use <em> and <bold>. Regardless of which route you take, styling these elements via CSS is always possible.
Bear in mind that accessibility plays a big role in web development. Be mindful of the differences above and always consider people visiting your site with screen readers.
<span> vs <div>
Two commonly used tags for grouping elements: <div> and <span>. They both group elements, but they carry significant differences. These differences surface when used with CSS.
<div> is widely used to separate different content from each other. It’s a block-level element. Developers can define different blocks and style them without affecting other content.
<span> is an inline element, often used as a container for some text. While <div> defines a whole block, <span> targets something different within the group. With <span> you can format inline text inside a paragraph:
<p>Hello there, my name is <span style="color: red;">Joe</span>.</p>In short: <div> groups block-level elements for styling, while <span> handles inline elements and styling.
Images
Let’s look at some particularities related to images.
Local vs Remote Image src Value
The <img> tag embeds and displays images on a web page. When choosing an image to display, you’ve got two options: pick an image that’s “local” to your application, or pick one that lives on a third-party service.
Absolute vs relative path
If the picture is local to the application, linking to it is simple because you can use a relative file path. Just point to the file relative to the current page. The length of the path depends on where the picture is stored.
<img src="/downloads/images/logo.jpg" alt="my logo">Absolute paths require specifying the entire path:
<img src="https://mysite.com/images/logo.jpg" alt="my logo">Image Delivery and Optimisation
While learning about implementing images on websites, I came across many articles discussing image optimisation. That research led me to a platform called Cloudinary.
A website grabs attention when it has well-placed images, videos or other multimedia content.
One of the most useful services from Cloudinary is how easily it handles image and video optimisation. You upload your images (the ones you want to use during development), and you can access them anytime, anywhere. You can crop, apply effects, or change the quality of the image. All the manipulation happens server-side, so the browser receives an already optimised image.
Loading pictures on a website usually takes time, but Cloudinary cuts that load time. Load times vary across browsers, and Cloudinary can automatically choose the right file format for each one.
For a bit of fun: if you want to express your artistic side, you can apply filters, effects and overlays to your images using Cloudinary.
Here’s an example. I chose an image of three players from my favourite NBA team (Toronto Raptors) and wanted to add a crown on top of their heads (because they rule!). With Cloudinary’s face recognition add-on, it was pretty easy. I just modified the URL of the image and got the following result, without any special image editing:
Cloudinary, with the help of the add-on, detects the face automatically. Based on the coordinates returned by the add-on, it places another image as an overlay (the crown image is also stored in Cloudinary), resizes the crown (and even turns it to the right angle), without me having to touch Photoshop.
The final URL looks like this:
https://res.cloudinary.com/balazskemenesi/image/upload/l_cropped-crown,e_trim/c_lpad,g_north_east,w_1.0,h_2.45/g_adv_eyes,fl_region_relative,w_2.8,fl_layer_apply/toronto_team.jpgWhat are all these options?
- think about the sections separated by
/as layers l_cropped-crown- specifies the crown as the layerg_north_east,w_,h_specify the location of the overlay as well as the width and the heightg_adv_eyesis a feature to do advaned factial attributes recognition (see above)fl_region_relative: region_relative flag together with a2.8width to scale the overlay to 280% of the width of the detected eyesfl_layer_apply: applies all the chained transformations
And here’s the image itself:
Hot Linking
When talking about external images, we also need to mention “hotlinking”. Hotlinking means grabbing an image (or linking to an image) from a third-party site, one outside your control (which isn’t the case with Cloudinary). Not all external images are hotlinks: if you pull a picture from a forum, for example, you can easily stumble into legal violations.
Be mindful when using external pictures, especially ones provided by a third party. The image could be removed, leaving a broken link on your site.
Sites that don’t want their image assets used elsewhere can block hotlinking at the webserver level using an appropriate file such as .htaccess on Apache.
The Importance of Names and Values in Form Elements
When you’re creating forms, you’ll often add radio buttons. Sometimes selecting a radio button still allows multiple choices. That’s likely because you missed adding some HTML attributes to those elements.
To “group” radio buttons, you need to add both a value and a name to each one. When you only add type and id attributes, the buttons won’t be connected.
Say you’re building a registration form where the user picks an age range with radio buttons: one selection is 10-20, the other is 21-30. Without the name attribute, you can select both answers. To limit the selection to one choice, add a name attribute where both inputs share the same name.
The value itself isn’t visible to the user. But it becomes essential when you send the information to a processing server, because that’s the value you can extract from the form. If you skip the value, the server will only receive “on” as the value of the group. Not meaningful.
Here are some examples.
<form>
<label for="10-20">10-20:</label>
<input type="radio" id="10-20" />
<label for="21-30">21-30:</label>
<input type="radio" id="21-30" />
</form>This gives you two radio buttons, but you can choose both at the same time. Not what you want. You need to add the value and the name to get properly functioning radio buttons. The look won’t change, but it gives “meaning” to the whole form.
<form>
<label for="10-20">10-20:</label>
<input name="age" value="10-20" type="radio" id="10-20" />
<label for="21-30">21-30:</label>
<input name="age" value="21-30" type="radio" id="21-30" />
</form>Now the buttons are connected, so you can only choose one from the given possibilities.
Form and Input Element Attributes
Right, let’s talk about forms in HTML.
Form
The form tags represent interactive elements. You can build contact forms, todo lists, login forms and more with them.
The attributes of form tags can be tricky, and I found them rather challenging.
The form opening tag should contain an action attribute. It defines where the data should be sent when the form is submitted. The form should also contain a method attribute indicating the HTTP method to use.
So action defines where the information goes for processing, and method defines the HTTP method used when submitting the form.
GET: The default value for submitting the form. Data sent via GET can be visible in the URL, so it shouldn’t be used for transmitting passwords. It also has limitations on the amount of data you can send.
POST: Larger data can be sent to the server, and it won’t be visible in the URL. It’s the right way to transmit information like passwords.
Did you know? On top of defining the
actionandmethodattributes, you can add atargetattribute to define where to open the response._blankwill open in a new page, while_selfwill be shown on the current page. This isn’t commonly used these days because of AJAX.
Input
Input tags live inside form tags and deliver a smoother user experience. These are the most important input attributes:
Name: Must be unique. Used by the server to identify the fields after form submission.
Value: You can set an arbitrary value for the input element. The server grabs this value when submitting a form.
Required: This attribute makes the field obligatory.
Placeholder: Informs the user about the expected input in the field.
Autofocus: The page will automatically focus on the field where the “autofocus” attribute is given.
There’s a lot more to forms, and there may be follow-up articles on this topic.
Conclusion
Studying HTML and understanding it is essential because it’s one of the fundamental building blocks of the web.
For people like myself learning HTML, there are nitty-gritty details to work through. But after a bit of research, everything connects and the pieces of the puzzle slot together.
I found attributes to be the most challenging part of HTML. They don’t always change how the website looks, but they’re indispensable for creating a well-functioning web page, not just on the surface, but in the backend as well.