Layout for <input type="search">
Categories
(Core :: Layout: Form Controls, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox81 | --- | fixed |
People
(Reporter: mounir, Assigned: ntim)
References
(Blocks 3 open bugs, Regressed 1 open bug, )
Details
(Keywords: dev-doc-complete, html5)
Attachments
(3 files, 5 obsolete 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).
Updated•15 years ago
|
Reporter | ||
Comment 1•14 years ago
|
||
You can open this page on each listed platform to see a preview of the input type search field.
Reporter | ||
Comment 2•14 years ago
|
||
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 ?
Reporter | ||
Updated•14 years ago
|
Reporter | ||
Updated•14 years ago
|
Comment 3•14 years ago
|
||
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?
Reporter | ||
Comment 5•14 years ago
|
||
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.
Reporter | ||
Comment 6•14 years ago
|
||
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.
Reporter | ||
Comment 7•14 years ago
|
||
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•14 years ago
|
||
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 10•14 years ago
|
||
Comment on attachment 440182 [details]
Screenshots
I'm confused, why are we seeing non-native text fields?
Reporter | ||
Comment 11•14 years ago
|
||
(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•14 years ago
|
||
Here's screen shots of text fields drawn in their native style on OS X and Vista.
Reporter | ||
Comment 13•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
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
Updated•14 years ago
|
(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?
Reporter | ||
Comment 18•14 years ago
|
||
(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?
Reporter | ||
Comment 20•14 years ago
|
||
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?
Comment 22•14 years ago
|
||
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.
Reporter | ||
Updated•14 years ago
|
Reporter | ||
Comment 23•14 years ago
|
||
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•14 years ago
|
||
(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.
Reporter | ||
Comment 25•14 years ago
|
||
(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•14 years ago
|
||
(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.
Reporter | ||
Comment 27•14 years ago
|
||
(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 ;)
Reporter | ||
Comment 28•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
(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•14 years ago
|
||
(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•14 years ago
|
||
(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.
Updated•14 years ago
|
Reporter | ||
Comment 33•14 years ago
|
||
Hmm, I don't think the doc for <input type='search'> styling have been done.
Comment 34•13 years ago
|
||
<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.
Reporter | ||
Updated•11 years ago
|
Comment 37•10 years ago
|
||
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•10 years ago
|
||
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•9 years ago
|
||
Note that this is also a usability issue: on other browsers, it's easier for the user to clear search filters.
Assignee | ||
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 40•6 years ago
|
||
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.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 41•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Comment 42•5 years ago
|
||
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 :)
Assignee | ||
Comment 43•5 years ago
|
||
Getting this off my plate for now, I might get back to it a few weeks time though.
Updated•5 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 45•4 years ago
|
||
Pushed by ntim.bugs@gmail.com: https://hg.mozilla.org/integration/autoland/rev/6b085a98f254 Implement layout for <input type='search'>. r=emilio,masayuki
Comment 46•4 years ago
|
||
bugherder |
Comment 47•4 years ago
|
||
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.
Description
•