Re: [whatwg] Search-suggestions without scripting
On Mon, 7 May 2012, Bjartur Thorlacius wrote: > On 5/5/12, Ian Hickson wrote: > > Note that even in this space, though, it's not the end of the story. > > For example, Chrome does more than just list the search autocomplete > > results; it also loads the first suggestion in the background, and > > mixes in results from local history search, etc. Other browsers do > > similar mixing. While this works well for browser UI, where the > > browser can mix in all the various results together, when you are > > talking about a Web page you still end up needing script to do that. > > So having it declarative isn't necessarily a win. > > Mixing multiple sources, such as user history and site suggestions, and > automatically performing actions upon them, such as prefetch and > prerender, should be easier for the user agent to do if the necessary > information to do so is declared, no? My point wasn't that the UA would want to add stuff, but that this kind of thing (an autocomplete widget, even one done entirely by and for the page, without the browser adding stuff) is in general more complicated than just "here's a list of completion suggestions". It's "here's five sources of data, let me rank them and figure out how to list them", or "here's a bunch of options including a rich entry with graphics", or any number of other complicated things. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Search-suggestions without scripting
On 5/5/12, Ian Hickson wrote: > Note that even in this space, though, it's not the end of the story. For > example, Chrome does more than just list the search autocomplete results; > it also loads the first suggestion in the background, and mixes in results > from local history search, etc. Other browsers do similar mixing. While > this works well for browser UI, where the browser can mix in all the > various results together, when you are talking about a Web page you still > end up needing script to do that. So having it declarative isn't > necessarily a win. > Mixing multiple sources, such as user history and site suggestions, and automatically performing actions upon them, such as prefetch and prerender, should be easier for the user agent to do if the necessary information to do so is declared, no?
Re: [whatwg] Search-suggestions without scripting
On Sun, 14 Aug 2011, Timo Beermann wrote: > > The search-suggestions of search-fields as in Google or Wikipedia should > be able without scripting, only with HTML/CSS. Because some users > deactivate Scripting (for security or whatever other reason) and on > other computers (school, university, work,...) you are not able to > change the settings, even if you want to. E.g. I use NoScript and only > allow scripting on very few trusted sites, that really need it. I looked into whether we should define a declarative solution for this, but I think that so far it seems that these autocomplete features are still very much evolving. For example, Google has been adding new things to their autocomplete regularly. In fact most autocomplete widgets seem to have some special feature that wouldn't easily fit into a generic declarative model -- consider Amazon's, where hovering over an item changes the department dropdown's selection without moving the autocomplete box, or Bing's, where typing "weather" inlines an interactive graphical weather box, or Apple's, where the items have an image and formatting. On Mon, 15 Aug 2011, Aryeh Gregor wrote: > > Scripting is generally necessary to get dynamic content. can > be used to provide search suggestions, but they'll be static if script > is disabled. Proper suggest-as-you-type functionality is precisely the > sort of thing that JavaScript is always going to be required for. Oh, I don't know. It's certainly plausible that this kind of thing will become commonplace enough and broadly similar enough that it makes sense to have a declarative way of specifying an autocomplete server, etc. But currently, we're still very much in the early days of this stuff. > Things that can already be done in script are usually only be made into > declarative features if they meet a very high bar: they must be *very* > commonly used, and there must be substantial benefit to typical users > (not just ones who disable script) from having them available as > declarative features. Agreed. On Wed, 17 Aug 2011, Aryeh Gregor wrote: > On Wed, Aug 17, 2011 at 4:12 AM, Alexandre Morgaut > wrote: > > I like the idea of a declarative way to support autosuggestions > > OpenSearch already made a successful specification supported by most > > browsers http://www.opensearch.org/Specifications/OpenSearch/1.1 > > That's an interesting point. There's no reason that autosuggest for > browser URL bars and search inputs has to be any different. Given that > all the infrastructure here is already present, a new attribute like > suggestions="http://path/to/opensearch"; would be all that's needed. It > would be relatively easy for browsers to implement, and trivial for > webpages to use if they're already using OpenSearch. I don't think this > has to be related to -- just have a new attribute on . If opensearch's version of this was the widely used state of the art and people weren't still very much innovating in this space, I'd probably agree. Note that even in this space, though, it's not the end of the story. For example, Chrome does more than just list the search autocomplete results; it also loads the first suggestion in the background, and mixes in results from local history search, etc. Other browsers do similar mixing. While this works well for browser UI, where the browser can mix in all the various results together, when you are talking about a Web page you still end up needing script to do that. So having it declarative isn't necessarily a win. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Search-suggestions without scripting
What I mean is a new possibility (not the datalist-item) where a search-field sends every typed or deleted character to the server (like a HTTP-Request, but another way) and the server sends the appropiate results to the client. Similar to JavaScript, but without scripting, just a HTML-Tag. (Of course the datalist wouldn't work for Google, Wikipedia,...) Best regards, Timo 2011/8/18 Alexandre Morgaut : > > On 18 août 2011, at 00:15, Aryeh Gregor wrote: >> That's an interesting point. There's no reason that autosuggest for >> browser URL bars and search inputs has to be any different. Given >> that all the infrastructure here is already present, a new attribute >> like suggestions="http://path/to/opensearch"; would be all that's >> needed. It would be relatively easy for browsers to implement, and >> trivial for webpages to use if they're already using OpenSearch. I >> don't think this has to be related to -- just have a new >> attribute on . > > > Just take care that: > > - The main difference between the autosuggest in HTML forms and autosuggest > in search bar is that for a search bar, the value associated to the label is > always an url. > -> for HTML forms, the result set should not be returned as a list of > element like in some OpenSearch result sets. Using elements > look more appropriate. > > - Using a datalist element is helpful because several elements can > then refer to the same value list (like for "home city" and "office city") > > - We may need to add an asynchronous API to be also able to manipulate the > list of options via JavaScript > > But yes, without maybe the last point, it should be quite simple to implement. > Another point: the code managing autosuggestion in search bars is not running > in a document context, and don't need currently to take care of Cross-Origin > policy... Just a bit of more work to do ;-) > > > > > Alexandre Morgaut > Product Manager > > 4D SAS > 60, rue d'Alsace > 92110 Clichy > France > > Standard : +33 1 40 87 92 00 > Email : alexandre.morg...@4d.com > Web : www.4D.com > > >
Re: [whatwg] Search-suggestions without scripting
On 18 août 2011, at 00:15, Aryeh Gregor wrote: > That's an interesting point. There's no reason that autosuggest for > browser URL bars and search inputs has to be any different. Given > that all the infrastructure here is already present, a new attribute > like suggestions="http://path/to/opensearch"; would be all that's > needed. It would be relatively easy for browsers to implement, and > trivial for webpages to use if they're already using OpenSearch. I > don't think this has to be related to -- just have a new > attribute on . Just take care that: - The main difference between the autosuggest in HTML forms and autosuggest in search bar is that for a search bar, the value associated to the label is always an url. -> for HTML forms, the result set should not be returned as a list of element like in some OpenSearch result sets. Using elements look more appropriate. - Using a datalist element is helpful because several elements can then refer to the same value list (like for "home city" and "office city") - We may need to add an asynchronous API to be also able to manipulate the list of options via JavaScript But yes, without maybe the last point, it should be quite simple to implement. Another point: the code managing autosuggestion in search bars is not running in a document context, and don't need currently to take care of Cross-Origin policy... Just a bit of more work to do ;-) Alexandre Morgaut Product Manager 4D SAS 60, rue d'Alsace 92110 Clichy France Standard : +33 1 40 87 92 00 Email :alexandre.morg...@4d.com Web : www.4D.com
Re: [whatwg] Search-suggestions without scripting
On Wed, Aug 17, 2011 at 4:12 AM, Alexandre Morgaut wrote: > I like the idea of a declarative way to support autosuggestions > OpenSearch already made a successful specification supported by most browsers > http://www.opensearch.org/Specifications/OpenSearch/1.1 That's an interesting point. There's no reason that autosuggest for browser URL bars and search inputs has to be any different. Given that all the infrastructure here is already present, a new attribute like suggestions="http://path/to/opensearch"; would be all that's needed. It would be relatively easy for browsers to implement, and trivial for webpages to use if they're already using OpenSearch. I don't think this has to be related to -- just have a new attribute on .
Re: [whatwg] Search-suggestions without scripting
I like the idea of a declarative way to support autosuggestions
OpenSearch already made a successful specification supported by most browsers
http://www.opensearch.org/Specifications/OpenSearch/1.1
The datalist element may support dynamic content
The element could support a template attribute similar to the one of
OpenSearch
Country :
http://myserver.com/suggestions.php?firstChars={value}";>
The response format should then be specified
In OpenSearch, the suggestions are all links with labels and sometimes
descriptions. They can be returned as Atom, RSS, or HTML/XHTML depending of the
requested MIME type.
The User-Agent should support at least a plain text response in which each
suggestion is on a separated line.
These lines may or not contain HTML tags
It would quite logic to expect a response which would be a set of
elements as expected in the content of static elements
We may also define specific MIME types like "application/datalist+xml" and
"application/datalist+json"
On 15 août 2011, at 20:39, Aryeh Gregor wrote:
> On Sun, Aug 14, 2011 at 3:26 AM, Timo Beermann
> wrote:
>> The search-suggestions of search-fields as in Google or Wikipedia
>> should be able without scripting, only with HTML/CSS. Because some
>> users deactivate Scripting (for security or whatever other reason) and
>> on other computers (school, university, work,...) you are not able to
>> change the settings, even if you want to. E.g. I use NoScript and only
>> allow scripting on very few trusted sites, that really need it.
>
> Scripting is generally necessary to get dynamic content.
> can be used to provide search suggestions, but they'll be static if
> script is disabled. Proper suggest-as-you-type functionality is
> precisely the sort of thing that JavaScript is always going to be
> required for. Things that can already be done in script are usually
> only be made into declarative features if they meet a very high bar:
> they must be *very* commonly used, and there must be substantial
> benefit to typical users (not just ones who disable script) from
> having them available as declarative features.
Alexandre Morgaut
Product Manager
4D SAS
60, rue d'Alsace
92110 Clichy
France
Standard : +33 1 40 87 92 00
Email :alexandre.morg...@4d.com
Web : www.4D.com
Re: [whatwg] Search-suggestions without scripting
On Sun, Aug 14, 2011 at 3:26 AM, Timo Beermann wrote: > The search-suggestions of search-fields as in Google or Wikipedia > should be able without scripting, only with HTML/CSS. Because some > users deactivate Scripting (for security or whatever other reason) and > on other computers (school, university, work,...) you are not able to > change the settings, even if you want to. E.g. I use NoScript and only > allow scripting on very few trusted sites, that really need it. Scripting is generally necessary to get dynamic content. can be used to provide search suggestions, but they'll be static if script is disabled. Proper suggest-as-you-type functionality is precisely the sort of thing that JavaScript is always going to be required for. Things that can already be done in script are usually only be made into declarative features if they meet a very high bar: they must be *very* commonly used, and there must be substantial benefit to typical users (not just ones who disable script) from having them available as declarative features.
Re: [whatwg] Search-suggestions without scripting
It is possible to use the new element to provide auto-suggest without scripting. It's even possible to use an external (XML) file. In all honesty, I don't see how Google or Wikipedia would add ALL their keywords to that list ;-) The spec used to allow directly interfacing to a server-side script, but that was removed due to simplifying the complexity. Again, like I mentioned in my other e-mail, the behavior needs to be added unobtrusive, and that's exactly what Google, Wikipedia and a lot of other websites do. You can search what you want without JS, but when you enable JS it will enhance your web experience. Regards *in all honesty, I didn't know there were still people disabling Javascript in 2011. I thought "the hype" was now to be very restrictive towards (3rd party) cookies ;-) --Original Message-- From: Timo Beermann Sender: whatwg-boun...@lists.whatwg.org To: wha...@whatwg.org Subject: [whatwg] Search-suggestions without scripting Sent: Aug 14, 2011 09:26 Hi! The search-suggestions of search-fields as in Google or Wikipedia should be able without scripting, only with HTML/CSS. Because some users deactivate Scripting (for security or whatever other reason) and on other computers (school, university, work,...) you are not able to change the settings, even if you want to. E.g. I use NoScript and only allow scripting on very few trusted sites, that really need it. Tobias Hanser --- Sent from my BlackBerry
[whatwg] Search-suggestions without scripting
Hi! The search-suggestions of search-fields as in Google or Wikipedia should be able without scripting, only with HTML/CSS. Because some users deactivate Scripting (for security or whatever other reason) and on other computers (school, university, work,...) you are not able to change the settings, even if you want to. E.g. I use NoScript and only allow scripting on very few trusted sites, that really need it. Tobias Hanser
