Bug 235519

Summary: [CSS 2.1 Conformance] A left floated box should shift left until touching the containing block edge while remaining on the same line
Product: [Applications] konqueror Reporter: Gérard Talbot (no longer involved) <browserbugs2>
Component: khtmlAssignee: Konqueror Developers <konq-bugs>
Status: RESOLVED WORKSFORME    
Severity: normal CC: kde
Priority: NOR Keywords: testcase
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Gérard Talbot (no longer involved) 2010-04-27 04:58:39 UTC
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
Comment 1 Gérard Talbot (no longer involved) 2011-02-21 20:04:48 UTC
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
Comment 2 Allan Sandfeld 2011-03-27 17:40:03 UTC
A quick test shows that firefix and opera passes this test, while webkitpart behaves like khtml.
Comment 3 Andrew Crouthamel 2018-11-05 03:16:12 UTC
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!
Comment 4 Andrew Crouthamel 2018-11-17 04:53:51 UTC
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!
Comment 5 Justin Zobel 2022-12-14 03:09:06 UTC
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!
Comment 6 Bug Janitor Service 2022-12-29 05:23:07 UTC
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!
Comment 7 Bug Janitor Service 2023-01-13 05:14:02 UTC
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!