Pokémon Browser Game: Landing page refinement

Course

Guided Builds

Module

Pokémon browser game

Outcome

Refine the landing page in two controlled changes. First, replace the feature collection’s Flexbox layout with CSS Grid. Then add one small transition to a main action link. Keep the existing content, semantic HTML, links, visual roles, and narrow-first behavior working throughout both changes.

This is the first stage that adds Level 2 knowledge. Grid is the main topic. The transition is a smaller second checkpoint that introduces motion as optional feedback for an interaction that already works without motion.

What you will practice

• Identify one Grid container, its Grid items, and the tracks that arrange them.
• Build a complete single-column Grid before adding a wider track arrangement.
• Use flexible Grid tracks instead of fixed card widths.
• Keep source order, keyboard order, content wrapping, and visible focus stable across layouts.
• Explain why Grid fits the feature collection while Flexbox still fits the navigation and action groups.
• Define a complete hover and focus state before adding motion.
• Add one short user-triggered transition while preserving an equivalent reduced-motion result.

Why these changes belong in the second draft

The first draft proves that the landing page works with Level 1 tools. You can now change one layout system without also solving content, navigation, or project-setup problems.

The feature collection contains repeated items that need to align across columns and rows when space permits. That two-dimensional relationship gives CSS Grid a specific job. Navigation and action links remain one-dimensional groups, so they can keep their working Flexbox layouts.

The action links already have static hover and keyboard-focus states. A short transition can add feedback when a visitor triggers one of those states. The static state remains the source of meaning, so a visitor who requests reduced motion receives the same information without movement or delay.

What is new and what is reused

• New: Grid containers, Grid items, column and row tracks, fractional track sizing, a Grid track list, CSS transitions, transforms, and the prefers-reduced-motion media feature.
• Reused: The completed first draft, semantic source order, shared classes, gap, custom properties, content-based media queries, flexible text, hover and focus states, keyboard checks, validation, DevTools, and Git checkpoints.

Starting point

Before you start

• The first landing-page article passes its complete self-check.
• Git contains the verified first-draft checkpoint, and the working tree contains no unexplained changes.
• index.html has one feature collection with at least three repeated feature items.
• styles.css uses Flexbox for that collection and has a working narrow-first media query.
• Navigation, main actions, placeholder pages, keyboard focus, narrow width, and 200% zoom already work.

Current state

The landing page is complete at the Level 1 baseline. Its feature collection uses Flexbox and all required content remains available at narrow and wide widths.

First action

Open index.html and styles.css side by side. Identify the feature wrapper, its direct feature items, and every CSS rule that currently controls their Flexbox layout.

First checkpoint

You can point to one future Grid container, its direct Grid items, and the existing declarations that must be replaced rather than layered underneath.

Help trigger

Use the nearest refresher or ask for help if you cannot identify the wrapper and its direct children, old Flexbox declarations still control the collection, Grid items overflow, keyboard order changes, the transition causes layout movement, or reduced-motion mode changes the result of the interaction.

Required result

Complete this stage when:

• the landing-page content and semantic HTML remain unchanged unless validation reveals a real structure error;
• the feature wrapper is a Grid container and its direct feature entries are Grid items;
• the base Grid forms one complete column without depending on a media query;
• the existing content-based min-width media query gives the feature collection at least two flexible columns when enough space is available;
• Grid track sizes avoid fixed card widths and let text wrap;
• old collection-specific Flexbox declarations no longer compete with Grid;
• navigation and action groups keep Flexbox because their one-dimensional relationship has not changed;
• visual order, source order, and keyboard order remain the same;
• one existing main action link has a complete static hover and keyboard-focus state before motion is added;
• that action can make one small visual shift through a short transition when a visitor hovers or focuses it;
• the transition runs only when prefers-reduced-motion: no-preference matches;
• reduced-motion mode shows the same interaction state without movement or delay;
• no animation runs on page load, loops, hides content, obscures the focus indicator, or blocks an interaction;
• the page passes the narrow-width, zoom, link, focus, motion-preference, HTML, CSS, and Console checks from the first draft; and
• Git records the verified Grid and motion checkpoints separately from the first draft.

Keep each new concept narrow

Complete and verify the Grid before you add motion. The motion checkpoint uses one CSS transition on one existing interaction. Do not add container queries, auto-fit, auto-fill, subgrid, @keyframes, JavaScript, SEO, analytics, or new game features in the required path.

1. Preserve evidence of the working first draft

Open the landing page at a narrow viewport and at a wide viewport. Record the current behavior before you edit CSS:

• feature order;
• number of visible feature columns;
• longest heading and paragraph;
• navigation and action-link behavior;
• presence or absence of horizontal page scrolling; and
• keyboard focus order.

Use Record the current layout before changing it for the evidence pattern. A screenshot can support your notes, but the observable behavior is the important baseline.

Run git status and inspect the result. Resolve or explain any earlier change before you start this refinement. The first-draft commit is the recovery point if the experiment stops working.

Check

You can describe what must stay unchanged and name the one layout relationship that will change.

2. Identify the Grid relationship

Read the beginning of Add the page and component foundation, then focus on Read the narrow-first component. Use those sections to identify the following terms:

• A Grid container is the element whose layout rules create the grid.
• A Grid item is a direct child that the grid places.
• A track is one row or column in the grid.
• A track list defines the columns or rows that the grid must create.
• An fr unit assigns a fraction of the available space to a Grid track.

Do not copy the complete resource-card stylesheet. That lesson has a different component and later introduces container queries. Transfer only the Grid concepts needed by the feature collection.

In your project, identify:

1. the one wrapper that contains all feature entries;
2. the direct children that must become Grid items;
3. any heading that must remain outside the Grid because it names the whole section; and
4. the existing Flexbox declarations that affect this wrapper or its item widths.

Use the Level 1 Identify the container and its items method again. The direct-child relationship matters for both Flexbox and Grid even though the two layout systems arrange those children differently.

Check

In DevTools, select the planned wrapper. Confirm that its highlighted direct children are only the repeated feature entries. If the section heading is highlighted as one of the layout items, the wrapper boundary is too broad.

If it does not work

If no existing wrapper contains only the repeated entries, add one neutral grouping element around those entries. Do not move the section heading into it. Reload the page and confirm that the content order and appearance remain unchanged before editing its layout.

Checkpoint: The Grid boundary is known

What now works

One wrapper contains only the repeated feature entries, each entry is a direct child, and the old collection-specific Flexbox rules are identified.

Files changed

index.html, styles.css

What remains

Replace the collection layout with a complete single-column Grid.

Next action

Open the base feature-wrapper rule in styles.css and remove only the Flexbox declarations that control this collection.

If it does not work

Inspect the wrapper and direct children in DevTools. Keep the heading outside the wrapper and do not change navigation or action-link containers.

3. Build the single-column Grid first

Edit the base feature-wrapper rule outside every media query.

1. Remove the wrapper’s Flexbox display mode, direction, wrapping, and distribution declarations when they exist only for the feature collection.
2. Make the same wrapper a Grid container.
3. Reuse the existing spacing value for the gap between feature entries.
4. Keep the base Grid to one column.
5. Remove feature-item width or flex-sizing declarations that no longer have a job.
6. Keep card presentation rules such as border, background, padding, and text styles when they still match the design.

Do not add the wider column track list yet. A Grid without an explicit multi-column track list places these feature items in rows in source order. The narrow result should therefore remain complete before conditional CSS runs.

Use Make the narrow layout the default to preserve the Level 1 responsive model. Use the Level 2 lesson’s Test before the conditional layout process to check the new Grid base.

Check

Temporarily disable the landing page’s media query in DevTools. Confirm that:

• the feature entries form one column in source order;
• every entry uses the available width without creating horizontal scrolling;
• long headings and paragraphs wrap;
• the page remains usable near 320px; and
• navigation and action links retain their working Flexbox behavior.

If it does not work

If the feature entries remain in a row, inspect whether the wider media-query rule is still active or an old item width remains. If an entry widens the page, inspect its minimum width, fixed width, padding, and longest unbroken content before changing the Grid container.

2Assistance 2 — Separate layout rules from card appearance

In the wrapper rule, mark declarations that arrange the direct children. In the item rule, mark declarations that size the items. Keep declarations that only control the cards’ color, border, internal spacing, or text. Replace the collection layout instead of rebuilding the complete design.

3Assistance 3 — Restore a stable narrow Grid in three checks

First, make the wrapper report Grid in DevTools. Second, confirm that its direct children appear as Grid items. Third, confirm that no explicit multi-column track list applies in the base rules. Stop there until one-column layout, wrapping, and keyboard interaction pass.

Checkpoint: The base Grid works without a media query

What now works

The feature wrapper is a Grid container, its entries form one complete narrow column, old feature Flexbox sizing no longer competes, and the rest of the page still works.

Files changed

styles.css

What remains

Define a wider track arrangement inside the existing content-based media query.

Next action

Increase the viewport width and find when two feature entries can share a row without crowding their longest content.

If it does not work

Return to the first-draft commit if necessary, then repeat only the wrapper display change and removal of feature-specific flex sizing.

4. Choose the wider Grid tracks from the content

Reuse the content-based breakpoint process from Level 1. Do not choose a phone, tablet, or desktop label.

1. Increase the viewport width slowly from the working narrow Grid.
2. Find when at least two feature entries can share a row while their longest heading, paragraph, and link remain readable.
3. Compare a two-column and a three-column arrangement in DevTools.
4. Choose the arrangement that fits the actual content without forcing narrow cards.
5. Keep the existing breakpoint when it still matches this evidence. Change it only when the Grid content demonstrates a better threshold.

Use Choose the breakpoint from the content for the method.

Inside the existing min-width media query, define the feature wrapper’s wider column track list. Use flexible fractional tracks so available space belongs to the columns instead of fixed card widths. Use the Level 2 card example to inspect how a grid-template-columns declaration defines tracks, then write the track list that matches your chosen number of feature columns.

Change only the feature collection declarations required for the wider arrangement. Do not duplicate its colors, spacing, borders, or text rules inside the media query.

Check

Test immediately below, at, and immediately above the breakpoint. Confirm that:

• below the breakpoint, entries remain in one column;
• above the breakpoint, the chosen number of flexible columns appears;
• a later row starts at the same column edges as the row above;
• source order and visual order agree; and
• no card or text crosses the viewport edge.

If it does not work

If columns are unequal without a content reason, inspect the track units and any remaining fixed item width. If content becomes crowded, reduce the column count or move the breakpoint later instead of shrinking the text.

Reference result: narrow and wider Grid

This responsive screenshot shows one possible result. At a narrow viewport, the four feature cards form one complete column. At a wider viewport, they form two aligned columns. The content, reading order, and other page layouts remain unchanged. A screenshot cannot prove which layout system produced the result, so use the DevTools checks above to confirm that your feature wrapper reports as Grid.

Refined home pageEnlarge

The base Grid keeps one complete column at a narrow viewport. The wider Grid aligns the same four feature cards in two flexible columns.

Refined home page

Close

The base Grid keeps one complete column at a narrow viewport. The wider Grid aligns the same four feature cards in two flexible columns.

5. Compare the jobs of Grid and Flexbox

Inspect the final page in DevTools and classify each layout container:

Page relationship	Layout tool	Reason
Vertical page sections	Normal flow	Each section follows the previous section in reading order
Navigation links	Flexbox	One group follows one main axis and can wrap
Main action links	Flexbox	One action group follows one main axis and can wrap
Feature collection	Grid	Repeated items align across columns and rows

Compare this table with When to use Flexbox and when to keep normal flow and the Level 2 Container query mental model. Use only the Grid part of that model in this article; the complete page still responds to the viewport through a Level 1 media query.

Do not replace every working Flexbox layout because Grid is newer. Choose the layout tool from the relationship among the items.

Check

Disable the Grid container declaration in DevTools. Confirm that only the feature collection loses its Grid arrangement. Restore the declaration and confirm that navigation and action groups remain Flexbox containers.

6. Stress-test the Grid without changing the product

Use temporary DevTools edits or a temporary saved change for these tests:

1. Replace the shortest feature heading with a much longer heading.
2. Add one long sentence to one feature description.
3. Test one fewer and one additional feature item.
4. Resize through the breakpoint range.
5. Set browser zoom to 200%.
6. Use Tab through the complete page.

The Grid must respond to content pressure without clipping text, hiding a feature, or changing keyboard order. Restore the intended content after the layout test.

Use Keep source order and visual order consistent and Test responsive behavior with evidence for the verification method.

If it does not work

• If a long word or URL widens a track, identify that content and apply the narrowest wrapping correction that preserves readability.
• If the layout needs three columns only at a much wider range, keep two columns at the current breakpoint or choose a later evidence-based breakpoint.
• If keyboard order differs from visual order, remove reordering declarations and restore meaningful HTML source order.
• If a feature appears missing, inspect the DOM before adding CSS. Grid arranges existing direct children; it does not create or delete content.

Checkpoint: The Grid survives content and interaction tests

What now works

Long content wraps, the chosen columns respond at an evidence-based breakpoint, source and keyboard order remain stable, and the landing page still passes narrow-width and zoom checks.

Files changed

index.html, styles.css

What remains

Validate and record the Grid checkpoint before adding motion.

Next action

Restore the intended feature text, save every file, and review styles.css in the VS Code Problems panel.

If it does not work

Restore the intended content first. Then test one width and one feature item while inspecting the active Grid tracks in DevTools.

7. Verify and record the Grid checkpoint

Repeat the first draft’s product route before adding another concept:

1. Validate the unchanged or repaired HTML with Validate the HTML source.
2. Review the updated stylesheet with Review CSS diagnostics in VS Code.
3. Open all three pages from the shared navigation.
4. Use browser Back after each route.
5. Press Tab through the landing page and confirm visible focus in source order.
6. Test the single-column Grid near 320px.
7. Test the wider Grid on both sides of the breakpoint.
8. Test at 200% browser zoom.
9. Confirm that the browser Console reports no error.

Inspect the Git diff. The expected source change is focused on the feature collection’s layout rules. An HTML wrapper change is valid only when the first draft did not already provide the correct Grid boundary.

Use the solo-development loop to record the verified Grid as a separate checkpoint. This commit gives you a stable recovery point before the motion experiment.

Checkpoint: The CSS Grid refinement is stable

What now works

The narrow and wide Grid states pass validation, content-pressure, zoom, link, and keyboard checks, and Git records the verified layout change.

Files changed

index.html, styles.css

What remains

Add one preference-aware transition to an interaction that already has a complete static result.

Next action

Choose one main action link and describe the visual difference between its default and hover or focus states.

If it does not work

Return to the Grid checkpoint. Do not start the motion change while a layout or validation check still fails.

8. Define the interaction before the motion

Choose one existing main action link, such as the link that opens the game. Do not choose the primary navigation for this first motion exercise.

The navigation must be stable and available as soon as the page loads. A navigation bar that glides into place automatically moves a primary control without responding to a visitor action. It can also delay access or create unwanted motion. Keep the navigation in its final position.

Use the selected action link to define a smaller interaction:

1. Write one sentence that states what the interaction must communicate.
2. Identify the link’s default visual state.
3. Identify the visual state that appears on both pointer hover and keyboard focus.
4. Confirm that the changed state remains clear through more than color alone.
5. Confirm that the visible focus indicator remains clear and appears without a delay.

Use Add visible link interaction states to review the complete static states. Then read Define the state before the animation for the Level 2 principle. That lesson uses JavaScript later, but this checkpoint transfers only its state-first method.

Check without motion

Temporarily make sure no transition declaration affects the action link. Test the link with a pointer and with Tab. The state change must be immediate, visible, and usable. Activating the link must still open the expected page.

If it does not work

• If hover works but keyboard focus does not, inspect the selector for the focus state.
• If the state depends only on a subtle color change, add another static cue such as a border, underline, or change in contrast.
• If the complete link moves surrounding content before a transition exists, correct the box-model change before adding motion.

Checkpoint: The static interaction is complete

What now works

One main action link has clear default, hover, and keyboard-focus states; the focus indicator remains visible; and the link works without any motion.

Files changed

styles.css

What remains

Add a short visual shift as an optional layer for visitors who have not requested reduced motion.

Next action

Open the selected link rule and identify which visual property will change between its stable states.

If it does not work

Remove or disable the transition. Restore a complete immediate state change before you continue.

9. Add one preference-aware transition

Use a CSS transition for this interaction. A transition connects two known states. An @keyframes animation is not required.

Plan the motion before you write CSS:

• choose a small transform translation that gives the action link a brief lift or shift;
• choose a short duration that makes the response noticeable without delaying it;
• use no start delay;
• keep the movement small enough that the link still feels anchored to the action group; and
• keep the static hover and focus cues as the source of meaning.

Keep the static hover and focus cues outside motion-preference conditions. Place both the transform and the transition declarations inside a prefers-reduced-motion: no-preference media query. The page must therefore keep the immediate static state change, without a shift, when motion is not permitted.

Use Add motion as a preference-aware layer to identify where the transition and motion declarations belong. Write values that fit your action link rather than copying the lesson’s complete component.

Check

With normal motion settings:

1. Move the pointer onto and away from the link.
2. Press Tab until the same link receives focus.
3. Press Shift + Tab to move focus away.
4. Confirm that the effect finishes, reverses, and never loops.
5. Confirm that nearby text and links do not move when the transform runs.

Reference recording: action transition

Play the recording to inspect the timing. The browser recording does not show the pointer. Watch the red Visit the game page link: it starts in place, lifts when hover begins, and returns when hover ends. The recording repeats the interaction once so you can compare the start and end states.

Primary action transitionVideo · playback controls available

The red primary action moves upward by 0.2rem over 200 milliseconds, then returns when the hover state ends.Static alternative: before the interaction, both action links share the same baseline. With normal motion, the red link keeps its thicker underline and moves slightly upward during hover or keyboard focus. In reduced-motion mode, the same underline and focus cues appear without movement or delay.

If it does not work

• If the page layout shifts, confirm that you transform the rendered link instead of changing its margin, padding, width, or position in normal flow.
• If keyboard users receive a different result, compare the hover and focus selectors.
• If the focus indicator becomes hard to see or is clipped, reduce the transform and restore the indicator’s immediate visual state.
• If the response feels delayed, remove any delay before changing the duration.

2Assistance 2 — Separate the result from the movement

Disable the transition declaration in DevTools. The action must still show its changed background, border, underline, or other static cue. Re-enable the transition only after that check passes.

3Assistance 3 — Reduce the motion experiment to one change

Keep one action link, one hover-and-focus state, one small transform, and one transition. Remove additional animated properties until you can explain the start state, end state, trigger, duration, and reduced-motion result.

10. Test the reduced-motion result

Use the browser’s rendering tools or operating-system setting to emulate prefers-reduced-motion: reduce. Follow Test reduced motion if you need the browser process.

Repeat the pointer and keyboard route. Confirm that:

