28393 - child node w/ no set size should snap to content size, not parent bounds (absolute positioning)

Status: VERIFIED INVALID

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Joe Hewitt]

When an absolutely positioned element has an absolutely positioned child, and 
that child does not explicitly declare it's size in a style, the child's size 
should be calculated from the size of it's flowed children.  However, currently 
in Mozilla, the size of the child extends to the boundaries of it's parent. See 
test case in attachment "test case 1"

When a relatively positioned element has an absolutely positioned child, and 
that child does not explicitly declare it's size in a style, once again the 
child's size should be calculated from the size of it's flowed children.  
However, currently in Mozilla, the width of the child incorrectly extends to 
the boundaries of the window, but the height of the child does correctly snap 
to it's flowed children's height.  See test case in attachment "test case 2".

You will also notice that in "test case 2" there is a second positioned child 
node whose size is not declared, and it comes out to (0,0) which again, should 
become the size of it's flowed children.

To see the correct behavior for these test cases, just fire them up in IE5.

Comment 1

[Joe Hewitt]

Attachment: test case 1

Comment 2

[Joe Hewitt]

Attachment: test case 2

Comment 3

[Hixie (not reading bugmail)]

(If IE5's behaviour is different to ours, there is about an equal chance of
it being wrong as there is of us being wrong.)

The absolute positioning rules are currently being rewritten by the CSS WG.
I'm reassigning this to Todd, but leaving unconfirmed.

Comment 4

[troy]

Marking INVALID. The CSS2 spec says that for absolutely positioned elements a 
'width' or 'height' of 'auto' ends with a size that's based on the containing 
block and not on the content size

Yes, that doesn't agree with how Navigator and IE implement it and as Ian 
indicated this issue is under discussion by the W3C CSS WG and will likely 
change to be backwards compatible with existing browsers

However, Geck currently implements this as it is defined in the CSS2 spec

Comment 5

[Joe Hewitt]

Now hold on a second, this bug is NOT resolved.  I don't care what the CSS2 
spec says, there is a very valid reason why all browsers snap to content size 
and not parent size.  When you put text in a DIV, the object you are thinking 
about is the TEXT.  The DIV represents the text, and should be the size of that 
text.  Why anyone would want the DIV to be it's parent's size, I have no idea.  
So now if you have an application that wants to put text in that label and 
change the background color to "blue" when you mouse over it, now the blue box 
is going to be some weird, arbitrary size instead of the exact size of the 
label.  Am I the only one who sees why this is really really bad? When you put 
text inside an element you REALLY WANT TO KNOW THE WIDTH AND HEIGHT OF THAT 
TEXT!! 

What is wrong with the W3C? There are so many sizing/positioning related holes 
in the CSS2 and DOM2 specs it's not even funny.  Besides this bug, there is the 
problem of getting the actual size of an element.  IE has offsetWidth, etc.. NN 
has layer.width, and these are properties you use ALOT if you are constructing 
a GUI.   Vidur Apparao recently implemented IE's offset* stuff, but it should 
have been in the DOM2 spec.  And what about clipping? Look at bug 10915. The 
W3C didn't think clipping would be useful for a container of positioned 
elements? DUH.  Look at bug 27809.  Padding has ALWAYS meant space INSIDE the 
content area, not OUTSIDE, but the W3C says otherwise and Mozilla just goes and 
implements it, destroying web pages everywhere.  

My point is, for the love of Pete, give web developers a way to find out the 
width and height of a block of text.  I don't care what the CSS2 spec says.  
These kinds of things are goign to have developers screaming bloody hell at 
Mozilla once people start using your browser.  Please let common sense over-
ride the W3C in times like this. 

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

joehewitt - These issues are being addressed:
 - this bug - It's better to wait for the new rules to be finalized before
implementing them, so that it's done correctly.
 - bug 10915 - nobody's arguing that it's not a bug -- again, it's just better
to wait for clarification of exactly what the correct behavior *is* before going
ahead and implementing it
 - Padding:  padding has been defined the same way according to CSS since well
before any browsers started to implement it, and for good reasons.  I don't see
the argument that CSS1 should have been written to imitate browsers that didn't
exist yet when the spec was written.  However, the 'box-sizing' property will
probably be added to CSS3 so that both models can be used.

Comment 7

[troy]

It's kind of ironic that this is from the guy who complains that no one 
implements the CSS2 spec which has been around for two years.

Today we implement exactly what the CSS2 spec says should happen. Yes, that's 
different from what IE5 implements, but hey the spec has been around for two 
years.

Marking INVALID again.

Comment 8

[troy]

Two additional comments.
1. Gecko already implements 'box-sizing'
2. As David indicated absolute positioning and clipping are being revisited by 
the W3 CSS WG.

Comment 9

[Joe Hewitt]

Kudos for you for implementing the spec correctly.  Too bad the spec 
is "wrong".  By "wrong" I mean that, unless I'm missing something, they 
obviously didn't consider developers would have the need to know the exact size 
of content. I'm tempted to use profanity to describe my feelings about this, 
but I'll refrain.  I'm taking this up with the W3C.  Sorry for bugging you guys 
about it.

Comment 10

[Hixie (not reading bugmail)]

Agreed.