HTML and CSS

HTML and CSS

So often as web developers, we stop thinking about why we are using HTML and CSS. Our markup and our styling are automatic to us, steps that must be done in order to present our super cool application in some way.

I want to delve into the philosophy behind using HTML and CSS with the intention of giving more insight into the why behind using these tools, with the intention of improving how we use them.

Content

Always, always start with content. I honestly believe this is non-negotiable. Sure, that can be seen as a dogmatic, controversial statement. However, HTML should not be seen as a producer of content. Instead, the idea that I want to explore today is about HTML providing context to content. In order to provide context, there must be content.

Let’s take some straightforward text about me:

Don Burks
I teach at Lighthouse Labs.
I have no hair.
I love coffee.

By itself, there is no hierarchy outside of what the pattern recognition engine in my lizard brain implies. I know my name is my name, and therefore make it be the most important. Also, it’s the first piece of content I consume out of this block, so my brain says that if it’s on top, it must be the most important. However, when a device is consuming this content, there is absolutely no structure to it. No data hierarchy, no layout, there is no context to this content.

HTML

Using HTML, I can add context. Regardless of whether it is another person or an app consuming this content, I can communicate the context that this content has implicitly, using HTML.

<h1>Don Burks</h1>
<ul>
	<li>I teach at Lighthouse Labs.</li>
	<li>I have no hair.</li>
	<li>I love coffee.</li>
</ul>

In each case where I needed to give context to a piece of content, I have used a tag (defined as text within angle brackets, or < >) to markup that content. In doing so, I have demarcated with HTML that the content within the tag should have the context of the tag’s name.

For example, this HTML I have chosen gives this content a very clear context. I can see that I am presenting two very distinct pieces of content here. One is a header bit of content, my name in this case. It has been marked up using an <h1> tag, the most important of the <h1> - <h6> tag family. The other is a list, as indicated by the unordered list (or <ul>) tag. Then, within the list are three more items of data. For each of these, the list item, or <li> tag has been chosen. Those data points are in a different tier of hierarchy than the header, and are subordinate to the list.

I can take this further by adding more HTML to group things together, getting semantic with my tags and really implicitly declaring all of the context of my content.

<!doctype html>
<html>
	<head>
		<title>Some Facts About Me</title>
	</head>
	<body>
		<section>
			<header>Don Burks</header>
			<article>
				<p>Some facts about me:</p>
				<ul>
					<li>I teach at <a href="https://lighthouselabs.ca" title="Lighthouse Labs">Lighthouse Labs</a>.</li>
					<li>I have <em>no</em> hair.</li>
					<li>I <strong>love</strong> coffee.</li>
				</ul>
			</article>
			<img src="http://donburks.com/public/images/don.png" alt="Don Burks" />
		</section>
	</body>
</html>

This is now a complete page, and I have added more context to my content. I have converted the H1 tag to a header tag, which better represents its role within the content. I have added an anchor to the words ‘Lighthouse Labs’ to indicate that those words as an element of content are anchored to an external document.

I have added emphasis to the ‘no’ in ‘I have no hair.’. I have indicated that the word ‘love’ in the sentence ‘I love coffee.’ should be considered strong in context. I have wrapped the primary content in a <section> indicating that all content within that section is related. The <article> tag is there to indicate the primary content for that section. And there’s an image of my head. What is important to realize about these changes is this:

I have not dictated appearance with any of my markup.

While I know as a developer that browser applications have CSS built in and will display these elements in various ways, none of my considerations for adding these tags are about how it will appear. Every consideration for choosing these tags is about the context of my content, not its presentation.

Even without CSS and the appearance/presentation, this is still human-readable. I wouldn’t recommend it as light reading on a Friday night, but I can view this content with its markup and understand its hierarchy without hesitation. This is accomplished only because I have focused on using markup to indicate context, instead of to facilitate appearance.

Attributes

Examining the <a> and the <img> tags above shows that I have added attributes. I do not have to add an href attribute to indicate that an anchor existed on that text. But the attribute adds to the context by indicating where the anchor connects. Similarly, with my <img> tag, the src attribute indicates from where the media element should retrieve its content.

If we look at attributes such as id and class, these attributes still do not approach the presentation or appearance, only context. An id attribute is going to identify (hence the name) that the content of that HTML element should be considered as unique and distinctive, separate from all other content. That id will contain a label that uniquely names the content.

Whereas the class attribute indicates that all elements with that same class value share some similar characteristics. A “class” of content may not be geographically near on a page to another member of that class, but as a consumer of content I am given the context that all content in this class shares a certain hierarchy or possesses characteristics that group it together.

Last, it is worth noting that the title attribute on my anchor and the alt attribute on my image are not there for getting tooltips in the browser. They are there to give context to consumers of that content other than web browsers. Screen readers, for example, or SEO bots, or perhaps an e-paper browser.

CSS

Keeping the presentational elements to the CSS language mean that we have a complete separation of concerns between our content and how it will be displayed/rendered. And this is ideal. Structuring HTML for the purposes of presentation often results in extremely verbose and unnecessarily complex markup in your document.

CSS, without HTML, is truly pointless. In most cases, CSS is structured to only work with a particular configuration of HTML. It becomes very difficult to take the CSS from one page and apply it to another from a different site. CSS is a set of presentational rules, elevating the context given a particular set of content to a visual level.

Browsers have CSS built-in. The default stylesheet present in all browsers defines the appearance of all HTML elements. Base CSS and HTML is 100% responsive. Always has been, likely always will be. It’s the CSS we add to projects that screws up responsiveness.

Base CSS and HTML is 100% responsive.

The process of adding CSS is to override existing properties in the browser’s default stylesheet in order to get the presentation you want. If you are needing to target specific elements or groups of elements, then that is the time to add IDs and classes, because you are adding context to that content that stipulates that an element with an ID is a unique piece of content with its own meaning and characteristics, and a class of elements all share characteristics.

Summary hello

This is probably a very different way to look at HTML and its relationship with CSS than you might have experienced before. However, it’s a great way to get a solid understanding of the separation of concerns, it focuses on a content-first mentality, and it encourages a minimum amount of markup and presentation work. Overall, I assert that this philosophy leads to cleaner, more semantic, and more maintainable code.


If you have any comments or questions about this post, please feel free to shoot me an e-mail at don (at) donburks (dot) com. I would love to hear from you and continue the conversation.

Published 15 Feb 2017

Writing better code by building better JavaScript
Don Burks on Twitter