Pokémon Browser Game: Build the first landing-page draft

Course

Guided Builds

Module

Pokémon browser game

Outcome

Build a responsive first draft of the Pokémon browser game’s landing page. Create working placeholder pages for the game and Pokédex so every navigation link has a real destination.

This stage uses only Level 1 knowledge. The result is a complete working baseline, not a temporary broken page.

What you will practice

• Create and connect the first HTML and CSS files for the project.
• Choose semantic HTML from the purpose of each content region.
• Use normal flow and Flexbox to create a narrow-first landing page.
• Apply a small reusable visual system with clear interaction states.
• Verify links, keyboard focus, narrow width, zoom, HTML, and CSS before recording the checkpoint.

Why this stage starts with Level 1

The later game will add JavaScript state, DOM events, CSS Grid, animation, testing, and technical SEO. Those changes are easier to understand when the project already has a stable page structure, shared navigation, and working responsive CSS.

This stage also gives you a focused way to check which Level 1 skills are ready to reuse. Open a linked refresher only when you need it. You do not need to reread every Level 1 lesson before you begin.

What is new and what is reused

• New: The Pokémon game project folder, its three-page product context, and your first design decisions for this website.
• Reused: HTML documents, semantic landmarks, relative links, external CSS, normal flow, the box model, custom properties, Flexbox, narrow-first media queries, keyboard checks, validation, and the solo Git workflow.

Starting point

Before you start

• You completed the Pokémon Browser Game introduction and can describe the purpose of index.html, game.html, and pokedex.html.
• You can create HTML and CSS files, open a local page in a current browser, and use browser developer tools.
• You can return to the linked Level 1 material when a concept or check is unfamiliar.
• You have a location for a new project folder and permission to create a private Git repository for your own work.

Current state

The product is defined, but the student project folder and website files do not exist yet.

First action

Create a folder named pokemon-browser-game, open that exact folder in VS Code, and create index.html.

First checkpoint

index.html opens in the browser and shows a descriptive browser-tab title and one visible main heading.

Help trigger

Use the nearest refresher link or ask for help if VS Code opened a different folder, an HTML file displays as text, the stylesheet does not load, or a saved change does not appear after a reload.

Required result

Complete this stage when:

• the project has index.html, game.html, pokedex.html, and styles.css;
• every HTML page has a descriptive browser-tab title, one visible main heading, semantic page regions, and a link to styles.css;
• the same navigation lets a visitor open all three pages without a broken link;
• each page marks exactly one current navigation link with aria-current="page" and gives it a visual state that does not depend on color alone;
• index.html explains what the game will let the visitor do and provides clear routes to the game and Pokédex;
• game.html and pokedex.html identify their future purpose without pretending that those features are complete;
• the landing page uses normal flow and Flexbox, but not CSS Grid;
• the narrow layout works before a media query applies;
• one content-based min-width media query improves the wider layout without changing the meaningful source order;
• links have visible hover and keyboard-focus states;
• the page remains usable at about 320px width and at 200% browser zoom;
• the HTML passes validation and VS Code reports no unresolved CSS author error; and
• Git records the verified first draft in the project’s private repository.

Keep later technologies out of this draft

Do not add JavaScript, CSS Grid, container queries, animation, analytics, or project-specific technical SEO work in this article. Keep correct Level 1 foundations such as semantic HTML, descriptive page titles, meaningful links, and image alternatives. The later SEO stage will evaluate and improve the finished pages.

1. Create the project baseline

Create these remaining files beside index.html:

First landing-page workspace

pokemon-browser-game/
├── index.html
├── game.html
├── pokedex.html
└── styles.css

Use the HTML document refresher to create a complete document in each HTML file. Give each page its own title and h1. Connect each page to styles.css with a relative path.

Open all three HTML files in the browser before you add the final content. At this checkpoint, plain unstyled text is correct. The browser must not show a missing-file page.

Create a local Git repository after the files open. If you need the commands or the state checks, use Create the local repository. Connect it to a new private GitHub repository through the Level 1 solo-project workflow.

