Closed Bug 98617 Opened 25 years ago Closed 24 years ago

div and span underlay left-aligned img (image)

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows ME
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: shelby, Assigned: ian)

References

(
URL
)

Details

(Keywords: compat, Whiteboard: INVALID/WONTFIX)

1. <DIV> does not correctly wrap around left aligned <IMG>, e.g. <IMG ... align=left hspace=0><DIV style="padding:4px">Text</DIV> aligns the right edge of image with left edge of "T", instead of left edge or box created by <DIV>. See the horizontal bar at topmost edge of the following web site for example of the problem: http://downloadfast.com/bugzilla.php 2. In a related problem, I tried to correct this by using <SPAN> instead of <DIV>, but then the top of edge of window aligned with top edge of "T" instead of top edge of box created by the <SPAN>. 3. In summary, it appears that aligning is done on the content (text) of a <DIV> and <SPAN> instead of the <DIV> or <SPAN> themselves. Since the <DIV> and <SPAN> are renderable elements (can have background color, border, etc), then the apparent treatment of them as invisible containers (non layout parent nodes) is an erroneous assumption. IE (at least 5+) does not have these problems. Perhaps related to, but different from, Bug#: 73069 I wasn't sure whether to classify this as HTML Element or Layout.
->layout
Assignee: clayton → attinasi
Component: HTML Element → Layout
QA Contact: bsharma → petersen
align="left" is the same as style="float: left". From the CSS2 spec: Since a float is not in the flow, non-positioned block boxes created before and after the float box flow vertically as if the float didn't exist. However, line boxes created next to the float are shortened to make room for the floated box. In other words "aligning is done on the content (text) of a <DIV> and <SPAN> instead of the <DIV> or <SPAN> themselves" is exactly what should be happening per the spec. ccing ian for his thoughts.
Good point. HTML 4.0 sets the default style for DIV {display:block}. So I changed the DIV in this case to display:inline and that does seem to correct the flow problem to some degree but causes 2 other bugs to manifest. See new example: http://downloadfast.com/bugzilla2.php Now obviously the vertical alignment is wrong and the 100% width style is no longer honored. Also in the original example it wasn't honoring CSS2 either because it wasn't clearing vertically. So that is 3 bugs. Also IE renders both examples the same, as a layman would expect. It is not intuitive that visible elements should clear automatically just because they are block boxes in the default style. I guess one could say that the user agent is free to set it's own default style, and I think IE has done the intuitive thing. There is a clear style when one wants to force a visible element to clear vertically. Bottom line is I have tried numerous combinations. I have found no way to get an image left and adjacent to 100% width background, bordered box in Mozilla, yet it is quite easy and intuitive in IE. If CSS2 is broke, then fix it, but please make your browser work if you want it supported. Also I am cross-referencing this to Bug#98621, which is the other bug I reported on the first example dealing with the 100% width style not being honored correctly.
> Now obviously the vertical alignment is wrong and the 100% width style is no > longer honored. From http://www.w3.org/TR/REC-CSS2/visudet.html#the-width-property: This property does not apply to non-replaced inline-level elements. As for vertical alignment, I see nothing in that stylesheet that would make the image and the menus have the same height.... Did you forget a "height" property on the menu div? > I have found no way to get an image left and adjacent to 100% width > background, bordered box in Mozilla, #myimage { float: left } #mybox { border: 1px solid red; margin-left: image_width; margin-right: 0; padding-left: 0; padding-right: 0; width: auto; display: block } where image_width is the width of the image ("186px" in your case) In general, please read http://www.w3.org/TR/REC-CSS2/box.html > If CSS2 is broke, then fix it That would be the purview of the W3C. > Also in the original example it wasn't honoring CSS2 either because it wasn't > clearing vertically. Clearing vertically? I saw no uses of the "clear" property in that page... > I think IE has done the intuitive thing IE has done the broken thing. The page has a doctype that triggers strict mode, by the way... so you should certainly be getting per-spec rendering from both Mozilla and IE6. IE 5.x may well give you crap. Looks invalid to me.
QA Contact: petersen → ian
Problems I see in comments from, Boris Zbarsky 2001-09-07 07:06: 1. Yes true that width:100% not valid for non-replaced inline elements. Apologies my oversight. 2. However, width:auto is taken as 0 unless display:block, yet according to previous comment, Boris Zbarsky 2001-09-06 22:36, diplay:block ignores float thus is implemented correctly should this flow vertically to next line? Or when CSS2 says "as if float didn't exist" do we take this to mean "as if image did not exist". You see the fine points of interpretation are critical. The spec says "as if float doesn't exist", which takenly literally means as if the image was not floated. If we are going to use CSS2 as our bible, then we have to make sure it is not ambiguous else we have no excuse when our site breaks in IE. Which do think is more important commercially for sites IE or Mozilla? 3. Hmmm. my site currently works great in IE and for 95% of visitors. Define "broken"? 95% of people would try Mozilla and say Mozilla is "broken" (in fact they are saying that about Mozilla regarding many sites). This is the reality, not theory. 4. About the clear issue, Boris quoted CSS2 which says display:block should flow vertically "as if float doesn't exist", so I assume that is same as a clear, according to my strict reading of the verbage. Again refer to my comment #2 above. I just want to get this work. It shouldn't be this difficult to write a web page where the image in on left and has a 100% box on adjacent right and still work in all browsers. If CSS2 is this complicated and ambiguous, one needs to question whether Mozilla can win by being snobbish about it. Let's get done to reality and solve this issue please, instead of being inclined to dismiss it as "invalid". Certainly is valid for the thousands of people who visit our web sites every day and toss their Netscape 6.1 because it still doesn't work after 2 years of wrangling.
> should this flow vertically to next line? Should _what_ flow vertically to the next line? > when CSS2 says "as if float didn't exist" It says "as if the float didn't exist" where "the float" is the box that's floating. That is agreed upon by the creators of the spec (which would include Microsoft, by the way). > Hmmm. my site currently works great in IE Your site was designed for IE. This is a circular argument. Let's not argue politics here. > About the clear issue, Boris quoted CSS2 which says display:block should > flow vertically "as if float doesn't exist", so I assume that is same as a > clear No. If that were the case there would be no need for the clear property. The block is placed pretending that the floating box is not in the document at all. Then the floating box is placed over or under it (depending on z-indices and order of appearance in document). The the inline content of the block is placed, taking into account the float. > I just want to get this work. It shouldn't be this difficult to write a web > page where the image in on left and has a 100% box It should be if you insist of thinking of it as a "100% box" instead of "a box that takes up all the remaining space". Those are very different concepts. > If CSS2 is this complicated and ambiguous Complicated, sometimes. Ambiguous, also sometimes. The working group welcomes feedback. > one needs to question whether Mozilla can win by being snobbish about it. As much as IE6 can by being snobbish (which it is, in strict mode). > solve this issue please Which issue? That the per-spec rendering of your markup was not what you expected? > Certainly is valid for the thousands of people who visit our web sites every > day and toss their Netscape 6.1 because it still doesn't work after 2 years of > wrangling. I understand that you're frustrated. That's no reason to insult the hard work of hundreds of people. Feel free to mail me in person if you'd like to discuss the state of the Web, how Mozilla relates to it, and the progress of the project. That discussion really does not belong in this bug.
I'm not frustrated. I am just making one last attempt to help you guys before it is too late. I just question your facts, as I will continue to. This is not about politics, this is about engineering and that means making things work. Any discussion we have here makes no difference when Mozilla doesn't work, but IE does. I did try to design my site for Mozilla, but it is much easier in IE. IE is more intuitive to design for. "Things work as expected the first time". I can guarantee you the more intuitive browser, which already has more market share, will destroy the thing that claims adherence to a spec that appears to be brittle, ambiguous, not user friendly, debateable, and thus not robust. As an engineer I am sure you are familiar with these concepts and the spec doesn't matter if the space shuttle crashes. That is my point to you but you are closed to what I am saying. Oh well. Also over 1 year ago, I invested considerable amount of my time to make bug reports here, only to be met by this same kind of attitude, and thus my site continued to not work in Netscape 6.0 (actually it got worse on each Mozilla release) and 6.0 was a miserable flop universally hated by web developers, as IE chomped up more market share. To imagine we were once Netscape fans. Certainly if you all can use this forum to crack jokes about the vending machine raising prices by $0.05, then I can make valid points about what I consider to be a bug. Whether the bug is in CSS2 or Mozilla makes no difference to my visitors. I am taken by how quickly you want to make something invalid. Perhaps that is brought on by the sheer number of bugs in Mozilla. I think it is a disservice to those 100s of people who gave their hard work, to not listen a little more openly to people who are profitable on the internet (again a rare occurrence!). I am trying to tell you that the vast majority of developers will not go to the extreme I have to try to find a solution. They will just ignore your browser. Wake up! Maybe you also see the other bug I reported where this page is taking like 20 seconds to render (after been loaded over network) and not in IE! On to facts debate: 1. You say that we should infer that "the float" means "the box that's floating", but I am saying to you that the spec does not say that explicitly (or at least not in that same place for clarity). The spec says that "the float doesn't exist", which means it was not floated. If the spec intends "the box that is floated does not exist" then it should say that. Taking your word for it, is not going to fly on large scale. Especially when that is not what the installed base of IE does. Why should I break potentially my site in IE or Opera, to support your interpretation of CSS2??? 2. Don't try to get inside my head, I am not as stupid as you think. I am not thinking 100% width. In fact, I always felt that 100% width in a correct sense should mean 1.0 * containing block width. However, gettings to work in practice and in reading the spec is as I've shown above not so nice in real world as it is in your little theoretical cubicle. Where I have disagreed with the spec, and apparently IE as well, is that if the border and padding are not included in the width, then things get very messy and non-intuitive, as I am illustrating here. I am perfectly happy to use the width:auto display:block, but the spec implies it won't work in a correct implementation, and you are telling me to interpret the spec in a way it was not written. That seems like a glaring flaw in CSS2. For example, exclude the 100% case. What if I want 50% width but still want 1 pixel border?? What I am trying to say to you is that your theoretical foundation is flawed at the core. Please don't imply again that I am not thinking through a lot of angles. That is not appreciated. Remember I came here to try to help Mozilla and I just as easily leave this discussion and profit just fine. Before I try your suggestion we need to resolve the spec inconsistency issue. That is troubling for me, and should be for you too if you base so strongly your foundation on the spec instead of on making things work for the majority.
About the vertical alignment, Boris said "...menus have the same height". Please notice that in the bugzilla2.php example, the DIV is (as I had said) off the top of the non-scrolled window. I wasn't saying anything about their relative heights. Seems to me it should always be a bug to render something above top of a non- scrolled window, unless it was absolutely positioned that way.
Okay I have tried using width:auto and margin-left:186px as Boris suggested, and now I lose the background in both IE5.5 and Mozilla: http://downloadfast.com/bugzilla3.php Also in Mozilla I also lose the inline images for the down arrows. Also in addition to other concerns raised, I will probably lose IE4 compatability with this, and have to switch to browser detection. Like I said, if borders and padding are including in the width and height then whole thing would be a lot less messy and apparently perhaps more backwardly compatible. In any case, there are still bugs in Mozilla as noted, and this is not solution yet.
Shelby, a few questions: 1) What happens if you change the doctype to 4.01 Strict? Does IE's rendering change? 2) What happens if you remove the doctype declaration entirely (or just remove the DTD url)? Does Mozilla's rendering change? It could be that the page is triggering quirks mode in IE and strict mode in Mozilla... though I'm not sure triggering our quirks mode would help here. > What if I want 50% width but still want 1 pixel border?? That one bothers the hell out of me too (the fact that I can't figure out a way to do it with just css2, that is). > Please don't imply again that I am not thinking through a lot of angles. I was not trying to do that. My apologies if it sounded like I was. > The spec says that "the float doesn't exist", which means it was not floated. > If the spec intends "the box that is floated does not exist" then it should > say that. Perhaps someone should suggest that erratum to the working group? In any case, the spec goes on to provide diagrams of expected renderings which remove that ambiguity. > now I lose the background in both IE5.5 and Mozilla Your style says: "margin-right:0px background:#808080;" That needs a semicolon after the margin-right value. Doing that should help the background issue. I can still see the down arrow images in a current trunk build. I assume you refer to the little black triangles near "All platforms" and "All categories"? > I will probably lose IE4 compatability with this Unfortunately, true. :( > if borders and padding are including in the width and height then > whole thing would be a lot less messy I personally happen to agree with you.... And I would be quite happy to lobby to get the spec changed to that effect. But the current spec is what's been agreed to for the moment. Trying to be compatible with IE without really knowing what quirks we're trying to be compatible with is certainly a losing game... the quirks can just get changed. > Please notice that in the bugzilla2.php example, the DIV is (as I had said) > off the top of the non-scrolled window. Looking into that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yep. Looks like what happens there is that we align the text content of the inline element with the surrounding text. So the top padding ends up being off the screen. I'm not that familiar with how inline boxes should get laid out, so deferring to hixie on this one.
One issue at a time. I added the missing semicolon and now bugzilla3.php works correctly in both IE5.5 and Mozilla. Thanks! Apologies on silly typo, as I was rushing to drop kids at cinema :)
About the doctype change, I am not sure which case you wanted me to test, but if you look at the current index.php for the site (which may change soon), it uses no doctype, and the rendering was unchanged from bugzilla.php. I just tried strict doctype for bugzilla.php (but with margin-left:186px;) and that did not change the rendering in either browser. However, I now see a major quagmire and error in CSS2 according to your stated interpretation. If I set the margin-left:186px, then DIV is positioned correctly with left edge adjacent to image in both IE5.5 and Mozilla. However, width:auto is probably not supported in older IE4, so I want can I do? I thought maybe I could use kludge width:97% and allow for a few pixels of empty space on right in most common window size, but Mozilla is assuming that "the float does not exist" when computing the containing block width, so thus I get 97% of entire window width. IE5.5 is either assuming that containing block is minus the image width, or that it is silly to make a box wider than window (either of which workforme :) Now imagine I wanted to make the right DIV box 50% or remaining space (minus image width). There is absolutely no way to do it with your interpretation of that CSS2 that "the box floated is pretended to not exist". I must assume that CSS2 means that the display:block (block) boxes pretend that the float doesn't exist, but in computing the containing block size they should still assume it exists?? Because since non-replaced inline boxes can not use percentage widths, then there is no other option. About the issue of whether CSS2 should be changed to include border and padding in width and height, after further thought I realized that the problem applies in both directions, and thus the best solution is probably to propose a new boolean style setting to control this, and by default to set it to IE way in quirks mode and CSS2 way in strict mode. Since I've made the effort here, perhaps you can champion the necessary issues we have discussed here regarding CSS2?? I really don't have the resources to approach W3C at this time. But I would like to see this problem set resolved in your favor rather than being left at the whim of IE's quirks. The containing block size issue with floats is an immediate problem that affects what I will put on the index.php for live site. What is the best tradeoff?? What can we do now???
*** Bug 98621 has been marked as a duplicate of this bug. ***
After further study of CSS2, I agree that Mozilla is doing the correct thing according to the spec: 10.1 Definition of "containing block" 2. For other elements, unless the element is absolutely positioned, the containing block is formed by the content edge of the nearest block-level ancestor box. Thus I also want to correct myself, and state that it should be possible create a box which spans a % of the remaining portion between the left image's right edge and right of window. This can be done by creating a display:block width:auto ancestor block, then the descendent block may use width:xx%. Pray that the average web developer will ever figure that out. However, I am still not satisfied that one has to resort to using a CSS2 (vs. CSS) feature to achieve this very simple effect. And it is a quite non- intuitive and convulted way IMO. It means that any one who wants to use this effect has to do a browser detect to support earlier browsers, and be aware of some very fine details spread out in CSS2 to get it right in Mozilla (CSS2 strict). As I said before, I think the most developers will just stop at what is intuitive and say that IE works and Mozilla is broken, even though that is apparently wrong in the strict since of CSS2 compliance. I think Mozilla and W3C should endeavor to rectify this problem, as I would bet MS knew very well the W3C had an inferior, non-intuitive design and probably quite happy with that fact. It is going to take more effort to outsmart MS, than just say "read the spec". Nevertheless, 2 issues remain which I think even Boris agrees are problems: 1. There is the display:inline case which misaligns vertically and the DIV goes off the top of the non-scrolled window. A bug in Mozilla apparently. 2. And currently in CSS2 there is no way to specify a % total combined width for a box which has px defined border and/or padding. I have suggested that someone propose a new boolean style flag to control whether border and padding are inclusive in width and height. It is not my job to raise this with the W3C. User Agents are usually free to reorganize content to fit the width of the window. It rarely makes sense to formulate content that has to be scrolled both horizontally and vertically (try that sometime and see how ridiculously annoying it is). Thus I think the solution to the non-intuitiveness of the CSS2 spec is exactly what IE has done. They honor the spec, but it would create something that would needlessly (instrinsic width is within horizontal dimension) create a horizontal scroll, IE apparently optimizes (rationalizes) the layout. This is probably the optimization Mozilla needs to make in order to make their browser intuitive in this case. I would not call this a "quirk". As I say, it has historically been true that User Agents reformat layout rationally to fit width of the window, for good reason. Lastly I want to go back to first case, and question whether the descendent text (content) of the display:block DIV should have been flowed around the float?? Seems to me that if the ancestor was block and thus ignored the float, then the descendent should to?? This bug may be a tough read, but no pain no gain I say. I think there are very valid issues here, now I leave to you guys to decide if you ignore it or not.
Sorry to be so brief, but can somebody please explain what the bug is, and maybe attach a testcase? I am totally confused by the long dialog so far reported here, sorry.
IMO: In http://downloadfast.com/bugzilla2.php, the DIV is off top of screen. In http://downloadfast.com/bugzilla.php and bugzilla4.php, and in general, why render the DIV wider than the window?? User agents are supposed to try to render inline content to fit window width. Needlessly creates a horizontal scroll bar. The long discussion illustrated the complexity of CSS2 needed to get case right (bugzilla3.php), pitfalls or increased complexity for get fractional width cases right, and that the general optimization (as IE apparently does) of not generating content needlessly wider than window, is IMO a solution/optimization that will make this more intuitive for designers. In http://downloadfast.com/bugzilla.php, I am wondering if it is bug to flow the descendent text around the image. I assume that since block box ignores the float, then it's descendents should too. Had this been this case, I think I would have figured out the correct CSS2 without making this bug report.
It's hard to tell, because these "test cases" are all WAY WAY WAY more complicated than they should be, but the first testcase is displaying the <div> correctly. The <div> is marked as display:inline with padding:4px, and the inline is therefore being aligned to the baseline of the line box created around it, and the padding is only then being taken into consideration, so the top padding goes off the top of the viewport. (Technically we should have a scrollbar, but that's another bug.) The second testcase is also displaying exactly as specified in the spec. The <div> in that case is a block, with an inner content width of '100%' of the parent's content width, PLUS, in addition, 8 pixels of horizontal padding (4 on each side) and 2 pixels of border (one on each side). The TOTAL width of the div is therefore wider than the container. To achieve the expected effect, the 'width' property should be set to 'auto' instead of '100%'. I don't understand the third issue. Finally, a note about test cases. Test cases for layout bugs should be less than one kilobyte in size and should not have any javascript in them, and preferably no tables. We appreciate the effort that has been put into this bug, but it is very hard to understand the issues when there are script blocks, tables, invalid content, and irrelevant sections all over the place. Given that the first two issues are invalid, could you create a small testcase demonstrating what you believe is the issue in your third point? Thanks!
Assignee: attinasi → ian
QA Contact: ian → bzbarsky
1. <frustrated>I gave real world test case as duplicated from our live web site which has over 3,700 download products listed. I absolutely will not make any more test cases! Who are you to be scolding me that my test cases are too complicated?? You should be thanking me for spending several hours of my time. I don't think it is our responsibility to save your time, rather it should be the other way around if you want developers to bother. If you want to make a simplified test case, I think it would take you all of about 5 minutes. Do you not test Mozilla with popular web sites on the web? Do you tell Yahoo to send you more simplied test cases?</frustrated> http://DownloadFAST.com 2. You seem determined to dismiss this bug, so I this is my last response on this bug. You are wasting my time. You win (ahem...I mean lose) based on your priorities. I am telling you that IE5.5 "works" in all these cases, and you are responding that Mozilla agrees with the CSS2 spec. Which do you think is a stronger argument in the real markets?? I guess you don't care. Fine. 3. In no case should you have content spilling off the edges of windows with non-absolute positioning. Geez what is the point of percent widths??? Think about it for a minute. That is simply very poor excuse to say it agrees with the spec, therefor that is justification to have **** layout appearance. The spec leaves leeway for user agents in this area to flow layout within the width and top edge of window. 4. The last case was very well articulated and succinct. There is only 1 <DIV> at the top of the window. It is very easy to find in the html source. Go back and read it more carefully if you want. SAME ATTITUDE AS I GOT LAST TIME (2000) I REPORTED BUGS. GO AHEAD AND MARK IT INVALID. I AND MY COLLEGUES WILL MARK MOZILLA AS INVALID.
Usually this sort of thing is the predictor of impending implosion of a project/product. Unfortunately this indicates to me we are on the last gasp of Mozilla. You have a product where the programmers are not thinking with any commercial common sense, much less being dogmatic about specifications which are inherently transient and imperfect/ambiguous. All commercially successful engineers strive to make a product which works for the users (which are visitors and developers in this case). I know you will write me off by stereotyping me somehow (that I'm seeking an incorrect solution or something other mischaracterization of what I was trying to teach you). However, I will bet anyone that there will still be far too many complaints about compatibility in the next release of Mozilla because of this prevelant attitude.
Shelby, the reason we need small, reduced testcases is simply that we have very *very* many bugs and very few engineering resources, relatively. The more simple and reduced a testcase, the less time it takes to resolve the issue. If you do no have the time, will, or deisre to reduce the testcase that is fine, however it will mean that this bug takes longer to get to. Hopefully somebody else will be able to reduce the testcase. We certainly HOPE that bug reporters will be sensitive to our desires and reporting guidelines, but we do not require anything - you do this of your own free-will, right? I'm sorry that you got so upset - we are all just trying to do a reasonable job of balancing resources and priorities. Mozill ais not on the verge of imploding, but we do have a log of outstanding bugs, some more critical than others, obviously. In the face of the overwhelming ratio of bugs to engineers, getting teh bugs clearly stated and reduced is generally the most expeditious way we have to see that we attend to the most bugs possible.
Apologies then. If this bug/issue is lower priority (which I agree it probably is), then just mark it lowest priority and come back to it in a year or so. Please rather than consuming more of my time to defend it as a valid issue. I also have limited resources and unlike Mozilla have to earn a profit to survive. In general, why doesn't someone send an urgent communication to AOL and tell them that if they don't commit the proper amount of resources then their browser will never be able to compete with IE. I've heard that MS has thousands of engineers working on IE. That probably does not include thousands for QA people.
Having looked further at the pages alleged to have rendering errors, I cannot find any errors with our rendering. We are doing it per spec. In answer to your comments: > You should be thanking me for spending several hours of my time. Thank you! I do appreciate the effort you have put into this bug. > I am telling you that IE5.5 "works" in all these cases, and you are > responding that Mozilla agrees with the CSS2 spec. Which do you think > is a stronger argument in the real markets?? I guess you don't care. Microsoft, along with companies such as Netscape, Opera Software, and Adobe, and members of organisations like the W3C, and a few invited experts such as myself, work together to decide how web browsers should work. Our work results in specifications such as the CSS2 specification. We then go back and implement this. Microsoft has a poor track record at implementing the specs. However, they have been following Mozilla's lead, and in IE6 standards support has improved. What you suggest we do is follow IE's bugs... but when they fix their bugs, should we then suddenly change as well? If we did that, we would be at the mercy of Microsoft, always going back and changing our implementation every time Microsoft fixed a bug. I'm sorry, but as a volunteer contributor working on this project, I don't have the *time* to reverse engineer IE's behaviour, write a spec for it, implement it, and then go back and do the whole thing over again when IE changes. Instead, I follow the document that MICROSOFT (and others) have agreed to. > In no case should you have content spilling off the edges of windows with > non-absolute positioning. The spec disagrees. What you want is to use 'width:auto', which will work. Or, a nested box with the percentage set on the outer box. Or the proprietary '-moz-box-sizing' property, a Mozilla extension which controls this behaviour. The second (nested boxes) will also work in IE, if that is a requirement. > That is simply very poor excuse to say it agrees with the spec, therefore that > is justification to have crappy layout appearance. If _web pages_ also follow the standards, then Mozilla will do its best. > The spec leaves leeway for user agents in this area to flow layout within > the width and top edge of window. Actually, it doesn't. (Please point me to the part of the spec which does, if you still think it does.) > The last case was very well articulated and succinct. I believe we are handling this float in the same way as IE. I personally do not understand what you think the problem is here. I can't "invent" an understanding, sorry. If you want me to understand this, I'm afraid I will have to ask for a small explanatory testcase. :-) > I AND MY COLLEGUES WILL MARK MOZILLA AS INVALID. Will you mark IE as invalid as well when they fix their bugs? I'm afraid this bug is 'INVALID' (or 'WONTFIX') unless there is something behind the third issue, which I do not understand.
Keywords: compat
Whiteboard: INVALID/WONTFIX
Looking at the last testcase, all the <div> seems to contain is a <script> element, and it's not floated (as of this date). Closing as INVALID. Good luck with CSS2, shelby--it is quite difficult to use, at times.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.