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.
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 :-)
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: 2.0 Branch → 1.8 Branch
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...
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 :-)
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.
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...
Component -> Layout: Block and Inline
Component: Layout → Layout: Block and Inline
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.
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...
> 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
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.