Add support for #placeholder to relevant Field API widgets

Added to http://drupal.org/node/1183606.

sub.

sub

$form['field'] = array(
 '#attributes' => array(
    'placeholder' => 'your text here',
  ),
);

Although i imagine #placeholder support would come equipped with backwards compatibility JS support.

Should have it in Form API before we stick the support for it into Field API: #1174694: Allow FAPI usage of the placeholder attribute.

Oh, it was committed? Well then.

Placeholder support is already in form api. It was probably the 1st html5 patch to get in, a while back.

This issue is about adding placeholder support in the field api aka when someone creates a new field, and you get the option to add labels, default text, and now also placeholder :)

Oh and no, backwards compatibility is not included. Even thought is probably the simplest fallback ever.

But so far none of the html5 feature have had backwards compatibility added to them.Anyways this should be discuss in a separate issue.

- no placeholder
- instance label as #placeholder rather than regular #title
- custom text as #placeholder rather than or in addition to instance label as regular #title

I think that this can be simplified to:

- No placeholder (default)
- Instance label (Use label as placeholder)
- Custom text

How do we communicate, through the UI, what a 'Placeholder' is, and what it does?

It should be clear to everyone that placeholder is not in anyway a replacement for title/label. Placeholder is a completely different attribute and should in no way have anything to do with the title/label.

So what should be expected in this patch is another text field, with the Title of "Placeholder". Now the description can be for now be what's explain in the actual spec which does a good job -- "The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry. A hint could be a sample value or a brief description of the expected format. ".

This way the user chooses what to put in the placeholder we don't need to have any default or anything like that. The default is nothing if nothing is entered :)

Here is a first try to implement it for the text field type. Would it be done like that for the other field types, as well?

Thanks for looking at it. Yeah ... I suspected something like that, so I only did it for text, first. Rather like this?

So ... here's the same thing for all the relevant widgets.

@yched: I think #13 makes a legitimate point about that, though.

Reroll with the new default settings.

Reroll to make this apply after #1540174: Some attributes not allowed for the new HTML5 input elements.

Bumping and tagging for myself :)

#23: 1241938-field-placeholder-23.patch queued for re-testing.

This is so cool, let's get this in asap! Patch (+tests) takes the approach so widget plugins only need to add the 'placeholder' setting to their settings and it will be available automatically on the field instance settings screens and on the entity forms. I think this is a nice DX and also makes sure we don't have to copy the same $placeholder element form to every widget form of every field type. It *could* be a helper function of course, but I really like this approach.

I also agree with #13 as well. Let's make this initially easy and not confusing for users.

And some screenshots.

@ericduran Hope I didn't make you waste valuable time, I initially read the date wrong - I though you assigned it 4 months ago :)

What is in 'settings' is the playground of each widget type

Hmm I agree that it might be annoying and even bad DX that a potential key in your settings is reserved. But I don't like the code duplication either. Hmm, hmmm, let me think about this. Food first, I need to eat something today as well :)

So I'd suggest controlling it by a boolean $supportsPlaceholders property in WidgetInterface.

(while eating) Not immediately a big fan of that. Some stuff then lives in annotations, other as properties. It's better DX in a way than to know all allowed properties in annotations, but it feels so schizofrenic to me. If we introduce properties, it then feels like we should remove 'default_value' as well, unless that's the plan :) (eating further)

I'd personally be fine with just putting 'support_placeholders' in the annotations for now

(almost done eating). I'm almost thinking to let this live in settings but let every widget handle itself. This would drop (kind of ugly) following code:

+  // Add default placeholder element if exposed by the widget definition.
+  if (isset($instance['widget']['settings']['placeholder'])) {

This way, widgets are fully responsible like you also suggested. Also, we're in 'trouble' in case of the 'Link' field that prints 2 text fields in its widget.
This patch then isn't an (small) API change anymore and probably much easier to get in and no hassle afterwards to refactor or whatever :)

And there we go :)

Fixing tests.

This looks great. I agree it makes more sense to rather get this functionality in now. We can think about potential ways to automate/harmonize it in a separate follow-up issue.

I'd RTBC this patch, but it looks like Link field is missing?

@sun two placeholder fields then for the title and the link ?

Also on link, screenshot attached as well :)

Thanks!

And I guess that Link field widget pretty much clarifies why an automated/harmonized solution for all widgets will be hard to achieve ;)

Awesome, let's get this in! :)

Crap, you're right, I keep confusing those two so heavily. Attached. Gimme another hour with tests for every widget!

That even didn't take an hour .. :)

Looks even better! :) Thanks!

Okidoki :)

+1 to RTBC
PS:
Suppose this setting should be a part of each text input like format for textarea. Let's discus this in follow-ups, probably we need a change on element level

Wow, what a lovely little patch! :D

Committed and pushed to 8.x. Thanks!

Wow, that was crazy fast. I blink and it was done! :)