OE1-5.1 Web Basics, HTML5 & CSS

Standard web platform behaviour and the frameworks named in the course outline — written September 2026

What this is and why it exists

One picture holds this whole subject together. A browser asks a server for a resource, and the server answers with bytes plus a statement of what those bytes are.

Everything else, in every topic of this course, hangs on that exchange. Get it clear first and the rest has somewhere to attach.

The vocabulary

  • Browser — the program that requests resources and renders them.
  • Web server — the program that answers those requests.
  • URL — the address naming a resource: which protocol, which host, which path.
  • MIME type — the declaration of what a response's bytes are, such as a page, an image or data.
  • HTTPS — the same protocol carried over an encrypted, authenticated connection.
  • Element — one item of markup, such as a heading, a paragraph or an image.
  • Block element — one that takes a whole line of its own.
  • Inline element — one that sits within a line of text.
  • Cascade — the rules deciding which style applies when several could.

The mental model

The request and response cycle is the model. The browser sends a request naming a resource by its address. The server replies with a status, some headers and a body. One of those headers declares the type of the body. That declaration tells the browser whether to render a page, display an image, or hand the bytes to something else.

That type declaration matters more than it looks. The same bytes mean different things depending on what they are announced as. The browser trusts the announcement rather than guessing from the file name.

The secured version of the protocol adds two things rather than one. It encrypts the exchange, so nobody in between can read it, and it authenticates the server, so you know which server you reached. The second is the part people forget, and it is the one that matters when a network is hostile.

Now the markup, and one principle governs all of it. Markup says what a thing is. Styling says how it looks. Keeping those separated from the first page you write is the habit that decides whether a site stays maintainable.

That principle produces a rule with a history. Tables are for data, not for layout. Using them to arrange a page was standard for years. It left pages that could not be restyled and could not adapt to a small screen. A screen reader announces a table as a table, so the content read as nonsense. Inheriting that lesson is cheaper than learning it.

Forms are where the web stops being read-only. A form collects input and sends it to the server, and it is the front end of everything in the later topics. Anything arriving from a form was typed by someone you do not control, which is a point the framework topic returns to.

Grouping elements is what makes layout and styling possible, and there are two kinds. A block-level grouping element occupies a whole line and is what you wrap sections in. An inline one sits inside a line and is what you wrap a phrase in. Neither carries any meaning of its own, and that is exactly their purpose: they exist to be positioned and styled, not to say anything.

Getting the block and inline distinction right early saves a great deal of confusion, because the layout behaviour of the two is completely different.

The two-dimensional layout system is the modern way to arrange a page, defining rows and columns and placing content into them. It replaced a long history of workarounds that used mechanisms designed for something else. Learning it first means never learning those.

The cascade is the part that surprises people and repays attention. Several rules can apply to the same element, and a defined order decides which wins. How specifically the rule selects the element, where it was declared, and in what order. When a style does not take effect, it is almost always the cascade rather than a typing error. Knowing the ordering turns a mystery into a lookup.

What you should now be able to explain or do

Describe the request and response cycle including the type declaration. Say what the secured protocol adds beyond encryption. Keep markup and styling separated and say why. Explain why tables are not used for layout, including the screen-reader reason. Distinguish block from inline grouping, and explain what the cascade decides.

Check yourself

It tells the browser what the bytes are, so it knows whether to render a page, show an image or pass them elsewhere. It does not guess from the name.

Authentication of the server. You know which server you reached, which matters as much as nobody being able to read the exchange.

The result cannot be restyled or adapted to a small screen. A screen reader also announces it as a table, so the content reads as nonsense.

Exactly that. They exist to be positioned and styled, and carrying no meaning is what makes them safe to use for it.

The cascade. Another rule selects the element more specifically, or comes later, so it wins.

Go deeper

We haven't checked most of these for screen reader use yet.

Back to Web Basics, HTML5 & CSS: work through the checklist