Version: (using KDE Devel) Installed from: Compiled sources OS: Linux The width of any container element (tested with DIV and TABLE->TR->TD) is not taking into account the padding in the container's subelements when subelements are 'width: 100%'. It makes our web menu render *really* screwy, because stuff like borders on the containers are half-rendered (some of it falls behind the subelements, stuff like that). It also messes up javascript dynamic width calculations by giving wrong offsetWidth values. Steps to Reproduce: Open the HTML file (which I'll attach in one moment) in these browsers: * IE * Opera * Konqueror Results: IE: TD is 97 pixels, A is 97 pixels, dialog shows "Phew, same size." Opera: TD is 67 pixels, A is 67 pixels, dialog shows "Phew, same size." Konqueror: TD is 109 pixels, A is 139 pixels, dialog shows "A element is larger than containing element!"
Created attachment 15550 [details] Test case for bug 125315
FireFox also exhibits this bug, reported at: https://bugzilla.mozilla.org/show_bug.cgi?id=333472
The CSS layout guy from the FireFox team, Gérard Talbot, seems to think that the behaviour is correct, even though the rendered output is screwed. According to him, while padding is an amount of spacing that's added inside an element, the amount of space that it takes up should not be counted as part of the element's width. Mr. Talbot has not made any arguments describing why this would be desirable behaviour. According to Mr. Talbot, if a DOCTYPE declaration is added to the test case, IE will render the inside element larger then the container that it's in. I've confirmed that this is correct both for IE and Opera. We're forced to conclude that in Firefox and KHTML, there's no way to accomplish this (seemingly simple) feat: * Have an element fill the entire width of it's parent * Use a fixed amount of pixels as padding on this element to give space around it's text We can also see that IE-compatible rendering is broken in both FireFox and KHTML, but not Opera, based on the DOCTYPE experiment.
CSS 2.1 layout model uses the content edge for width/height (which means it does not include border/padding). If you want to use the border edge (as MSIE/Opera in quirk mode), then you need to set the corresponding CSS 3 property (box-sizing: border-box;)
Errata to comment #3: IE does not change behaviour with DOCTYPE now that I re-test, only Opera does. IE still sizes the container so that the contents will fit. I'm not sure whether IE changes behaviour sporadically, or if I did something wrong while testing the first time. > you need to set the corresponding CSS 3 property (box-sizing: border-box;) Since CSS3 is unsupported on just about every browser on the market, that's not a very good solution :-). Unless you have a way to set it specifically for KHTML (and preferably FireFox too)? Also, looking at the W3C draft it seems like the W3C folks are not quite sure what foot to stand on wrt. the box-sizing property - there's mention of other solutions like adding an additional pair of width/height properties as well as a rather complex-sounding solution involving virtual container elements. > as MSIE/Opera in quirk mode Shouldn't KHTML per default (no DOCTYPE given) render the same as IE/Opera in quirks mode? Or does it not aim to be compatible? > CSS 2.1 layout model uses the content edge for width/height > (which means it does not include border/padding). As I've demonstrated, that's clearly broken. If you do not understand why it's broken, read comments #0 and #3 and see the test case.
box-sizing works in Opera, Konqueror and Safari. In Firefox/Mozilla it works if you set -moz-box-sizing. So that is every browser on the market except MSIE
I guess that the combination of box-sizing and -moz-box-sizing is an acceptable solution then, in lack of a better/supported one.. I'll try it out tomorrow. Thanks for the help, Germain & Allan :-)
Should we close this. Looks like the issue has been resolved. Though I will note it has not been "fixed" yet. The test case still presents the same error. Using Gentoo Linux ~x86 (testing in gentoo lingo). KDE and the majority of packages compiled using gcc 4.3.0.
This is most likely a KDE3 issue. Please check whether it is still valid for Konqueror 4.8.4. 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 set the bug status 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!
Dear Bug Submitter, 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!