Know and understand the reason tables are used to structure elements within a web page

21 Website Authoring – Using Tables for Layout

Objective (21.0)

Know and understand why tables were once used to structure elements within a web page and be able to evaluate when a table‑based layout is appropriate for the intended audience and device.

21.1 Web‑development layers (syllabus 21.1)

  • HTML – defines the logical structure and content of a page.

  • CSS – controls presentation (layout, colours, fonts, responsive behaviour).

  • Scripting (JavaScript) – adds interactivity, but the IGCSE syllabus does not require any scripting for this topic.

When studying tables for layout we focus on the HTML layer (structure) and the CSS layer (presentation).

21.2 Why tables were historically used for layout (21.2)

  • Early browsers (mid‑1990s) offered only limited CSS support – no floats, no absolute/relative positioning, and no media‑query‑driven responsiveness.

  • Tables provide a built‑in grid of rows and columns, allowing designers to align text, images, forms and navigation without extra code.

  • Cell dimensions are calculated together, so related elements stay together when the page is resized.

  • WYSIWYG editors (e.g., FrontPage, Dreamweaver) visualised the table grid, making it easier for non‑programmers to create a layout.

  • Many legacy sites and corporate intranets still use table‑based layouts; understanding them enables students to read and modify existing code.

21.3 Advantages of table‑based layout (AO1)

  1. Predictable rendering – the table model is part of the HTML standard, so pages look the same across all browsers, including very old ones.

  2. Simple markup – only <table>, <tr>, <td> (and optional <th>) are required.

  3. Convenient for genuine tabular data – a price list or schedule can serve both as data and as page layout.

  4. Easy visual design in legacy WYSIWYG tools – the grid is displayed directly in the editor.

21.4 Disadvantages and modern alternatives (AO2)

  • Presentation vs. content – tables imply tabular data, so the markup is not semantic.

  • File size & load time – extra <tr>/<td> elements increase HTML size.

  • Accessibility – screen readers announce table cells as data tables, confusing navigation for users of assistive technology.

  • Maintenance – inserting or moving a column often requires editing many rows.

  • Responsive design – tables do not adapt easily to different screen widths without complex nesting or JavaScript.

  • Modern CSS techniques – Flexbox, Grid and CSS positioning separate style from structure, are lighter, and support media‑query‑driven responsiveness out of the box.

21.5 Comparison: Table Layout vs. CSS Layout (AO3 – evaluation)

AspectTable LayoutCSS Layout (Flexbox / Grid)
Semantic meaningLow – interpreted as data tablesHigh – HTML describes content; CSS describes presentation
Responsive designComplex – requires nested tables or scriptsBuilt‑in with media queries, flex‑wrap, grid‑auto‑fit
AccessibilityScreen readers announce a data table; navigation can be confusingARIA roles/landmarks can be added; linear reading order is preserved
MaintenanceHard – many rows/columns to edit for a small changeEasy – change a single CSS rule or adjust a grid template
Browser compatibilityExcellent on very old browsers (Netscape 4, IE 4)Supported by all modern browsers (Chrome, Edge, Firefox, Safari)
PerformanceMore HTML markup → larger downloadLess markup; CSS is cached separately
Legacy supportWorks without any CSS – useful for extremely old environmentsRequires CSS support; not suitable for pre‑1998 browsers

21.6 Procedural steps to create a simple two‑column page using a table (AO2 – practical)

  1. Create a new HTML file and add the standard <!DOCTYPE html> declaration.

  2. Inside the <body>, insert a <table> element.

  3. Add a single row: <tr>.

  4. Within that row, create two cells:

    • <td id="nav">…navigation links…</td>

    • <td id="content">…main article…</td>

  5. Give the table a width of 100% so it spans the full browser width:

    <table width="100%" border="0">

  6. Set column widths (either with the deprecated width attribute or, preferably, with CSS):

    td#nav { width: 20%; vertical-align: top; }

    td#content { width: 80%; }

  7. Close the tags: </tr> and </table>.

  8. Save the file and open it in a browser – you will see a two‑column layout.

Mapping to assessment objectives: Steps 1‑5 demonstrate knowledge of HTML structure (AO2); Steps 6‑7 show application of CSS for presentation (AO2); the whole procedure reflects the ability to produce a functional layout (AO2).

21.7 Evaluation rubric – When to choose a table vs. CSS (AO3)

CriterionTable layout suitable?Reason (AO3 justification)CSS layout preferable?Reason (AO3 justification)
Content is genuinely tabular (e.g., price comparison)YesSemantic markup matches the data; no extra CSS needed.NoUsing a table avoids unnecessary CSS and keeps the markup simple.
Project must run on very old browsers (pre‑1998)YesOlder browsers do not understand Flexbox/Grid or media queries.NoCSS layout would be ignored or rendered incorrectly.
Design needs to adapt to phones, tablets and desktopsNoTables require complex nesting or JavaScript to become responsive.YesFlexbox/Grid + media queries provide native, maintainable responsiveness.
Accessibility for screen‑reader users is a priorityNoScreen readers treat tables as data tables, disrupting navigation.YesSemantic HTML + ARIA landmarks give a clear reading order.
Team prefers quick visual layout in a WYSIWYG editorPossibly (legacy editors only)Older editors visualise table grids directly.Yes (modern editors)Current WYSIWYG tools now render CSS visually, removing the need for tables.

21.8 Syllabus checklist (quick reference)

Syllabus codeContent coveredAssessment objective(s)
21.0Reason for using tables; link to audience‑appropriate layoutAO1
21.1HTML, CSS, (note: scripting not required)AO1
21.2Historical reasons – limited early CSS supportAO1
21.3Advantages – predictable rendering, simple markup, WYSIWYG ease, suitability for real data tablesAO1
21.4Disadvantages – non‑semantic, size, accessibility, maintenance, poor responsiveness; modern alternatives (Flexbox, Grid)AO2
21.5Side‑by‑side comparison table (semantic meaning, responsiveness, accessibility, maintenance, compatibility, performance, legacy support)AO3
21.6Step‑by‑step procedure for a two‑column table layout (mapped to AO2)AO2
21.7Evaluation rubric with justified criteria (when to use tables vs. CSS)AO3
21.8Key take‑away – legacy knowledge vs. modern best practiceAO1 / AO3

Suggested diagram: side‑by‑side illustration of a simple 2‑column layout created with a table (HTML only) and the same visual result produced with CSS Flexbox (HTML + CSS). The diagram highlights the different underlying code structures while showing identical output.

Key take‑away (21.9)

Tables were once a convenient shortcut for page layout because early browsers lacked robust CSS support. Modern CSS techniques (Flexbox, Grid, media queries) provide cleaner, semantic, accessible and responsive solutions. However, legacy web sites and exam questions may still contain table‑based layouts; students must be able to read, modify, and evaluate them, and decide when a table is genuinely appropriate versus when CSS is the better choice.