Bug 56768 - Placeholder functionality should trim the input value on blur.
Summary: Placeholder functionality should trim the input value on blur.
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 523.x (Safari 3)
Hardware: All All
: P4 Enhancement
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-21 13:54 PDT by Benjamin Bertrand
Modified: 2011-12-06 17:24 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Bertrand 2011-03-21 13:54:28 PDT
If you type " " one space and Tab off the input field, then the placeholder value is not redrawn. 
If you paste line-breaks or Tabs into an input field, the placeholder value is not redrawn when the input loses focus. 

I cannot think of an edge case where an input or search box with placeholder text would want to accept extra whitespace characters as part of the input or query. 

After a user types, pastes or otherwise inputs their characters into an INPUT tag with a "placeholder" attribute, the placeholder functionality should trim leading and trailing whitespace before comparing it to the placeholder value.
Comment 1 Benjamin Bertrand 2011-03-21 13:57:09 PDT
Edit: change Priority to P4, as it's a UX issue.
Comment 2 Kent Tamura 2011-12-05 22:07:57 PST
Does this issue still exist?
Comment 3 Benjamin Bertrand 2011-12-06 10:04:03 PST
Yes, the issue still exists. 

0. What is the explicit placeholder functionality? The HTML5 spec is vague on how to the implement the functionality. The spec does say that the placeholder value _itself_ cannot contain line-breaks, tabs or restricted/whitespace characters. I'm not referring to that. I am referring to the rendering of INPUT tags with an attribute of PLACEHOLDER. 

1. Browsers should validate the user character input by trimming leading and trailing whitespace BEFORE checking if the input is (not) equal to the placeholder value. 

Front-end devs have done this with JavaScript(JS) for years, and more than a few omit this needed step. 

To support this position: 
2.a) This validation step is trivial for a compiled browser. It could be done with a regular expression. 
2.b) It would improve UX greatly: no empty strings, control chars or other trivial whitespace would make it into an HTML Request when submitted via INPUT with a PLACEHOLDER. 
2.c) While server-side systems must handle empty or whitespace character input, this will head-off many such things. 
2.d) Who searches for whitespace? What are their motives? Unless the user has a specific code-based inquiry, there's almost no reason to search for whitespace. And coders are going to have tools that they use that for (grep, etc.) 
2.e) It removes the need for developers to re-implement their own JS override for this oft-overlooked detail in placeholder functionality. 

My point being, if you are going to implement a placeholder, then implement it right. Currently, the PLACEHOLDER attribute implementation is incomplete without trimming. 

Latest versions of Chrome and Safari both display the same behavior; they do not validate the input.
Comment 4 Kent Tamura 2011-12-06 17:24:54 PST
Thanks.  Probably I understand the issue.

Steps to reproduce the problem:
0. A page has an <input> with a placeholder attribute
1. A user types whitespace characters into it
2. The <input> loses focus.

Current behavior:
The placeholder is not shown because the <input> has the whitespace value.

Benjamin's expectation:
The placeholder should be shown because the whitespace value is meaningless.


The current standard explicitly says "when the element's value is the empty string ..."
So we can't change the current behavior of WebKit.  You should contact to WHATWG or W3C HTML WG.