• the link changes to the same static hover or focus result;
• the link does not glide, lift, or shift;
• the state appears without a delay;
• the focus indicator remains visible;
• activating the link still opens the same page; and
• no navigation or other page content starts moving automatically.

Return to the normal motion setting and repeat the route once more. Motion preference changes how the feedback appears, not what the visitor can learn or do.

Why the menu bar does not glide into the page

A page-load entrance is automatic motion, and the menu is a primary route through the site. This first exercise uses motion only after a visitor hovers or focuses an action. A later animation can explain a real state change after the project has interactive JavaScript state.

Checkpoint: The transition is optional feedback

What now works

The action link gives short user-triggered motion in the normal setting and the same immediate static result in reduced-motion mode. Navigation stays stable and every route still works.

Files changed

styles.css

What remains

Run the complete landing-page verification route and record the motion checkpoint.

Next action

Restore the normal browser setting, save styles.css, and start the final checks at narrow width.

If it does not work

Disable the transition, verify the static state, and add the no-preference condition again before adjusting timing or distance.

11. Validate and record the landing-page refinement

Run the complete verification route:

1. Validate all HTML files and review styles.css in the VS Code Problems panel.
2. Open all three pages through navigation and action links, then use browser Back.
3. Test the Grid near 320px, on both sides of its breakpoint, and at 200% zoom.
4. Use Tab and Shift + Tab through the complete page.
5. Test the selected action with a pointer and a keyboard in normal motion mode.
6. Repeat that interaction in reduced-motion mode.
7. Confirm that no content clips, no horizontal page scrolling appears, and the Console reports no error.

Use Run the final verification matrix to keep the motion checks separate. Use the Level 1 test report structure for the complete page route.

Inspect the Git diff. The second diff should contain only the static action-state correction, when one was needed, and the focused transition layer. Use the solo-development loop to record the motion checkpoint separately from the Grid checkpoint.

Self-check

Complete these checks against the required result.

1. Confirm that the feature wrapper reports Grid in DevTools and its direct feature entries report as Grid items.
2. Disable the media query and confirm that the complete feature collection remains usable in one column.
3. Confirm that the wider media-query state uses at least two flexible columns without fixed card widths.
4. Confirm that collection-specific Flexbox declarations no longer compete with Grid and the other one-dimensional groups still use Flexbox.
5. Compare source, visual, and keyboard order below and above the breakpoint.
6. Confirm that long test content, about 320px width, and 200% zoom produce no clipped content or horizontal page scrolling.
7. Disable transition declarations and confirm that the action still has clear hover and focus states.
8. Confirm that normal motion mode gives one short user-triggered shift that finishes and does not move surrounding content.
9. Confirm that reduced-motion mode gives the same static result without movement or delay.
10. Confirm that navigation never moves on page load and every link still opens the correct destination.
11. Confirm that HTML validation passes, VS Code reports no unresolved CSS author error, and the browser Console is clear.
12. Confirm that Git records separate Grid and motion checkpoints after the first-draft checkpoint.

Optional extensions

Choose one extension only after the required result passes.

Compare two valid column decisions

Compare two and three feature columns at a wide viewport. Record which version keeps the longest text easier to scan, which uses the available width more effectively, and where each version stops working well. Keep the version supported by your observations.

Compare two transition decisions

Compare two small transform distances or two short durations on the same action link. Test both with pointer and keyboard input. Keep the version that communicates the state change without drawing attention away from the page heading and navigation. Do not add another animated element.

Next step or safe stopping point

This is a safe stopping point. The landing page now combines a Level 1 responsive foundation with a focused Grid improvement and one optional layer of user-triggered motion.

Do not add container queries, keyframe sequences, or JavaScript yet. Continue to Build the Pokédex catalog from this verified website baseline. The next article replaces the Pokédex placeholder with eight complete static entries before a separate article introduces JavaScript.