WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
54402
REGRESSION (
r72052
): Placeholder text doesn't have the right padding for search fields on Windows
https://bugs.webkit.org/show_bug.cgi?id=54402
Summary
REGRESSION (r72052): Placeholder text doesn't have the right padding for sear...
Yair Yogev
Reported
2011-02-14 11:14:56 PST
Placeholder text in input elements is always aligned to top instead of centred, it ignores padding and alignment. It also appears too close to the left corner when using "type=search". Confirmed using Windows Safari using WebKit
r78045
inChromiumBug:
http://crbug.com/72413
Attachments
test case
(201 bytes, text/html)
2011-02-14 11:16 PST
,
Yair Yogev
no flags
Details
screenshot from Chrome before and after
(2.75 KB, image/png)
2011-02-14 11:26 PST
,
Yair Yogev
no flags
Details
test2 (text-align)
(245 bytes, text/html)
2011-02-14 23:59 PST
,
Yair Yogev
no flags
Details
patch for search field padding
(44.86 KB, patch)
2011-02-21 18:12 PST
,
Adele Peterson
mitz: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Yair Yogev
Comment 1
2011-02-14 11:16:25 PST
Created
attachment 82342
[details]
test case
Yair Yogev
Comment 2
2011-02-14 11:26:05 PST
Created
attachment 82343
[details]
screenshot from Chrome before and after
Adele Peterson
Comment 3
2011-02-14 15:36:49 PST
There's no padding in this test case. Is this Windows-specific?
Yair Yogev
Comment 4
2011-02-14 23:58:47 PST
I only tested under Windows. In the screenshot, the left side is the current results, the right part is the pre
r72052
results (which is apparently the expected results for the test case). it also ignores styles such as "text-align: center;" (see test2)
Yair Yogev
Comment 5
2011-02-14 23:59:44 PST
Created
attachment 82424
[details]
test2 (text-align)
Adele Peterson
Comment 6
2011-02-16 11:21:54 PST
I confirmed this is specific to Windows.
Adele Peterson
Comment 7
2011-02-16 14:38:52 PST
So far, we have these issues: line-height text-align and search field default padding For the line-height problem, I haven't yet been able to figure out why this would be different on Mac and Windows. We're getting the y position of the inner text element to figure out where to draw the placeholder. I don't know why that would be different.
Adele Peterson
Comment 8
2011-02-16 16:21:12 PST
For the text-align case, the placeholder is appearing in the same horizontal position as where the actual text shows up. I know that's a change from before, but that doesn't seem as bad as the other issues.
Seth Archer Brown
Comment 9
2011-02-18 20:14:42 PST
This problem is not specific to windows I've verified it in OS X .
Adele Peterson
Comment 10
2011-02-18 23:14:00 PST
Perhaps we should break this out into separate bugs. I actually think the text-align behavior is right since the placeholder now shows up where the text will actually show up. So maybe we should use this bug for the search field padding (which, I think should be fixed by considering results/cancel padding + margin in the clientPaddingLeft/Right methods), and then we should file a new bug for the line-height bug. Both of those do not reproduce on Mac for me.
Adele Peterson
Comment 11
2011-02-18 23:29:17 PST
I take it back - the line-height bug exists on Mac too. I'll file another bug for that.
Adele Peterson
Comment 12
2011-02-18 23:32:37 PST
https://bugs.webkit.org/show_bug.cgi?id=54797
REGRESSION (
r72052
): Placeholder text isn't centered with a large line-height
Yair Yogev
Comment 13
2011-02-19 01:02:27 PST
(In reply to
comment #10
)
> I actually think the text-align behavior is right since the placeholder now shows up where the text will actually show up.
i'm confused. how can the "text-align" behavior be correct if "input::-webkit-input-placeholder" is explicitly used? you can replace it with "input:-moz-placeholder" to see how it's supposed to look in FF (the same way it did before
r72052
in WebKit)
Yair Yogev
Comment 14
2011-02-19 01:04:01 PST
correction for the last part: (the same way "input::-webkit-input-placeholder" did before
r72052
in WebKit)
Adele Peterson
Comment 15
2011-02-19 08:41:05 PST
We don't support all styles on the input element, and it doesn't make sense to respect text-align in the placeholder, but not the actual text.
Yair Yogev
Comment 16
2011-02-19 08:52:14 PST
(In reply to
comment #8
)
> For the text-align case, the placeholder is appearing in the same horizontal position as where the actual text shows up.
i can easily add "style="text-align: right"" to the input tag, in that case the placeholder will still be aligned to the left (despite webkit-input-placeholder) but after clicking on the box any text entered will be right aligned... am i missing anything? i can think of plenty of reasons to use a deferent alignment for the placeholder (probably since i speak an RTL language)
Adele Peterson
Comment 17
2011-02-19 09:02:53 PST
For RTL languages, direction:rtl will work just fine.
Yair Yogev
Comment 18
2011-02-19 09:11:16 PST
true, but RTL directionality and alignment is not the same thing. not a good example anyway, it doesn't have to be right alignment: <input type="text" placeholder="blabla" style="text-align: center" /> is another example where according to my tests the placeholder will be left aligned but the text centered. apparently "text-align" for the placeholder has a use or it wouldn't have been reported in the chromium bugtracker
Adele Peterson
Comment 19
2011-02-19 10:07:18 PST
Please file a new bug for text-align. I don't plan on addressing that issue at the same time as these other, more serious, issues.
Yair Yogev
Comment 20
2011-02-19 15:38:48 PST
filed
https://bugs.webkit.org/show_bug.cgi?id=54814
REGRESSION (
r72052
): Placeholder text ignores text-align
Adele Peterson
Comment 21
2011-02-21 18:12:30 PST
Created
attachment 83251
[details]
patch for search field padding
Adele Peterson
Comment 22
2011-02-21 20:56:30 PST
Committed revision 79284.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug