Version: (using KDE 4.4.2) OS: Linux Installed from: Ubuntu Packages Testcase -------- http://www.w3.org/Style/CSS/Test/CSS2.1/20100316/html4/floats-001.htm Actual results in Konqueror 4.4.2 --------------------------------- The blue square is located outside the black bordered rectangle. Expected results ---------------- The blue square should be inside the black bordered rectangle touching its left inner edge. Notes ----- Firefox 3.5.9, Firefox 3.6.3, IE 8 and Opera 10.10 pass this test. Reference --------- " A floated box is shifted to the left or right until its outer edge touches the containing block edge or the outer edge of another float. If there's a line box, the top of the floated box is aligned with the top of the current line box. " http://www.w3.org/TR/CSS21/visuren.html#floats regards, Gérard
Most recent URL of testcase: http://test.csswg.org/suites/css2.1/20110111/html4/floats-001.htm (RC5) and http://test.csswg.org/suites/css2.1/nightly-unstable/html4/floats-001.htm This testcase is failed by Konqueror 4.6 only because Konqueror processes white-space *_before_* floating div#div3 and not *_after_* floating div#div3: not *_after_* removing div#div3 from normal flow of line. Blank (U+0020) white-space processing should only apply to normal flow. It should not apply when floats are present, are involved. ---------------- http://test.csswg.org/suites/css2.1/20110111/html4/floats-001.htm (RC5) http://test.csswg.org/suites/css2.1/nightly-unstable/html4/floats-001.htm http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_9/floats-001.xht Actual code ----------- <style type="text/css"> #div1 { border: solid 5px black; height: 1in; /* 1in == 96px ; standard DPI in test suite */ width: 2in; /* 2in == 192px */ } div div { display: inline-block; height: 1in; /* 1in == 96px */ width: 1in; /* 1in == 96px */ } #div3 { background-color: blue; float: left; } </style> </head> <body> <p>Test passes if the blue box is on the left inner edge of the black box.</p> <div id="div1"> <div id="div2"></div> <div id="div3"></div> </div> div#div2 is an inline-block and, after executing bullet 4, sub-bullet 2 [1], it has only one blank (U+0020) white-space remaining to its right. We know that one single white-space (U+0020) character occupies about 5px under Linux (and about 4px under Windows) when using a normal font. If I set the width of container #div1 to 197px (2in plus 5px), then all browsers (including Chrome 9, Safari 5 and Konqueror 4.6 which fail the testcase right now) pass: http://www.gtalbot.org/BrowserBugsSection/Konqueror4Bugs/floats-001-container-197px.htm If I remove the blank white-space (which is at the right-hand side of #div2), then all browsers (including Chrome 9, Safari 5 and Konqueror 4.6 which fail the testcase right now) pass: http://www.gtalbot.org/BrowserBugsSection/Konqueror4Bugs/floats-001-no-separating-blank-space.htm (Right here, this version of the testcase is reliable proof that this bug is about white-space processing more than about actual/accurate compliance with rules of floating elements) The browsers (Chrome 9.0.597.98, Safari 5.0.x and Konqueror 4.6) that fail this test only fail because they do not remove that blank (U+0020) white-space trailing at the end of line once/after removing the floating div#div3 from normal flow. " As each line is laid out, (...) 3. If a space (U+0020) at the end of a line has 'white-space' set to 'normal', 'nowrap', or 'pre-line', it is also removed. " 16.6.1 The 'white-space' processing model http://www.w3.org/TR/CSS21/text.html#white-space-model Such white-space (U+0020) removal should occur after removing the floating div#div3 from normal flow, once removing of floating div#div3 from normal flow has been carried out, executed. [1]: 4. If 'white-space' is set to 'normal' (...) 2. any space (U+0020) following another space (U+0020) — even a space before the inline, if that space also has 'white-space' set to 'normal', 'nowrap' or 'pre-line' — is removed. Section 16.6.1 The 'white-space' processing model http://www.w3.org/TR/CSS21/text.html#white-space-model regards, Gérard
A quick test shows that firefix and opera passes this test, while webkitpart behaves like khtml.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!