Re: [whatwg] Safari-compatible input type=search
Binoculars are more appropriate because they can be used to look around whereas a magnifying glass cannot. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christoph Päper Sent: Tuesday, September 30, 2008 11:55 PM To: WHAT working group Subject: Re: [whatwg] Safari-compatible input type=search The magnifying glass was a particularly poor choice by Apple[1], because icons featuring one usually represent zooming (in). Binoculars are (for some reason) more common as symbols for searches. Eyes and spectacles OTOH most often represent visibility.
Re: [whatwg] Safari-compatible input type=search
On Tue, Sep 30, 2008 at 3:46 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 2:55 PM, Christoph Päper wrote: Anyhow, the appearance of this or other types of |input| should not be specified by HTML5 / WF2+. Of course browsers could choose what the icon should look like; Would it be desirable to allow the icon to be specified in css? -- Andy Lyttle
Re: [whatwg] Safari-compatible input type=search
Would it be desirable to allow the icon to be specified in css? That's up to the author/user agent, and currently you can have a small icon in the background of an edit field with regular css. On Wed, Oct 1, 2008 at 8:29 AM, Garrett Smith [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 3:46 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 2:55 PM, Christoph Päper wrote: Anyhow, the appearance of this or other types of |input| should not be specified by HTML5 / WF2+. Of course browsers could choose what the icon should look like; Would it be desirable to allow the icon to be specified in css? -- Andy Lyttle
Re: [whatwg] Safari-compatible input type=search
On Sep 30, 2008, at 7:18 AM, Kristof Zelechovski wrote: How can the Web designer know how many recent search terms the user would like to keep handy at the search box? The same way the web designer knows anything else: taking an educated guess at what would be most appropriate for their users. Personally, I would have done it a little differently and called this property something other than results, but Apple has already done it, and there is value in staying compatible with them. What if autosave strings clash, or get deliberately stepped upon? You can avoid clashing by using reverse-FQDN notation, e.g. autosave=com.phroggy.weblog.search, or using your company name or other trademark. It is OK for them to be deliberately stepped upon - this is actually a design feature. If you want to make a search field on your site that searches my site (submitting to the same CGI that my form submits to), you can specify the same autosave string that I use, and search history will be shared between both forms. There is no security problem, because the search history list is not accessible to you (or me) unless the user explicitly chooses an item from it (which you can't distinguish from pasting in a string from elsewhere). I think it is a user preference + browser QoI and Web sites should not try to outsmart it. The whole point of this is to provide sensible markup that the browser can use to figure out the best way to handle it. Browsers aren't obligated to handle search history at all if the user doesn't want them to. Using input type=search gives users MORE choice about how the browser should behave, by providing more information about what the web designer was trying to do, instead of using CSS and JavaScript hacks to implement a specific behavior that may not be desirable to some users. Marking a box as a search box is already there (ISINDEX, deprecated). Nobody uses that, and it's not a form element. We could resurrect it, but I don't see a compelling reason to do so. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Safari-compatible input type=search
On Sep 30, 2008, at 7:40 AM, Nils Dagsson Moskopp wrote: I assume that this should be based on the search elements ID attribute, am I right ? Because common UA behaviour already is to cache entries (based on ID) ... so what unsolved problem is solved there ? If I have a form on my site, using a particular autosave string for a search field, you can create a form on your site that submits to the same CGI URL, with a search field that uses the same autosave string, and browsers will know that they should share the search history between both forms. This is not a security problem, because the history list is not accessible to you (or me). I don't see this feature getting a lot of use, but Apple has already implemented it, and I don't see a compelling reason not to support it. And who knows, if it's supported, maybe someone will think of some clever use for it that I haven't thought of, that couldn't have been done well without this feature. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Safari-compatible input type=search
I am not against INPUT[type=search]; I am against INPUT[results=10] because I cannot see how it can be reasonably preset. Is this control for simple search only or is it designed to be used in an advanced search interface? Should it be unique within a form? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Lyttle Sent: Tuesday, September 30, 2008 7:03 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Safari-compatible input type=search On Sep 30, 2008, at 7:18 AM, Kristof Zelechovski wrote: How can the Web designer know how many recent search terms the user would like to keep handy at the search box? The same way the web designer knows anything else: taking an educated guess at what would be most appropriate for their users. Personally, I would have done it a little differently and called this property something other than results, but Apple has already done it, and there is value in staying compatible with them. What if autosave strings clash, or get deliberately stepped upon? You can avoid clashing by using reverse-FQDN notation, e.g. autosave=com.phroggy.weblog.search, or using your company name or other trademark. It is OK for them to be deliberately stepped upon - this is actually a design feature. If you want to make a search field on your site that searches my site (submitting to the same CGI that my form submits to), you can specify the same autosave string that I use, and search history will be shared between both forms. There is no security problem, because the search history list is not accessible to you (or me) unless the user explicitly chooses an item from it (which you can't distinguish from pasting in a string from elsewhere). I think it is a user preference + browser QoI and Web sites should not try to outsmart it. The whole point of this is to provide sensible markup that the browser can use to figure out the best way to handle it. Browsers aren't obligated to handle search history at all if the user doesn't want them to. Using input type=search gives users MORE choice about how the browser should behave, by providing more information about what the web designer was trying to do, instead of using CSS and JavaScript hacks to implement a specific behavior that may not be desirable to some users. Marking a box as a search box is already there (ISINDEX, deprecated). Nobody uses that, and it's not a form element. We could resurrect it, but I don't see a compelling reason to do so. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Safari-compatible input type=search
On Sep 30, 2008, at 10:23 AM, Kristof Zelechovski wrote: I am not against INPUT[type=search]; I am against INPUT[results=10] because I cannot see how it can be reasonably preset. Yeah, that's weird. I think if I designed it myself, I would have made the presence of autosave (instead of results) trigger the magnifying glass icon, used a sensible default for the number of items in the search history (maybe 10 or 20), used something like historylength to override it, and make setting historylength=0 disable the menu (leaving the icon). Something like that. But that's not how Apple did it, and we should be compatible with them. Is this control for simple search only or is it designed to be used in an advanced search interface? Should it be unique within a form? Excellent question! I imagine it should be unique within a form. Whether it's appropriate for an advanced search interface would depend on the interface; if there's one input that's an obvious choice for type=search then go ahead and use it, otherwise it might be better to stick with type=text. Hopefully someone more qualified than I can provide a better answer. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Safari-compatible input type=search
On Tue, 30 Sep 2008 12:40:23 +0100, Andy Lyttle [EMAIL PROTECTED] wrote: I would like Apple's input type=search adopted as an official standard, maintaining Safari compatibility. Comments? I like type=search. Special search box style is used throughout Mac OS X and Mac-centric sites try to fake it with borderless inputs that often end up looking broken. Windows has now a standard search box look too, so type=search would be good for intuitively looking search boxes across platforms. I'm in favor of placeholder on input type=search. It may be a bad UI, but it is used very often regardless. Standarizing it at least gives more control to UAs and frees authors from writing potentially buggy scripts (I haven't figured out yet how to write one that's not annoying on Opera Mini). I suggest ignoring onsearch and incremental attributes. They can be replaced with combination of oninput and onchange. I also don't like results and autosave. They're a bit confusing (if autosave=yes became popular, it would cause a mess). It can be abused (autosave=google's + script that puts site's own keywords just before user submits search). Such things are best controlled by browsers/users. To disable autosave authors could use autocomplete=off. -- regards, Kornel Lesinski
Re: [whatwg] Safari-compatible input type=search
Andy Lyttle: results - if present, shows a little magnifying glass icon, which helps to visually identify the field as a search box The magnifying glass was a particularly poor choice by Apple[1], because icons featuring one usually represent zooming (in). Binoculars are (for some reason) more common as symbols for searches. Eyes and spectacles OTOH most often represent visibility. Anyhow, the appearance of this or other types of |input| should not be specified by HTML5 / WF2+. results=10 - the magnifying glass functions as a drop-down menu containing a history of the last (whatever number) search terms I'm not sure, but I think it would be a first to have a binary attribute that is overloaded to alternatively also accept an integer as its value. Therefore input type=search results would have to be equivalent to input type=search results=0 and not input type=search results=results which looks wrong, because you would at least expect it to mean input type=search results=1. [1] I could name a number of other poorly chosen Apple icons, but their fault usually is cultural bias or disharmony within a set.
Re: [whatwg] Safari-compatible input type=search
On Sep 30, 2008, at 2:55 PM, Christoph Päper wrote: The magnifying glass was a particularly poor choice by Apple[1], because icons featuring one usually represent zooming (in). Binoculars are (for some reason) more common as symbols for searches. Eyes and spectacles OTOH most often represent visibility. Anyhow, the appearance of this or other types of |input| should not be specified by HTML5 / WF2+. Of course browsers could choose what the icon should look like; binoculars aren't a bad choice (although I think you're wrong about them being more common than a magnifying glass these days). The key is that the browser gives some sort of non-text indication to the user about the purpose of the field, in a platform-appropriate way. -- Andy Lyttle [EMAIL PROTECTED]
