A Beginner Friendly Guide to HTML Coding.
by steve-gibbs5 in Design > Software
88 Views, 3 Favorites, 0 Comments
A Beginner Friendly Guide to HTML Coding.
Welcome dear reader. This is a companion Instructable to my Touchscreen Interactive Multi-Map Wall Console project where I show how I made the wall unit, graphics and animations, and the mention a bit about the coding. But to save making it too long, I decided to split it into two parts, this part as the title says, will guide through the actual HTML (Hypertext Markup Language) coding that made all the maps/games come to life, built using real-world web technology and live data. For this, I am using my Transport Ops map as the example as it's one of the less complicated web apps, but has a few different features.
On the surface, the map lets you:
- View a live map
- Toggle transport layers like buses and tube lines
- See traffic conditions
- Interact with on-screen markers that show real-time information
But as I mentioned, the real purpose of this project isn’t just the map itself… it’s understanding how the code behind it works, how each part connects, and how you can safely change things without everything falling apart. The inspiration to write this is to hopefully help others who are thinking how I was (and still am)... wanting to make something cool using code, but unsure or lacking confidence and knowledge to do so.
It's also worth mentioning, and this matters… I am still learning this coding game too. So this isn’t written from the perspective of someone who's been doing this for years (about 6 months at time of writing), it’s written from building something basic that worked, then breaking it repeatedly, figuring out why, making it work again, then improving on it. A beginners guide to HTML code, written from a beginners perspective. In Step 9, I have also included a bonus web app code specifically for this Instructable for you to play around with.
So lets get stuck in.
Supplies
I made and use my MCARS multi-map project with Widows 11 and using Chrome as my default browser, so I will be referring to this in the following steps, but I think this will also relate to other OS and browsers. You don’t really need anything complicated to get started:
- Notepad (perfectly fine for beginners. I mainly used this)
- Or Notepad++ (recommended, much easier to read code. I used this sometimes as well)
- A modern browser like Chrome or Edge
- An internet connection (needed for online maps and live data)
- An good online coding community for asking questions and advice.
Useful learning sites:
- Brilliant.org, Codecademy and W3Schools which is great for the basics
- Leaflet documentation (for maps)
- API keys free or paid (for live/up to date data)
What Is an HTML Web App
In its basic form, an HTML web application is a web page that contains three main parts working together:
- HTML: builds the structure (what you see on the screen)
- CSS: controls the appearance (how it looks, buttons, images, colours, text etc.)
- JavaScript: controls behaviour (makes the app function)
These three parts are broken down into the following...
- <html> → the container for the entire webpage, everything sits inside this
- <head> → setup area (links, settings, map libraries), not visible on screen
- <style> → where your CSS lives, this controls how everything looks
- <body> → everything you actually see on screen (map, buttons, layout)
- <script> → where your JavaScript lives, this controls what everything does
These function using a web browser and act as your own person web page . The map itself is powered by a library called Leaflet (my other projects also uses MapLibre), which handles things like zooming, panning, and placing markers.
The live data part comes from APIs, which are basically services on the internet that send data back when you ask for it, some are free to use, others you pay for.
A useful thing you can do to help yourself, especially as projects grow, is to leave clear notes inside your code, often called "Comments". These don’t affect how things run, they’re purely there for humans… including future you, who will absolutely forget what something did after a few weeks. In HTML, comments look like <!-- --> (for example, <!-- TRANSPORT MAP -->) and are useful for labelling sections or marking important areas of the layout. In CSS and JavaScript, you’ll usually see /* */ (/* MAP AREA */) for block comments, or in JavaScript also // (// TomTom Traffic Tile Layer) single line notes. The key is to use them to explain why something exists, not just what it is… a few well-placed, meaningful notes can come in very useful.
Below is the full code I use for my Transport Ops app which I will use as the example...
Understanding the HTML Structure
So, for anyone new to code, this will probably look a bit overwhelming at first glance… it certainly did for me. But once you start breaking it down, you realise it’s not one giant complicated thing, it’s just a handful of simple parts stacked together. The easiest way to think about it is like building a control panel… you start with the frame, then add the buttons, then wire up the logic behind it.
We’ll use the Transport Ops map as the example here.
1. The start of every HTML code (top section):
This is always the starting point. It’s basically telling the browser “this is a webpage, load it as such”. A simple start, but without it things will behave strangely.
You’ll also see things like:
This is setup so everything displays correctly, especially on different screen sizes. Without the viewport line for example, things can look zoomed out or broken on smaller screens.
2. Loading the map system (Leaflet):
This pulls in Leaflet, which if you remember, is the map engine doing all the heavy lifting. Without this, your <div id="map"> would just sit there as an empty box. Leaflet is what turns that box into an actual interactive map you can zoom, move, and add things to.
3. Styling everything (the <style> section):
This is where all the visual side of things lives… layout, colours, spacing, positioning, etc.
For example:
This tells the map exactly where to sit on the screen, leaving space for your LCARS side panel and borders. In the above example, you don't really need all four positions, using Top and Left will be enough, but using all four can change an elements height and width, although there Height: and Width: codes for this.
You’ve also got things like:
- #controls: your button panel on the left
- #frame: the LCARS-style border wrapping the screen
- #blue-rect-top and bottom: those header/footer bars
- .pulse-marker: the glowing animation on buses and tube icons
So this entire section is purely about how things look and their locations, not what they do.
4. The actual visible layout (HTML body):
This is what actually appears on screen. Inside #controls, you have your buttons:
- ROAD MAP
- BUSES
- TUBE
- TRAFFIC
- etc.
Each button has something like:
Which means "play a sound effect> then run a function". So the HTML is not just layout, it’s also connecting the buttons to the logic behind them.
5. Sounds and basic setup (JavaScript starts here):
This loads your button sound file. keyok3.mp3 is the file path name of my sound effect file. I should note that the file format I used is .mp3, and although this does work for me, I read that it's advisable to use .wav files instead as they work better so I did this in all of my future projects that use sound. If you have MP3 files, you can convert them using a sound editor like Audacity. Simply open a new project, import the MP3, then export it saving it as a WAF file instead.
Then:
This makes sure the sound plays every time you click, even if you click quickly if you watch the games in the MCARS video demo, you will see this in action with rapid fire. It’s a small detail, but it adds a lot to the feel of the interface.
6. Creating the map:
This is where the map actually comes to life.
- [51.5074, -0.1278] is London (latitude and longitude)
- 12 is the zoom level
Then you’ll see:
Which adds the visible map layer. Without this, you technically have a map… but nothing would be visible.
7. Layers (this is where cool things start to happen):
Each layer is like its own container.
- One for buses
- One for tube
This lets you turn them on and off without affecting anything else. You also have separate tile layers like:
- Traffic (TomTom)
- Train lines (Thunderforest)
These behave slightly differently, but the idea is the same… they can be toggled independently.
8. Making the buttons do things:
When you press something like BUSES:
- It checks if the layer is already on
- If it is, it removes it
- If not, it adds it
Then it calls functions like:
Inside that, you’ll see markers being created:
That’s what actually places the icons on the map.
9. Live data:
This is the clever part, but the idea is simple:
This is asking TfL (Transport for London)... “Give me nearby bus stops and arrival times”
Then:
This converts the response into something JavaScript can use. After that, the code loops through the results and creates markers with popups showing things like:
- Bus number
- Destination
- Time until arrival
So the process is:
- fetch = go get data
- then = do something with it
10. Simulated tube system (a bit of creative license):
Unlike buses, tube train tracking is not pulled live here. Instead:
- Random positions are generated
- Random “next stops” are chosen
- But actual line status is pulled from TfL
So it looks dynamic, gives real data, even though parts are simulated.
11. Dark mode toggle:
This simply switches between:
- Light map
- Dark map
It removes one layer and adds the other.
12. Exit button:
This is mainly for kiosk (running in full screen, no address or taskbars visible) or touchscreen setups.
NOTE… this only works properly in certain environments (like locally opened files or controlled systems), not always in normal browser tabs. How to use this is explained in Step7 of my MCARS Instructable.
In short…
If you strip everything back, the whole system is basically:
- Build the layout (HTML)
- Style it (CSS)
- Create the map (Leaflet)
- Add buttons
- Link buttons to functions
- Load data (optional but powerful)
Everything else is refinement. A very useful habit you should use is when you start experimenting, don’t work directly on your only copy, especially if it's a working one. Do this instead:
- Create a master or baseline file like, Transport Map.html: this is your clean, working version. Then make a second file, Transport Map TEST.html → this is your playground. Now you can...
- Change things
- Break things
- Experiment freely
And if it all goes wrong… just copy the baseline file text and paste it back in the test file and start again. It saves a lot of frustration, trust me on this.
Code Tags and Symbols
Tags:
Most things in HTML work in pairs, what you might call opening and closing tags.
For example:
- <div> → this is the opening tag, it starts something
- </div> → this is the closing tag, it ends it
Anything placed between those two sits inside that element. You’ll see this pattern everywhere:
So the browser reads it like a set of containers, one inside another, a bit like boxes stacked inside boxes. A couple of useful things to know:
- The closing tag always has a / in it
- If you forget to close something, the page can behave strangely
- Some tags don’t need closing (like <meta>), but most do
In simple terms, opening tags start something, closing tags finish it… and everything in between is what they control. Once you get used to that idea, the whole structure of a webpage becomes much easier to follow.
Symbols:
- { } these define a block of code, like a container. You’ll see them in CSS and JavaScript
- Example:
- Everything inside the braces belongs to that rule or function
- : this means “set this to this”, used mainly in CSS and objects
- Example:
- Which reads as “colour equals red”
- ; this marks the end of a line or instruction. Think of it like a full stop at the end of a sentence. Without it, things can run together and stop working properly
So in plain terms: { } = the container : = assigns a value ; = ends the instruction. Small symbols… but if one goes missing, the whole thing can and will stop working.
HTML Recap (Hyper Text Markup Language)
So lets recap the three separate code formats individually. The HTML is the foundation and it tells the browser what elements exist.
For example:
This line creates an empty box. It doesn’t look like much, but this is where the entire map gets drawn. Another important section:
This creates the container for your buttons. Inside it, you’ll see things like:
This does two things at once:
- Displays a button labelled “BUSES”
- Tells the browser to run a function called toggleLayer when it’s clicked
So HTML isn’t just layout… it also links to behaviour.
CSS Recap (Cascading Style Sheets)
On to CSS, this is where beginners often experiment first, because it’s visual and more hands-on, think of it like drawing with code.
Example:
Let's look at this in more detail and use a button as an example.
- background controls the background colour of the button
- color controls the text colour inside the button
These are not the same thing. You could have a dark background with bright text, or the opposite.
Colours: What is #222 or #4fc3f7?
These are hex colour codes. A hex code always starts with # and is followed by characters, like:
RR = red, GG = green, BB = blue. Each pair ranges from 00 (none) to FF (maximum). So:
- #000000 = black
- #ffffff = white
- #ff0000 = red
- #222 is actually shorthand for #222222, which is a dark grey.
You can also use colour names instead. For example:
But not all colours have names, and named colours are less precise. Hex codes give you full control.
Project Layouts:
This positions items on the screen, like our map example. Instead of saying “width 500px”, this says:
- Stay 50px from the top
- 170px from the left
- 40px from the right
- 40px from the bottom
So the map stretches to fit the space.
Animation (Pulsing Marker):
This defines an animation. Then:
This means:
- Run the animation
- Take 1.5 seconds
- Repeat forever
How I made my codes were to give them basic controls and styling, make the app fully functional, then finish off by playing around with button shapes, colours, text etc. To keep in with my Star Trek LCARS system theme, I made the buttons pill shaped. The code would look like this:
The border-radius:40px; is what gives the buttons the rounded sides. So with the user interface set up, we need to make it functional.
Javascript Recap (Also Known As JS)
This is where everything actually happens, the functionality. For our transport app, we need to make it usable.
Creating the Map:
This line:
- Finds the HTML element with id "map"
- Creates a Leaflet map inside it
- Centers it on London
- Sets zoom level to 12
You can change the coordinates to move the starting location.
Layers (Different Map Styles):
These are different map backgrounds to create a light mode and a dark mode, so only one of these maps are shown at a time.
Buttons Trigger Functions:
This connects our HTML code to JavaScript. When clicked, it runs:
Inside that function, the app decides if it should show this layer or hide it.
Fetching Data (Talking to APIs):
This sends a request to TfL. Think of it like “Give me nearby bus stops and arrival times”. The API sends back data, which our code then processes.
Adding Markers:
This places an icon on the map. When clicked, it can show a popup with information. An icon can be an emoji or an image file, even an animated GIF file.
So with the code setup explained, there are some things we need to know to make it work correctly.
Spelling and Text Format
I live in the U.K so I use U.K spelling, and this is something I found out pretty early on in my coding journey and something that caused me a little frustration at first... spelling matters, but not everywhere.
In CSS (important):
CSS uses American spelling, so:
works perfectly, but:
does nothing at all… it’s simply ignored. As I was using the letter 'U' from the start, I couldn't figure out why a simple experiment code didn't work. It wasn't until I did a little online research that I figured out why. The same goes for things like... background-color (works), background-colour (does not). So in CSS, you must use American spelling only.
In HTML:
HTML doesn’t really use words like that for styling, so spelling isn’t an issue in the same way. But that said, for attribute names, spelling still matters:
So it’s about matching the exact expected names.
In JavaScript:
JavaScript is very strict. If you create something like:
Then later write:
That will fail… because color and colour are treated as completely different variables. So in JS, spelling must match exactly, every time. I found out that since most coding languages and documentation use American spelling, it’s usually easier to go with... color, center, behavior, etc.
Adding File Paths:
This is not used in our transport code example, but something to note. If you use a full file path (i.e, right click a sound effect file, click "Copy as path"), when you paste it into your code you will get something like "C:\Users\your name\My Project\my picture.png".
First thing, you only need one pair of quote marks, is if copy and pasting, check this. Second, the pasted path has back slashes, these need to be changed to forward slashes or you file wont execute, so make sure you change each one.
In simple terms:
- CSS: must use American spelling
- HTML: exact names matter, not UK/US spelling
- JavaScript: spelling must match exactly
A single missing letter won’t just look wrong… it can quietly break things without telling you why as I found out. Using something like Notepad++ can help you spot mistakes, but I found out that it won’t reliably detect them, especially with coding-specific spelling like color vs colour, because to the editor it’s all just text. What it does do well is syntax highlighting, so correct keywords are coloured and incorrect ones often aren’t, which can give you a visual clue something’s off. It won’t warn you about broken logic or wrong variable names either, so if something stops working, it’s usually down to you to track it down. What is very helpful for actual error checking, is doing it in your browser… open your file, press F12, and check the console, as that’s where JavaScript errors will usually show up.
What You Can Change Safely, and What Needs a Bit More Care
This is the part where you start experimenting… and honestly, this is where I learnt the most. But it helps to know the difference between things you can change safely, and things that need a bit more attention. First, the safe stuff… this is where you can play around without worrying about breaking the whole app.
Things like:
- Colours in the CSS
- Text labels (button names, titles, etc.)
- Button sizes and spacing
- The starting position of the map (those latitude/longitude numbers)
- The emojis used for icons
All of these only affect how the app looks, not how it actually works. So if something looks wrong, you can just change it back. Nothing critical will stop working.
For example, changing a colour like:
to something else won’t break anything… worst case, it just looks a bit ugly until you fix it.
Now, the next group… this is where you slow down slightly.
Things like:
- Functions such as toggleLayer()
- The fetch() URLs that pull in data
- Layer logic (adding and removing map layers)
You can change these… but this is where things are connected behind the scenes (covered in the next step). For example:
- If you rename a function in one place but not another, the button will stop working
- If you change part of a fetch URL incorrectly, the data just won’t load
- If you remove part of the layer logic, markers might not appear, or might never disappear
This is usually where beginners hit that moment of “it worked five minutes ago, now it doesn’t”. And the reason is almost always something small:
- A variable name doesn’t match anymore
- A function isn’t being called
- A URL has been slightly altered
So the approach here is simple, change one thing at a time… test it… then move on. If you treat this part carefully, you won’t break the system… and more importantly, you’ll actually understand how it works as you go.
Connected Code and Variables
I touched on this in the last step, and this is one of the most important ideas to get your head around… because this is where code stops being lines on a page, and starts behaving like a connected system.
Take this example:
Here you’re creating something called layers, and inside it you’ve got a bus layer stored under the name bus. Later on, you’ll see:
Now this line is reaching back to that earlier definition. It’s saying "Go to layers, find the thing called bus, and add it to the map", so even though these lines are in completely different parts of the code, they’re linked together by that shared name. It's the same idea with functions. You define one here:
That’s where the actual work happens… fetching data, placing markers, etc. Then somewhere else, often triggered by a button, you’ll see:
This is what actually 'calls' that function and makes it run. So:
- One place defines it
- Another place uses it
Now here’s where you can get caught out. If you change the name in one place, like this:
…but forget to update this part:
The connection is broken. The code will still run, but that function will never be found or executed, so nothing happens. This is why it helps to think of code less like separate lines, and more like a system of references or links.
- Names must match exactly
- One part often depends on another
- Changing something in isolation can quietly break the connection
It’s a bit like wiring... everything might look fine on the surface, but if one connection is off, that part of the system just stops responding. Once you understand that, debugging becomes a lot easier… because you know to follow the chain, not just stare at one line.
Variables:
An important piece to add here is variables, because they’re what make all these connections possible.
A variable is simply a named container for a piece of data. You give something a name, store a value in it, and then reuse that name elsewhere instead of rewriting the value every time.
For example:
Here, TFL_KEY is the variable. Instead of typing your API key everywhere in the code, you store it once and then reuse it wherever it’s needed. So later on, when you see something like:
It’s pulling that value from the variable. The same idea applies to things like:
Now map becomes a reference you can use throughout the code, instead of recreating it every time. The important thing to understand is:
- A variable’s name must be used exactly the same way everywhere
- If you change the name in one place, you must change it everywhere else it’s used
- Variables are what allow different parts of the code to talk to each other
So when you see code working across multiple sections, it’s often variables quietly linking everything together behind the scenes.
API Keys
To gather the data, this map app uses three API keys, Transport for London (TFL), TomTom, and ThunderForest (for the trainlines map). TomTom and Thunder are global maps, where as TFL is for London data only (not much use if you live in other parts of the world), but this can easily be replaced with a transport API service for your location. You’ll need that provider’s API key, endpoints, and data format, then update the fetch() links and how the data is read (lat/lon, arrivals, etc.) to match—same logic, just different data source behind it.
This is your API key, which is basically a permission token. It tells the TfL system who you are and allows your app to request data. Without it, the request either won’t work at all, or it will be heavily limited.
Changing the Key:
If you get your own key, you simply replace the value inside the quote marks:
That’s all you need to do at this level. You don’t touch anything else around it.
Where That Key Is Actually Used:
Further down in the code, you’ll see it being inserted into a request, like this:
This is called a template string, and it’s just a way of dropping your key into the URL automatically. So instead of hardcoding the key everywhere, you define it once at the top, and the code reuses it wherever needed. This keeps things cleaner and avoids mistakes. Think of it as a variable.
Important: Changing Location (Why the Key Alone Isn’t Enough):
This is where a lot of beginners may get caught out. You might think “If I change the API key, I can just use this for another city”, but it doesn’t work like that. Take this line:
This URL is specifically designed for Transport for London. It knows about London bus stops, London routes, London data. So even if you replace the key, the request is still asking “Give me London transport data”.
Example – Switching to New York:
If you wanted to build the same idea for New York for example, you would need to change more than just the key. You would need:
- A completely different API (for example, something from New York’s MTA or another data provider)
- A different request URL (because each API has its own format)
- Possibly different data handling, because the structure of the returned data may not match TfL
So instead of just swapping this:
You’d also be rewriting things like:
and adjusting how the results are read and displayed.
To gather the data, this map app uses three API keys, Transport for London (TFL), TomTom, and Thunder (for the trainlines map). TomTom and Thunder are global maps, where as TFL is for London data only (not much use if you live in other parts of the world), but this can easily be replaced with a transport API service for your location. You’ll need that provider’s API key, endpoints, and data format, then update the fetch() links and how the data is read (lat/lon, arrivals, etc.) to match—same logic, just different data source behind it.
Example: Replace TFL with New York (MTA-style API)
The original (TFL) fetch from my code:
Replace it with an MTA (Metropolitan Transportation Authority) endpoint:
Then adjust how you read the data from TFL:
to MTA-style:
Marker example:
In short, swap the URL, add the new API key, update the data fields (lat/lon/names). You will have the same system, but with a different data feed. And treat your API keys like you would your bank card pin code, never share it. If you think someone else is using it, go to the supplier, delete the key and generate a new one, then add this to your code, replacing the old one.
One thing I want to mention to save you any potential headaches, there are free and paid for API keys available from different services. The ones I use are free to use and have usage limitations, perfectly fine for personal use as long as I don't make hundreds of calls a day. That said, I did make an air traffic app using a free OpenSky key which I was pleased with, tracking planes and helicopters and clicking on them to see the aircraft data. I had the basic functions working and was happy with it through light testing. I came back to it the next day... no planes were showing at all. I checked the code, asked for help on forums, but no joy. I put to one side and worked on something else. I came back to it and it was working again (I tried it for less than 2 minutes). I focused on the styling, tried it again, the planes were gone again. It turned out it was the API key was harshly limiting the data, very temperamental and kinda sucked. So at time of writing, I was using OpenSky's own public air traffic tracker wrapped in a HTML background and adding some of my own data until I find a better solution.
A Web App Code to Experiment With
The following code is something I made specifically for this Instructable. It is a basic World Clock Map web app that uses MapLibre for that actual maps, and a couple of usable buttons to toggle between light and dark mode, and to clear the drop pins, and no API keys to worry about. Tap/click anywhere on the map to drop a little pin and a popup will display with the current time/date for that location. I wrote this code so you can copy/paste it, study it along with this Instructable, then have a play around with the code, changing button styles, colours, and maybe use it as a baseline to add other fun and useful features.
To use this, open Notepad on your PC, open a new tab, copy the code above then paste it into the empty Notepad page. Then you need to save it a particular way because Notepad will save anything as a .txt file by default. Click File > Save > name your app file something like "World Clock" but write it as follows... World Clock.html as it's the .html that turns it from a simple text file to an actual working web app.
To get to the code to make changes, there are two options:
- Go to your map file location (your Pictures or Documents folder) > right click the file > select Open with > then select Notepad.
- Or open Notepad > File > Open > in the bottom corner where it says Text documents, click the drop down and select All files > then click on the map file.
One thing to note, a simple static image of a world map will display visually in a web app, but is no good for an app like this because it has no underlying structure for the code to interact with, it’s just pixels on a screen. The application needs real geographic data, coordinates, zoom levels (seeing the whole globe right down to seeing roads), and event handling (like clicks and positions), which a picture simply cannot provide. Without a mapping engine, the code has nothing underneath to calculate locations from or place dynamic markers onto. That’s why tools like MapLibre are essential, they turn the map into a live, interactive system rather than just a visual background.
Conclusion
And that brings us to a close to this coding lesson. If you take anything away from this, it should be that... you don’t need to understand everything at once. What matters is:
- Knowing what each part roughly does
- Knowing what you can safely change
- And not being afraid to break things
Because breaking things is how this project was built in the first place. And if you keep going, step by step, changing things, testing things, You stop copying code and start building your own systems which, I imagine, is exactly where you intended to end up which it is for me.
I do hope that this Instructable gives you the confidence and inspiration to give this a go yourself, it was, and still is a challenge for me, but it's one I'm pleased I took on because I love using my MCARS Multi-map console and quietly proud of what I have achieved so far.
Thanks for reading, and happy making.