Build a single-page, front-end-only web app for a fictional ...

Prompt

Build a single-page, front-end-only web app for a fictional private jet charter company called "Meridian Air". Vanilla HTML/CSS/JS only — no frameworks, no UI libraries (no Bootstrap, no jQuery, no date-picker plugins, no icon libraries requiring a build step). No backend — simulate all data client-side with a hardcoded JSON array of ~10 flight options. Everything must be hand-built and testable in a single browser tab. DESIGN Dark, minimalist, quiet-luxury aesthetic — charcoal/black background, champagne-gold accent, elegant serif headings + clean sans body text. Same visual bar as a top-tier luxury brand site, but the priority here is FUNCTIONAL CORRECTNESS, not visual flourish. CORE FUNCTIONALITY (this is the real test — get these right) 1. SEARCH & FILTER FLIGHT LIST - A hardcoded dataset of ~10 flights (departure city, arrival city, date, aircraft type, seats available, price). - Search inputs: departure city, arrival city, date, passenger count. - Filtering must actually work against the dataset (not just visually hide/show placeholder cards). - Sort control: by price (asc/desc) and by departure time. - Debounce the text search inputs (300ms) so filtering doesn't re-run on every keystroke. - Pagination or "load more" if results exceed a page size you define. 2. STATES YOU MUST HANDLE EXPLICITLY - Loading state: simulate a fake 800ms network delay with a skeleton loader before showing results. - Empty state: no flights match filters — show a real empty-state message, not a blank screen. - Error state: add a hidden "Simulate error" trigger (e.g. a small dev button or a URL param like ?fail=true) that forces the search to fail, showing an error message with a working "Retry" button. 3. CUSTOM COMPONENTS BUILT FROM SCRATCH (no libraries) - A custom dropdown/select for aircraft type or sort options — must be keyboard operable (arrow keys to navigate options, Enter to select, Escape to close) and use correct ARIA (role="listbox", aria-expanded, etc). - A custom date picker OR a well-validated text date input with real format validation and clear error messaging — your choice, but state which you picked and why. - A modal for flight details (click a flight card → modal with full info + "Request to book" button). Modal must trap focus while open, close on Escape and on backdrop click, and return focus to the triggering element on close. 4. MULTI-STEP BOOKING FORM (triggered from the modal's "Request to book") - Step 1: passenger details (name, email, phone) — real validation: proper email regex check, phone format check, required-field checks, inline error messages (not just red borders). - Step 2: trip preferences (catering, ground transport — checkboxes). - Step 3: review + confirm. - Submit button must be disabled until the current step is valid. Back/next must preserve entered data. Show a fake success confirmation on final submit (no real network call). 5. PERSISTENCE - Persist the user's last search filters in localStorage and restore them on page reload. - Persist a light/dark theme toggle (default to system preference via prefers-color-scheme, but let the user override and remember their choice). 6. ACCESSIBILITY (will be checked, not assumed) - Full keyboard operability: every interactive element reachable and usable via Tab/Shift+Tab/Enter/Escape/arrows. - Visible focus states on everything (no `outline: none` without a real replacement). - Proper semantic HTML and ARIA roles/labels on all custom components. - Color contrast must meet WCAG AA for text against backgrounds (check the gold-on-black combos specifically — this is a common luxury-site failure point). 7. RESPONSIVE - Must work cleanly at 320px, 768px, 1024px, and 1440px+ widths. Flight cards, filters, and the multi-step form all need to reflow sensibly on mobile (not just shrink). CONSTRAINTS / NO SHORTCUTS - Do not copy a known open-source component library's markup/CSS wholesale — build the dropdown, modal, and form logic yourself and comment briefly on your approach. - Do not fake the filtering (e.g. don't just hide the same 3 hardcoded cards regardless of input) — the logic must actually query the dataset. - Do not skip the error/empty states — they're part of the test. DELIVERABLE + SELF-REVIEW Single HTML file with embedded CSS/JS (or clearly organized multi-file if you prefer — your call, just make it runnable). At the very end of your response, add a short "Known limitations / what I'd add for production" list — be honest about anything you simplified, faked, or skipped.

A system prompt was added to support web rendering