Building TNT Adventures

“Home” describes what the file does; “Index” describes how it was historically generated. In the early web, index.html was auto-generated by Apache directory listings — a convention that survived long after most sites stopped using directory listings. In a deliberately designed site, every file should have a name that communicates its role to the developer who opens the project in an editor six months from now.

Rule: If you can read the filename and immediately know what the page does without opening it, the name is correct. adventureHome.html passes that test. index.html does not.

The naming hierarchy for the Adventures section now has three distinct patterns, each self-describing:

• adventureHome.html — the section landing page
• sHuntHome.html — the scavenger hunt catalog (camelCase: activity type + role)
• sh-xray-2026-08-01.html — individual hunts (kebab-case: type prefix + topic + date)

When index.html is removed from a directory, any browser that navigates to the bare directory URL (/adventures/) gets a 404. Keeping a redirect shim in place — two-line HTML with <meta http-equiv="refresh"> plus a JS fallback — costs nothing and eliminates all compatibility risk.

The canonical name is the new one (adventureHome.html). The old file exists only to serve any traffic that arrives via the directory URL or an outdated bookmark. It is not linked from anywhere in the project going forward.

The three-section <details> format from swingAlphabetSPARK.html maps directly onto the Stooges page:

• Episode overview (open) — We Want Our Mummy (1939), a .mission-quote dialogue block, and the persistence theme
• The Adventures connection — the Curly–student parallel, with Hunt #1 stops 1 and 9 as concrete evidence
• Fun Facts — Stooges adventure-genre history with amber border (matching swingAlphabet)

The .content-card was updated to #111827 and the clip frame border changed from green to amber — consistent with swingAlphabet and other clip pages. Adventures green stays in the hero gradient; the shared dark card palette is now uniform across the clip collection.

Two placements were considered: in the content area (between hero and activity cards) or inside the hero itself. The hero wins: the blurb is visible on load alongside the title, setting tone before anything else is read.

The blurb renders at 88% size and 62% opacity — subordinate to the title and subtitle, but immediately readable. The “Meet them →” link uses amber so it reads as the one actionable element in the hero without competing with the main headings.

“Meet them” implies the Stooges are characters you can go and encounter — not a footnote about the background image. The arrow makes it a direction, not a label.

The profile is stored under tntAdventureProfile as a JSON object: { firstName, lastName, period }. Date is deliberately excluded — it belongs to individual activity submissions, not the identity record. When a hunt page needs to record a response, it reads the profile from localStorage and appends the submission date at that moment.

Three behaviors driven by the presence or absence of the stored key:
No profile → modal opens immediately, non-dismissable (static backdrop, no Escape, no close button) until form is completed.
Profile exists → modal skipped; student bar renders at page bottom showing name, period, and Edit / Reset links.
Edit clicked → modal opens in edit mode with pre-filled values and a visible close button (fully dismissable).

The same <div class="modal"> serves onboarding and editing, but with different Bootstrap options. On first visit: backdrop: 'static', keyboard: false. On edit: backdrop: true, keyboard: true with the close button made visible.

Options are passed programmatically as the second argument to new bootstrap.Modal(el, options) rather than set as data-bs-* HTML attributes, because the behavior must differ between the two modes. One element, two instantiation contexts, correct behavior in both cases.

The student bar sits at the bottom of <main>, between the content section and the footer — visible to a student looking for it, unobtrusive for one who is not. It is a status indicator, not a call to action.

The Reset link invokes confirm() before clearing the profile. A student who clicks Reset accidentally should not lose their saved data without a second deliberate action.

The student bar now has two layers: the normal status row (id="studentBarMain") and a hidden confirmation row (id="resetConfirm"). When Reset is clicked, the confirmation row slides into view below the status line with two styled buttons: Yes, clear it (red) and Cancel (grey). Cancel hides the confirmation row. Yes, clear it performs the actual reset.

No overlay, no browser dependency, no thread blocking — and the visual language (red for destructive, grey for safe) communicates the intent without any words beyond the label.

openModal() now calls bootstrap.Modal.getInstance(el) before creating a new instance. If a stale instance exists, prev.dispose() is called first. Only then is new bootstrap.Modal(el, options) called, with a clean element.

Rule: Always call getInstance() before new Modal() on a shared DOM element. Stale instances are the most common source of unexpected Bootstrap modal behavior, and they are invisible — no console error, just wrong behavior.

When openModal(false) is called (first-visit or post-reset mode), the three form fields are now explicitly cleared and any is-invalid classes from a previous attempt are removed. Without this, old values and red validation highlights from a prior session persist in the form after a reset — which is confusing precisely because the user just cleared their profile and expects a blank slate.

The immediate initProfile() call is replaced with a two-branch check. If document.readyState === 'complete', all resources are already loaded and initProfile() runs immediately. Otherwise, it is registered as a window.load listener, which fires only after every stylesheet, script, and image is fully applied.

The readyState guard is necessary because the script sits at the bottom of <body>: by the time the browser parses it, load may have already fired. Registering a listener for an event that has already fired does nothing — the guard prevents that silent failure.

The pageshow event fires for both normal loads and BFCache restorations. When event.persisted === true, the page was served from cache. A listener for this event calls initProfile() again, correctly rendering either the student status bar (if a profile is saved) or the welcome modal (if not).

pageshow is the only event that fires in both load and cache-restore contexts. DOMContentLoaded and window.load do not fire on BFCache restoration — this is by design, for performance. Any page that initializes UI from stored state must listen for pageshow to behave correctly after back/forward navigation.

One template for all five Adventures pages. Path values vary by directory depth; the structure is identical:

• Icon 1: TNT dynamite icon → site home (index.html)
• Icon 2: Validate icon → W3C validator (dynamic URL via validateLink JS pattern)
• Text: All rights reserved. • © 2015–[year] TechNoviceTools (TNT) • Last updated: [date]

Why no Bootstrap icon? Bootstrap is a framework dependency, not a content partner. Dependency credit belongs in page comments or chatlog tech notes, not in student-facing footer chrome.