18  6987 
"Francois du Toit" <fr************@gmail.com> 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
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>
"Francois du Toit" <fr************@gmail.com> 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
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/visude...eight-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/visude...-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.
"Francois du Toit" <fr************@gmail.com> 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
"Francois du Toit" <fr************@gmail.com> wrote: From:
http://www.w3.org/TR/REC-CSS2/visude...-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
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.h...-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 .
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/visude...eight-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/visude...-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
"Francois du Toit" <fr************@gmail.com> 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.h...-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
>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/
"Francois du Toit" <fr************@gmail.com> wrote: 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.
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. 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.
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
Spartanicus <in*****@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
Gérard Talbot <ne***********@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
Martin Bialasinski <ag********@uni-koeln.de> 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?
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
On Thu, 15 Sep 2005 11:56:03 +0200, Martin Bialasinski
<ag********@uni-koeln.de> wrote: Gérard Talbot <ne***********@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?
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
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?
Do you know of a fix or workaround in the meantime?
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Gustav Medler |
last post by:
Hello,
there is a known problem with Opera and the execution of content shown
in <NOSCRIPT> tag.
Everythings works fine, if there is only one simple script like:...
|
by: Robert Lapes |
last post by:
I'm just getting into using CSS and I'm having a problem getting Opera
to display a Navigation Bar in the same way as IE6. Can someone
please point me in the right direction?
The site I'm...
|
by: TheKeith |
last post by:
Is it just me or does opera and ie not render the float style properly?
IE does a sucky job at it, but opera makes a total mess; Mozilla/Firefox
renders it correctly however. I'm just trying to be...
|
by: Lachlan Hunt |
last post by:
Hi,
I've been trying, but failing to work out what is causing Opera to
render my drop down menu incorrectly on my site.
http://www.lachy.id.au/
For some reason, there seems to be extra margin...
|
by: jmm-list-gn |
last post by:
Hello,
<http://www.asaom.edu>
There are some curious spacing issues with the top bar (gray) and the
main navigation bar.
The most significant is how the nav bar looks in Opera v6 (win2k): the...
|
by: eternalD3 |
last post by:
Hi,
I have a problem to get this working on Opera 7.x+. This does not need
to work on older Opera browsers
There are problems on rendering the sub-level navigation. It aligns
right on Firefox...
|
by: Mark Pappert |
last post by:
I've got a linked 'common.js' file that contains one function, on IE
and Firefox everything works as expected. However, Opera generates the
following error:
...
|
by: =?Utf-8?B?UGhpbCBKb2huc29u?= |
last post by:
Hi,
I have a gridview and I need it to display correctly in Opera.
I need to set the row height, so that even on the last page of data all the
rows are the same height as on the other pages.
...
|
by: rhino |
last post by:
I've put together a prototype of two-tiered CSS tabs that works really well
in IE6, IE7, and FF2. It also works very well in Opera 9.27 _except_ that
the placement of the lower tier of tabs is...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
