Step One on My Coding Journey

Michael Fares
10 min readFeb 16, 2021

Through my myriad pursuits in life thus far, I have always found myself inspired by the Chinese Philosopher Lao Tzu’s timeless wisdom that “a journey of a thousand miles begins with a single step.”

At times when seeking motivation, this quote often reminds me that when a new pursuit feels so gargantuan, it is often simply that the hardest part is to start.

In moments of self-reflection I’ve found the greatest pitfall to my motivation can often be simply overthinking a new project or pursuit. If I think too much about starting something, anticipating every hypothetical challenge, then I am more than likely to end up just thinking myself out of feeling motivated to act in the first place.

But for the times I have chosen to just act and take the first step, I have often found I want to keep going, and that as long as I keep a strong work ethic, flexible mindset, and right attitude, then the rest of the journey can be an exciting ride that tends to almost magically pull me along.

I have so far found this no less true since I started upon my latest goal to learn to code.

Since deciding to take the first step in my journey learning to code by joining Austin Coding Academy’s Part-Time Full-Stack Web Development Bootcamp this month, I feel excited and enthusiastic about traveling the long but rewarding road ahead.

First, a little more about my background to illustrate the things that excite me most about learning to code, and how I think it can change the world for the better.

I am half-Lebanese and half American and a 3rd culture kid who grew up in Saudi Arabia where my dad worked and our family lived for my entire childhood. Starting from age 4 and until adulthood, I travelled constantly between the US, Lebanon, and Saudi Arabia, along with many other stops along the way.

I was therefore privileged enough to be able to discover first hand from a young age something I will always fundamentally believe to be true: that despite ultimately superficial differences like culture, language or religion, we the people who inhabit planet earth share much more in common with one another than not. The things that might divide us are dwarfed by the underlying commonalities in basic human experience and condition that can powerfully unite us.

That is why learning to code excites me, because I feel like at this stage of my career, it is the next natural step on my path doing my part to contribute to a world where more and more people have the chance to discover, celebrate, and innovate upon our shared experiences, aspirations, needs, and frustrations as a human race.

Speaking of career: In my current field as an educator who teaches about Arabic language and culture, I have seen technology take on an increasingly important role in the learning of my students and play an increasingly central role in how they relate to and connect to the rest of the world. The opportunity to learn to code therefore excites me because it will allow me the chance to build things that make the work of education more engaging, more connecting, and perhaps most importantly from my perspective — more equitable economically and socially.

But just in general there is also something so exhilarating to me about how coding offers the potential for me to create and implement something exactly as I have envisioned it in my mind.

But enough about me for now — on to my first coding blog post about HTML and CSS!

The HTML Doctype Declaration and its Importance

HTML, which stands for hyper-text markup language, forms the backbone of most pages and websites on the internet. A typical page on the web, no matter how complex looking or interactive, is first coded in an HTML file, which the browser interprets to know the basic content of the page. The browser does this by rendering the HTML file into the document object model tree, also known as the DOM tree. The DOM tree is critical in that it provides the browser with a map of every single HTML element on the page in the form of a “family tree” that catalogues all parent-child element and sibling element relationships, where each element is then referred to as a node on the tree with a specific position. Each node can then be uniquely manipulated by CSS styling or by Javascript interactivity.

Long story short, this is why every HTML file must be started with the doctype declaration: <DOCTYPE! html>. Without this declaration, the browser will not be able to convert the HTML file into a DOM tree, and if the page even loads at all, it will look like an ugly webpage from the 90’s with none of the CSS or Javascript working.

HTML Elements vs HTML Tags

While many people use the term tag and element interchangeably, there is a subtle important difference. In the case of most HTML tags, taking for example the paragraph tag, the tag can either be an opening tag <p> or a closing tag </p>. However, there is no such thing as an “opening element” or “closing element”. Rather, an HTML element is technically the opening tag, the closing tag, and everything in between. In other words, the opening and closing HTML tags are what define the element for the browser, showing where the element starts and where it ends. In between opening and closing tags of the element, there need not be only text, but there can also be other sets of opening and closing tags that set off child elements within the larger parent element. For example, my paragraph element above could have nested within it a span element set off by a set of opening and closing span tags:

<p>
This is a paragraph element with content, and inside of it there is a <span> child span element with its own content</span> and now I am finishing off the paragraph.
</p>

A final important note is that there are some HTML elements marked by only one “opening” tag that does not have a closing tag, such as the image tag<img> or the line break tag <br>. These are called self-closing tags or empty tags, and as elements they are sometimes referred to as void elements.

CSS: Cascading Style Sheets and What the “Cascade” Part Means.

The cascade is critical to what gives CSS its power to efficiently apply styles to an HTML page without redundancy. To understand how the cascade works, I like to use an analogy where I think of the HTML page as a new house with blank white walls and the CSS as an interior decorator I hired. Suppose I wanted to have a uniform style throughout my house, like say: blue walls, beige tiled floors, and chic, Edison-style lightbulbs. I can simply tell my interior decorator this and they will understand what to do to make the house look how I want.

In the same way that I don’t have to walk my decorator through every single room and point them to every single wall, floor, and light fixture only to repeat the same exact style preferences every single time, so too thanks to the cascade I do not have to keep repeating the same CSS style for each individual element I want to have that style. Rather, I can simply set a CSS style rule for a particular element by using an element selector, and then the rule will “cascade” downward and apply to every instance of that element on the page. For example, if I had 10 paragraphs on my page and I wanted all of them to have blue color text, I could simply set the rule: p {color: blue}, without having to set this same rule for each and every paragraph tag in the HTML.

Moreover, due to the cascade most (but not all) child elements inherit by default the values of the style properties declared for their parent elements. For child elements that do not inherit parent element styling by default, we can make this happen anyways by simply using the inherit value. This value is accepted by all CSS properties, and so can be used to tell any child element property to have the same style value that was assigned to the parent element.

If and as needed, the cascade can also be “overridden” by making a more specific style declaration. This is done by using more specific CSS selectors. Let’s return to the house analogy for a little to see what this means. Suppose I changed my mind and want the exact same general style except that now I want my kitchen to be painted red, and not blue like the rest of the house. I just tell my decorator “I want blue for all the rooms, except for the kitchen, which should be red”.

In the same way but with CSS, if I want to similarly choose only the first paragraph on my page and make its color red instead of blue, one way I can do so is by assigning a class to only the first paragraph element in my HTML code, and then use a class selector in my CSS to create a new style rule for paragraph 1 only that will “override” the rule set by the the more general element p selector, the later which will still apply to the rest of the paragraphs. Examples of what this would look like in HTML and the corresponding CSS code, respectively, are below:

HTML

<p class="first-paragraph">This is the first paragraph with class of "first-paragraph" assigned</p>
<p>This is the second paragraph, to which the general rules set for the p selector in CSS will apply</p>
<p>This is the third paragraph, to which the general rules set for the p selector in CSS will apply etc..</p>

CSS

/*Less specific element selector*/p {
color: blue;
}
/*More specific class selector, which comes further down in the cascade*/.first-paragraph {
color: red
}

Basically, CSS assigns style rules according to how specific the selector is: if I choose a more specific selector and set it unique style rules for it, then these will effectively override the more general element selector rules set previously in the cascade.

It is for this same reason why, in determining which HTML elements match which CSS selectors so as to apply the style correctly, the browser actually reads the CSS selectors from right to left, as this results in a much faster match between each HTML element and any corresponding CSS selectors.

This obviously does not matter for selectors that only consist of one element, but for the various kinds of more specific combinator selectors (which are too vast to go into here), it makes a critical difference. For example, assume we have the combinator child selector p > span to apply a specific style to every span element that is a child of a paragraph element. If the browser read the selector from left to right, it would have to look at every single paragraph element in the HTML and then check if it has span elements as children.

Assuming for simplicity that only one paragraph element in my HTML has spans as children, then reading the CSS selector left to right would be very inefficient for the browser, since it will have to look at all the other paragraph elements and then look to see if they have spans as children, even though none of them will. However, reading the p > span declaration from right to left allows the browser to look for the spans first and then check that they are children of a paragraph element, which will result in a match much sooner.

In other words, the browser determines which CSS selectors match an html element by starting from the innermost nodes of the DOM tree (in this simple example the child spans) and then working outward (in this simple example the parent paragraph element), since this guarantees the best probability for the fastest possible match.

An important consequence of this is that less specific a CSS selector, the more quickly the browser will be able to match it with the correct HTML elements. Therefore, although highly specific selectors might offer a lot of versatility in singling out elements for unique styling on a page, if we can nonetheless find ways to achieve the styles we want while also keeping our CSS selectors relatively broad, this means that the browser will be faster to render those styles on the page.

From my perspective and current understanding, not being any more specific than we need to with CSS selectors also would seem to result in much more readable and maintainable CSS code.

Three Ways to Use CSS with an HTML File

There are 3 Ways to use CSS with an HTML file to style a webpage: Inline CSS, Internal CSS, and External CSS.

I’ll illustrate all three with the blue color paragraph example from earlier.

Inline CSS involves using a style attribute directly inside of the HTML tag as in:

<p style="color:blue;">A blue paragraph</style>

Internal CSS involves placing opening and closing <style> tags inside the <head> tag of the HTML document and then making all CSS declarations inside the <style> element, as in:

<DOCTYPE! html>
<html>
<head>
<style>
p {
color: blue;
}
</style>
</head>
<body>
<p>This is my blue paragraph</p>
</body>
</html>

External CSS involves placing a link to a separate CSS file inside the <head> tag of the HTML document, and setting the relation attribute in the <link> tag to “stylesheet” as in:

<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="styles.css">
</head>
<body>

<p>This my blue paragraph whose style is set in the separate, linked CSS file</p>

</body>
</html>

Of these three methods, linking an external CSS file is by far the most preferred because it allows for more modular and more maintainable CSS code that can also be more easily debugged.

That is all for now. I hope you liked reading about the first step in my coding journey as much as I liked writing about it, and will stay tuned for more!

--

--

Michael Fares

I am a Web Developer, Educator, Lifelong autodidact, 3rd Culture Kid, and Citizen of the World.