Premier League Predictor: Astro — Chapter 12, Exercise 1
====================================================

TASK
Explain precisely why a <base href="/predictor/"> tag would do
nothing at all for this app's own paths, using the real distinction
between a relative URL and a root-relative URL, and contrast that
directly with why the identical fix genuinely worked for the FastAPI
sibling.

SOLUTION

A <base> tag changes how the browser resolves a RELATIVE URL — one
that doesn't start with a leading slash, like "api/foo" or
"../styles.css". For a URL written that way, the browser combines it
with whatever base URL is currently in effect (either the page's own
real URL, or an explicit <base href="..."> if one is set) to work out
the real address to actually request.

A ROOT-RELATIVE URL — one that does start with a leading slash, like
"/api/foo" — works completely differently. The browser treats a
leading slash as an instruction to resolve from the site's own origin
(scheme + host + port) directly, ignoring whatever path the current
page is actually at, and ignoring any <base> tag entirely. This is
documented browser behavior, not a quirk: a root-relative URL is, by
definition, already fully resolved with respect to any base path —
there's nothing left for a <base> tag to contribute.

Every path this Astro app generates — every href built in a page's
own frontmatter, every Astro.redirect() call, every fetch() URL in a
client script — is written with a leading slash: "/admin/...",
"/api/...". That was true from the very first chapter that needed to
generate a path, since it's the simplest, most natural way to write
one in both Astro's own templates and in plain JavaScript. Because
every single one of these paths is root-relative, not relative, a
<base href="/predictor/"> tag would have zero effect on any of them —
they'd all still resolve straight from the site's own root, exactly
as if no <base> tag were present at all.

The FastAPI sibling's own identical fix worked specifically because
that course's own client-side code was rewritten to use genuinely
relative paths — dropping the leading slash — specifically so that a
<base> tag would have something to actually apply to. The fix wasn't
"add a <base> tag" on its own; it was "add a <base> tag AND switch to
relative paths so the tag has an effect," a two-part change. This
course's own app never made that second change anywhere, which is
exactly why the identical single-part version of the fix (a <base>
tag alone) would do nothing here.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly and precisely distinguishes relative from root-relative
URL resolution, explains exactly why a <base> tag structurally cannot
affect a root-relative path, and correctly identifies that the
FastAPI sibling's own real fix was a two-part change (relative paths
PLUS a base tag) rather than the base tag alone — which is the actual
reason the same single ingredient doesn't transfer to a codebase that
never made the accompanying path-format change.