Closed Bug 142433 Opened 22 years ago Closed 22 years ago

Error in positioning 'auto'-top and 'auto'-left for absolute positioned elements

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 44508
Milestone:
Future

People

(Reporter: laura.bottelier, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: qawanted, testcase)

Attachments

(2 files)

Simple absolute-positioning tests
2.59 KB, text/html
Details
Testcase for 'auto'-top and 'suto'-left for absolute positioned elements
13.55 KB, text/html
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc1) Gecko/20020417
BuildID:    2002041711

The background colour applied to a <P> containing both text and a form is
rendered incorrectly. The part that is covered by the text has the assigned
background colour, but the area the form is in hasn't.

An image that is placed at the right side of the screen using the position and
right CSS properties is moved into an anonymous block containingbox instead of
an inline containingbox. i.e. the two images should share the same vertical
space instead of being placed beneath eachother.

Reproducible: Always
Steps to Reproduce:
1. Open the page http://test.iradis.org
2. Click "Without tables" to see the bad page
3. Click "With Tables" to see the images renderd correctly without using CSS

Actual Results:  The right image is rendered to low
There is no background colour behind the form

Expected Results:  Images are on the same vertical position
The area under the form is filled with grey
I see the image issue, but I'm not sure what correct layout is here, given that
"top" is not specified...

The background problem I cannot reproduce.
Keywords: qawanted
OS: Windows 98 → All
Hardware: PC → All
Both CSS level 1 and 2 specify a default value of 0 for the left, and top
properties and the width and height of the replacement for all for replaced
objects.

I've added a correct and the mozilla result screenshot at test.iradis.org.
While making the screenshots I noticed problem 3. The small blue ruler a <P>
elements just like the grey bar have the width attribute set to 100% and are
within the same contentblock and should be of equal length. Like shown in the
good rendered page screenshot.

Confirming issue in the June 05 build (2002-06-05-05 1.0.0)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → Future
Demonstration code moved to http://test.iradis.org/mozilla/
Found another CSS related layout bug. A <hr> element is rendered without taking
the oobject box into account i.e. it is always draw using the screen left and
right positions not the box' left and right positions.

See http://test.iradis.org/mozilla/education.html
> Both CSS level 1 and 2 specify a default value of 0 for the left, and top
> properties

CSS2 does no such thing.  It specifies that the default value is "auto".  CSS1
does not even mention this, since positioning is not part of CSS1.

And in fact, "top" should apparently be computed based on where the element
would be if it were statically positioned.  So I think we are in fact doing the
layout correctly given that CSS....

The <hr> thing is also not a bug -- <hr> is a block element and should ignore
in-blocks when laying out.  In quirks mode we break this for backwards compat,
but this page is HTML4.01 Strict, so we render it per standards.
Nothing says HR is a block-level element.
HTML4 DTD:

<!ENTITY % block
     "P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
      BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">

our html.css:

hr {
  display: block;
  border: 1px -moz-bg-inset;
  margin: 0 auto 0 auto;
}

Appendix A to the CSS2 spec (suggested HTML4 stylesheet):

HR, MENU, PRE   { display: block }

Now none of these _force_ us to lay <hr> out as a block.  We could change
html.css or even take the "it cannot be described by CSS" route we take with
form controls.  However, until we change html.css or decide that the box model
does not apply to <hr> that layout seems correct to me....
According to this stetement the <P>, <DIV> <PRE> <TABLE> <DL> etc elements
shoudl also be sized and positioned according the the 'screen' and in respect of
the body it's box. Thus the paragraphs texts, horizontal rulers, headings,
tables, lists and preformatted texts should just overlay all other tables,
images and other floating objects? This also means that a tanble with 5 rows
should be rendered by overlaying all 5 rows using the complete width of the body?

For the top value CSS2 states auto which means aligned in the normal manner. Or
in other words laynout within it's parents box following standard flow. Thus the
top value is 0 because no other objects are defined before the image object that
effect its vertical position. And since CSS2 doesn't define that when altering
one of its propeties the other properties change by themselfs it remains auto=0.
Further more when the right property is not specified the image IS indeed
aligned to the top. So when only changing the right value to the top remains
auto equals 0.

For the CSS1 bit. CSS1 doe not speicify any method to change an objects
position. Therefore the image is aligned using normal flow within it's parents
box. And therefore the left and top position are 0 and always 0.

