A component is a reusable, self-contained piece of code. Components are like lego blocks you can build websites with. Most websites are made by “composing” components in this way.

Examples of UI components: header, nav, hero, card, breadcrumbs, toast, chip, carousel, rating. There are so many more.

It clearly doesn’t make sense to try to memorise oodles of components in zillions of libraries. Instead, we should spend our time more wisely:

• identifying common patterns
• breaking down designs into these common patterns
• finding and reading documentation so we can use components in any library or design system

♻️ Re-use

Instead of writing out all the HTML and CSS each time, we can save our decision about how a card should work, or how a button should look, in a component and re-use it over and over. If we want to change the rules, we can change them in just one place, our component, instead of over many files or pages.

👩🏽‍👩🏽 Consistency

If we call a header component, we know that all our headers will match on our site, because they all use the same shared rules.

🍱 Composition

We can build bigger components out of smaller components and compose them onto pages to make views. This is how we build complicated interfaces quickly.

🚅 Efficiency

We can split up the tasks and work in parallel. One person can work on the button component, another on the card component. When a new developer joins the team, they can make changes to a limited part of the codebase, rather than having to understand the whole thing first.

So, we actually can’t yet, not really! We are only beginning our journey with components now. (If you are here from a scheduled review, update your answer.)

To compose pages from many small reusable pieces stored in separate files, we need a third programming language. We are going to learn JavaScript to help us do this. We could use other languages (this curriculum is written in Go), but we will start with JavaScript.

We will keep meeting this idea of small reusable pieces and composition throughout the course. Keep an eye out for it!

🧑🏿‍💻💬 Trainee: What does form mean? It’s like a set of options for a user to choose from on a website.

👩🏻‍💻💬 Mentor: Yes, that is true, that is a correct answer. A deeper answer might be form means shape. It’s how we define the shape of data. So, imagine a shape sorter. You put a square thing in the square hole; you put a round thing in the round hole. Each form field is a different shape in the shape sorter lid. That’s what we’re doing when we write forms. We are forming data with fields.

🧑🏿‍💻💬 Trainee: Of course because it makes it easier to sort it out.

👩🏻‍💻💬 Mentor: Yeah, absolutely! Because you know we’re going to post that data to a database. Our database doesn’t know what all these strings mean. We have to define the data. We have to label the data. We have to group it, and we have to do something with it: to post it to a database or in some cases, get it from a database.

So that’s the point of all this.

👩‍💻💬 Trainee: Field? It means like the window is completed with some information. A piece of data.

👩🏻‍💻💬 Mentor: Right! You put a piece into a form field; you just put one thing in there. A form has many fields, and a field is a single piece of data. It is the smallest piece.

So we structure data with forms. And we do that by defining form fields.

🧑🏻‍💻💬 Trainee: Gathering data you mean? I’d be doing a search…

🧑🏿‍💻💬 Trainee: Can I say? We can structure… an action, a connection.

👩🏻‍💻💬 Mentor: Ooh, that’s a great answer. We can structure interaction. We tell the user, what to put in the form field, and how to put that data in. We structure a really specific kind of interaction. We guide them and tell them what to do. And the way that we structure those interactions is, again, using form fields. Using HTML form elements, attributes, and values.

That’s really important to think about, because when you’re deciding what to write in a form, you need to start with ‘what data do I need.’ It’s better to do that than to try and memorise all the different types of form fields. If you think:

Then look up that last part. That’s more effective than trying to memorise all the different types of form fields.

🧑🏿‍💻💬 Trainee: Yeah, maybe checkbox?

👩🏼‍💻💬 Trainee: radio button.

👨🏿‍💻💬 Trainee: submit input type, could be submit or button itself.

👩🏽‍💻💬 Trainee: autocomplete?

👨🏻‍💻💬 Trainee: I think autocomplete is an attribute, but it’s not itself an element or element type? How about textarea ?

🧑🏿‍💻💬 Trainee: select and option

👨‍💻💬 Trainee: The input of type password…

👩🏻‍💻💬 Mentor: The point being that there are absolutely loads of different form elements!

What you need to focus on is what you’re actually doing. We’re structuring data: you are defining, naming and then grouping data. Keep that goal front and center, then your forms will work well.

🧑🏿‍💻💬 Trainee: Input means to put something in. In this case the data we put in the form.

👩🏻‍💻💬 Mentor: Bang on.

🧑🏿‍💻💬 Trainee: Do you mean validation? Don’t we need JavaScript for that?

🧑🏾‍💻💬 Mentor: We’ll learn about validation with JavaScript later on, but there’s actually a lot of validation built in to HTML. For example, if you put a required attribute on a field, the browser will not let you submit the form until you fill in that field. That’s validation: it checks against rules and rejects the data if it doesn’t meet the rules.

