Inline element with vertical padding do not modify parent height

RESOLVED INVALID

Status

()

RESOLVED INVALID
12 years ago
10 years ago

People

(Reporter: aveclafaux, Unassigned)

Tracking

({testcase})

1.8 Branch
x86
Windows XP
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060918 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060918 Firefox/2.0

When am <a> element inside a <li> element has its padding set to a value different from zero, the <li> parent element height does not change.
It results in the child being bigger than the parent, and actually along the horizontal direction (left and right) it *does* modify the parent size.

IE 6.0 does expand the parent size - at least when the <li> element display is set to inline - but actually I'm not good enough in spec reading to decide who is right :-)

Of course, I have a practical use where this behaviour matters, and I needed a ugly CSS hack to make it right.

Reproducible: Always

Actual Results:  
The parent size is the same whether the child has padding or not

Expected Results:  
Using padding should expand the parent vertically (it does it horizontally).

I'll upload a reduced testcase ASAP.
(Reporter)

Comment 1

12 years ago
Created attachment 241316 [details]
Padding testcase

In the testcase <li> box is in blue and <a> box is in red.
The worrying case described above, is the 4th case : I will expect the parent box <li> to extend over the child box <a> vertically, particularly as it is doing it horizontally.

If you test the textcase with IE 6.0 you will see that the two browsers behave the same way (except for a stupid extra space in IE after the <a>) except for the 4th case where IE is actually having a more logical behaviour, AFAICT, which is not much :-)

Updated

12 years ago
Keywords: testcase
Version: unspecified → 2.0 Branch

Updated

12 years ago
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: 2.0 Branch → 1.8 Branch

Comment 2

12 years ago
Hello,
For several reasons (standards compliant rendering mode is one), I wish to replace your testcase with this testcase:

http://www.gtalbot.org/BugzillaSection/Bug355505.html

Your testcase shows only a difference for the last list-item where the <li> is of type display: inline. So, it becomes an inline element with a padding nested inside another inline element. So, the question ends up to be: if a nested inline element should make its inline parent grow vertically...
(Reporter)

Comment 3

12 years ago
Dear Gerard,
yes indeed - your testcase is an exact summary and much simpler.

In my testcase I just wanted to show the 'original' code where I saw it (in case the problem origin was not what I thought) and at the same time the reasons why I thought it was a bug and not a feature by comparing different cases.

I'm afraid we will have to wait for a CSS guru to dig into this one, but if it is not in the spec and not too difficult to change, I will say we should follow IE - it seems to make more sense to me, and I have a real case where it would help :-)

Comment 4

12 years ago
I'm looking into the CSS 2.1 spec right now...

"The height of a line box is determined by the rules given in the section on line height calculations.
A line box is always tall enough for all of the boxes it contains."
http://www.w3.org/TR/2006/WD-CSS21-20060411/visuren.html#inline-formatting

So far, I've read section 9.2.2 Inline-level elements and inline boxes
http://www.w3.org/TR/2006/WD-CSS21-20060411/visuren.html#q7
Section 9.4.2 Inline formatting context 
http://www.w3.org/TR/2006/WD-CSS21-20060411/visuren.html#inline-formatting
section 10.8
http://www.w3.org/TR/2006/WD-CSS21-20060411/visudet.html#line-height

Nowhere do I see that an inline box should stretch vertically, should grow to accomodate nested (childs) inline boxes.

Opera 9.02, Safari 2.x, Firefox 1.5+ and Seamonkey 1.5a all render my testcase the same way. It does not mean anything per se... but when all these browsers render testcases the same way, it's *_exceptionally rare_* that they all are wrong and that IE 6 is right.

> if it is not in the spec and not too difficult to change, I will say we 
> should follow IE"

IMO, that's not the correct way to deal with the issue. If it's not in the spec, then we should contact the W3C CSS working group to get clarification.

Comment 5

12 years ago
I read section 10.6.1 Inline, non-replaced elements
http://www.w3.org/TR/2006/WD-CSS21-20060411/visudet.html#inline-non-replaced
and I'm not sure.

Adding qawanted keyword

I'll search for a duplicate...
Keywords: qawanted

Comment 6

12 years ago
Component -> Layout: Block and Inline
Component: Layout → Layout: Block and Inline

Comment 7

12 years ago
Ok, I think this quote is the relevant one:

"The height of the content area [of an inline, non-replaced element] should be based on the font"
http://www.w3.org/TR/2006/WD-CSS21-20060411/visudet.html#inline-non-replaced

and not on the height of its inline box children
See bug 202942 comment #2

I'm leaving qawanted keyword so that someone else more knowledgeable than me can confirm or infirm my understanding/interpretation.
(Reporter)

Comment 8

12 years ago
Yeah, I'm afraid you're right, my only remaining hope is that the spec does not talk about children elements at all, and that for the width, the inline change size according to the children, thus calling for a 'symmetrical' case for the height :-)

Of course, as you mentioned, if only IE agree with me, I don't have a strong case :-)

Actually if I understand correctly the spec, it seems that to obtain the same effect, instead of using 'padding' I should use 'line-height' and some 'vertical-align'. Although it seems counter intuitive, I'll see how it goes...

Comment 9

12 years ago
> if only IE agree with me, I don't have a strong
> case :-)

That's not the most appropriate way to think :) The spec is decisive, determinant and should be what matters when browsers are triggered into standards compliant rendering mode, not the browsers' behaviors.

Resolving as INVALID
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Keywords: qawanted
Resolution: --- → INVALID
Duplicate of this bug: 452608
You need to log in before you can comment on or make changes to this bug.