Check

Confirm that VS Code shows the four files from the file tree at one project level. Reload each HTML file and confirm that its browser-tab title and visible main heading identify the same page.

If it does not work

If a page does not open, inspect its exact filename and extension. If the CSS later fails to load, confirm that styles.css is beside each HTML file and that each stylesheet path starts from the current HTML file.

Checkpoint: The three-page baseline opens

What now works

index.html, game.html, and pokedex.html each open locally, show their own title and main heading, and point to one shared stylesheet.

Files changed

index.html, game.html, pokedex.html, styles.css

What remains

Define the visitor route and build the semantic page structure.

Next action

Write one sentence that states what the landing page must help a first-time visitor do.

If it does not work

Open one HTML file at a time. Check its document structure, filename, title, heading, and stylesheet path before comparing it with another page.

2. Define the visitor route before the layout

Use this purpose statement for the required path:

The landing page introduces the browser game and helps a visitor choose between playing the game and opening the Pokédex.

Plan the page content by role. Write your own visitor-facing text; do not copy a finished Pokémon landing page from another source.

Content role	Required information	Your design decision
Site header	Project name and navigation to all three pages	The short site name shown on every page
Introduction	One page heading and a concise explanation of the game	The exact heading and supporting text
Main actions	One route to the game and one route to the Pokédex	The link text that describes each destination
Feature overview	At least three short items that preview setup, exploration, encounters, battles, or the collection	Which three or four features to emphasize
Page footer	A short project identifier	The exact footer wording

The feature overview describes the planned product. Do not claim that unfinished game behavior already works. Use future or descriptive wording where necessary.

On game.html and pokedex.html, add enough content to identify the page and its planned purpose. State clearly that implementation comes in a later stage. These are working destinations, not finished features.

Use Build a visual hierarchy to decide what the visitor should notice first, second, and third. Keep that reading order in the HTML before you consider layout.

Reference result: home page

This wide-layout screenshot shows one possible first draft. Use it to identify the content roles and reading order. Your text, colors, typeface, and spacing can differ.

Home pageEnlarge

The first-draft home page introduces the future game, offers routes to the game and Pokédex, and previews four planned features.

Home page

Close

The first-draft home page introduces the future game, offers routes to the game and Pokédex, and previews four planned features.

Check

Read only the unstyled index.html page from top to bottom. Confirm that a visitor can answer:

1. What is this website?
2. What will the game let me do?
3. Where can I play?
4. Where can I open the Pokédex?

If the page cannot answer one question without visual styling, revise the content before adding layout CSS.

3. Build the semantic HTML and navigation

Choose each HTML element from the content’s purpose. Use Connect elements to meaning and Choose an element by purpose when you need a refresher.

Build one complete page structure in index.html:

1. Identify the repeated site header and primary navigation.
2. Identify the unique main content.
3. Divide the main content into named sections when each section has a distinct topic.
4. Mark each feature item according to whether it can stand as an independent entry.
5. End with the page footer.

Keep one h1. Give each major section a clear h2. If a feature item needs its own heading, place that heading below the section heading in the hierarchy.

Create the navigation as a semantic list of real links. Use relative links so each page can reach index.html, game.html, and pokedex.html. Give the navigation a name that identifies its purpose.

Add aria-current="page" to the navigation link for the open page. Move the attribute to the matching link in each HTML file. Give that link a visible state that does not depend on color alone. Use Mark and style the current page in navigation for the Level 1 pattern.

When the landing-page structure and navigation work, add the same repeated header, navigation, and footer pattern to the two placeholder pages. Change only the current-page state and the unique main content.

Reference result: placeholder pages

These wide-layout screenshots show the working destinations at this stage. Each page identifies its future purpose, marks its current navigation link, and states that its main feature is not complete.

Game pageEnlarge

The game placeholder names the planned game features without claiming that they already work.

Game page

Close

The game placeholder names the planned game features without claiming that they already work.

Pokédex pageEnlarge

The Pokédex placeholder explains the future reference page and keeps the full three-page navigation working.

Pokédex page

Close

The Pokédex placeholder explains the future reference page and keeps the full three-page navigation working.

Use Add the page-level regions for the landmark pattern and Test links and browser history for the navigation check.

Check

Start on each page in turn. Open every navigation link, use the browser Back button, and confirm that the expected page opens. Confirm that exactly one link has aria-current="page" and that it matches the open page. Inspect the heading order without using CSS as evidence.

If it does not work

If one link fails only from one page, compare that link’s href with the destination filename. If a page has an unclear outline, list its headings in source order and correct the first level that skips or repeats a page heading.

2Assistance 2 — Identify each region by its job

Ask one question for each content group: Is this repeated site navigation, unique page content, a named topic, an independent feature entry, or closing page information? Return to the semantic-element table in the linked lesson and choose from the job, not from the element’s default appearance.

3Assistance 3 — Build and test one region at a time

Keep the document information and body in place. Add the repeated site header and test its links. Add the main introduction and check the heading order. Add the feature overview and check its item order. Add the footer last. Save and reload after each region so the first broken state remains small.

Checkpoint: Content and navigation work without CSS

What now works

The landing page has a meaningful source order, all three pages share working navigation, each page marks its matching current link, every page identifies its purpose, and the feature text does not claim that unfinished behavior exists.

Files changed

index.html, game.html, pokedex.html

What remains

Create one shared visual system and a narrow-first layout.

Next action

Open styles.css and list the page roles that need reusable color and spacing values.

If it does not work

Temporarily ignore appearance. Verify one page title, landmark, heading, and link destination at a time before restoring the shared pattern across all pages.

4. Create the shared CSS foundation

Build styles.css in layers. Keep a browser window open and reload after each layer.

1. Make element sizing predictable.
2. Set page-wide text, background, type, and line-height defaults.
3. Constrain the main page regions to a readable fluid width with stable edge space.
4. Define a small set of role-based custom properties for colors, spacing, and any repeated border or radius value.
5. Style headings, paragraphs, feature items, and the footer from those roles.
6. Make navigation and action links recognizable before hover.
7. Add visible hover and keyboard-focus states.

Use these Level 1 refreshers at the relevant step:

• Make width calculations predictable
• Control the page width
• Add the shared design values
• Add visible link interaction states
• Mark and style the current page in navigation
• Group related content
• Use contrast by role

Choose the visual values, but keep the system small. The first draft needs a clear reading order and usable interaction states. It does not need a complete game art direction.

Optional design cheat sheet

Your design does not need to match the screenshots. If choosing every visual value is blocking progress, use this guide as a complete starting point. You can reproduce the example, adapt selected values, or return to your own design after the required page behavior works. The guide gives you design values, not finished CSS rules. Use the linked Level 1 process to connect each value to a role-based custom property or focused selector.

One optional corner detail is outside this stage

The example header has square top corners and rounded bottom corners. Reproducing that exact combination requires a multi-value border-radius form that the linked Level 1 material does not teach. This corner treatment is not required. To stay within the Level 1 path, use one radius value for all four corners or use 0 for four square corners. The guide records the example’s visible result so the screenshot and specification remain consistent.

Optional design reference

Pokémon Trail first-draft design guide

Use all of these values to reproduce the example, adapt only the parts you need, or create a different visual design.

Typography

Begin your Pokémon journey

Font family

"Trebuchet MS", Arial, sans-serif

Body and actions

1rem / 1.6 · 16px

Introduction and h3

1.125rem · 18px

Site name

1.25rem · 20px · bold

h2

1.5rem / 1.2 · 24px

h1

2.25rem / 1.1 · 36px

Bold text

Headings, labels, the site name, current navigation, and action links

Color palette

• Page#E8F4FF
• Surface#FFFDF5
• Body text#18233F
• Muted text#4B5876
• Blue border#2F5DB3
• Deep blue#19376D
• Red accent#CF3030
• Yellow highlight#F3CF3F
• Focus outline#762A80

