Closed Bug 100611 Opened 23 years ago Closed 18 years ago

Text absolute box not overflow in containing box with "overflow:visible"

Categories

(Core :: Layout: Positioned, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED INVALID
mozilla1.2alpha

People

(Reporter: sf_alpha, Unassigned)

Details

(Keywords: qawanted, testcase, Whiteboard: (py8ieh: sweet absolute positioning testcases))

Attachments

(3 files)

Table increased size when I use block (div) with z-index : 2 inside table. ? It's should float over a table ? I also found that box size should be auto computed to cover all contents with white-space : nowrap; but when use absolute positioning. contents overflowed, but a box not ! It's limited inside table border. Codes ... <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>Test Case !</title> </head> <body> <table summary="Test" style = "width : 100px; overflow : visible; border : 2px #cccccc solid;"> <tr> <td> <div id = "divA" style = "position : relative; left : 100px; height : 150px; border : 1px #0000ff solid; padding : 5px; overflow : visible; z-index : 2;"> These cyan are absolute inner box <div id = "divB" style = "position : absolute; top : 50px; border : 1px #ff0000 solid; background-color : #00ffff; white-space : nowrap; z-index : 3"> 1st Long text xxxxxxxxxxxxxxxxxxxxxxxxxxx<br> </div> <div id = "divD" style = "position : absolute; top : 75px; border : 1px #ff0000 solid; background-color : #00ffff; white-space : nowrap; z-index : 3"> 2nd Long text xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br> </div> </div> <hr> <div id = "divA" style = "position : relative; left : 100px; height : 150px; border : 1px #0000ff solid; padding : 5px; overflow : visible; z-index : 2; z-index : 3"> These yellow are relative inner box <div id = "divB" style = "position : relative; top : 50px; border : 1px #ff0000 solid; background-color : #ffff00; white-space : nowrap; z-index : 3"> 1st Long text xxxxxxxxxxxxxxxxxxxxxx<br> </div> <div id = "divD" style = "position : relative; top : 55px; border : 1px #ff0000 solid; background-color : #ffff00; white-space : nowrap; z-index : 3"> 2nd Long text xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br> </div> </div> </td> </tr> </table> </body> </html>
Over to layout
Assignee: jst → attinasi
Component: DOM Views and Formatting → Layout
QA Contact: lchiang → petersen
relatively positioned blocks _should_ affect the size of the parent... So the <td> size you perceive is correct. The overflow is also correct. The total width of the box (left margin/padding/border + content + right margin/padding/border) should be the width of the parent. To do what you want to do, size your box in em or better yet make it display:table-cell. Setting qa to hixie; I believe this is invalid as we render it per spec.
QA Contact: petersen → ian
Wow, that's a complicated testcase... not because it is too big, but because it tests the interactions of three different shrink wrap algorithms in one go! I like it! :-) I shall look at this in more detail at some point, so I'm not marking it RESOLVED for now.
Keywords: qawanted
Whiteboard: (py8ieh: sweet absolute positioning testcases)
I only want to wrote HTML to have a div layer over the Table ? I also included z-index style properties ... but div block effect the table cell size ? (I've tested in IE, = not effect ...) I 've read the CSS Spec for a time and don't know how it computed cell size if div with high order layer inside (float over ... not a float block) (I can't find describe about block over table ??? .. and I 'll read it again to find) Addition in something with test case... Text is overflowed ... but box not ... why ??? That I guess that major bug.
Addition again I've written new test and found some other error ! Now in vertical ... Contents are overflowed ... but block effect ? I see it different in IE and Moz... What correct ? Oh ... CSS spec TR is needed again. I 've to read it. See alternative test case ...
Now I was changed summary to pointed about "overflow : visible absolute box." Please look on vertical effect test case and compare between Moz and IE. It looks like to be bug. I've read W3C CSS-2 TR. This show "Absolute" box are effect size of table.
Summary: box block display wrong inside table → Text absolute box not overflow in containing box with "overflow:visible"
Marking these all WORKSFORME sorry about lack of response but were very overloaded here. Only reopen the bug if you can reproduce with the following steps: 1) Download the latest nightly (or 0.9.6 which should be out RSN) 2) Create a new profile 3) test the bug again If it still occurs go ahead and reopen the bug. Again sorry about no response were quite overloaded here and understaffed.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
reopening
Status: RESOLVED → UNCONFIRMED
Keywords: testcase
Resolution: WORKSFORME → ---
looks like bug, but too much for my little brain. confirming until Hixie gives OK.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla1.2
Mozilla 1.2 alpha? I thougth Mozilla was all about Standarts? So Mozilla 1.0 will not be full CSS compliant-> overflow:hidden and overflow:visible are not working.
> So Mozilla 1.0 will not be full CSS compliant Of course not. This was never even a stated goal... The stated goal was CSS1 compliance, and we've not quite gotten there yet. Full CSS compliance (whatever that means given that CSS3 is modular) is not even on the radar.
>Full CSS compliance (whatever >that means given that CSS3 is modular) is not even on the radar. I do not know if anybody is even using CSS3,but I was assuming that CSS1&CSS2 compliance is considered widely "CSS full compliance" for a browser. I do not think every single scrap of standard will get acceptance from community. For now, CSS1 and CSS2 are widely used therefore they are needed for a browser. if "CSS2" is not even on the "radar"(that is what I understand from your ambigious comment given above), then the question comes down to why should I even bother using Mozilla at all? I remember that there are people giving lessons on standards on bugzilla; then your comments invalidates all that and shows me that Mozilla development is driven not by innovation, but by personal egoism.
> if "CSS2" is not even on the "radar" At least the following parts of CSS2 are "not on the radar" in that no one is working on them at the moment and it's not clear when someone will be: Aural properties Font downloading Full support of paged-media properties Counters The fact is, the CSS2 standard is _very_ large. Full implementation is not likely to ever happen in any UA, because there are parts of the standard that may simply be irrelevant to the target users of the UA (eg aural properties for a UA designed to print only). This is why CSS3 is modular... > Mozilla development is driven not by innovation, but by personal egoism. Mozilla development is driven by one thing only. An entity (a company, a person, whatever) decides to implement something and implements it. This entity's reasons can range from "I want to use it on my web page" to "this would be good for the future of the web". What are your reasons?
Yes, Mozilla's development is driven by personal interests alone... what did you think it was based on? Regarding this bug, it is much more likely to be fixed sooner if it has a small testcase (the current testcases are way over-complicated and unclear). See http://www.damowmow.com/mozilla/css-testing.html ...for some tips. Sorry I haven't the time to do it myself right now. Thanks!
>At least the following parts of CSS2 are "not on the radar" in that no one is >working on them at the moment and it's not clear when someone will be: >Aural properties >Font downloading >Full support of paged-media properties >Counters Hmm, Perhaps these are extremes. Implementing the parts included in javascript binding would suffice. >What are your reasons? I have no reasons but to see Mozilla's success. >An entity (a company, a >person, whatever) decides to implement something and implements it I seriously doubt it. Without Netscape's help Mozilla was nothing. And it is good to see that Netscape has been in the development eventhough ambition driven bloat has furiously delayed it. >Yes, Mozilla's development is driven by personal interests alone... what did >you think it was based on? I think it is not very wise of you to make such an ironical comment. If this is an open project you should listen what others say. It does not exclude anybody from being critisized just because he/she is a mozilla developer.I do not doubt that many of you have been contributing great deal of time, code and brain power ,like Boris, but I am here to report the troubles I have encountered and CRITISIZE other's "so called troubles" if I see its fix obviously will be damaging for the mozilla's near future, and also to CRITISIZE Mozilla development, and nothingelse. You should not be particularly get offended from these.
Don't worry, we are not offended. But in a free software development environment such as this one, it is naive to think that bugs are fixed for any reason _other_ than personal interests (or corporate interests, in the case of the contributor being a company). In any case, this bug still requires a small, simple test case. Thanks for the help!
->R & A Pos
Assignee: attinasi → position
Component: Layout → Layout: R & A Pos
The primary rendering difference between IE and Firefox in the attached testcases is that IE changes the width of the table cells based on overflow, which is a bug in IE.
Status: NEW → RESOLVED
Closed: 23 years ago18 years ago
Resolution: --- → INVALID
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: