nirravv/hospital-management-html

1. This repository is a static, client-rendered hospital website: each route is a separate HTML file, and there is no backend, API layer, database, or build pipeline. The site is meant to run directly from the filesystem or a static host such as GitHub Pages.

2. The architecture has three main layers: page content in the root HTML files, shared presentation in assets/css/modern.css, and shared interaction logic in assets/js/modern.js. Those two asset files are the common dependency for nearly every page.

3. The navigation is not a framework component; it is part of the shared front-end shell behavior. The JavaScript handles nav injection/behavior, mobile drawer interaction, and auto-hide-on-scroll behavior, so the same navigation experience is reused across pages.

4. The site uses a dark-first visual system with an optional light mode. Theme persistence is handled on the client side, likely through browser storage, so the appearance state survives refreshes without any server involvement.

5. Core “marketing” and informational content is split into dedicated pages: index.html for the landing page, about.html for hospital background and values, doctors.html for staff profiles, gallery.html for media, blog.html for articles, and contact.html for contact details plus a message form. privacy.html and terms.html are standalone legal/prose pages.

6. The action-oriented pages form a separate functional cluster: appointment.html is the booking flow, while registration.html and login.html are authentication-style entry points. In this repo they are front-end-only forms, so they function as UI demos rather than wired transactional systems.

7. The JavaScript adds progressive enhancement rather than application state management. According to the README, it drives scroll-reveal animations, animated counters, the gallery lightbox, hover interactions, theme toggling, and form demos. There is no SPA routing or client-side data fetching.

8. The CSS is the main source of layout and visual system design. It uses a single stylesheet with custom properties, grid-based layouts, backdrop blur/glass effects, and keyframe animations. That means the visual language is centralized and shared, rather than repeated per page.

9. Asset organization is content-based rather than component-based. Images are grouped by purpose under assets/img/bg, blogs, gallery, slider, and team, which maps directly to page sections like hero backgrounds, blog cards, gallery items, hero sliders, and doctor portraits.

10. The primary data flow is static: browser loads an HTML page, that page pulls in the shared CSS/JS, the JS enhances the DOM after load, and user actions like theme toggling or gallery viewing stay entirely in the browser. The only durable client state called out is the theme preference.

11. From an architecture-diagram perspective, the key boundaries are: page content vs shared assets, presentation vs behavior, and static public pages vs interactive UI affordances. The repo is deliberately simple and monolithic at the source level, but functionally organized by page type and shared enhancement layer.