The Cornerstones of HTML

Inspection of different pillar elements of HTML and the importance of them. Including topics like images, divs, forms, different tags and other key elements of HTML.

I have recently finished studying the basics of HTML, and in this article, I would like to highlight and go through some of the pillars of it. This article is not going to be on how to create paragraphs, or how to construct HTML elements one after the other but instead, we'll take a look at some of the exciting cornerstones of the markup language that has defined the web for over a decade.

Throughout the article, I will try to highlight things that I found to be complicated at first. These points are mostly in correlation with the features, where developers don't see the direct effect of the changes or where making changes are not immediately visible at first hand.

These "invisible" elements, will help later to understand the correspondence of the code and will make the developer capable of adding small details, which makes any web product more user-friendly, makes it available and accessible to users. These details may look unnecessary, but the reality is that they are required. Having a strong knowledge of these fundamental features of HTML is crucial. We could compare this with studying at a university: skipping specific lectures could still allow you to pass a test, but if you truly want to master a skill you have to attend all the lectures and complete all the homework. It's a much easier approach compared to coming back and learning everything again. With regards to HTML, we need to make sure we understand why some elements have been created, spaced out and designed the way there are today.

Though HTML is not a programming language used for development, I consider it to be the basis for applying logic and structure to a website. So let's see what I, as a beginner, found notable in HTML.

Block-level and inline elements

To understand the structure and the building blocks of a webpage, it is crucial to understand the difference between block-level and inline elements.

The main difference is that a block-level element takes the full width of the page, on multiple lines as well. (That's logical henceforth the name "block") An inline element, on the other hand, doesn't cause a line break. Therefore it could be used inside a block-level element as well, and it will use up the space between the opening and closing tags. Combining block-level and inline elements together are responsible for displaying the content flow of any webpage.

The most common block-level elements are: <p>, <h1>, <div>, <ol> and <ul> just to mention a few.
The most common inline elements are: <b>, <i>, <im>, <label> and <img> amongst others.

Another important distinction between them is that block-level elements refer to something with a larger structure, while inline elements apply to shorter structures (even within block-level elements).

<b> or <strong>? <i> or <em>?

In HTML, there are different options to markup text to draw the attention of the user. You can make the important text bold, or you can display it using italics. Both of these visualisations could be used with different tags, and seemingly these elements produce similar results.

For making text bold there is <b> and <strong> and for making text italic, there is <i> and <em>.

Although these are being used for presentational purposes, they also have important semantic meanings. Because the visualisation is the same for both of the tags, the difference lies deeper.

A standard web browser (like Chrome or Safari) displays the text, in the same way, a screen reader, on the other hand, would recognise the difference between <strong> and <b> as well as <i> and <em>. Although both will add a "style" to the text (effectively changing how the text is displayed), these tags are used as a differentiator in highlighting the emphasis. (Note that adding additional styles like the colour is still possible for both of these using CSS of course.)

Let's take a look at two examples for italic text:

“There <em>were</em> some errors.” In this case, the screen reader would pronounce the word "were" with an emphasis.

“Everyone in the group visited the Mars factory.” Here there won't be any emphasis, but the software will recognise that "Mars" is different from the planet Mars.

To sum this up if the text has a semantic meaning, use <i> and <b>, but if you want a screen reader to recognise that the text should be pronounced (and toned differently), use <em> and <bold>. Regardless of which route you go down, styling these elements via CSS is always going to be possible.

Please bear in mind that accessibility plays an important factor in web development, so be mindful about the differences mentioned above and always consider people visiting your site with screen readers.

<span> vs <div>

There are 2 commonly used tags for grouping the elements: <div> and <span>. Though these two refer to group elements, there are some significant differences, which we will review now. These differences apply when used with CSS.

<div> is a widely used tag to separate different content from each other; it is a block-level element. With this tag, developers can define different blocks and style them without affecting other content.

Unlike <div>, <span> is an inline element, often used as a container for some text. While <div> defines a whole block, <span> could be used to define something different within the group. With <span> you can format inline text inside a paragraph, like so:

<p>Hello there, my name is <span style=”color: red;”>Joe</span>.</p>

Summing it up: <div> is for grouping block-level elements and styling, while <span> is for inline elements and styling.


In this next section, we'll go through some particularities related to images.

Local vs Remote Image src Value

The <img> tag is responsible for embedding and displaying images on a web page. When choosing an image to be displayed, there are 2 different options: either you choose an image that's "local" to your application, or you choose one that sits on a third party service/location.

Absolute vs relative path

If the picture is local to the application, linking to it is going to be simple because we can use a relative file path. All we need to do is to point to the file, relative to the current page; in other words, you have to find the path to the picture. The length of the path could vary, depending on where the picture is stored.

<img src=”/downloads/images/logo.jpg” alt=”my logo”>

Absolute paths, on the other hand, would require us to specify the entire path for the image like so:

<img src=”” alt=”my logo”>

Image Delivery and Optimisation

While learning about implementing images on websites, I have come across many articles discussing the importance of image optimisation. While researching this topic, I encountered a platform called Cloudinary.

In my opinion, a website is catching when it has a lot of well-placed images, videos or other multimedia content.

One of the most useful services of Cloudinary that I have encountered is the ease with which they optimise images and videos. You could upload your images (ones that you would like to use during the development), and you can access it anytime and anywhere. Furthermore, you can do things like image crop, apply effects or just changing the quality of the image. The good thing about all of this is that the image manipulation happens at server-side, so what gets delivered to the browser is an already optimised image.

While most of the time, it takes longer to load pictures on a website, you could cut down the load time with Cloudinary. The load time for images on different browsers could vary. Still, Cloudinary is also capable of automatically choosing the right file format for the browser.

Just for fun, if you want to express your artistic self, you can use a lot of filters, effects and overlays on your images using Cloudinary.

Let's take a look at an example, where I choose an image of three players from my favourite NBA team (Toronto Raptors), and I want added a crown on the top of their heads (Because they rule!). With Cloudinary's face recognition add-on, it was pretty easy. I just had to modify the URL of the image, and I got the following result, without having to do any special image modification:

Cloudinary, with the help of the add-on, detects the face automatically and based on the coordinates returned by the add-on, it's possible to place another image as an overlay (the crown image is also stored in Cloudinary), to resize the crown (and even turning it into the right angle), without me having to photoshop the image.

This is how the final URL looks like:,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.jpg

So what are all these options?

  • think about the sections separated by / as layers
  • l_cropped-crown - specifies the crown as the layer
  • g_north_east, w_, h_ specify the location of the overlay as well as the width and the height
  • g_adv_eyes is a feature to do advaned factial attributes recognition (see above)
  • fl_region_relative: region_relative flag together with a 2.8 width to scale the overlay to 280% of the width of the detected eyes
  • fl_layer_apply: applies all the chained transformations

And last but not least, here's the image itself:

Hot Linking

When talking about external images, we also need to mention the term "hotlinking". Hotlinking refers to getting an image (or linking to an image) from a third-party site (a website that's outside of our control, which is not the case with Cloudinary). Not all external images are hotlinks: if you use a picture from a forum, for example, you can easily run into legal violations.

Please also be mindful when using external pictures - especially the ones provided by a third party, because the image could be removed, easily yielding an error after a while on your site.

Sites who don't wish their image assets to be used in other locations by other sites can use a prevention technique at the webserver level by using an appropriate file such as .htaccess in the case of Apache to disable hotlinking.

The Importance of Names and Values in Form Elements

When you are creating forms, often you also add radio buttons. Sometimes selecting a radio button still selects multiple choices. It likely is because you missed adding some HTML attributes to these elements in your code.

To "group" radio buttons, we not only have to add value but also a name to each of them. When we add just a type and id attributes, the different buttons won't be connected.

Let's say we want to create a registration form where the user could choose the age with radio buttons: one selection is 10-20 and the other is 21-30. If we don't add the name attribute to the code, we could select both of the answers. To create the option for only one choice, we have to add name attribute, where both of the inputs would have the same name.

The value itself is not visible for the user. Still, it becomes essential when we send the information to a processing server because that's the value that we can extract from the form. If you omit the value from the code, the server will only receive "on" as a value of the group, which is not meaningful.

Let's look at some examples.

 <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">

With this example there will be 2 radio buttons, but we could choose both at the same time, so it’s not going to work well. We have to add the value and the name in order to get well functioning radio buttons. It is not going to change the looks, but gives “meaning” to the whole 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">

Now with adding the name, the buttons will be connected, so we could choose just one from the given possibilities.

Form and Input Element Attributes

Oh boy, here comes the discussion of forms in HTML :)


The form tags represent interactive, form elements, with which we can build many features starting from contact forms and todo lists to login forms.

However, the attributes of form tags are a bit troublesome and found it to be rather challenging.

The form opening tag should contain action attributes. It defines the location where the data should be sent when the form is submitted. Furthermore, the form should also contain a method attribute indicating the HTTP method to be used.

So, the action attribute defines where the information is going to be sent for processing while the method attribute will define the HTTP method to be used when submitting the form.

GET: The default value for submitting the form. The data sent via GET could be visible in the URL as well; therefore, it should not be used for transmitting passwords, plus it has certain limitations as well with regards to the amount of data to be sent.
POST: With this method, larger data can be sent to the server, and it won't be visible in the URL; therefore, it's the right way to transmit information such as passwords.

Did you know? On top of defining the action and method attributes, we could add a target attribute, so we could define where to open the response. _blank will open in a new page, while _self will be shown on the current page. This is not being used these days because of AJAX.


Input tags are part of form tags, and these deliver the user experience much smoother. These are the most important input attributes:

Name: It must be unique, used by the server to identify the fields after the form is submitted
Value: We can set an arbitrary value for the input element. Also, the server grabs this value when submitting a form
Required: With this attribute, you will add a rule to the input that makes the field obligatory
Placeholder: This 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 additional articles coming up on this topic, explicitly discussing them.


In my opinion, studying HTML and understanding is crucial because it is one of the fundamental building blocks of the web.

For people like myself learning HTML, there are some nitty-gritty details to go through. Still, after a bit of research, everything is understandable, and the pieces of the puzzle are all connected.

I found attributes to be the most challenging part of HTML, because they don't always have an impact on how the website looks, however, they become indispensable to create a well-functioning web page, not just on the surface, but in the backend as well.

Print Share Comment Cite Upload Translate
Select a language: