Open Bug 558594 Opened 10 years ago Updated 5 months ago

Style for <input type="search">

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set

Tracking

()

People

(Reporter: mounir, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs, )

Details

(Keywords: dev-doc-needed, html5)

Attachments

(6 files)

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).
Summary: Style for <input style="search"> → Style for <input type="search">
You can open this page on each listed platform to see a preview of the input type search field.
Assignee: nobody → mounir.lamouri
Status: NEW → ASSIGNED
Attached patch Patch v1Splinter Review
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 ?
Attachment #439560 - Flags: review?
Attachment #439560 - Flags: review? → review?(faaborg)
Attachment #439560 - Flags: review?(faaborg) → ui-review?(faaborg)
can you attach screen shots for the ui-reviews
(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?
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.
Attached image 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.
Attachment #440182 - Flags: ui-review?(faaborg)
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 ?
Attachment #439560 - Flags: ui-review?(faaborg)
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).
(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 on attachment 440182 [details]
Screenshots

I'm confused, why are we seeing non-native text fields?
(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 ?
Here's screen shots of text fields drawn in their native style on OS X and Vista.
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 ?
Attached image 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.
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).
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
Attachment #440182 - Flags: ui-review?(faaborg) → ui-review?(limi)
(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?
(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.
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?
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.
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?
Depends on: 562219
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.
Attachment #439560 - Flags: review-
Attachment #440182 - Flags: ui-review?(limi)
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.
(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.
(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.
(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.
(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 ;)
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
Blocks: 566348
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.
(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.
(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?
(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.
Hmm, I don't think the doc for <input type='search'> styling have been done.
No longer blocks: 566348
<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.
Assignee: mounir → nobody
Duplicate of this bug: 1009619
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.
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.
Note that this is also a usability issue: on other browsers, it's easier for the user to clear search filters.
Status: ASSIGNED → NEW
Blocks: html-forms

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.

You need to log in before you can comment on or make changes to this bug.