🧑🏽‍💻💬 Mentor: You could say that all the rules you make about what the user can put in a field are also validation. Every type we just named - input type checkbox, input type email, number, date… are rules about data.

I think the difference is that there’s no way to type into a checkbox: there’s no error message, you just can’t do it. If you type your birthday into an email field, the browser will tell you that’s not a valid email address. So one is just impossible to do and the other gives you an error message, and that’s normally what we mean by validation.

👨🏻‍💻💬 Trainee: Because if you don’t validate it, you might not be able to use it?

🧑🏾‍💻💬 Mentor: Right. Forms go wrong when you are vague. You must enforce input with validation, because if users can get it wrong, they will.

👨🏾‍💻💬 Trainee: Oh well then people will write in things that aren’t email addresses?

🧑🏿‍💻💬 Trainee: And you won’t know until you try to send them an email…

👩🏻‍💻💬 Mentor: Yeah they will. You can be absolutely guaranteed that users will do that. You have to save them from themselves, and save your database from your users!

Cascading Style Sheets are a language of style - a way to change how we visualise the DOM - using selectors, properties, and values in rulesets. They provide a way to change how a browser displays HTML.

A ruleset is made up of a selector and a list of declarations. A declaration is made up of one property and value pair. This is the syntax of CSS.

selector {
  property: value;
}

Rulesets look like this: p { background: red; }. The selector is the p in this case. This p selects all elements of the DOM tree called p and sets rules about how to show them. Selectors always come first in a ruleset.

A property is a quality, a characteristic. A value is the amount.

For a person, you might say their ‘age’ property has the value of 40. For an element, you might set the width property to the value of 100%.

Within a ruleset, multiple declarations may set values for properties, and each declaration ends with a semi-colon (;), e.g. p { background: red; color: blue; }.

You learn them by using them. You look it up here: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference. Another thing you can do is look at the autocomplete in Devtools.

via GIPHY

A cascade is a stream or sequence of a things where each thing affects the next. You might imagine pouring champagne into a tower of glasses. The champagne flows into the top container; it then cascades into the next container; etc. In CSS we’re actually pouring from many bottles into one tower.

So in CSS ’the cascade’ means the order or sequence of the rules as they flow into the DOM tree according to CSS precedence.

Several rules may apply to one element, and they are applied in a particular order, with later, more specific, or more important rules adding to or overriding ones that have already been applied.

It means the order rules are applied.

One way rules are applied in CSS is inheritance: children inherit from parents. If a parent node has red text, all its children will inherit that red text color. But when another rule with higher precendence comes and overrules, it replaces the rule which had lower precedence. An explicit rule targeting an element directly overrules a rule it inherited from its parent.

Inheritance forms a hierarchy. The elements being styled are hierarchical - with children inheriting from (but perhaps overriding) parents.

Everything in CSS is determined by order. Order is so important in CSS because CSS is a declarative programming language that programs the layout of boxes.

CSS renders the nodes in our DOM tree as nested boxes, and we program their appearance using fonts, colours, and spacing.

It means that we describe a set of rules, and all of the rules are processed and then applied, in a well-known order, in one go. The browser works out how to apply the rules. You don’t write for loops or if/else statements; there are no functions as such; you just declare the outcome with some rules, and those rules get applied.

In CSS you do the ‘what’, and the browser does the ‘how’.

Specificity is a weighting system for CSS rules. The more specific your selector, the more power it has. For example: IDs can only ever mean one node. IDs are unique, so they are more specific than classes, which could mean many nodes.

Classes added to html element are more specific than just a plain element selector, as a class of p (e.g. p.instruction) is more specific than just all p. If you get two rules with the same specificity then the one that comes last in the order wins.

The browser sorts all your rulesets, or declarations, into a defined order according to the power, or weight, of the declaration and applies the result, like a game of cards where higher value cards beat lower value cards.

Stronger rules override weaker rules. Everything is sorted and sorted until eventually a final value wins out and the view is rendered.

This only applies where there is a conflict. If both p { color: red; background-color: blue; } and p.instruction { color: orange; } apply to the same element, the color will end up orange because it was specified in a more specific rule, but the background-color will still be blue because nothing overrode that property.

The browser sorts like this:

1. Match the media
2. Sort by origin
3. Sort by specificity
4. Sort by document order

Specificity forms a hierarchy. CSS rules are hierarchical - with more specific rules being applied after (and perhaps overriding) less specific rules.

Order means ‘what comes first?’.

Another way to think of ‘earlier and later’ is ‘farther and nearer’. The closer the declaration is to the node in the DOM, the ‘later’ it is in the CSS. So an inline style overrides a style set in a style block, which overrides a stylesheet linked in the head, which overrides any stylesheet linked higher up in the head, which all ultimately overrides the user agent style that comes in the browser.

