Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "86-public-pages"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Complete overhaul of all westside-playground pages. 8 new pages created, 14 existing pages updated with unified CSS, canonical/role-based nav, and component doc comments.
Changes
Public pages (9):
index.html— landing page, tryout content removed, practice count fixedstaff.html— canonical public navsponsors.html— canonical public navschedule.html(NEW) — 5 teams, travel/local divisions, TBD datesregister.html— updated, stale tryout refs removedsuccess.html— registration confirmation, updatedlogin.html(NEW) — Keycloak login page mockforgot-password.html(NEW) — Keycloak forgot password mockreset-password.html(NEW) — Keycloak reset password mockAuthenticated pages (14):
admin.html,admin-players.html,admin-teams.html— Admin role navcoach.html,coach-profile.html— Coach role navparent.html,player-profile.html— Parent role navbilling.html,team.html— role-appropriate navcheckout.html,checkout-success.html,checkout-cancel.html(NEW) — Stripe checkout mockjersey.html,jersey-success.html(NEW) — Jersey selection mockTest Plan
grep -ri "tryout" *.htmlreturns zero on public pagesReview Checklist
Related
westside-playground-overhaulPR #37 Review
PR: feat: public + authenticated pages overhaul (#86, #87)
Branch:
86-public-pagesParent issues: westside-app#86 (Public pages), westside-app#87 (Authenticated pages)
Domain: HTML/CSS/JS playground (static prototypes)
I read all 26 HTML files,
shared/style.css, andshared/app.json the86-public-pagesbranch. This review covers the full file set.DOMAIN REVIEW
Tech stack: Vanilla HTML/CSS/JS playground (static prototypes for SvelteKit promotion). No build tooling, no framework.
What was delivered well:
shared/style.css-- CSS unification is complete.schedule.html,login.html,forgot-password.html,checkout.html,checkout-success.html,checkout-cancel.html,jersey.html,jersey-success.html-- all well-structured with proper@route,@auth,@api,@gaps,@notesannotations. Excellent documentation for SvelteKit promotion.aria-labelon nav toggle,aria-expandedtoggling,aria-controls,lang="en",:focus-visiblestyles,.sr-onlyutility class.login.htmlandforgot-password.htmlcorrectly usemeta name="robots" content="noindex".Findings:
Auth page CSS duplication (DRY):
login.htmlandforgot-password.htmlboth contain identical inline<style>blocks (~90 lines each) defining.auth-page,.auth-card,.auth-logo,.auth-title,.auth-subtitle,.auth-form,.auth-submit,.auth-links,.auth-back. These classes do not exist inshared/style.css. The whole point of the CSS unification (issue #85) was to eliminate inline styles. These should be inshared/style.css.forgot-password.htmlinline script: Contains an inline<script>block forshowForgotSuccess()instead of putting it inshared/app.js. The app.js has an auto-init pattern inDOMContentLoaded-- this function should follow that pattern.login.htmlmissingshared/app.js: Does not include<script src="shared/app.js" defer>. The mobile nav toggle handler lives inapp.js. While login has no nav, omitting it breaks the "all pages use shared/app.js" convention stated in the PR scope.forgot-password.htmlmissingshared/app.js: Same issue as login.html.Broken link:
forgot-password.htmlline 169 links toreset-password.htmlwhich does not exist in the repo. The "Open Reset Page (Demo)" button leads to a 404.schedule.htmlinline style repetition: 16 inlinestyle=""attributes, with the same 3-line pattern (margin-top, padding-top, border-top + two styled paragraphs) copied 5 times across team cards. These should be CSS classes like.card-upcoming-eventsand.card-upcoming-label/.card-upcoming-text.Legacy pages not updated:
westside-index.htmlandoriginal-index.htmlstill have the old 5-item nav (missing Schedule link) andwestside-index.htmllinks to itself instead ofindex.html. These may be intentionally preserved as history, but if they are meant to be part of the playground, their nav is stale.Role label inconsistency:
team.html,player-profile.html,billing.html, andcoach-profile.htmlusenav-user-rolevalueplayerinstead ofmember. Thesignin.htmlannotations explicitly state roles areadmin,coach,member("not player -- the account holder, not the athlete"). New pages (checkout, jersey) correctly usemember. Pre-existing pages were not corrected.BLOCKERS
None. This is a static HTML/CSS playground -- no server-side code, no user input processing, no auth logic, no secrets. The BLOCKER criteria (test coverage for new functionality, unvalidated user input, secrets in code, DRY in auth/security paths) do not apply to static HTML prototypes. The DRY violation in the auth CSS is a quality concern but not a security-path DRY violation.
NITS
Auth CSS to shared/style.css: Move the
.auth-*classes from inline<style>blocks inlogin.htmlandforgot-password.htmlintoshared/style.css. This completes the CSS unification goal from issue #85.Inline script to app.js: Move
showForgotSuccess()fromforgot-password.htmlinline<script>toshared/app.jswith auto-init detection in theDOMContentLoadedhandler.Add app.js to auth pages: Include
<script src="shared/app.js" defer>inlogin.htmlandforgot-password.htmlfor convention consistency.Fix broken reset-password link: Either create
reset-password.htmlor change the link to point to an existing page / remove it with a note that the reset flow is handled by Keycloak.Extract schedule card inline styles: Create CSS classes for the repeated "Upcoming Events" card section pattern in
schedule.html.Normalize role labels: Change
playertomemberinteam.html,player-profile.html,billing.html, andcoach-profile.htmlnav-user-role values to match the documented role model.Decide on legacy pages: Either update
westside-index.htmlandoriginal-index.htmlnav to match the canonical 6-item set, or add a comment/README note that these are intentionally frozen snapshots.SOP COMPLIANCE
86-public-pagesreferences issue #86PROCESS OBSERVATIONS
reset-password.htmllink is the only functional regression risk.@route,@auth,@api,@state,@interactivity,@gaps,@notesannotations in HTML comments are excellent. This is exactly the documentation needed for SvelteKit promotion. Every page is a self-contained spec.VERDICT: APPROVED
The core deliverables are solid: 8 new pages created, canonical public nav unified across all public pages, role-based authenticated nav consistent per role, all pages on shared/style.css, good annotation coverage. The nits (auth CSS duplication, inline script, broken link, role label inconsistency) are quality improvements that should be tracked as cleanup work (issue #88 exists for this purpose). No blockers for a static HTML playground.