hasLayout.net

Document Scrollbars Overflow Inconsistency

Affected Versions

This bug affects: IE7

Symptoms

Unconventional default value for `overflow` on <html> element that may appear as a bug with regard to `overflow` on <body>.

Date of the Tutorial

Tue Aug 18 15:56:27 2009

Description

The reason I am not calling this, umm, "effect" a bug is because to my understanding it isn't. What we are dealing here with is an inconsistency between IE7 and other browsers with regard to default value for overflow property on ' element"><html> element. I could not find anything about the default value in the spec - feel free to point it out to me.

I've seen a few people claim this as bug that overflow is not applied to ' element"><body> element because it seems to "work" in other browsers. Let's take a look at the demo that shows this pseudo-bug:

Demo

The demo is available on a separate page

HTML Code:
<p>There are no scrollbars on this page in sane browsers</p>
CSS Code:
html, body, p {
    margin: 0;
    padding: 0;
}
body {
    overflow: hidden;
}
p {
    width: 5000px;
    height: 5000px;
}

We have overflow set to hidden on ' element"><body> element and inside of it we have a ' element"><p> element that has very large dimensions set on it. What we see in sane browsers is that any excess window overflow caused by the ' element"><p> is hidden and there are no scrollbars on the page. In IE7 we just see the vertical one.

Yes, this sounds like a bug description, but if we look closer we will realize that ' element"><body> does not have neither width nor height set on it, and for that reason, it would not hide any overflow. Why do sane browsers hide then? Section 11.1.1 of CSS 2.1 Spec states that if the value of overflow on root element (' element"><html> element in our case) is set to value visible then user agents must apply the value of overflow from ' element"><body> element to the viewport.

What causes the problem here is that sane browsers by default set value visible on ' element"><html> element, while [judging by observation of behaviour] IE7 has it as html { overflow-x: visible; overflow-y: scroll }. Since the overflow from ' element"><body> element would transfer to viewport only when overflow on ' element"><html> element set to visible, there is no bug in IE, only unconventional default on ' element"><html> element; as a side note: Opera 9.62 seems to miss this vital detail and transfers overflow from ' element"><body> all the time.

Solutions

Below are solutions for the above bug ordered by the solution type.

Solution (Clean Solution)

Date of the Solution

Tue Aug 18 15:56:41 2009

Fixed Versions

All of the affected

Description

To fix this inconsistency, we will simply apply overflow on ' element"><html> element, much the same way most of us use CSS reset of sorts. Let's have a look:

Fixed demo is available on a separate page

HTML Code:
<p>There are no scrollbars on this page in sane browsers</p>
CSS Code:
html, body, p {
    margin: 0;
    padding: 0;
}
html {
    overflow: visible;
}
body {
    overflow: hidden;
}
p {
    width: 5000px;
    height: 5000px;
}

I've added html { overflow: visible; } to the demo, and now IE transfers overflow from ' element"><body> element to the viewport, as per spec.

Sidenote: the solutions of the people who would regard my demo as an IE bug (i.e. ignore of body { overflow: hidden; }) list html { overflow: hidden; } as a solution. This would work just fine; the only difference is that my solution shows more of what's going on with regard to the fix as well as more flexible (e.g. for { overflow: auto; }) - you can even stick it in your reset sheet that you are using.