558594 - Layout for <input type="search">

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, task)

Description

[Mounir Lamouri (:mounir)]

HTML5 specs say input element in search type should be showed differently.
A discussion has begun in bug 456229: we may want to follow the style of the current searchbox (a magnifying glass at the left of the field).

Comment 1

[Mounir Lamouri (:mounir)]

Attachment: Input type search preview

You can open this page on each listed platform to see a preview of the input type search field.

Comment 2

[Mounir Lamouri (:mounir)]

Attachment: Patch v1

I see one negative aspect with this patch: i can't set a right margin for the background so if the icon has no blank pixel it may not really beautiful. Actually, it mostly concern GTK theme because the icon depends on the user theme.
If that's really disappointing, we would be able to use 'calc(100% - Xpx)' when implemented.

On MacOS X we can't use -moz-appearance: searchfield (with rounded corner) because it's does not support 'height' (it is scaling !).

What is your opinion Alex ?

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

can you attach screen shots for the ui-reviews

Comment 4

[d]

(In reply to comment #2)
> Created an attachment (id=439560) [details]
> On MacOS X we can't use -moz-appearance: searchfield (with rounded corner)
> because it's does not support 'height' (it is scaling !).

How has Webkit solved this?

Comment 5

[Mounir Lamouri (:mounir)]

Attachment: Safari (MacOS) input search

On MacOS, Webkit is styling the input with round corners but you can't resize the input... which is IMO a really bad choice.
On every platforms, there is a cancel button inside the input to allow the user to clear the field.
See attached screenshot.

Comment 6

[Mounir Lamouri (:mounir)]

Attachment: Screenshots

MacOS, Windows (Aero) and GTK screenshot.
The GTK style is using the theme search icon so it will depend on the user theme. This screenshot has been taken with the last Ubuntu theme.
Non-aero windows will only use another icon AFAIK.

I wrote some text into the MacOS field to demonstrate that the text doesn't show on top of the icon. The behavior is the same on all platforms.

Comment 7

[Mounir Lamouri (:mounir)]

Comment on attachment 439560 [details] [diff] [review]
Patch v1

Alex, I'm removing the ui-review flag on this patch. Should you review this patch or I should ask someone else ? In this case, who ?

Comment 8

[philippe (part-time)]

1. The problem with your approach is that you completely lose the appearance of native widget (on OS X, the Aqua look). Looking at those search fields, it looks like a throw back to the mozilla 1.0 years.

2. Everywhere on OS X, search fields have the magnifier on the left (and the 'clear button' on the right).

( I see what you mean about the -moz-appearance: searchfield; it can't really be styled by page authors; but that is currently the same issue on WebKit's side).

Comment 9

[d]

(In reply to comment #8)
> 1. The problem with your approach is that you completely lose the appearance of
> native widget (on OS X, the Aqua look). Looking at those search fields, it
> looks like a throw back to the mozilla 1.0 years.
> 
> 2. Everywhere on OS X, search fields have the magnifier on the left (and the
> 'clear button' on the right).
> 
> ( I see what you mean about the -moz-appearance: searchfield; it can't really
> be styled by page authors; but that is currently the same issue on WebKit's
> side).

I very much agree with you on both your points, but, I don't think the issue is that type="search" fields can't be styled, because I think most properties will work as normal (please correct me if I'm wrong, I have no experience of "-moz-apperance: searchfield;" and can't try it right now). The issue here is that it won't look good if it gets scaled, but... hm, I was thinking about the resizer, but we don't have that on inputs. Are you thinking of properties like height, width and -moz-transform: scale()?

Those could indeed be an issue, but perhaps "-moz-apperance: searchfield;" could be redone to scale properly (is it just an image right now?), although the default style remains the one we have now?

Comment 10

[Alex Faaborg [:faaborg] (Firefox UX)]

Comment on attachment 440182 [details]
Screenshots

I'm confused, why are we seeing non-native text fields?

Comment 11

[Mounir Lamouri (:mounir)]

(In reply to comment #8)
> 1. The problem with your approach is that you completely lose the appearance of
> native widget (on OS X, the Aqua look). Looking at those search fields, it
> looks like a throw back to the mozilla 1.0 years.

I'm probably influenced by my platform (GTK) which doesn't really have a native search field (or not used).
I agree there is one on MacOS but it is not really doable at the moment.
For Windows, I have no idea. I will check that tomorrow.

> 2. Everywhere on OS X, search fields have the magnifier on the left (and the
> 'clear button' on the right).

Having the magnifier on the left would be better for a Mac user ?

> ( I see what you mean about the -moz-appearance: searchfield; it can't really
> be styled by page authors; but that is currently the same issue on WebKit's
> side).

Honestly, I do not think it is a good idea to rely on this.
As said Magne (comment 9), we could change |-moz-appearance: searchfield| but I think it would be good for a follow-up.

(In reply to comment #10)
> (From update of attachment 440182 [details])
> I'm confused, why are we seeing non-native text fields?

What do you mean ?

Comment 12

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Example of native text fields

Here's screen shots of text fields drawn in their native style on OS X and Vista.

Comment 13

[Mounir Lamouri (:mounir)]

Indeed, it looks like there is a difference. I will check that tomorrow (I've no Windows/MacOS system).
Except this issue, what's your opinion about the styles ? Do you want me to test something like the magnifier on the left on MacOS ?

Comment 14

[philippe (part-time)]

Attachment: search vs native, OS X

a native text field vs the proposed style for input type="search"

> (In reply to comment #8)
> > 1. The problem with your approach is that you completely lose the appearance of
> > native widget (on OS X, the Aqua look). Looking at those search fields, it
> > looks like a throw back to the mozilla 1.0 years.
> 
> I'm probably influenced by my platform (GTK) which doesn't really have a native
> search field (or not used).
> I agree there is one on MacOS but it is not really doable at the moment.

It goes way beyond the existence or not of a native 'search field'. Look at the borders of your widget, compared to the default appearance of a text field.

The correct way to fix this bug is to fix '-moz-appearance: searchfield', imho.

Comment 15

[Alex Faaborg [:faaborg] (Firefox UX)]

Yeah, we will likely want the magnifier on the left on OS X, and rounded
corners.  Each platform should have the close button to cancel the search,
similar to the XUL search widget.  On platforms where the magnifying glass is
on the right, the cancel control replaces the magnifying glass (again identical
to the XUL search widget).

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

As long as the appearance and behavior is identical to '-moz-appearance: searchfield' I don't have an opinion on the specific implementation.  In terms of code review, your set of potential reviewers is the owner and peers for the Layout Engine: http://www.mozilla.org/about/owners.html

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(In reply to comment #14)
> The correct way to fix this bug is to fix '-moz-appearance: searchfield', imho.

I agree with this. Mounir, do you think you'd be able to do this?

Comment 18

[Mounir Lamouri (:mounir)]

(In reply to comment #17)
> (In reply to comment #14)
> > The correct way to fix this bug is to fix '-moz-appearance: searchfield', imho.
> 
> I agree with this. Mounir, do you think you'd be able to do this?

Unfortunately as it is a MacOS widget, it's written in Objective-C AFAICT and I do not have a Mac. Even if I can get one in the office for this work, I'm clearly not the best person to do that.
Maybe we could ask to the person who push this ? According to hg blame it's 'mstange'.

By the way, for the 'cancel button' I think it could be a nice feature but it is going to make the style much more complicated... Actually, I'm wondering if there would be a way to do that without creating a new layout for the search field.

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

But the whole point of <input type=search> is to get OS look and feel for styling. It doesn't provide any other functionality, no?

Comment 20

[Mounir Lamouri (:mounir)]

Yes, I'm not saying we shouldn't do that. Actually, the real question behind this comment was: should we think about a simple first step to have the field styled or do we want to directly the requested style ? I'm wondering what is the policy in this situation.

Comment 21

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

My gut reaction is that if we can't style this well enough that there is a reason for sites to use it, then we shouldn't bother with type=search for now. There's plenty of other HTML5 form controls.

However that still leaves figuring out how well is "well enough".

I guess I don't think we need to get perfect rendering. How are we doing the rendering for the search box next to the url bar? That doesn't appear to use native rendering, but has something that is close enough.

Can we replicate that?

Comment 22

[Dão Gottwald [:dao]]

Comment on attachment 439560 [details] [diff] [review]
Patch v1

I'm pretty sure this doesn't work at all. toolkit/themes/*/global/textbox.css styles XUL textboxes -- the default namespace is the XUL one, too, so input[type=search] wouldn't even match HTML elements even if the stylesheet applied to web content.

Comment 23

[Mounir Lamouri (:mounir)]

So, we could use "-moz-appearance: searchfield" for Windows (bug 559747) and MacOS and add the icons at the required position ?
For MacOS, the field will look ugly if resized but we can consider it's not common enough. In addition, Safari is just not resizing the field if it's resized. I think we should fix it in a follow-up.

By the way, for information, as far as I've checked, the only style other browsers are applying to the search field is round corner on MacOS. There is no icon no cancel/erase button.

Comment 24

[d]

(In reply to comment #23)
> By the way, for information, as far as I've checked, the only style other
> browsers are applying to the search field is round corner on MacOS. There is no
> icon no cancel/erase button.

The cancel/erase button appears in Mac OS X itself, but, while being convenient at times, it is not necessary in any way.

Comment 25

[Mounir Lamouri (:mounir)]

(In reply to comment #24)
> (In reply to comment #23)
> > By the way, for information, as far as I've checked, the only style other
> > browsers are applying to the search field is round corner on MacOS. There is no
> > icon no cancel/erase button.
> 
> The cancel/erase button appears in Mac OS X itself, but, while being convenient
> at times, it is not necessary in any way.

Indeed, I don't think this button is mandatory but my comment was too underline that even if the cancel/erase button is (as I see it) quite MacOS'ish, Safari do not implement it in the search input field.

Comment 26

[philippe (part-time)]

(In reply to comment #25)

> Indeed, I don't think this button is mandatory but my comment was too underline
> that even if the cancel/erase button is (as I see it) quite MacOS'ish, Safari
> do not implement it in the search input field.

That is not correct. The cancel / clear button is always there, but only visible when the user has entered some text in the search field. That is both in any search field part of OS X and the html5 input[type="search"].

And note: it is more a 'clear' button than a 'cancel' button.

Comment 27

[Mounir Lamouri (:mounir)]

(In reply to comment #26)
> (In reply to comment #25)
> 
> > Indeed, I don't think this button is mandatory but my comment was too underline
> > that even if the cancel/erase button is (as I see it) quite MacOS'ish, Safari
> > do not implement it in the search input field.
> 
> That is not correct. The cancel / clear button is always there, but only
> visible when the user has entered some text in the search field. That is both
> in any search field part of OS X and the html5 input[type="search"].
> 
> And note: it is more a 'clear' button than a 'cancel' button.

Oups, indeed.
But the magnetizing glass isn't present... even when there is some text in the field ;)

Comment 28

[Mounir Lamouri (:mounir)]

mstange confirmed me there are three sizes available for the MacOS widget so it can't be sized to the wanted size without stretching it.

Related code:
http://mxr.mozilla.org/mozilla-central/source/widget/src/cocoa/nsNativeThemeCocoa.mm#631

Comment 29

[d]

Isn't there a possibility that we could create a style looking exactly, or at least very similar to the standard Mac OS X fields with border-radius and (inset) box-shadow? In that case, it would be fully resizeable to any size (although our standard size should match the real Mac OS X fields, I suppose), being very style-able for page authors and we would be able to control it more easily.

Comment 30

[Dão Gottwald [:dao]]

(In reply to comment #29)
> Isn't there a possibility that we could create a style looking exactly, or at
> least very similar to the standard Mac OS X fields with border-radius and
> (inset) box-shadow?

No, it needs to be done through -moz-appearance, otherwise it would fail when authors apply custom CSS.

Comment 31

[d]

(In reply to comment #30)
> (In reply to comment #29)
> > Isn't there a possibility that we could create a style looking exactly, or at
> > least very similar to the standard Mac OS X fields with border-radius and
> > (inset) box-shadow?
> 
> No, it needs to be done through -moz-appearance, otherwise it would fail when
> authors apply custom CSS.

I am not familiar with -moz-appearance, but aren't the authors custom styles just supposed to override our CSS? What happens with and without -moz-apperance? And finally, does -moz-appearance have to be an image, or can it be certain CSS styles instead?

Comment 32

[Dão Gottwald [:dao]]

(In reply to comment #31)
> I am not familiar with -moz-appearance, but aren't the authors custom styles
> just supposed to override our CSS? What happens with and without
> -moz-apperance?

Custom styles such as a background color or a border are expected to drop the native appearance entirely; no shadow or border radius should remain.

> And finally, does -moz-appearance have to be an image, or can
> it be certain CSS styles instead?

-moz-appearance values need to be implemented in widget code, but I don't know the capabilities there.

Comment 33

[Mounir Lamouri (:mounir)]

Hmm, I don't think the doc for <input type='search'> styling have been done.

Comment 34

[Steffen Wilberg]

<input type="search"> should definitely show a clear button. Chrome and Safari already do this, see http://html5tutorial.info/html5-search.php.

The xul textbox type="search" does this as well, see e.g. Firefox Options - Applications.

Comment 37

[Florens Verschelde :fvsch]

Just adding that IE10 has a clear button that appears on the right (and possibly on the left in rtl) when the input is not empty.

Comment 38

[Florens Verschelde :fvsch]

Also, as a web author, let me add that Safari/Chrome’s default styling for <input type="search"> is a pain. Many front-end devs use type=search to get the right keyboard on mobile devices, and use Webkit-specific CSS to avoid the corresponding styling:

input[type="search"] {
  -webkit-appearance: textfield;
}

input[type="search"]::-webkit-search-decoration,
input[type="search"]::-webkit-search-cancel-button,
input[type="search"]::-webkit-search-results-button,
input[type="search"]::-webkit-search-results-decoration {
  display: none;
}

It’s unclear whether adding to those often necessary vendor-specific resets would be wise.

Adding default styling for <input type="search"> might break the look and feel of many websites written in the past few years, which use <input type="search"> with the WebKit-specific resets and probably won’t be updated to accommodate Gecko.

Comment 39

[Zach Lym]

Note that this is also a usability issue: on other browsers, it's easier for the user to clear search filters.

Comment 40

[Tim Nguyen :ntim]

See bug 635240 for how the spin buttons in <input type=number> are implemented (the code has probably changed a bit now), the same approach could potentially be used to implement the clear button (if it's wanted).

Implementing the clear button would be nice in the de-xbl perspective, to replace the textbox[type=search] binding in a straightforward way, but not necessary as a custom element could also work.

Comment 41

[Tim Nguyen :ntim]

Attachment: Bug 558594 - Implement layout for <input type='search'>.

Comment 42

[Tim Nguyen :ntim]

Attachment: Screencast of patch

The current patch pretty matches Chrome and Safari in terms of UX. There's a clear button that only appears when a value is typed, which you can click to clear the value.

As for the implementation, there's a lot of copy paste from input type=number :)

Comment 43

[Tim Nguyen :ntim]

Getting this off my plate for now, I might get back to it a few weeks time though.

Comment 45

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6b085a98f254
Implement layout for <input type='search'>. r=emilio,masayuki

Comment 46

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/6b085a98f254

Comment 47

[Chris Mills [:cmills]]

MDN Documentation completed for now. This is behind a flag, so for now, Rachel has just added an entry to https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features#HTML about it.