Bug 109068 - input elements don't respect padding attribute
Summary: input elements don't respect padding attribute
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-14 12:57 UTC by Roberto
Modified: 2007-12-31 19:35 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
testcase - form elements and padding (899 bytes, text/html)
2005-10-23 03:44 UTC, Germain Garand
Details
patch for review (4.08 KB, patch)
2005-10-23 04:26 UTC, Germain Garand
Details
testcase box-sizing, in conjunction with button and image (514 bytes, text/html)
2005-10-23 18:12 UTC, Germain Garand
Details
khtml rendering after patch for #13121 (12.11 KB, image/png)
2005-10-23 18:15 UTC, Germain Garand
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roberto 2005-07-14 12:57:29 UTC
Version:            (using KDE KDE 3.4.1)
Installed from:    Gentoo Packages
Compiler:          gcc (GCC) 3.3.5-20050130 (Gentoo Linux 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1) 
OS:                Linux

html <input> elements don't apply padding, for example:

<input type="text" name="text" style="padding: 5px">

The padding in the above piece of code is ignored. I've tested it with Firefox in Windows and Linux, and with Internet Explorer in Windows, and those browsers apply the padding correctly.
Comment 1 Germain Garand 2005-10-23 03:25:40 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)



Comment 2 Germain Garand 2005-10-23 03:44:48 UTC
Created attachment 13113 [details]
testcase - form elements and padding
Comment 3 Germain Garand 2005-10-23 04:26:04 UTC
Created attachment 13114 [details]
patch for review

include padding in the widget area for at least buttons, textarea and lineedit
(type=text)
Comment 4 Maksim Orlovich 2005-10-23 04:36:33 UTC
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 ;-)
Comment 5 Germain Garand 2005-10-23 04:52:15 UTC
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.
Comment 6 Allan Sandfeld 2005-10-23 14:39:42 UTC
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
}



Comment 7 Germain Garand 2005-10-23 18:06:58 UTC
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?


Comment 8 Germain Garand 2005-10-23 18:12:07 UTC
Created attachment 13121 [details]
testcase box-sizing, in conjunction with button and image
Comment 9 Germain Garand 2005-10-23 18:15:31 UTC
Created attachment 13122 [details]
khtml rendering after patch for #13121
Comment 10 Charles Samuels 2007-12-31 19:35:29 UTC
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