Identify clearly. Name explicitly.

Render means to hand over, or to give back. In the browser, it means to show the result of all these computations we have talked about. It turns the code into pixels and paints them on your screen. So it’s the end result - how the page finally looks on your screen.

HTML stands for Hypertext Markup Language. Markup means tags that go around content like text, pictures, videos, to “mark up” or describe what they are.

HTML tags look like this: <p>This is a paragraph.</p>. They typically surround a piece of content, like a block of text, and describe it as such. In this case, the <p> tag describes the content as a paragraph.

Examples of HTML tags include <mark>, <section>, <header>, and <button>.

Nesting is like Russian dolls - or tupperware - a box in a box in a box. We nest tags inside each other. That’s how we write HTML. For example:

<article>
  <header>
    <h1>Title</h1>
  </header>
</article>

Here the <header> tag is nested inside the <article> tag, and the <h1> tag is inside the <header> tag.

Not all tags are nested, in this example:

<article>
  <header>
    <h1>Title</h1>
  </header>
  <p>Some content</p>
</article>

Both the <header> and <p> tags are nested inside the <article> tag, but the <header> and <p> tags are not nested inside each other - they are siblings.

Chrome, Firefox, Safari, Lynx, JAWS, Brave, Edge, Vivaldi, Opera…

It produces what we see - it produces a visual representation of the document. But in a little more detail: the browser parses the HTML we write, executes the linked Javascript, loads the CSS, media, and other resources, and produces a model of our document, called the document object model. It produces an API called the DOM.

It uses all of this information to decide what to show us.

Make sense of. Analyse syntactically.

The rules that structure language, so it can be understood by someone else. I put words in an order, according to rules, I structure meaning and you can get that meaning back out if you know the same rules. Programming languages are the same - they each have a set of rules, they each have a syntax.

Think about HTML and CSS. They use different syntaxes.

For instance, when grouping together the information about an HTML tag, you may write: <h1 class="main-title">This is a title</h1> - there are several pieces of syntax here, and one is that the tag is opened by <h1> and its contents are done when you see </h1>.

In CSS, on the other hand, you may have a rule like h1 { color: red; } - we group together declarations applying to the selector between {}s.

HTML and CSS use different syntaxes, even though some of the concepts are similar.

API stands for Application Programming Interface.

Imagine you want to know what the weather is going to be tomorrow. You may have an app in your phone which can tell the weather, but it doesn’t know the weather everywhere - it will ask some service on the internet.

That service on the internet is an API. The service on the internet can be asked specific questions. Maybe it can be asked “What will the temperature be tomorrow in London?” or “Tell me the next week’s temperatures for every city in the UK?” or “When will it next rain in Glasgow?”.

And when you ask a question, you need to know how to interpret the answer. If you ask “When will it next rain in Glasgow”, and get back an answer of “5”, what does that mean? In 5 minutes? In 5 hours? It’s been raining for the last 5 days?

The service may have a lot of knowledge, but it can only be asked specific questions. And the app on your phone needs to know how to interact with it. “What can I ask/tell the API?”, “How do I ask/tell it those things?”, and “How should I interpret the answers I get back?” are all good things to think about when thinking about an API.

The DOM is an API. From our code, we can tell it things (like “All h1 tags should be blue”), and it will take action as a result. One of the ways we can interact with the DOM API is by giving it a CSS file - it will apply the CSS file when it’s working out how to display a page. The CSS specification helps us understand how we can interact with the API - what we can tell it, and how we tell it those things.

Semantics means meaning. Semantic HTML is meaningful code: each piece of data marked up with correct, that is to say, descriptive tags. A heading has an h1 tag. A button has a button tag. There are only two html tags that deliberately have no meaning (div and span).

These tags are then interpreted by APIs to give functionality to the page. A button tag is interpreted by the browser as a button, and so it can be clicked, or triggered in many ways. A heading tag is interpreted by the browser as a heading, and so provides a traversible page outline to a screen reader.

HTML tags are powerful because they are meaningful. They are meaningful because they are semantic. Semantic HTML is powerful HTML.

HTML tags are powerful because they are meaningful. They are meaningful because they are semantic. Semantic HTML is powerful HTML.

The better structured your document, the more meaning you can pack into it, the more powerful your code is, the better it will work in more contexts, and more things will be able to interface with it.

One place semantic HTML is useful is that if you use a <footer> tag instead of a <div> tag, a screen reader can understand that it is a footer, and treat it specially.

Another place it’s useful is that another programmer reading the CSS you’ve written can see a header { ... } block and know that you’re styling the header, rather than needing to work out what div.top { ... } means and applies to.

By using semantic conventions, we make it easier for everyone and everything to understand what we’re trying to express.