Padding and bordered not visible in Internet Explorer 7: why?

Hello fellow stylesheet colleagues,

URL of demo:
http://www.gtalbot.org/BrowserBugsSe...firmedBug.html

In IE 7, the red border around the body seems to suggest/indicate that
the body has a higher z-index than its inner content... at least, it
seems visually, graphically rendering as such.

I checked carefully the CSS 2.1 spec and I can not find a spot where
it explains what should happen of padding and borders of inline-
elements when they obviously protrude outside the line box of inline
elements.

10.6 Calculating heights and margins
Section 10.6.3 Block-level non-replaced elements in normal flow when
'overflow' computes to 'visible'
http://www.w3.org/TR/CSS21/visudet.html#normal-block
states
"If it [a block-level non-replaced element] only has inline-level
children, the [its] height is the distance between the top of the
topmost line box and the bottom of the bottommost line box."

But what happens when those inline-level children have padding and
borders: how are they eventually rendered, according to CSS 2.1 spec?
I'm 90% sure there is a bug in IE 7... but I can't find the CSS 2.1
spec proving or stating so...

Firefox 2.0.0.11, Opera 9.25, Safari 3.0.4, Hv3 TKHTML alpha 16 all
render the testcase identically.

Amaya 9.55 makes the body node as high as the nested inline-elements
=~ 1px + 32px + 16px + 32px + 1px = 82px.

Regards, Gérard
--
Internet Explorer 7 bugs
http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/

On 2008-01-19, GTalbot <newsgroup (AT) gtalbot (DOT) org> wrote:

Hello fellow stylesheet colleagues,

URL of demo:
http://www.gtalbot.org/BrowserBugsSe...firmedBug.html

In IE 7, the red border around the body seems to suggest/indicate that
the body has a higher z-index than its inner content... at least, it
seems visually, graphically rendering as such.

Better not to use the word z-index to describe the bug.

You haven't set z-index on anything, so this is just a "stacking order
bug".

I checked carefully the CSS 2.1 spec and I can not find a spot where
it explains what should happen of padding and borders of inline-
elements when they obviously protrude outside the line box of inline
elements.

They just get drawn, with the dimensions as specified and in the
stacking level specified.

They probably should be clipped if overflow:hidden is set on the
container, which Firefox doesn't seem to be doing, but that's a separate
issue.

See CSS 2.1 8.8.1, at the bottom of that section, where stacking order
is specified. Body's borders (stacking level 1) should be drawn behind
its in-flow inline-level descendents (stacking level 5).

[...]

Firefox 2.0.0.11, Opera 9.25, Safari 3.0.4, Hv3 TKHTML alpha 16 all
render the testcase identically.

Amaya 9.55 makes the body node as high as the nested inline-elements
=~ 1px + 32px + 16px + 32px + 1px = 82px.

Amaya is wrong. Inline-box padding is not supposed to affect line box
height (10.6.1 "only the line-height is used when calculating the
height of the line box).

On 20 jan, 10:18, Ben C <spams... (AT) spam (DOT) eggs> wrote:

On 2008-01-19, GTalbot <newsgr... (AT) gtalbot (DOT) org> wrote:

Hello fellow stylesheet colleagues,

URL of demo:
http://www.gtalbot.org/BrowserBugsSe...firmedBug.html

In IE 7, the red border around the body seems to suggest/indicate that
the body has a higher z-index than its inner content... at least, it
seems visually, graphically rendering as such.

Better not to use the word z-index to describe the bug.

You haven't set z-index on anything, so this is just a "stacking order
bug".

Hello Ben,

I reported the bug as bug 102:

http://www.gtalbot.org/BrowserBugsSe...E7Bugs/#bug102
and
http://www.gtalbot.org/BrowserBugsSe...neathBody.html

Yes, you're right. I should and will remove reference to z-index.
Added to my to-do list.

I checked carefully the CSS 2.1 spec and I can not find a spot where
it explains what should happen of padding and borders of inline-
elements when they obviously protrude outside the line box of inline
elements.

They just get drawn, with the dimensions as specified and in the
stacking level specified.

They probably should be clipped if overflow:hidden is set on the
container, which Firefox doesn't seem to be doing, but that's a separate
issue.

See CSS 2.1 8.8.1, at the bottom of that section, where stacking order
is specified. Body's borders (stacking level 1) should be drawn behind
its in-flow inline-level descendents (stacking level 5).

There is no section 8.8.1. You most likely meant section 9.9.1:
http://www.w3.org/TR/CSS21/visuren.html#z-index

"
The root element forms the root stacking context. Other stacking
contexts are generated by any positioned element (including relatively
positioned elements) having a computed value of 'z-index' other than
'auto'. Stacking contexts are not necessarily related to containing
blocks. In future levels of CSS, other properties may introduce
stacking contexts, for example 'opacity' [CSS3COLOR].

Each stacking context consists of the following stacking levels (from
back to front):

1. the background and borders of the element forming the stacking
context.
2. the stacking contexts of descendants with negative stack levels.
3. a stacking level containing in-flow non-inline-level
descendants.
4. a stacking level for floats and their contents.
5. a stacking level for in-flow inline-level descendants.
"

Yes, that is it. That is what IE is not doing correctly. Stacking from
back to front, starting from body to in-flow inline-level descendants
in that #bug102 demo.

[...]

Firefox 2.0.0.11, Opera 9.25, Safari 3.0.4, Hv3 TKHTML alpha 16 all
render the testcase identically.

I added this explanation:

"Although margins, borders, and padding of non-replaced elements do
not enter into the line box calculation, they are still rendered
around inline boxes. This means that if the height specified by 'line-
height' is less than the content height of contained boxes,
backgrounds and colors of padding and borders may 'bleed' into
adjoining line boxes. User agents should render the boxes in document
order. This will cause the borders on subsequent lines to paint over
the borders and text of previous lines."
CSS 2.1, Section 10.8.1, Leading and half-leading
http://www.w3.org/TR/CSS21/visudet.html#leading
... but I now understand that such paragraph is actually referring to
something else, different; I now think this section 10.8.1 paragraph
has nothing to do with the #bug102.

I'll fix that later...

Amaya 9.55 makes the body node as high as the nested inline-elements
=~ 1px + 32px + 16px + 32px + 1px = 82px.

Amaya is wrong. Inline-box padding is not supposed to affect line box
height (10.6.1 "only the line-height is used when calculating the
height of the line box).

Correct. Amaya has a bug.

This is great, Ben. I really appreciate your assistance on this.

Best regards and many thanks, Ben,

Gérard

On 2008-01-23, GTalbot <newsgroup (AT) gtalbot (DOT) org> wrote:

On 20 jan, 10:18, Ben C <spams... (AT) spam (DOT) eggs> wrote:
[...]
See CSS 2.1 8.8.1, at the bottom of that section, where stacking order
is specified. Body's borders (stacking level 1) should be drawn behind
its in-flow inline-level descendents (stacking level 5).

There is no section 8.8.1. You most likely meant section 9.9.1:
http://www.w3.org/TR/CSS21/visuren.html#z-index

Yes I did mean 9.9.1

"
The root element forms the root stacking context. Other stacking
contexts are generated by any positioned element (including relatively
positioned elements) having a computed value of 'z-index' other than
'auto'. Stacking contexts are not necessarily related to containing
blocks. In future levels of CSS, other properties may introduce
stacking contexts, for example 'opacity' [CSS3COLOR].

Each stacking context consists of the following stacking levels (from
back to front):

1. the background and borders of the element forming the stacking
context.
2. the stacking contexts of descendants with negative stack levels.
3. a stacking level containing in-flow non-inline-level
descendants.
4. a stacking level for floats and their contents.
5. a stacking level for in-flow inline-level descendants.
"

Yes, that bit.