OK.  Let's get something clear... The _text_ in a block and the block itself are
not the same thing.  If you have a paragraph with a border and an "float:left"
table as in your example, the paragraphs border _will_ overlap the table.  The
text will not, however, since that's in inline boxes (the line boxes) and
floaters _do_ affect the layout of inline boxes.  <hr> has a border, but no text.

As for "top":

> For the top value CSS2 states auto which means aligned in the normal manner.
> Or in other words laynout within it's parents box following standard flow.

Agreed.

> Thus the top value is 0 because no other objects are defined before the image
> object that effect its vertical position.

Sure there are.  You have:

<p class="logo">
  <img src="logo.gif" width="275" height="100" alt="The IRADIS Foundation logo"
valign=top>
  <img valign=top style="position:absolute; right:0.6em;" src="images.jpg"
width="275" height="100" alt="Art">
</p>

Now position:absolute forces display:block.  So the "standard flow" would be the
same as foe:

<p>
  <img>
  <img style="display:block">
</p>

Now that first <img> is an inline, the second is a block.  So the second one
should come _below_ the first one (in fact below the line box that holds the
first one).  Which is where we put it.

> And since CSS2 doesn't define that when altering one of its propeties the
> other properties change by themselfs

Of course it does.  "top: auto; bottom: 0; height: 20px".  Is "top" still going
to be 0 in that case?  No.  

> Further more when the right property is not specified the image IS indeed
> aligned to the top.

That seems incorrect to me.

I think we can forget about CSS1, since it's pretty irrelevant in this case...
CSS doesn't state that a HR element is composed of the top and bottom borders as
far as I remember. And the quoted definition of the HR element is an informative
exmaple to show how a stylesheet could be defined. It is not normative.
Furthermore CSS2 doesn't specify how elements are defined and rendered the HTML
spec define them. The latest HTML spec specifies:

><!ELEMENT HR - O EMPTY -- horizontal rule -->
><!ATTLIST HR %attrs; -- %coreattrs, %i18n, %events -->
>Start tag: required, End tag: forbidden
>Attribute definitions
>align = left|center|right [CI]
>    Deprecated. This attribute specifies the horizontal alignment of the rule
>with respect to the surrounding context. Possible values:
>        * left: the rule is rendered flush left.
>        * center: the rule is centered.
>        * right: the rule is rendered flush right.
>    The default is align=center.

Mozilla does follow the following:
|    Deprecated. This attribute specifies the horizontal alignment of the rule
|WITHOUT respect to the surrounding context. Possible values:

The HTML4.01 specs are irrelevant to a CSS2 example that is informative only?


CSS2 doesn't specify that when changing the right of left propertie the top
and bottom value do change by themselfs. Both bottom and top remain set to auto.

Also taken from the HTML4.01 specs:
>it is usually replaced inline by the image designated by the src attribute,
>the exception being for left or right-aligned images that are "floated" out
>of line.
and
> top: means that the top of the object should be vertically aligned with
> the top of the current text line.

Where is specified that ALL floating object have their bottom set to 0? Or where
is defined an inline top aligned IMG should create a new virtual box for that
next objects with its top at the baseline of the current box? Even when the
bottom is set to 0 the image would be rendered next to the other image because
the height of the box containing the images has the same height of the images 
(100px) The image would be rendered below the first image id its containbox
would have a height of 200px. Since a bottom of 0 doen't specify the top beeing
draw at the bottom of its surrounding box but with the bottom aligned to the
bottom of its box.

Both the HR and IMG are handled differently in Mozilla that all 6 CSS2 capable
browers. All 6 handle the HR at the same as paragraph content like _text_,
headings, images and tables. And do not change the align as soon as the right=
property is set. Only Mozzila does this, and the behaviour is illogical. 
> Furthermore CSS2 doesn't specify how elements are defined and rendered 

On the contrary, the _only_ reason CSS2 exists is to specify how things are
rendered.  Further, Mozilla is a CSS browser, not an HTML browser.  Any default
rendering of HTML should be describable via a user-agent stylesheet, as is
explicitly said in the CSS spec.

"with respect to the surrounding context" is exactly what we do.   We align the
rule.  If you set a width on the rule, you will see that it is indeed aligned in
the right direction with respect to the stuff around it.

> Both bottom and top remain set to auto.

Agreed, they do.  The fact that our layout in this case depends on the "right"
value is a bug, I think; the layout with "right" set is correct.