Spacing scale

Pixel equivalents assume the browser's usual 16px root text size.

• Extra small · 0.5rem · 8px
• Small · 0.75rem · 12px
• Medium · 1rem · 16px
• Large · 1.5rem · 24px
• Extra large · 2.5rem · 40px

Shape and borders

Small radius

0.25rem · 4px

Card radius

0.75rem · 12px

Header corners

Square at the top; 0.75rem at the bottom

Standard border

2px solid

Top accent border

0.5rem solid · 8px

Status border

0.25rem solid · 4px

Focus outline

3px solid with 3px offset; yellow in the header and purple elsewhere

Link underline

0.1em normally; 0.2em on hover and current page; 0.2em offset

Layout

Page regions

width: 90% · max-width: 60rem

Text measure

max-width: 42rem

Wide breakpoint

min-width: 48rem

Wide feature basis

flex-basis: 13rem

Common flex gap

1rem

Header padding

1.5rem block · 1rem inline

Hero and card padding

1.5rem

Navigation padding

0.5rem block · 0.75rem inline

Action padding

0.75rem block · 1rem inline

Narrow layout

Stack the header and feature cards before the media query applies.

Component recipes

• HeaderDeep blue surface with an 8px yellow bottom border.
• Hero and placeholdersCream surface, 2px blue border, and 8px red top border.
• Feature cardsCream surface, 2px blue border, and 8px yellow top border.
• ActionsRed primary action and yellow secondary action, both with deep-blue borders.
• Current navigation linkYellow surface, deep-blue text, bold type, and a thicker underline.
• Status messagePale-blue surface with a 4px red left border and 1rem padding.
• Footer2px blue top border with 1.5rem vertical padding.

This reference contains the complete visual specification used by the three first-draft screenshots. Matching it is optional; the required result is the working, accessible page structure and responsive behavior.

Check

Reload all three pages. Confirm that the shared header, navigation, main width, focus state, and footer have the same visual roles. Confirm that the current-page link is identifiable without color and that the landing-page h1 remains the first point of attention.

If it does not work

If one page remains unstyled, inspect its stylesheet path before changing CSS. If a custom property has no effect, inspect its spelling where it is defined and where it is used.

5. Arrange the first draft with normal flow and Flexbox

Keep vertical page sections in normal document flow. Add Flexbox only where a group needs a one-dimensional row or column relationship.

Use Flexbox for these required relationships:

• the primary navigation, with wrapping when the links need more room;
• the main action links, with wrapping instead of clipping; and
• the feature collection, which starts as one vertical column and may share a row when enough space is available.

Do not apply Flexbox to the complete page only to move unrelated sections. Identify each flex container and its direct flex items before adding the declaration. Use Identify the container and its items and When to use Flexbox and when to keep normal flow when choosing the boundary.

Give the feature items a repeated visual pattern, but keep their HTML order meaningful. Do not use CSS order, row reversal, or column reversal to produce a different visual story.

Check

In DevTools, inspect each intended flex container. Confirm that the highlighted direct children are the items you expected. Make the viewport narrow and confirm that links and feature items wrap or stack without leaving the viewport.

Checkpoint: The narrow first draft has a stable layout

What now works

Page sections follow a meaningful source order, navigation and action links wrap, feature items form one narrow column, and no required content depends on a media query.

Files changed

index.html, game.html, pokedex.html, styles.css

What remains

Choose one content-based breakpoint and verify the complete responsive page.

Next action

Increase the viewport width slowly and find when the header or feature collection has enough room for a wider arrangement.

If it does not work

Disable one Flexbox rule in DevTools. Confirm the selected container and its direct items before changing alignment, direction, wrapping, or item sizing.

6. Add one content-based responsive change

The base CSS must remain the complete narrow layout. Use Make the narrow layout the default to review that rule.

Find a breakpoint from the actual landing-page content:

1. Start near 320px and confirm the base layout works.
2. Increase the viewport width slowly.
3. Find when the navigation, main actions, or feature items have enough space for a useful wider arrangement.
4. Test the longest required text near that range.
5. Choose a nearby value in rem.
6. Immediately above the media query, add a short CSS comment that names the content relationship that now has enough room. Name the content, not a device category.
7. Add one min-width media query that changes only the declarations needed for the wider arrangement.

Use Choose the breakpoint from the content and Add one min-width media query for the Level 1 process.

Test immediately below, at, and immediately above the breakpoint. The change between the narrow and wide arrangements must not hide content, change the link order, or introduce horizontal scrolling.

Check

At about 320px, confirm that all content fits and remains readable. At a wide viewport, confirm that the changed arrangement uses the available space for a clear reason. Set browser zoom to 200% and repeat the keyboard route.

If it does not work

If the wide layout activates too early, inspect the longest heading, paragraph, and link near the breakpoint. If horizontal scrolling appears, use Find and correct horizontal overflow instead of hiding overflow.

Optional: add one meaningful local image

The required first draft can remain text-based. Add an image only when you have a teacher-supplied asset, an asset you created, or a source you are permitted to use.

If you add one:

1. Create assets/ at the project root, then save the project copy inside it.
2. Choose alternative text from the image’s purpose in this landing-page context.
3. Keep the rendered image inside its containing block and preserve its aspect ratio.
4. Test it at narrow width and 200% zoom.

Use Add the responsive image to HTML, Write alternative text from context, and Keep the image flexible as needed.

Do not use a remote image URL as a substitute for a project asset.

7. Validate and record the first draft

Save all files, reload each page, and complete the checks in this order:

1. Validate index.html, game.html, and pokedex.html with the process in Validate the HTML source.
2. Review styles.css with Review CSS diagnostics in VS Code.
3. Open every navigation and main-action link and use browser Back.
4. Press Tab through every link on index.html. Confirm that the order follows the source and the focus indicator remains visible.
5. Run the separate narrow-width and zoom checks from Test narrow width and zoom separately.
6. Inspect the browser Console and confirm that the current pages produce no error.

Repair one confirmed issue at a time. Repeat the failed check after each repair, then rerun the affected route.

When every required check passes, use the solo-development loop to review the diff, commit the verified first draft, and push it to the project’s private remote.

Self-check

Complete these checks against the required result.

1. Confirm that the three required HTML files and one shared stylesheet exist at the project root.
2. Open every page from the shared navigation and confirm that Back returns to the previous page.
3. Confirm that each page has exactly one aria-current="page" link, that it matches the open page, and that its visible state does not depend on color alone.
4. Read index.html without CSS and confirm that its landmarks, headings, text, features, and links remain meaningful.
5. Confirm that the required landing page uses normal flow and Flexbox and contains no CSS Grid declaration.
6. At about 320px, confirm that text and links remain visible without horizontal page scrolling.
7. At 200% zoom, confirm that content reflows and every link remains reachable with visible keyboard focus.
8. Confirm that the HTML checker and VS Code Problems panel report no unresolved author error and the browser Console is clear.
9. Confirm that Git records only the intended project files and that the private remote contains the verified checkpoint.

Checkpoint: The Level 1 landing-page draft is complete

What now works

The project has three connected pages, a responsive and accessible landing-page baseline, valid HTML and CSS, and a recorded Git checkpoint.

Files changed

index.html, game.html, pokedex.html, styles.css

What remains

Replace one Flexbox collection with a CSS Grid layout while preserving the working content and responsive behavior.

Next action

Open the next article, then inspect the feature collection in index.html and its current Flexbox rules in styles.css.

If it does not work

Return to the last passing self-check. Restore that behavior before starting the landing-page refinement.

Next step or safe stopping point

This is a safe stopping point. The site works without JavaScript or Level 2 layout features.

Continue to Landing page refinement when the first draft passes every self-check. The next article keeps the same content and introduces CSS Grid followed by one small interaction transition.