WDD9 - CSS: height and width
- I can set an element's width and height explicitly using pixel and percentage values.
- I can explain how percentage width and height are calculated relative to a parent element.
- I can describe what happens by default when content does not fit inside a fixed-size box.
- I can calculate a percentage width or height in pixels, given the parent's size.
- I can explain why percentage height needs the parent to have an explicit height set.
- I can identify overflow as the cause when content spills outside a fixed-size box.
WDD9 combines width/height with the box model and margin rules from WDD7 and WDD8.
margin: 10px 20px; (a 2-value shorthand), what does the second value set?Key vocabulary
Setting width and height
Default sizing before anything is set
Before any width or height is set, a block-level element behaves in a specific default way: its width stretches to fill all of the available width inside its parent, while its height shrinks to fit whatever content is inside it - just tall enough, no more. This is sometimes called the element's intrinsic size. Setting width or height explicitly overrides this default behaviour, fixing that dimension to the value given regardless of how much content is inside, or how much space the parent has available.
Width and height still only set the content box
As with the box model from WDD7 and WDD8, width and height set the size of the content layer only. Padding and border are still added outward from that, so a box declared as width: 300px; with padding: 20px; and a 5px border on every side has a visible width of 300 + 40 (padding both sides) + 10 (border both sides) = 350px, exactly as WDD7 and WDD8 already established for the box model in general.
Percentage width and height
Percentage width: calculated from the parent's width
A percentage width is calculated as a percentage of the parent element's own width. If a parent is 800px wide and a child has width: 50%;, the child renders at 400px wide - straightforward, because the parent always has a defined width one way or another (its own explicit width, or the viewport width if nothing else is set).
Percentage height: needs the parent to have an explicit height
Percentage height works the same way in principle - a percentage of the parent's height - but has a much more common failure case. A parent's height is very often left at its default, auto, meaning it shrinks to fit its own content rather than having any fixed height of its own. If the parent's height is auto, there is no fixed reference height for a percentage child height to be calculated from, so a percentage height on the child typically has no effect - it behaves as if no height had been set on the child at all, rather than producing any specific number. This only starts working correctly once the parent is given an explicit height of its own, such as a fixed pixel value.
.child { height: 50%; }
Overflow: when content doesn't fit
The default is visible, not hidden or resized
Fixing a box's height (or width) creates a new question: what happens if the content inside genuinely needs more space than the box provides? By default, the browser does not shrink the content to fit, and does not automatically grow the box to accommodate it. Instead, the content simply overflows - it spills outside the edges of the box, visibly, often overlapping whatever comes after it on the page. This default behaviour is controlled by the overflow property, whose default value is visible. WDD7 already introduced overflow: hidden; as a fix for a different problem (a collapsing floated container); here the same property is relevant again because fixed-height text containers are a common real-world source of overflowing content, especially once content length is variable - user-submitted text, or a translated version of a page with longer words than the original.
Worked examples
.thumb {
width: 300px;
height: 100px;
padding: 20px;
border: 5px solid #185FA5;
}
300px wide and 100px tall - this is what width/height set directly..parent { width: 800px; }
.child { width: 50%; }
800px.50% width is calculated relative to that: 50% of 800px..child { height: 50%; }
Has no effect. The parent's height is auto, so there is no fixed reference for 50% to be calculated from.
.child { height: 50%; }
Works. The child renders at 200px tall - 50% of the parent's fixed 400px height.
A parent element has an explicit height of 600px. Its child has height: 25%. What is the child's rendered height in pixels?
The parent has an explicit height (600px), so the percentage has a fixed reference to calculate from.
25% of 600px = 150px.
Child height: 150px.
Practical: percentage height and overflow, WebStorm
Build this from scratch - no starter file this time.
- In WebStorm, create a new HTML file called
sizing.html. - Add a
<div class="parent">containing a<div class="child">with some short text inside. - In an internal stylesheet, give
.childheight: 50%;and a background colour, but leave.parentwith no height set. Open in a browser - the child's height should look like it has had no effect. - Now give
.parentan explicitheight: 400px;. Save and refresh - the child should now visibly become exactly half that height. - Finally, give
.childa fixedheight: 30px;and paste in several sentences of text. Observe the text overflowing the box by default, then addoverflow: hidden;to.childand observe the difference.
<div class="parent">
<div class="child">Some sample text</div>
</div>
.parent {
height: 400px;
border: 2px dashed #999;
}
.child {
height: 50%;
background: #E6F1FB;
}
Compare your own file against this rather than copying it - the key thing to observe is the child's rendered height changing only once .parent has an explicit height of its own.
- Assuming percentage height always works like percentage width. Percentage height needs the parent to have an explicit height set - if the parent's height is auto, the percentage typically has no effect.
- Forgetting that width and height set the content box only. Padding and border still add to the box's visible size on top of whatever width/height is declared.
- Assuming content too big for a fixed-size box gets squeezed to fit. By default (overflow: visible), oversized content spills outside the box instead of shrinking or being clipped.
- Setting a fixed height on a text container without considering variable content length. Longer translated text, or longer pupil/user input than expected, is a common real-world cause of overflow bugs.
If a question asks what happens when content is too big for a fixed-size box, the precise term is overflow, and the correct default behaviour is that it spills outside the box (overflow: visible) - not that it gets clipped, and not that the box grows automatically. For percentage height questions, always check whether the parent's height is stated explicitly in the question - if it is auto or unstated, that is usually the point being tested.
Task Set A - Core questions
.thumb {
width: 200px;
height: 200px;
padding: 10px;
}
.thumb {
width: 180px;
height: 180px;
padding: 10px;
}
width and height set the content box only - the original 200px content size plus 10px padding on each side added up to 220px visible. Reducing the content width/height to 180px means 180 + 10 + 10 = 200px visible in each dimension.
Task Set B - Extension
File this in OneNote under:
Higher Computing Science > Web Design & Development > WDD9
Timing: content is scoped for a single period but this lesson lands on a double (Mon 30 Nov 2026, per WDD.md §2a/§4 table) - the same "extra time" mismatch as WDD6 and WDD8, not a shortfall. Core pace through Task Set A: 6 min warm up, 10 min sizing notes + Example 1, 12 min percentage width/height notes + context box + Examples 2/3, 6 min overflow notes, remaining time on Task Set A. Use the spare second period for the full WebStorm practical in class, Task Set B, and extra retrieval practice on WDD7/WDD8 box model content ahead of WDD10.
Scope control: deliberately does not cover box-sizing: border-box (an alternative box model where width/height include padding and border) - the SQA spec and Chris's own L8 both work with the default content-box model throughout, so introducing border-box here would contradict the box model as already taught in WDD7/WDD8. Also does not cover vh/vw viewport units or min-width/max-width/min-height/max-height, which are not part of the confirmed spec list for this lesson.
Percentage height is the highest-value gotcha in this lesson, matching margin collapse's role in WDD8 - it is the one behaviour pupils are most likely to get wrong from intuition alone. A4/A5/A8/B1 test it from four angles: conceptual MC, numeric calculation, written explanation, and a multi-child extension case.
Practical built from scratch (no starter file), continuing the WDD6(starter)/WDD7(scratch)/WDD8(starter)/WDD9(scratch) alternation.