I'm not sure what floated images have to do with this....  Explain?

> All 6 handle the HR at the same as paragraph content like _text_, headings,
> images and tables

tables are not paragraph content, nor are headings.  If you want <hr> to be
handled like headings, you want our current behavior... If you want it rendered
as an inline (as it is in quirks mode, I must add), that needs to be justified.  


> CSS doesn't state that a HR element is composed of the top and bottom borders

You're right, it does not.  However given that an HR needs to be defined in CSS,
how would you implement it?
I think that there are some wires crossed here. CCS (1 and 2) provide a
standarised way to let a page desinger specify the tool / style of a page. It
doesn't replace HTML as your additional comment states. IT is an add-on to HTML.
HTML defines what objects exists, what properties they have, how they are
rendered, and handled. CSS provides a way to have greater control over the
layout and repaces the non-standarised propeties such as the bgcolor property
indroduced in sertain browser. If mozilla was only a CSS browser very little
would be visible.

Taken from CSS2 specs:
>CSS2 is a style sheet language that allows authors and users to
>attach style (e.g., fonts, spacing, and aural cues) to structured
>documents (e.g., HTML documents and XML applications).

And taken from chapter 15 of the HTML4.01 specs:
>but not for all of the people, all of the time. They include:
>    * Using proprietary HTML extensions
>    * Converting text into images
>    * Using images for white space control
>    * Use of tables for page layout
>    * Writing a program instead of using HTML
>These techniques considerably increase the complexity of Web pages,
>offer limited flexibility, suffer from interoperability problems,
>and create hardships for people with disabilities.
>Style sheets solve these problems

>For example, the following short CSS style sheet .....
>Authors may link this style sheet to their source HTML
>document with the LINK element:

As you look at the output of the example it is clearly shown that the heading
elements are not handled in the same manner as the ruler is. The headings are
nicely aligned with the text the ruler is not!

>> CSS doesn't state that a HR element is composed of the top and bottom borders
>You're right, it does not.  However given that an HR needs to be defined in CSS,
>how would you implement it?
As stated HTML defines that a rule consist of one or two horizontal lines with a
UI specific distant of each other. Respecting the surrounding objects for its
width and justification.
The default CSS style should reflect the default visualisation as specified in
the HTML specs: alignment = centered, color = default system colors, height =
default height for selected font and font height, border = none. (see HTML specs
15.3)

> It doesn't replace HTML as your additional comment states.

True.  HTML still provides the structure.  CSS provides the presentation. 
That's the whole point.  In other words, HTML defines that a <hr> means a
"horizontal rule" as opposed to a "hidden record".  CSS defines what a
"horizontal rule" should look like and how it's laid out with respect to the
surrounding content.

> HTML defines what objects exists, what properties they have, how they are
> rendered, and handled.

It defines the first of those two.  It does not define rendering (excepting the
transitional stuff).  I'm not sure what you maen by "handled".

> As you look at the output of the example it is clearly shown that the heading
> elements are not handled in the same manner as the ruler is. The headings are
> nicely aligned with the text the ruler is not!

Put a border on the headings.  Or a background color, for that matter...

At this point there are three separate issues in this bug, as far as I can see
-- the background on the <p>, the positioned image layout, the <hr> thing.  

The <hr> thing is covered in bug 84887.  See the comments in that bug, in
particular bug 84887, comment #4.

The background thing I cannot reproduce.

The image layout is correct in the testcase provided; if it is incorrect in
other circumstances, plese file bugs on those and assign them to me...



The HR element is mentioned only twice in the CSS specs. That is in
apendix A which contain in informative stylesheet example.

The HR element is indeed a blocklevel element meaning it has it own box
within its parent box. Just like the ADDRESS, BLOCKQUOTE, BODY, DD, DIV,
DL, DT, FIELDSET, FORM, FRAME, FRAMESET, H1, H2, H3, H4, H5, H6, IFRAME,
NOFRAMES, OBJECT, OL, P, UL, APPLET, CENTER, DIR, MENU, and PRE elements.

CSS doesn't specify how an element is rendered it only provides a way to
color and size, and layout elements. In order to do this CSS2 defines
the box model and different types of display categories like block,
inline, compact, run-in and floating boxes. Each box type can either be
anonymous, replaced and non-replaced.

