HTML & CSS Primer

From Design Software to Code

You already know how to design. The challenge is understanding how code accomplishes what you do instinctively in Illustrator, InDesign, or Photoshop.

In those programs, you create objects and place them anywhere on the page. Click, drag, done. Behind the scenes, the software writes a long list of instructions describing what you made—position, size, color, relationships. You never see those instructions. The interface hides them.

Code is that list of instructions without the interface.

Each line of code is a potential design object. Your job is learning to see it that way.

Two Languages, Two Jobs

Web pages are built with two languages that handle separate tasks:

HTML (HyperText Markup Language) defines what the content is. This is a headline. This is a paragraph. This is an image. This is a list.

CSS (Cascading Style Sheets) defines how it looks. This headline is red, 48 pixels tall, and positioned in the upper left.

Think of HTML as the content and structure. CSS as the form and appearance. You need both.

HTML: Marking Up the Content

Before anything can be styled, it must be marked up. This means wrapping each piece of content in tags that identify what it is.

A tag is an instruction to the browser. Tags come in pairs—an opening tag and a closing tag—with content between them:

<p>This is a paragraph.</p>

The <p> tells the browser “a paragraph starts here.” The </p> tells it “the paragraph ends here.” Everything between becomes a paragraph element—an object you can style.

Common tags:

• <h1> through <h6> — Headlines, from most important to least
• <p> — Paragraph
• <div> — A generic division or container
• <ul> and <li> — Unordered list and list items
• <img> — Image (replaced by the image itself, no closing tag needed)

The first step in building any web page is marking up all the content. Every piece. Only then can you start giving it form.

CSS: Giving Form to the Content

Once content is marked up into elements, CSS rules control how those elements appear.

Here’s where your design software experience helps.

In InDesign, you draw a text box, then look at the toolbar. It shows X and Y coordinates (distance from the top-left corner), plus width and height. You could type numbers directly into those fields to position and size the box precisely.

In CSS, you write those same values as a rule:

p {
	position: absolute;
	left: 300px;
	top: 500px;
	width: 200px;
	height: 100px;
}

This says: take every paragraph, position it 300 pixels from the left edge, 500 pixels from the top, make it 200 pixels wide and 100 pixels tall.

In InDesign, you might add a 1-point stroke around the box and some inset spacing to keep text from touching the edges. You’d use the Text Frame Options dialog.

In CSS, you add properties to the rule:

p {
	border: 1px solid black;
	padding: 6px;
}

Same result. Different method.

In InDesign, you select a word and make it bold using the menu or keyboard shortcut.

In HTML, you wrap the word in a tag:

<p>This word is <strong>important</strong>.</p>

Then CSS defines what “strong” looks like:

strong {
	font-weight: 700;
}

The principle is consistent: HTML identifies the element, CSS styles it.

How Content Flows

Here’s where code diverges from design software.

In Illustrator or InDesign, objects sit wherever you put them. They’re independent. Move one, the others stay put.

On the web, elements are chained together in a document flow. By default, they stack from the top of the page downward, like paragraphs in a word processor.

Block elements (paragraphs, headlines, divs) behave like paragraphs—each one starts on a new line and takes up the full width available. They stack vertically.

Inline elements (links, bold text, images) behave like characters in a sentence—they flow horizontally, one after another, wrapping to the next line when they run out of room.

Think of it this way: block elements are paragraphs. Inline elements are words within those paragraphs.

The Upside-Down Block Stack

Imagine a child stacking blocks. Now flip it upside down—blocks stacking onto the ceiling, hanging down.

That’s how web elements work. They originate from the top-left corner and accumulate downward. The first element sits at the top. The next one appears below it. Then the next.

If you delete an element, everything below it shifts up to fill the gap. The chain adjusts. This is fundamentally different from fixed-position print design.

Why? Because the web is fluid. A page might be viewed on a phone, a tablet, a laptop, a giant monitor. The layout must adapt. Elements need to reflow depending on the viewport—the browser window.

This flexibility is the point. It’s also what makes web layout feel unfamiliar at first.

Breaking the Flow

You can remove elements from the document flow and position them independently, like objects in Illustrator. CSS properties like position: absolute let you place an element at exact coordinates, ignoring everything else on the page.

But this is usually the wrong approach for web design. Fixed positions break when the viewport changes size. The layout that looked perfect on your laptop falls apart on a phone.

Instead, web layouts use the document flow strategically—organizing elements so they reflow gracefully across different screen sizes. You’ll learn techniques for this: Flexbox for arranging elements in rows or columns, Grid for more complex layouts, media queries for adapting to different devices.

For now, understand that the default flow exists for a reason. You’ll work with it more often than against it.

The Design Happens Before the Code

This is the part that surprises design students: there’s little design in the act of coding.

All the creative work—composition, typography, color, hierarchy—happens before you write a single line of HTML. Thumbnails, wireframes, mockups. The same process you’d use for any design project.

Coding is execution. You’re translating a design you’ve already made into instructions the browser can render. It’s closer to prepping a file for print than to designing the piece.

The process:

1. Sketch thumbnails to explore layouts
2. Draw wireframes to establish structure
3. Create mockups to define the visual design
4. Write HTML to mark up the content
5. Write CSS to apply the design

Only steps 4 and 5 involve code. The design decisions are already made.

Coding is problem-solving—figuring out how to achieve in code what you designed in your mockup. It can be satisfying in the way puzzles are satisfying. But it’s not where the design happens.

What Comes Next

You have two weeks to learn HTML. Then two weeks for CSS. The rest of the semester applies what you’ve learned to real projects.

The learning comes through repetition. Mark up content. See what happens. Mark up more content. The tags will become familiar. The logic will start to make sense.

It’s not difficult. Creating effective communication in a crowded field—that’s difficult. The code is just the medium.