Add new HTML5 FAPI element: search

+++ b/includes/form.incundefined
@@ -3635,8 +3635,48 @@ function theme_textfield($variables) {
+  element_set_attributes($element, array('type', 'id', 'name', 'value', 'size', 'maxlength'));

Missing #placeholder ?

and more ??
http://www.w3.org/TR/html-markup/input.search.html#input.search

Powered by Dreditor.

+++ b/includes/form.inc
@@ -3635,8 +3635,48 @@ function theme_textfield($variables) {
+  _form_set_class($element, array('form-search', 'form-text'));

I don't think we should add the .form-text class here. Such double-classes complicate theming/styling.

Powered by Dreditor.

I think we need it.

is it array rendering sequentially??
it should

+  _form_set_class($element, array('form-text', 'form-search'));

Do we want to add placeholder on this patch?

There's already an issue for placeholder.

Go, testbot, go!

Ok. Rebased and fixed the half-trivial merge conflicts. Let's see how this does in testing.

Note that it looks like this in Bartik, so I guess the CSS needs to be fixed, too:

http://css-tricks.com/webkit-html5-search-inputs/ might or might not be helpful for someone trying to fix the CSS. It also shows that there are quiet some limitations for how this element can be styled.

This one should fix the test.

It did. Thanks. Now back to needs work for fixing the CSS?

I'll see what I can do here this sprint.

Rebased because #1174630: Add new HTML5 FAPI element: url and #1174620: Add new HTML5 FAPI element: email got in :)
Needs review for the testbot.

And needs work for jacine ;)

Sorry for taking so long to get to this. Here's a re-rolled patch that includes fixes for Bartik and some screenshots. I tested in Chrome, Firefox, IE8/9 and Opera and it looks consistent across all of them. Hopefully it's what you guys were looking for.

This looks good, personally I don't like the -webkit-appearance: textfield :-p but is only in the Bartik css so that's cool :)

Wow! Excellent! Thank you. I didn't even believe that could be done.

Three questions:

• Are there reasons using input[type="search"] vs .form-type-search input?

• +#block-search-form input[type="search"]::-webkit-search-decoration {
  +  display: none;
  +}

  Does this hide the X to clear the input in some browsers? If so: Should we really be doing that?

• Should we style all search inputs or only those in #search-form and #block-search-form?

I've also asked me this and why we remove the input X as this seams the only reason for using the search element. Why is the apperance set to textfield in bartic only and not the other themes and how to repro the issue. There is no screenshot how it looks without the change.

It may also be useful to use results=5 and autosave=uniquekey on search fields.

Hey guys.

In response to #29:

1. input[type="search"] is shorter. The other example is IE6 style CSS IMO. Not a big deal either way though. :)

2. No, no, no. It doesn't remove the X. That's a different pseudo element: input[type="search"]::-webkit-search-cancel-button. Did you guys look at the Chrome screenshot? The X is clearly there. This pseudo element just resets some default padding that Webkit browsers provide. It only affects Webkit and is perfectly safe. See Formalize and Normalize libraries, which set them as global resets.

3. You guys told me you wanted to match what Bartik originally looked like and that you needed help, so here I am. LOL. As for whether to style it globally, I dunno. I'd rather leave that up to Bartik maintainers. All I'm trying to do here is prevent a visual regression from D7. Anyway, it's unfair to hold up getting the search element in right now because of Bartik, so I am leaning toward committing this, and opening a follow up to give the Bartik maintainers the option to do something else, if they see fit.

#30

- Before and after is attached. Note, it's only a webkit thing and it's not a bug persay, just how webkit styles it, and it looks crappy in bartik because of the way bartik styles the search form.
- Regarding the results and autosave attributes, I don't think we should put those in by default, but I think it might make sense to add them as properties. What does everyone else think?

Oops. Now before and afters are attached.

#29:
1. Excellent.
2. Excellent. (Yep, I did look at the screenshots, just asked to be sure that doesn't hide it in other browsers.)
3. Excellent ;)

#30:
Actually we did have before screenshots already. No problem at all.
Since "we want the search element" is pretty clear, but "should we add properties for result and autosave, or leave it attributes, and/or give them default values, and/or use default values for the search module" needs discussion, I'd say that'd be a follow up issue. No?

Not to forget: Thank you, Jacine, again! And indeed: We only needed Bartik. For Seven and Stark it looks exactly the same before and after. (Except for the X).

Ok, awesome. It seems like we're all in agreement.

I'm updating the Issue summary now.

Updated issue summary.

Thanks folks. Committed/pushed to 8.x.

Yay! Should we add a note to http://drupal.org/node/1315186?

Yes :)

Alright, done ;)