This capstone project exists to prove a single point: everything covered across this module — dialogs, popovers, details/summary, custom elements, modern forms, and PWA installability — isn't a collection of isolated tricks. It's a coherent, production-capable toolkit, and this project is where that becomes undeniable.
1The Brief And The Core Reusable Component
The project brief: a task-management application with a task list, an 'Add Task' flow built on <dialog>, a per-task ⋮ actions menu built on the Popover API, expandable task detail panels using exclusive <details name> accordions, a genuinely reusable <task-card> custom element, and full PWA installability — six required features, each directly pulled from an earlier lesson in this module, now required to work together in one cohesive application rather than in isolation.
Each task renders through a <task-card> custom element, built with <template>, Shadow DOM, and named slots exactly as covered in the Reusable HTML Components lesson — giving the application one single, encapsulated source of truth for a task's structure and style, rather than duplicated card markup scattered across the app.
2Status-Driven Styling And The Task Creation Flow
A task's status drives both its CSS styling — via a data-status attribute and matching CSS attribute selectors, from the data-* Attributes lesson — and its participation in an exclusive <details name="task-group"> accordion group, from the Advanced Details/Summary lesson, so expanding one task's detail panel automatically collapses any other currently-expanded one, entirely natively.
The 'Add Task' dialog's form combines native constraint validation (required, type="date") for immediate, zero-JS feedback with a submit handler reading the new task's data via FormData rather than manually querying each input — directly applying both the Constraint Validation and FormData lessons together in the project's core create-task flow.
3The Finishing Step: Genuine Installability
The project's final requirement turns the finished task manager from merely a working page into a genuinely installable application: a linked web app manifest (<link rel="manifest">) with "display": "standalone" and both a standard and maskable icon, plus a registered service worker deferred until after the load event — exactly the checklist from the HTML For PWAs lesson, applied for real rather than as an isolated example.
Completing this step is the concrete, practical proof that this module's individual lessons compose into something genuinely production-shaped: a real application, installable on a home screen, built entirely from native HTML and browser APIs with no framework runtime required for any of its core interactive behavior.
4Step-by-Step Breakdown
Every Lesson In This Module, One App. This is where every individual lesson in this module — dialogs, popovers, templates, slots, custom elements, modern forms, and PWA installability — stops being separate topics and becomes one real, working, installable application.
The Brief: An Installable Task Manager. The project: a task-management app with a task list, an 'Add Task' flow using a <dialog>, a per-task '⋮' popover menu, exclusive-accordion task-detail panels via <details name>, a reusable <task-card> custom element with named slots, native form validation on task creation, and full PWA installability.
The Project Brief. Which native element handles the 'Add Task' modal form flow in this project's required feature set?
- →<dialog>, via showModal()
- →A popover-attribute element
- →A custom, hand-built modal <div>
Building The Reusable <task-card> Component. Each task renders as a <task-card> custom element with named slots (title, due-date, status) — built with <template> and Shadow DOM exactly as covered in the Reusable HTML Components lesson — giving the app a genuine, encapsulated, reusable building block rather than duplicated markup per task.
The task-card Component. Why does building a reusable <task-card> custom element (versus duplicating card markup for each task) matter for this project?
- →It gives the app one encapsulated, reusable source of truth for a task's structure, instead of duplicated markup
- →There's no meaningful difference either way for this project's scope
- →Browsers technically require custom elements for repeated UI patterns
**Wiring Data-Status To Both CSS And data-* Attributes.** A task's status (urgent, normal, done) drives both its visual styling — via a data-status attribute and matching CSS attribute selectors — and its exclusive <details name="task-group"> grouping for detail panels, directly applying both the data-* Attributes lesson and the Advanced Details/Summary lesson in one cohesive feature.
Combining Two Earlier Lessons. What does giving every task's <details> element the same name="task-group" attribute accomplish in this project?
- →Only one task's detail panel can be expanded at a time, natively
- →It only affects CSS styling, with no functional behavior
- →It's required for the data-status attribute to function at all
Native Form Validation Plus FormData Submission. The 'Add Task' dialog's form uses required and appropriate input types for immediate, zero-JS validation feedback, and its submit handler uses FormData (not manual field-by-field reading) to build the new task — directly applying both the Constraint Validation and FormData lessons together in the project's core create-task flow.
The Task Creation Form. Why use FormData to read the new task's field values, rather than manually reading each input's .value individually?
- →It reads directly from the real form, so it can't drift out of sync as fields are added or renamed
- →There's no real difference for a form this small
- →It's specifically required whenever a form is inside a <dialog>
Making It Installable: The Final Piece. The project finishes by adding a linked web app manifest with standalone display mode, a maskable icon, and a registered service worker deferred until after load — exactly the HTML For PWAs lesson's checklist — turning the finished task manager into a genuinely installable application, not just a page.
The Final Installability Step. What three things does a page need together before a browser will typically offer to install it as a PWA?
- →A linked web app manifest, a registered service worker, and HTTPS
- →Only a linked manifest; nothing else is required
- →Only a sufficiently high-resolution icon file
Final Project Complete. You've now built a complete, installable application combining every major feature from this module — proof that these aren't isolated tricks, but a coherent, production-capable native HTML toolkit for building genuinely modern 2026 interfaces.
Assemble The Full Page Skeleton. Bring together every landmark you've learned: header, nav, main, and footer.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Every Accessibility Property From Earlier Lessons — Dialog Focus Trapping, Details Disclosure Semantics, Correct Form Labeling — Must Genuinely Hold In The Combined Application
A capstone project is exactly where accessibility regressions from combining multiple features can slip in unnoticed — verify each piece's accessibility behavior still holds once integrated, not just in isolation.
Best Practices
Build And Verify Each Required Feature Individually Before Integrating Them Into The Full Application
Confirming the dialog, the popover, the custom element, and the form each work correctly in isolation makes integration debugging far more tractable than building everything simultaneously.
Run The Professional HTML Checklist From The Previous Lesson Against This Finished Project
The checklist lesson exists specifically to be applied to real work like this — treat the final project as the concrete test of that review process, not a separate, disconnected exercise.
Frequent Bugs
The task creation dialog's form submits successfully even with an empty required title field.
Verify the required attribute is actually present and the input's name matches what the FormData read logic expects.
Expanding one task's details panel doesn't collapse a previously-expanded one.
Confirm every task's <details> element shares the exact same name attribute value, forming one single exclusive group.
Real-World Examples
The Project's Core Structure, Assembled
The skeleton tying together dialog, popover, custom element, and details grouping for one task.
<li data-status="urgent">
<task-card>
<span slot="title">Ship the release notes</span>
</task-card>
<button popovertarget="menu-1">⋮</button>
<div id="menu-1" popover><button class="edit-task">Edit</button></div>
<details name="task-group">
<summary>Details</summary>
<p>Full description…</p>
</details>
</li>
<dialog id="task-form-dialog">
<form id="task-form" method="dialog">
<input name="title" required>
<input name="dueDate" type="date" required>
</form>
</dialog>