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

Resources → Subject Notes → Information Communication Technology ICT → Lesson Plan

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)

Aspect Table Layout CSS Layout (Flexbox / Grid)
Semantic meaning Low – interpreted as data tables High – HTML describes content; CSS describes presentation
Responsive design Complex – requires nested tables or scripts Built‑in with media queries, flex‑wrap, grid‑auto‑fit
Accessibility Screen readers announce a data table; navigation can be confusing ARIA roles/landmarks can be added; linear reading order is preserved
Maintenance Hard – many rows/columns to edit for a small change Easy – change a single CSS rule or adjust a grid template
Browser compatibility Excellent on very old browsers (Netscape 4, IE 4) Supported by all modern browsers (Chrome, Edge, Firefox, Safari)
Performance More HTML markup → larger download Less markup; CSS is cached separately
Legacy support Works without any CSS – useful for extremely old environments Requires 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)

Criterion Table layout suitable? Reason (AO3 justification) CSS layout preferable? Reason (AO3 justification)
Content is genuinely tabular (e.g., price comparison) Yes Semantic markup matches the data; no extra CSS needed. No Using a table avoids unnecessary CSS and keeps the markup simple.
Project must run on very old browsers (pre‑1998) Yes Older browsers do not understand Flexbox/Grid or media queries. No CSS layout would be ignored or rendered incorrectly.
Design needs to adapt to phones, tablets and desktops No Tables require complex nesting or JavaScript to become responsive. Yes Flexbox/Grid + media queries provide native, maintainable responsiveness.
Accessibility for screen‑reader users is a priority No Screen readers treat tables as data tables, disrupting navigation. Yes Semantic HTML + ARIA landmarks give a clear reading order.
Team prefers quick visual layout in a WYSIWYG editor Possibly (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 code Content covered Assessment objective(s)
21.0 Reason for using tables; link to audience‑appropriate layout AO1
21.1 HTML, CSS, (note: scripting not required) AO1
21.2 Historical reasons – limited early CSS support AO1
21.3 Advantages – predictable rendering, simple markup, WYSIWYG ease, suitability for real data tables AO1
21.4 Disadvantages – non‑semantic, size, accessibility, maintenance, poor responsiveness; modern alternatives (Flexbox, Grid) AO2
21.5 Side‑by‑side comparison table (semantic meaning, responsiveness, accessibility, maintenance, compatibility, performance, legacy support) AO3
21.6 Step‑by‑step procedure for a two‑column table layout (mapped to AO2) AO2
21.7 Evaluation rubric with justified criteria (when to use tables vs. CSS) AO3
21.8 Key take‑away – legacy knowledge vs. modern best practice AO1 / 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.

Create an account or Login to take a Quiz

87 views
0 improvement suggestions

Log in to suggest improvements to this note.