Three languages, three jobs
A website made by hand is built from three technologies that each have a distinct responsibility. Keeping those responsibilities separate is the single most useful idea in the whole subject.
- HTML describes content and structure: this is a heading, this is a paragraph, this is a list, this is a link, this is an image, this is a form.
- CSS describes presentation: colours, fonts, spacing, layout and how the page adapts to different screen sizes.
- JavaScript describes behaviour: what happens when someone clicks, types, scrolls or when data arrives.
A useful test is to ask what would happen if one layer were missing. Without CSS, the page would still be readable, just plain. Without JavaScript, a well-built page would still show its content and links. Without HTML there would be nothing to style or script. Building in that order, content first, then style, then behaviour, tends to produce sites that are faster, more accessible and easier to fix.
What HTML actually does
HTML marks up text with elements. Their value comes from meaning, not appearance. A heading element says “this is a title for a section” and a list element says “these items belong together”. Browsers, search engines and screen readers all use that meaning.
A minimal page has a head, which holds information such as the title and links to styles, and a body, which holds what visitors see:
<main>
<h1>My Projects</h1>
<p>A short introduction.</p>
</main>Some habits make a big difference:
- Use headings in a logical order, with one main heading per page.
- Choose elements for their meaning, such as navigation, main content and footer regions, rather than relying on generic containers for everything.
- Give images a short text description for people who cannot see them.
- Label form fields properly.
These habits help accessibility and also tend to help search visibility, because a clear structure is easier for software to understand.
What CSS does
CSS selects elements and sets rules for how they look. It controls the typography, colour, spacing and the arrangement of blocks on the page. Three ideas deserve early attention.
The cascade and inheritance. Rules can come from several places, and the browser decides which wins based on specificity and order. Many text styles pass down from parent to child elements. If a style seems to be ignored, a more specific rule is often overriding it.
Layout. Modern CSS offers dedicated layout systems for arranging items in rows, columns and grids. You rarely need tricks. Learning how the browser’s box model treats padding, borders and margins explains most mysterious spacing problems.
Responsive design. People view sites on phones, tablets and large monitors. A sensible approach is to design for a narrow screen first, use flexible units and let the layout widen, adding rules for larger screens only where needed. Always test with the browser’s device preview and, if possible, on a real phone.
Keep your style rules in a separate file shared by all pages, so a change to a colour or font happens in one place.
What JavaScript does
JavaScript runs in the browser and can change the page after it loads: show or hide a menu, validate a form, filter a list, fetch fresh data. A small site often needs very little of it. Reaching for scripts when a plain link or a CSS feature would do adds weight and more things to break.
When you do use JavaScript, a few principles apply:
- Make the page useful without it where possible, and use it as an enhancement.
- Keep scripts in separate files, and keep functions small and named clearly. The principles of readable code apply as much here as anywhere.
- Treat anything coming from a user or an outside source as untrusted. Do not insert it into the page without care, because that is how injection problems arise.
- When your page fetches data from other services, understand how web APIs work, and never place private keys into scripts that visitors can read; see API key secrecy.
Anything that runs in the browser is visible to the visitor, so a browser script is never a safe place for secrets.
Planning a small site
Before writing code, spend time on paper.
- Purpose. What is the site for, and who will use it? A portfolio, a club page and a project log need different things.
- Pages. List them. For a small site this is often a home page, an about page, a page of projects or articles, and a contact page.
- Navigation. Decide how a visitor gets from any page to any other. Keep it short and consistent, with the same menu everywhere.
- Content. Gather the actual text and images before designing around placeholders. Layout built around real content holds up better.
- Look and feel. Choose a small set of colours, one or two fonts and a consistent spacing approach. A simple, restrained design usually looks more professional than a busy one.
A rough sketch of each page, even on paper, helps you see which elements repeat and which are unique.
Structuring files
A small site needs a tidy folder, not a framework. One common arrangement is an index page at the top level, additional pages alongside it or in subfolders, and separate folders for styles, scripts and images. Use lowercase file names without spaces, and keep names descriptive. A folder with an index page gives you clean addresses, and consistent naming makes links easier to maintain.
Remember that every page repeats the same header, navigation and footer. In pure hand-coded HTML you copy those parts into each page, which becomes tiresome as the site grows. This is a point where many people move to a static site generator that assembles pages from templates, and it is worth knowing about before your site has fifty pages.
Habits worth building early
Even for a small site, some practices save time:
- Version control. Keeping your files under version control lets you try changes without fear and go back if something breaks.
- Validation and testing. Run your HTML through a validator, check the site in more than one browser and test the keyboard navigation. Sometimes simple automated testing is also possible for scripts.
- Debugging. Browser developer tools let you inspect elements, see which CSS rules apply, read console errors and watch network requests. Learning them is a big step up, and a sensible debugging strategy turns them into a fast way to find faults.
- Performance. Resize and compress images, avoid unnecessary scripts and keep pages light. Fast pages are better for visitors, particularly on slow mobile connections.
- Accessibility. Check colour contrast, make sure everything works from the keyboard and use meaningful text for links.
Publishing and keeping it safe
A finished static site is a set of files that any web host can serve. Choose a host, upload your files and point a domain name at it; how names are turned into addresses is explained in DNS resolution. You can also host at home, but that has its own security responsibilities, covered under home web server.
Static sites have a small attack surface, which is a benefit. If you add forms, logins or a database, security questions multiply, and you need to learn about validation, data encryption and protecting accounts. Use HTTPS, choose strong passwords through password managers and enable two-factor authentication on your hosting account. Keep backups of your source files. A sensible backup strategy takes minutes to set up.
If you reuse code, fonts or images from others, check their licences. And if you share your own code, decide on a licence; see software licenses.
What to build first
Begin with a one-page site and get it online. Then add a second page, shared styles and a menu. Add JavaScript only when a specific need appears. Resist adding frameworks until you can explain what problem they would solve for you. A small, hand-coded site that you fully understand is a solid foundation for later work, whether that is a larger site, a CMS-based one or a web application.