472,145 Members | 1,595 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,145 software developers and data experts.

top: 50%; position: relative; question

Hello fellow stylers,

When trying this page

http://www.gtalbot.org/BrowserBugsSe...sitioning.html

I get different rendered layouts with IE 6, IE 7 beta 2, Firefox 1.5.0.2
and Opera 9.0 build 8367.

Firefox 1.5 and Opera 9 will just ignore the CSS declaration
top: 50%; position: relative;

IE 6 and IE 7 beta 2 position the red div at 50% of the height of the
body node.

After carefully reading the CSS 2.1 spec, I wonder (am not sure)

- which browsers is right, which browser is wrong
- and why (in terms of the CSS 2.1 spec)

What do you think?

Gérard
--
remove blah to email me
Apr 18 '06 #1
6 5930
Els
Gérard Talbot wrote:

http://www.gtalbot.org/BrowserBugsSe...sitioning.html

I get different rendered layouts with IE 6, IE 7 beta 2, Firefox 1.5.0.2
and Opera 9.0 build 8367.

Firefox 1.5 and Opera 9 will just ignore the CSS declaration
top: 50%; position: relative;
Maybe they can't figure out of which you want it to calculate 50%.
IE 6 and IE 7 beta 2 position the red div at 50% of the height of the
body node.
So I think they're wrong, and just try to please you :-)
After carefully reading the CSS 2.1 spec,
Which section? Got a url?
I wonder (am not sure)

- which browsers is right, which browser is wrong
- and why (in terms of the CSS 2.1 spec)

What do you think?


What I think? I think you're mistaking position:relative for
position:absolute.
The fact that you mention which element is "its nearest block-level
ancestor box" confirms that thought.

position:relative means relative to its own original position.
If you want it to be positioned at 50% of the height of body, then you
need position:absolute, which is relative to the first positioned
ancestor.

--
Els http://locusmeus.com/
accessible web design: http://locusoptimus.com/

Now playing: Yes - Ritual [live][Symphonic Tour]
Apr 18 '06 #2
Els wrote :
Gérard Talbot wrote:

http://www.gtalbot.org/BrowserBugsSe...sitioning.html

I get different rendered layouts with IE 6, IE 7 beta 2, Firefox 1.5.0.2
and Opera 9.0 build 8367.

Firefox 1.5 and Opera 9 will just ignore the CSS declaration
top: 50%; position: relative;
Maybe they can't figure out of which you want it to calculate 50%.
IE 6 and IE 7 beta 2 position the red div at 50% of the height of the
body node.


So I think they're wrong, and just try to please you :-)


You think. I think. What matters, I'd say, is what the spec has
provided, give, etc.
After carefully reading the CSS 2.1 spec,


Which section? Got a url?


Here's my line of reasoning based on CSS 2.1

http://www.w3.org/TR/2006/WD-CSS21-20060411/

Section 9.3.2 on Box offsets: 'top', 'right', 'bottom', 'left'
http://www.w3.org/TR/2006/WD-CSS21-2...position-props
says:
"Top
Percentages: refer to height of containing block"

What's containing block and how is it defined for relatively positioned
elements?

Section 10.1
10.1 Definition of "containing block"
http://www.w3.org/TR/2006/WD-CSS21-2...-block-details
says
"if the element's position is 'relative' or 'static', the containing
block is formed by the content edge of the nearest block-level, table
cell or inline-block ancestor box."

So 50% should be 50% of the body element's height.

10.6 Calculating heights and margins
10.6.3 Block-level non-replaced elements in normal flow when 'overflow'
computes to 'visible'
http://www.w3.org/TR/2006/WD-CSS21-2...l#normal-block
says

"If it has block-level children, the height is the distance between the
top border-edge of the topmost block-level child box that doesn't have
margins collapsed through it and the bottom border-edge of the
bottommost block-level child box that doesn't have margins collapsed
through it."

So, logically, the top: 50% should be 50% of the document.body.scrollHeight
In the testpage, you can see that value at the bottom of the page.

I wonder (am not sure)

- which browsers is right, which browser is wrong
- and why (in terms of the CSS 2.1 spec)

What do you think?


What I think? I think you're mistaking position:relative for
position:absolute.
The fact that you mention which element is "its nearest block-level
ancestor box" confirms that thought.


I was merely stating word for word what CSS 2.1 spec was saying and how
it was saying it in section 10.1:

"if the element's position is 'relative', [then] the containing block is
formed by the content edge of the nearest block-level ancestor box."
position:relative means relative to its own original position.
If you want it to be positioned at 50% of the height of body, then you
need position:absolute, which is relative to the first positioned
ancestor.


No. I think you're the one getting it wrong. With position: absolute,
the red div would be positioned at 50% of the height of the initial
containing block which is, by definition, a rectangle with the
dimensions of the viewport.
You need to read carefully section 10.1 on this.

Gérard
--
remove blah to email me
Apr 18 '06 #3
Els wrote :
Gérard Talbot wrote:
What I think? I think you're mistaking position:relative for
position:absolute.
The fact that you mention which element is "its nearest block-level
ancestor box" confirms that thought.

position:relative means relative to its own original position.
If you want it to be positioned at 50% of the height of body, then you
need position:absolute, which is relative to the first positioned
ancestor.


Try this:

http://www.gtalbot.org/DHTMLSection/Positioning.html

Choose Blue box, position absolute, 50 and % . Firefox 1.5.0.2, NS 8.1
(with rv:1.7.5 Gecko/20060111 rendering engine), IE 7 and Seamonkey 1.5a
all position the blue div at 50% of the height of the viewport. Only
Opera 9 build 8367 positions (wrongly IMO) at 50% of the document
scrollview, whole view.

Gérard
--
remove blah to email me
Apr 18 '06 #4
On 18/04/2006 19:38, Gérard Talbot wrote:

[snip]
Section 9.3.2 on Box offsets: 'top', 'right', 'bottom', 'left'
http://www.w3.org/TR/2006/WD-CSS21-2...position-props
says:
"Top
Percentages: refer to height of containing block"


You must keep in mind that the definition in CSS 2 has a very relevant
condition that seems to have been relaxed in 2.1: the height property of
the containing block must have an explicit value. Under these same
rules, the containing block will be the body element as the nearest
block-level ancestor, and that element has a height property value of
'auto'.

It would appear that here, both Firefox and Opera are implementing CSS
2. As a result, the top property value becomes 'auto'.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Apr 18 '06 #5
Gérard Talbot <ne***********@gtalbot.org> wrote:
When trying this page

http://www.gtalbot.org/BrowserBugsSe...sitioning.html

I get different rendered layouts with IE 6, IE 7 beta 2, Firefox 1.5.0.2
and Opera 9.0 build 8367.

Firefox 1.5 and Opera 9 will just ignore the CSS declaration
top: 50%; position: relative;
They don't.
IE 6 and IE 7 beta 2 position the red div at 50% of the height of the
body node.
What height? (you haven't specified one)
After carefully reading the CSS 2.1 spec, I wonder (am not sure)

- which browsers is right, which browser is wrong
- and why (in terms of the CSS 2.1 spec)

What do you think?


The basic 'Where Opera and Gecko agree and where IE renders differently,
IE is wrong' rule is as valid today as it ever was. IE '7' is still
years behind Opera and Gecko with regard to CSS compliance and feature
support.

A relatively positioned box is initially laid out as per normal flow,
and then offset as per it's box offset values.
http://www.w3.org/TR/CSS21/visuren.h...ve-positioning

Percentage values for the 'top' property are relative to the containing
block.
http://www.w3.org/TR/CSS21/visuren.html#position-props
http://www.w3.org/TR/CSS21/visuren.h...ntaining-block

In this case the containing block is the initial containing block
http://www.w3.org/TR/CSS21/visudet.html

In this case the containing block has no specified height, thus the
computed height resolves to 'auto'.
http://www.w3.org/TR/CSS21/visudet.h...eight-property

--
Spartanicus
Apr 18 '06 #6
Spartanicus wrote :
Gérard Talbot <ne***********@gtalbot.org> wrote:
When trying this page

http://www.gtalbot.org/BrowserBugsSe...sitioning.html

I get different rendered layouts with IE 6, IE 7 beta 2, Firefox 1.5.0.2
and Opera 9.0 build 8367.

Firefox 1.5 and Opera 9 will just ignore the CSS declaration
top: 50%; position: relative;
They don't.
IE 6 and IE 7 beta 2 position the red div at 50% of the height of the
body node.


What height? (you haven't specified one)
After carefully reading the CSS 2.1 spec, I wonder (am not sure)

- which browsers is right, which browser is wrong
- and why (in terms of the CSS 2.1 spec)

What do you think?


The basic 'Where Opera and Gecko agree and where IE renders differently,
IE is wrong' rule is as valid today as it ever was. IE '7' is still
years behind Opera and Gecko with regard to CSS compliance and feature
support.

A relatively positioned box is initially laid out as per normal flow,
and then offset as per it's box offset values.
http://www.w3.org/TR/CSS21/visuren.h...ve-positioning

Percentage values for the 'top' property are relative to the containing
block.
http://www.w3.org/TR/CSS21/visuren.html#position-props
http://www.w3.org/TR/CSS21/visuren.h...ntaining-block

In this case the containing block is the initial containing block
http://www.w3.org/TR/CSS21/visudet.html


Right. I got it all up to there.
In this case the containing block has no specified height, thus the
computed height resolves to 'auto'.
http://www.w3.org/TR/CSS21/visudet.h...eight-property


You and M. Winter got the bit I was missing
"If the height of the containing block is not specified explicitly
(i.e., it depends on content height), and this element is not absolutely
positioned, [then] the value computes to 'auto'."

Thanks

Gérard
--
remove blah to email me
Apr 18 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Markus Ernst | last post: by
2 posts views Thread by Martin Geisler | last post: by
2 posts views Thread by deko | last post: by
3 posts views Thread by rsrimantula | last post: by
10 posts views Thread by Mark | last post: by
reply views Thread by cook | last post: by
reply views Thread by Saiars | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.