Tutorial: Why html,body height:100% is required for div height:100% to work

A screen with dead space (below the copyright)

Dead Space

Source Code & Working Demo

When working with the new responsive web, one of the issues is to fill dead space (or white space, or negative space). The image (with the caption) Dead Space is an example of such an issue. A “workable solution” is to extend the <div> to the bottom of the screen. This type of solution works good on mobile phones, small tablets and media devices, like iPod Touch. You can test this on your device with the Working Demo.

Extended div.

Extended Div

The image (with the caption) Extended Div is what the “workable solution” would look like. The trick is simple enough.

Note, this trick is not explicitly described or talked about in any of the blogs I have read – including Chris Coyier and David Walsh. Now, it is possible to miss a blog describing this issues because the search is so generic (css height percentage tricks) .

Even when I found the this “trick”, no one could explain it or knows the process to make it happen. It took me a while to figure this out. The clue came from the CSS Almanac at CSS-tricks.com. The complete reason is below.

The CSS3 Trick

Set the follow attribute


for all the following HTML elements.

  • <html>
  • <body>
  • <div>

What the Specs Say

At first glance it is not entirely clear why this would work. But if you read multiple descriptions, then it makes sense.

From W3C CSS/Properties/height:

The percentage is calculated with respect to the height of the generated box’s containing block.

This helps, but it does not make sense.

From MDN: Height:

The percentage is calculated with respect to the height of the generated box’s containing block. If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, the value computes to auto. A percentage height on the root element is relative to the initial containing block.

Hmm… This adds details, but it still does not explain the issue.

NOTE: The next description seems to conflict, but that is because it is using convoluted logic. It is listed for completeness only. Read the description (max-height) that follows first.

From CSS Tricks: height:

(…) This means a value based on a percentage is still that of the elements content area. Similarly, if the height of the container is set to a percentage value, a child elements percentage height is still based on the content area of that child element.

From CSS Tricks: max-height:

The percentage is calculated with respect to the height of the containing block. If the height of the containing block is not specified explicitly, the percentage value is treated as none.

Okay. So now we have to draw on logic to have this make sense.  And we have to look closer into the W3C spec.

From W3C Visual Formatting Details: 10.5 Content height: the ‘height’ property we see in the “percentage” “meaning” section, the exact words from MDM, except *now* there are links. After reading the links and following the logic is it my contention that the specification is in error. It should read:

A percentage height on the initial containing block is relative to the root element.

If you read the sentence this way, it makes sense.


To be clear on height:100%,

if you do not have body {height:100%} and html {height:100%}, then div {height:100%} has no effect.

The likely reason for this was that the w3c committee want to add this feature without breaking existing features. One side effect is that this feature could be communicated easily verbally and in code, but it could not be communicated effectively in writing because of transcription error when add to the official specifications.

Slight Documentation Error causes Background Operations Issue

Baines_1835-Mule_spinningA recent question on a Google group uncovered an error in Apple’s iOS documentation as well as PhoneGap documentation (which also led to unnecessary technical workarounds). The question is How does one keep background opertations running in Phonegap without X Code?

These background opertations include: location, voip, fetch, remote-notification, newsstand-content, external-accessory, bluetooth-central and bluetooth-peripheral.

Here is the Issue

In the Apple documentation in the section entitled iOS Keys then scroll down to UIApplicationExitsOnSuspend; the correct documentation involves replacing ‘run’ with suspend, as shown here:


Specifies whether the app terminates instead of suspend in the background. See UIApplicationExitsOnSuspend for details.

In the Phonegap documentation (in Events#pause scroll down to iOS Quirks), similarly, the correct Phonegap documentation replaces ‘running’ with exit, as shown here:

For apps to exit when locked under iOS 5, disable the app’s multi-tasking by setting UIApplicationExitsOnSuspend to YES.

This inconsistencies are difficult to spot UNLESS you read other sections, and read carefully. Luckily, the correct setting turns out to be just below UIApplicationExitsOnSuspend It is UIBackgroundModes. In other words, DO NOT use UIApplicationExitsOnSuspend for background operations, use UIBackgroundModes.

How to Run Background Opertations in iOS

Specifies that the app needs to continue running in the background. See UIBackgroundModes for details.

Following through to Apple’s documentation there are nine (9) services that CAN run in the background.

  1. audio
  2. location
  3. voip
  4. fetch
  5. remote-notification
  6. newsstand-content
  7. external-accessory
  8. bluetooth-central
  9. bluetooth-peripheral

There is more, but I wanted to get this out.

Lastly for the location background service, Apple uses the phrase – “significant change location service”. That phrase is documented in the section ”Getting the User’s Current Location”.

Caveat Emptor – There are two (2) sections with similar titles on that page.

Lastly, I want to thank my friend Oswald Campesato for help me to make this a bit clearer. Any remaining unclarity is mine.