For each box type CSS2 specifies how the boxes are positioned to each
other and how their size is calculated. CSS doesnot specify how the
content of a box is rendered HTML does this. It only specifies the
outlines of the box containting the HTML specified elementand the box
its capability to have a border, padding and a margin. The only things
that CSS2 do specify for the rendered contents of the box are its color,
font, decorations, and optional inserted bullets and numbers.

You are 100$ correct in your statement that the background colour and the border
conpletely occupies the canvas and does underlay the floating div element. All
block elements do that. No question about that. The point is that the _rendered
conents_ are rendered in correctly. CSS does not specify them the HTML specs do
that. CSS2 has no mention of them. And the HTML specs define that the _rendered
contents_ of the HR, H, P, DL, DT, FORM, etc... are rendered with respect to the
surounding content including floating objects. Like Mozilla does for alle
elements except for the HR element. Sure the CSS2 box spans the page but the
_rendered contents_ do not.

>> HTML defines what objects exists, what properties they have, how they are
>> rendered, and handled.
>It defines the first of those two.  It does not define rendering (excepting the
>transitional stuff).  I'm not sure what you maen by "handled".
HTML defines how the FORM elemtnets handle data for instance.

>At this point there are three separate issues in this bug, as far as I can see
>-- the background on the <p>, the positioned image layout, the <hr> thing.  
>The background thing I cannot reproduce.
Release of Mozilla 1.0 still renders the FORM element incorrectly. The form is
not centered as in other browsers. This is a bug in the other browsers. But the
FORM overpaints the background of it's parent <P> element. Since the FORM
element has no background color specified and also the informative example from
apendix A does not force a background color for the FORM element it has the
default background color beeing transparent. Under Mozilla the FROM's background
is painted with the system background color and is not transparent as it should be.

For the image bug. Both images have set their alignment to "top". HTML specifies
that images became floating object if their alignement is set to either left or
right. So the images do not float by this rule.

CSS2 specs 9.3.1
> The box's position (and possibly size) is specified with the 'left', 'right',
>'top', and 'bottom' properties. These properties specify offsets with respect
to >the box's containing block. Absolutely positioned boxes are taken out of the
>normal flow. This means they have no impact on the layout of later siblings.
>Also, though absolutely positioned boxes have margins, they do not collapse
with >any other margins.

9.6:
>In the absolute positioning model, a box is explicitly offset with respect to
>its containing block. It is removed from the normal flow entirely (it has no
>impact on later siblings). An absolutely positioned box establishes a new
>.containing block for normal flow children and positioned descendants. However,
>the contents of an absolutely positioned element do not flow around any other
>boxes. They may or may not obscure the contents of another box, depending on
the >stack levels of the overlapping boxes. 

also see 9.8

According to the exmaples stated in capter 9 the right image is declared with
absolute positioning. Thus the position of following objects are not infuenced
by the image. Since an absolute box is still rendered with an offset to its
parent vox -- the box of the paragraph -- and has its right propety set the
right side of the right side of the image is positioned 0.6em from the right
side of the <P> its box. The top is still set to auto and bottom is still set to
suto. And capter 9 clearly specifies a absolute box is aligned to the left and
top of its parent box. We only override right so top still applies.

> The point is that the _rendered conents_ are rendered in correctly.

So what you're saying is that <hr> is an element which cannot be described via
CSS (a la form controls)?  I suppose that's one way of looking at it...

> FORM overpaints the background of it's parent <P> element

What does this mean exactly?  Could you contrast the "correct" and "incorrect"
rendering?

> Since an absolute box is still rendered with an offset to its
> parent vox -- the box of the paragraph

Actually, the box of the <html> -- see CSS2 section 10.1 [1]

> The top is still set to auto and bottom is still set to
> suto.
(sic)

Yes.

> capter 9 clearly specifies a absolute box is aligned to the left and
> top of its parent box.

Where does it say this?  The relevant portion of the spec here is section 10.6.4
[2], which says:

     If 'top' has the value 'auto' replace iat with the distance from the top
     edge of the containing block to the top margin edge of a hypothetical box
     that would have been the first box of the element if its 'position'
     property had been 'static'. (But rather than actually computing that box,
     user agents are free to make a guess at its probable position.) The value
     is negative if the hypothetical box is above the containing block.

So leaving "top" as "auto" is a chancy thing at best (not the "free to make a
guess" clause)...  That said, we are actually following this correctly in the
testcase in question.

[1] http://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-details
[2] http://www.w3.org/TR/REC-CSS2/visudet.html#abs-non-replaced-height
>> The point is that the _rendered conents_ are rendered incorrectly.
>So what you're saying is that <hr> is an element which cannot be described via
>CSS (a la form controls)?  I suppose that's one way of looking at it...
Not exactly. As described in the HTML specs the rendered content should be
handled the same as i.e. the H1 element. Both HR and H1 are describable using
CSS2. But both need extra layout processing within their CSS boxes. Just as like
a H1 has a left and a width the HR has. A little ascii art:

****************-----------------+
*              * Heading text    |
+--------------*-----------------+
* Floating obj * Paragraph text  |
*              *                 |
*              *                 |
*              *                 |
+--------------*-----------------+
*              * =============== |
+--------------*-----------------+
*              * Paragraph text  |
****************                 |
| Paragraph continues here       |
+--------------------------------+

The _box_ surrounded by the *s is of the floating div element
The _box_es surrounded by the -s are of the headings the paragraphs
and the rule. With the ===== as the rule it two lines following
the definetion of the HTML specification for the rendering and
the CSS specs for layout.


>> FORM overpaints the background of it's parent <P> element
>What does this mean exactly?  Could you contrast the "correct"
>and "incorrect" rendering?
Again a piece of ascii art:

<body>
<p style="background:silver"><string>Title</strong><br>
<form><input></form>
</p></body>
+-----------+    <------\
| T I T L E |           > Area 1
|+---------+|    <------/
|| form    ||
||+------+ ||           \
||| input| ||           > Area 2
||+------+ ||           /
|+---------+|
+-----------+    <------

C.B generated by  C.B. established by
-------------------------------------
body              initial C.B.
p                 body
strong            P
form              P
input             form

Since the form has no colour defined the color is set to transparent.
The system color is set to white so behind the body a white filled
rectangle is painted. On top of the body the P elemnt is painted in silver
on top of the top side of the P the _text_ "Title" is painted in black 
text-color with a transparent background. On the lower half a form is
painted which should be painted transparently and thus leaving the aera
behind it silverish.

           |  Area1     Area2
----------------------------------
Incorrect  |  silver    white
Correct    |  silver    silver


>> Since an absolute box is still rendered with an offset to its
>> parent box -- the box of the paragraph
>Actually, the box of the <html> -- see CSS2 section 10.1 [1]

<div><p>
<img><img style="position:absolute">
</p><p></p></div>

The chain of ancestors for this is
body
  div
    p1
      img1
      img2
    p2
       
Following chapter 10.1
|4 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.

Since both div and p are block level see informative example appendix A
|ADDRESS, BLOCKQUOTE, BODY, DD, DIV, DL, DT, FIELDSET, FORM,
|FRAME, FRAMESET,H1, H2, H3, H4, H5, H6, IFRAME, NOFRAMES, 
|OBJECT, OL, P, UL, APPLET, CENTER, DIR,
|HR, MENU, PRE   { display: block }

The C.B. of img1 is established by p1. The one of img2 by the html element as
you correctly stated. As the test case html shows the p1 has a height of 100px
just like the both image sources have. Further CSS2 section 10.6.5 refers back
to 10.6.4 which states (also mention by you):

| If 'top' has the value 'auto' replace iat with the distance from
| the top edge of the containing block to the top margin edge of a
| hypothetical box that would have been the first box of the element
| if its 'position' property had been 'static'.

Since top is left auto we calculate top as if its position property
was left at static is parent box would be p1 just like the img1 has.
So top equals the position of p1.top-margin. And not that top equals 
the bottom position of img1. Also following th culculation of section
10.6.5 positions the top of img2 at the top-margin position of p1.


I agree that our strict mode HR rendering is a bug.  However, comment 0 through
comment 5 seem to describe a different issue.  Why does this bug cover 2
different problems?
>comment 5 seem to describe a different issue.  Why does this bug cover 2
>different problems?
Grown historically due to the test case code. For corectness this bug be split
into multiple bug reports. The HR bug should be moved over to bug 84887 although
not entirely the same cause/result but defenerly the same topic.

Christian, thank you for the clear explanation (with small testcases!).  

> <body>
> <p style="background:silver"><string>Title</strong><br>
> <form><input></form>
> </p></body>

So the problem here is that per HTML4.01 <p> cannot contain <form>.  <p> also
has an optional end tag.  Hence:

<body><p><form></form></body>

and

<body><p></p><form></form></body>

are both valid HTML documents that should lead to the same DOM.  Your case is
like the second of these, but with an extra </p> after the </form> which the
parser just ignores because no <p> is open at that point.  This is why the <p>
background is not applied to the <form> -- the <form> is not inside the <p>.

> Since top is left auto we calculate top as if its position property
> was left at static is parent box would be p1 just like the img1 has.
> So top equals the position of p1.top-margin.

No, because "position: absolute" also forces "display: block", per CSS2, section
9.7.  So we're now computing the top of img2 for the following markup:

<div><p>
<img><img style="display:block">
</p><p></p></div>

When this is laid out, img2 comes below img1.
>So the problem here is that per HTML4.01 <p> cannot contain <form>.
<!ELEMENT P - O (%inline;)*            -- paragraph -->
<!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">
<!ENTITY % fontstyle "TT | I | B | BIG | SMALL">
<!ENTITY % phrase "EM | STRONG | DFN | CODE |
                   SAMP | KBD | VAR | CITE | ABBR | ACRONYM" >
<!ENTITY % special
   "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">
<!ENTITY % formctrl "INPUT | SELECT | TEXTAREA | LABEL | BUTTON">
Ideed you're right the start and end tags are out of sequence and
the form comes after the paragraph. And the FORM is correctly painter
after the P element and not on top as with other browsers who hereby
contain a bug.



>> Since top is left auto we calculate top as if its position property
>> was left at static is parent box would be p1 just like the img1 has.
>> So top equals the position of p1.top-margin.
>No, because "position: absolute" also forces "display: block", per CSS2,
>section 9.7. So we're now computing the top of img2 for the following markup:
You're negating section 10.6.5 list 1 item 2 here. Setting prosition to absolute
implicetly forces display = block.

|2. Otherwise, 'position' has the value 'absolute' or 'fixed', 'display'
|is set to 'block' and 'float' is set to 'none'. The position of the box
|will be determined by the 'top', 'right', 'bottom' and 'left' properties
|and the box's containing block.

From 9.6
|In the absolute positioning model, a box is explicitly offset with respect
|to its containing block. It is removed from the normal flow entirely
|(it has no impact on later siblings). An absolutely positioned box
|establishes a new containing block for normal flow children and
|positioned descendants. However, the contents of an absolutely
|positioned element do not flow around any other boxes. They may or
|may not obscure the contents of another box, depending on the stack
|levels of the overlapping boxes.

From 9.4.1
|In a block formatting context, boxes are laid out one after the other,
|vertically, beginning at the top of a containing block. The vertical
|distance between two sibling boxes is determined by the 'margin'
|properties. Vertical margins between adjacent block boxes in a block
|formatting context collapse.

Section 10.6.5 clearly tells us that the top of this conataining block refered
to in 9.4.1 has the same value as if position was left static. And secondly if
position was left static the display property would not have set and was still
inline. So CSS2 leave us here with two posibilities;
 1. The C.B. top starts at the top of the p element because section 10.6.5
    tells us to take the top-margin position of its parent when being static.
 2. The C.B. top starts at the top of the img1 element because section 10.6.5
    tells us we determine the top as if position has been left static so the
    display propertie would not have been forced block and was still inline
    so section 9.4.2 tells us to layout horizontally.

Unfortunatly section 9.8.4 doesn't contain an example with the elements we're
dealing with.
I've asked Bert Bos of W3C about how to interpret the CSS2 specification. He
agrees that my intrepretation is correct and that Mozilla does indeed handle
position:absolute incorrectly.

The CSS2 specification texts regarding positioning are beeing rewritten because
it is to vague about the matter. And will be included in the next specification


>> - Take the top as if the position would not have been absolute
>>   so we take the C.B. of p1 being 0px. (Section 10.6.5 literal)
>> 
>> - Take the top as if the position would not have been absolute
>>   so that the image would be still inline and would have been
>>   positioned next the img1 top being 0px. (Section 10.6.5
>>   free interpretation of the as it would been static so the
>>   image would not have been forced block but was still in-line)
>Dit is correct.
>
>>
>> Interpretation 1 and 2 give:
>> 
>> +-body C.B.--------------------------+
>> |+-div1 C.B.------------------------+|
>> ||+-img1 C.B.---+----+-img2 C.B.---+||
>> |||             |    |             |||
>> |||             |    |             |||
>> ||+-------------+----+-------------+||
>> |+----------------------------------+|
>> +------------------------------------+
>> 
>> 
>> Interpretation 3 give:
>> 
>> +-body C.B.--------------------------+
>> |+-div1 C.B.------------------------+|
>> ||+-img1 C.B.---+------------------+||
>> |||             |                  |||
>> |||             |                  |||
>> ||+-------------+----+-img2 C.B.---+||
>> |+-------------------|-------------|+|
>> |                    |             | |
>> |                    +-------------+ |
>> +------------------------------------+
>
>Het eerste diagram is correct: zonder 'position: absolute' zou de IMG
>op dezelfde hoogte als de andere IMG terechtkomen, dus dat is ook de
>hoogte waarop hij met 'top: auto' terechtkomt.
>
>De specificatie wordt op dit moment inderdaad herschreven. Hopelijk is
>de nieuwe tekst duidelijker.
>
>Bert
>-- 
>  Bert Bos                                ( W 3 C ) http://www.w3.org/
>  http://www.w3.org/people/bos/                              W3C/INRIA
>  bert@w3.org                             2004 Rt des Lucioles / BP 93
>  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France


Translation of Berts reply for those who don't speak dutch:
Reply quote text 1:
>This is correct

Reply quote text 2:
>The first diagram is correct: without 'position: absolute' the IMG
>would be positioned at the same height as the other IMG, so that
>is also the height it's positioned at with 'top: auto'
>
>The specifation is indeed being rewritten at the moment. Hopefully
>the new text is clearer.
Status: NEW → ASSIGNED
This bug has gotten too convoluted for me, so I created a set of three simple
testcases that I hope will help clear all this up (I'll attach the document
after this comment).  I believe that Gecko is incorrect in what it does as
compared to the intent of CSS2.  I believe this is what Christian has been
saying, and Bert confirms, although to be honest it's difficult to tell at this
point.  Which is why I've created the simple testcases.

The intent of the CSS2 specification, as I have always understood it, was as
follows:

"1. If 'top' has the value 'auto' replace it with the distance from the top edge
of the containing block to the top margin edge of a hypothetical box that would
have been the first box of the element if its 'position' property had been
'static'."

If the images (or spans, in my testcases) had been set to 'static', then there
would have been no implicit setting of block-level status.  Thus if I absolutely
position an element and don't set its 'top', then the top edge of the positioned
element should be aligned with the place where its top would have been had it
not been styled in any way at all.  I'm not sure what to do in the case of
elements with a top margin; arguably the placement should be as if the top
margin didn't exist, but I'm not sure about that part.

I recommend changing the summary to read "Error in positioning 'auto'-top
elements" or something like that, since that's the real problem.  So far as I
can see Mozilla is fine in what it does except for pushing elements down too far
when 'top' is set to 'auto'.

Testcase on the way.
In the first two tests, the "change bars" should be next to the lines
containing the words FOUND HERE.  In the third, the positioned image should
largely overlap the first image in the row.  (Assuming my interpretation of
CSS2:10.6.4 is correct.)
The simple testcase correctly reflects the problem. I'm also not 100% sure about
the margin and padding how thet effect the elements position.

It could be that not only the top position is calculated they wrong way but also
the left position since that is almost the same substitution.

After some further indept study i'll come back on both uncertainties and if
needed a testcase for the left position.

For the current test case the 'changebar' texts should be aligned with the line
containing 'FOUND HERE'. For the image test all images should start at the same
horizontal position. IMG2 (currently draw below the other images) should overlap
IMG3, and its left should be just next to the first '2' text.

I've added a testcase that shows the bug also affects the 'auto'-left case.

For the margin and padding setting of the element that defines the containing
block of the absolute positioned elemnt; the padding setting has no influence;
the margin setting determines the distance between its border and the edges of
the nearest neighbouring containing blocks, the correct position for a property
set to 0 it's aligned with this border (Mozilla renders correctly).

PS. i'll move the HR thing to another bug report.
Summary: CSS formatting error involving image position and forms → Error in positioning 'auto'-top and 'auto'-left for absolute positioned elements
Doesn't this bug overlaps with bug 44508? dupe or is blocked by....
It does overlap with bug 44508. It dups the bug for the top:auto. But proves
that this bug is also for position: relative and not only the top: property is
affected the left: property is also.
Both testcases works for me with the patch from bug 44508.

*** This bug has been marked as a duplicate of 44508 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Keywords: testcase
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: