| Author |
Opera div height bug
|
|
|
|
| Spartanicus 2005-09-13, 7:47 pm |
| "Francois du Toit" <francoisdutoit@XXXXXXXXXX> wrote:
>Can someone confirm this:
>http://www.purpleray.za.net/opera_bug.html
The containing block for div.l is div.bug (*not* div.h since it's
position is static), but div.bug has a height of 100%, which doesn't
compute to a defined height in your example.
I'd file a bug @ Mozilla.
--
Spartanicus
| |
| Francois du Toit 2005-09-13, 7:47 pm |
| Ok I think I see what you're saying, but what about this:
In opera you get a red block - and in firefox a blue block. Shouldn't
div.l inherit the height from div.h ?
<style type="text/css"><!--
div.rel {
background-color: red;
position: relative;
left: 10px;
top: 10px;
width: 50%;
}
div.h {
height: 100px;
width: 100%;
}
div.l {
width: 100%;
height: 100%;
background-color: blue;
position: absolute;
left: 0px;
top: 0px;
}
--></style>
</head>
<body>
<div class="rel">
<div class="h">
<div class="l"></div>
</div>
</div>
</body>
</html>
| |
| Spartanicus 2005-09-13, 7:47 pm |
| "Francois du Toit" <francoisdutoit@XXXXXXXXXX> wrote:
>Ok I think I see what you're saying, but what about this:
>
>In opera you get a red block - and in firefox a blue block. Shouldn't
>div.l inherit the height from div.h ?
No, same reason as with the other example.
--
Spartanicus
| |
| Francois du Toit 2005-09-14, 7:53 pm |
| Ok this did not make sence at first, but this is how I understand it
now. ;)
Refering to my first example (
http://www.purpleray.za.net/opera_bug.html )
The height is not inherited as you said, I misunderstood that. But
according to the specs from
http://www.w3.org/TR/REC-CSS2/visud...height-property :
<percentage>
Specifies a percentage 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), the value is interpreted like 'auto'.
and from
http://www.w3.org/TR/REC-CSS2/visud...g-block-details :
If the element has 'position: absolute', the containing block is
established by the nearest ancestor with a 'position' other than
'static', in the following way:
So as I understand it - div.l should get it's height from the
containing block established by div.bug and not div.h because div.h is
static.
div.bug's height is a percentage value - but since it's containing
block is not specified it should get it's height from it's content
(like auto).
It seems to me that opera computes the height for div.l from div.l's
content because it's containing block is not specified (div.bug has a
percentage value).
Firefox computes the height for div.l from the containing block of
div.bug. Although it is not specified, it does have a height that it
gets from it's content.
| |
| Spartanicus 2005-09-14, 7:53 pm |
| "Francois du Toit" <francoisdutoit@XXXXXXXXXX> wrote:
>It seems to me that opera computes the height for div.l from div.l's
>content because it's containing block is not specified (div.bug has a
>percentage value).
Correct, Opera does the right thing here.
>Firefox computes the height for div.l from the containing block of
>div.bug. Although it is not specified, it does have a height that it
>gets from it's content.
And it's not supposed to do that, Firefox gets this wrong.
--
Spartanicus
| |
|
|
| Spartanicus 2005-09-14, 7:54 pm |
| "Francois du Toit" <francoisdutoit@XXXXXXXXXX> wrote:
>From:
>http://www.w3.org/TR/REC-CSS2/visud...g-block-details
CSS 2.0 has effectively been obsoleted, use the 2.1 spec. instead.
>If the element has 'position: absolute', the containing block is
>established by the nearest ancestor with a 'position' other than
>'static', in the following way:
> 1. In the case that the ancestor is block-level, the containing
>block is formed by the padding edge of the ancestor.
>
>So I think firefox follows the CSS spec correctly.
You've not presented an argument that would support this conclusion, the
sections that you've quoted from the spec support that Opera is doing
the right thing.
If the height of the ancestor of an absolutely positioned box with
height:100% is undefined, then the height of the absolutely positioned
box is also undefined and resolves to auto, 100% of undefined is
undefined.
The fact that there is another box in between these two boxes with a
defined height as in your example is irrelevant since it's not the
containing block for the absolutely positioned element.
--
Spartanicus
| |
| Francois du Toit 2005-09-14, 11:21 pm |
| I changed the page a bit to make the problem clearer I hope.
The 2.1 spec says roughly the same thing as 2.
http://www.w3.org/TR/CSS21/visudet....g-block-details
If the element (div.l) has 'position: absolute', the containing block
is established by the nearest ancestor (div.bug) with a 'position' of
'absolute', 'relative' or 'fixed', which is the padding edge of the
ancestor (if it is block-level).
The padding edge of div.bug has a border in my example. This should
also be the containing block for div.l .
| |
| Gérard Talbot 2005-09-15, 4:26 am |
| Francois du Toit a écrit :
> Ok this did not make sence at first, but this is how I understand it
> now. ;)
> Refering to my first example (
> http://www.purpleray.za.net/opera_bug.html )
>
> The height is not inherited as you said, I misunderstood that. But
> according to the specs from
> http://www.w3.org/TR/REC-CSS2/visud...height-property :
>
> <percentage>
> Specifies a percentage 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), the value is interpreted like 'auto'.
>
> and from
> http://www.w3.org/TR/REC-CSS2/visud...g-block-details :
>
> If the element has 'position: absolute', the containing block is
> established by the nearest ancestor with a 'position' other than
> 'static', in the following way:
>
> So as I understand it - div.l should get it's height from the
> containing block established by div.bug and not div.h because div.h is
> static.
> div.bug's height is a percentage value - but since it's containing
> block is not specified it should get it's height from it's content
> (like auto).
>
> It seems to me that opera computes the height for div.l from div.l's
> content because it's containing block is not specified (div.bug has a
> percentage value).
> Firefox computes the height for div.l from the containing block of
> div.bug. Although it is not specified, it does have a height that it
> gets from it's content.
>
Opera has had that bug since Opera 7.0 beta 1, some 34 months ago. The
bugfile number is 123305 in Opera's BTS.
Gérard
--
remove blah to email me
| |
| Spartanicus 2005-09-15, 4:26 am |
| "Francois du Toit" <francoisdutoit@XXXXXXXXXX> wrote:
>I changed the page a bit to make the problem clearer I hope.
Nope.
>The 2.1 spec says roughly the same thing as 2.
>http://www.w3.org/TR/CSS21/visudet....g-block-details
>
>If the element (div.l) has 'position: absolute', the containing block
>is established by the nearest ancestor (div.bug) with a 'position' of
>'absolute', 'relative' or 'fixed', which is the padding edge of the
>ancestor (if it is block-level).
You continue to repeat this, but there is no disagreement about div.bug
being the containing block.
You've still not presented an argument for your conclusion that Opera is
wrong.
--
Spartanicus
| |
| Francois du Toit 2005-09-15, 7:29 am |
| >You continue to repeat this, but there is no disagreement about div.bug
>being the containing block.
So div.l should have a height of 100% of that containing block which in
my example is 200px.
>You've still not presented an argument for your conclusion that Opera is
>wrong.
The height of div.l is not 200px in opera. It is only as heigh as it's
content.
The height of div.l is 200px in FF.
If that's not clear enough, here is more examples:
http://www.gtalbot.org/BrowserBugsSection/Opera7Bugs/
| |
| Spartanicus 2005-09-15, 7:29 am |
| "Francois du Toit" <francoisdutoit@XXXXXXXXXX> wrote:
>
>So div.l should have a height of 100% of that containing block which in
>my example is 200px.
No it's not, div.bug has an undefined height, again: 100% of undefined
is undefined, hence it resolves to auto. The 200px height is specified
on the *other* div, which is *not* the containing block. If you want
that other div to be the containing block you have to set it's position
property to something else than static.
>
>The height of div.l is not 200px in opera. It is only as heigh as it's
>content.
>The height of div.l is 200px in FF.
Still no argument, all you are saying is that FF does it differently, so
Opera must be wrong.
I'm beginning to suspect that you are trolling.
--
Spartanicus
| |
| Martin Bialasinski 2005-09-15, 7:29 am |
| Spartanicus <invalid@invalid.invalid> wrote:
> You've still not presented an argument for your conclusion that
> Opera is wrong.
The crucial point is "height: 100%;" in div.bug.
Francois thinks it means "100% of its natural height" (inward
direction). Which would be 200px in the example.
Whereas you say the percentage is to be taken wrt to div.bug's parent
element (outward direction). And as its parent has height:auto,
div.bug's height is auto. Correct?
I think your interpretation of the spec. is the correct
one. Percentage height/width is relative to the parent, not the
content.
An example of the percentage calculations are the typical menus.
ul li(width:10em) a(width:100%)
Bye,
Martin
| |
| Martin Bialasinski 2005-09-15, 7:29 am |
| Gérard Talbot <newsblahgroup@gtalbot.org> wrote:
> Opera has had that bug since Opera 7.0 beta 1, some 34 months
> ago. The bugfile number is 123305 in Opera's BTS.
Did you get feedback? Do they agree with you it is an incorrect interpretation?
Bye,
Martin
| |
| Spartanicus 2005-09-15, 7:29 am |
| Martin Bialasinski <agr30+news@uni-koeln.de> wrote:
>
>The crucial point is "height: 100%;" in div.bug.
>
>Francois thinks it means "100% of its natural height" (inward
>direction). Which would be 200px in the example.
>
>Whereas you say the percentage is to be taken wrt to div.bug's parent
>element (outward direction). And as its parent has height:auto,
>div.bug's height is auto. Correct?
Not "parent", but "nearest positioned ancestor", which is his example is
div.bug which has no *defined* height. It has a height but it is based
on the content, thus it is not known until after the first rendering.
The CSS spec tries to prevent reflows if it can. Consequently percentage
heights refer to *defined* heights only, if the height is not defined as
in his example then a percentage height that refers to it resolves to
auto.
--
Spartanicus
| |
| Rijk van Geijtenbeek 2005-09-15, 7:39 pm |
| On Thu, 15 Sep 2005 11:56:03 +0200, Martin Bialasinski
<agr30+news@uni-koeln.de> wrote:
> Gérard Talbot <newsblahgroup@gtalbot.org> wrote:
>
>
> Did you get feedback? Do they agree with you it is an incorrect
> interpretation?
That bug report relates to percentage widths, not percentage heights. The
rules for widths are a bit different, they are always allowed IIRC
(because there is always a parent that has a defined width, while the
height of a document is not determined beforehand). And Opera 7/8 indeed
has a bug there where the wrong ancestor is used in some cases. This will
be fixed in the next major rendering engine upgrade.
--
Get Opera 8 now! Speed, Security and Simplicity.
http://my.opera.com/Rijk/affiliate/
Rijk van Geijtenbeek
| |
| Francois du Toit 2005-09-15, 7:39 pm |
| Maybe the height:100% in div.bug is confusing the issue. I've taken it
out now since it is not neccesary to illustrate the bug.
In my example, div.bug has a yellow border around it's padding edge.
This is correct in opera. The specs says that div.l's containing block
is the padding edge of the ancestor, which in this case is div.bug's
yellow border. So the height of div.l should be 100% of that yellow
border, which it is not in opera.
I started out with a wrong understanding of what went wrong - the
height:100% in div.bug is a seperate issue. Sorry for that.
Is there some way to make the div.l box's height the same as div.bug in
opera?
| |
| Francois du Toit 2005-09-15, 7:39 pm |
| Do you know of a fix or workaround in the meantime?
|
|
|
|
| Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |