What is the purpose of <thead>, <tbody>, and <tfoot>?

You're building a simple data table for a user dashboard. Walk me through how you'd structure the HTML — where would you put the column headers versus the data rows?

A designer hands you a table mockup with a sticky header row and a summary footer row. What HTML elements would you use for each, and why?

If you forgot to wrap your header row in <thead> and just used <tr> directly inside <table>, what would break — visually, for screen readers, or when printing?

We have a sortable, paginated table where the header row stays fixed while the body scrolls. The current markup puts everything in a single <tbody>. What accessibility or styling problems does that cause, and how would you restructure it?

A QA engineer reports that when printing a 50-row invoice table, the column headers only appear on the first page. The markup uses <thead> — why isn't it repeating, and what CSS might be interfering?

You're adding row-grouping to a report table (e.g., subtotals per region). Would you use multiple <tbody> sections or a different approach? What tradeoffs does each have for screen readers and CSS?

Our virtualized table renders only visible rows for performance, but we still want <thead> and <tfoot> to stay in the DOM for accessibility. How do you reconcile virtualization with semantic table structure without breaking screen reader navigation?

A legacy codebase has hundreds of tables missing semantic sections. You're tasked with a codemod to add <thead>/<tbody>/<tfoot> automatically. What heuristics would you use to detect header vs body vs footer rows reliably, and what edge cases would you flag for manual review?

In a server-rendered React app, hydration mismatches occur because the server renders a full <tbody> but the client initially renders an empty one for virtualization. How would you structure the HTML to avoid this while preserving semantic correctness?

You're defining the table component API for a design system used by 50+ teams. Do you enforce <thead>/<tbody>/<tfoot> as required slots, or allow flexible composition? How do you balance semantic guarantees against real-world markup variations teams will inevitably produce?

During a platform migration, you discover that 30% of tables in the codebase use <div> wrappers inside <tbody> for layout hacks, breaking semantic structure. Propose a migration strategy that fixes accessibility without a full rewrite, and how you'd prevent regression.

An analytics team wants to inject tracking pixels into every table footer across the product. They propose appending to <tfoot> via a global script. Why is this architecturally risky, and what alternative pattern would you design for cross-cutting table concerns?