Summary: | input elements don't respect padding attribute | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | Roberto <rober_box> |
Component: | khtml | Assignee: | Konqueror Developers <konq-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
testcase - form elements and padding
patch for review testcase box-sizing, in conjunction with button and image khtml rendering after patch for #13121 |
Description
Roberto
2005-07-14 12:57:29 UTC
hi ! next time you come and see us in #khtml, please stay a few hours :) As for the bug: all browsers seem to handle this somewhat differently, but indeed some form elements consistently accept padding (as if applying to the widget boundaries) Created attachment 13113 [details]
testcase - form elements and padding
Created attachment 13114 [details]
patch for review
include padding in the widget area for at least buttons, textarea and lineedit
(type=text)
I looked mostly out of curiosity, as I can't review something like this, but I do think that the "// form elements never have padding" comment there looks kind of wrong with the change ;-) quite right... let's say: - // form elements never have padding + // form elements either include padding in the widget boundaries or do not support it at all. WebCore is now using box-sizing to control if padding is part of the width or not. input, textarea, select, button { display: inline-block; box-sizing: border-box } mmh, I don't understand what that means. The point here is to decide if padding should be part of the object's box or of the widget's box, so it's completely independant of box-sizing, it just affect our representation of the object. IOW, if the object is felt as being replaced starting at the padding edge (like button in all browsers) or at the content edge (images). I'll attach a testcase, and khtml rendering after patch... could you tell me what webcore rendering would be then? Created attachment 13121 [details]
testcase box-sizing, in conjunction with button and image
Created attachment 13122 [details]
khtml rendering after patch for #13121
SVN commit 755231 by charles: Allow padding of form elements in the case of border-box, which causes the form element widget to get bigger but its active region to stay the same size. This is sometimes used to put little icons on lineedits. In the case of the content-box model, the padding goes around the form element, as it is today (also the default in non-quirky mode). There's still a strange bug with how the scrollbar on scrollable widgets doesn't have any hover effects and it has the "text input" cursor. But that's not a regression and is tolerable, so we decided to accept it until we have a chance to clean up render_replaced. Reviewed repeatedly by Germain. BUG: 109068 M +108 -8 render_form.cpp M +22 -6 render_form.h M +11 -1 render_replaced.cpp M +2 -0 render_replaced.h WebSVN link: http://websvn.kde.org/?view=rev&revision=755231 |