Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Jan 20, 2012 at 6:41 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 1 Aug 2011, Aryeh Gregor wrote: On Fri, Jul 29, 2011 at 7:24 PM, Ian Hickson i...@hixie.ch wrote: My overarching point, however, is that this is a UI issue, and not an authoring issue. The overarching counterpoint is that in-page UI *is* an authoring issue, because authors want to control exactly how their page looks and behaves. Browser/chrome UI issues shouldn't be standardized, but page UI issues absolutely should (at least in many cases). I disagree with this, at least in terms of a general guiding principle. I agree with Ian. I'm not sure how/why something like autocomplete should be treated different than select elements or alert dialogs. If you need a lot of control over the appearance or functionality, don't rely solely on native controls; enhance them with custom JS and CSS. I don't think it's reasonable for standards to try to address all appearance and functionality issues. The native implementations should work for everyone and be good enough for the majority. The rest is up to page, library, and framework authors.
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Jul 29, 2011 at 7:24 PM, Ian Hickson i...@hixie.ch wrote: My overarching point, however, is that this is a UI issue, and not an authoring issue. The overarching counterpoint is that in-page UI *is* an authoring issue, because authors want to control exactly how their page looks and behaves. Browser/chrome UI issues shouldn't be standardized, but page UI issues absolutely should (at least in many cases).
Re: [whatwg] input element list attribute and filtering suggestions
Þann mán 1.ágú 2011 15:28, skrifaði Aryeh Gregor: On Fri, Jul 29, 2011 at 7:24 PM, Ian Hicksoni...@hixie.ch wrote: The overarching counterpoint is that in-page UI *is* an authoring issue, because authors want to control exactly how their page looks and behaves. Browser/chrome UI issues shouldn't be standardized, but page UI issues absolutely should (at least in many cases). Every imaginable output media, or just the most common one?
Re: [whatwg] input element list attribute and filtering suggestions
Þann mán 1.ágú 2011 15:28, skrifaði Aryeh Gregor: On Fri, Jul 29, 2011 at 7:24 PM, Ian Hicksoni...@hixie.ch wrote: The overarching counterpoint is that in-page UI *is* an authoring issue, because authors want to control exactly how their page looks and behaves. Browser/chrome UI issues shouldn't be standardized, but page UI issues absolutely should (at least in many cases). Every imaginable output media, or just the most common one?
Re: [whatwg] input element list attribute and filtering suggestions
On Thu, Jul 28, 2011 at 5:54 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 May 2011, Jonas Sicking wrote: It seems to me that a simple boolean attribute and a few lines of script solves 80% of the use cases. What boolean attribute would that be? The mozNoFilter attribute we added in Firefox 4. On Wed, 4 May 2011, Aryeh Gregor wrote: I don't see any use-case where you wouldn't want to use mozNoFilter. Why doesn't it just work that way always? On Mon, 9 May 2011, Mounir Lamouri wrote: Basically, when you want to use the datalist to suggest a few things you might not want to filter and when the list is long, you very likely want to filter. You might not want to filter when the list is a real set of suggestions and you can type anything else. For example, a field in a support form can ask you What is your problem? and you could type a brief summary but some pre-written issues will be available. It's equivalent to a select element followed by an input field that you can use if you select other in the list. As I see it, when you filter, you have a very long list and you very likely want the user to select something in the list like a list of bugzilla emails, a list o metro stations, etc. Writing anything not in the list might not work. So why don't you just automatically filter if the list is long, and not filter if the list is short? I'm not a big fan of try-to-guess-what-the-author-wants-to-do solutions like that. Guessing will likely be as often wrong and annoying as it will be correct and helpful. / Jonas
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Jul 29, 2011 at 9:29 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 29 Jul 2011, Jonas Sicking wrote: On Mon, 9 May 2011, Mounir Lamouri wrote: Basically, when you want to use the datalist to suggest a few things you might not want to filter and when the list is long, you very likely want to filter. You might not want to filter when the list is a real set of suggestions and you can type anything else. For example, a field in a support form can ask you What is your problem? and you could type a brief summary but some pre-written issues will be available. It's equivalent to a select element followed by an input field that you can use if you select other in the list. As I see it, when you filter, you have a very long list and you very likely want the user to select something in the list like a list of bugzilla emails, a list o metro stations, etc. Writing anything not in the list might not work. So why don't you just automatically filter if the list is long, and not filter if the list is short? I'm not a big fan of try-to-guess-what-the-author-wants-to-do solutions like that. Guessing will likely be as often wrong and annoying as it will be correct and helpful. Showing the user an autocomplete list with hundreds of entries is going to be far more annoying. This to me seems to be entirely a UI issue. The problem is the other way around. When wanting to show a short list that should be filtered based on user input. / Jonas
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, 29 Jul 2011, Jonas Sicking wrote: The problem is the other way around. When wanting to show a short list that should be filtered based on user input. Why would it matter if the list is filtered or not when it's short? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 29 Jul 2011, Jonas Sicking wrote: The problem is the other way around. When wanting to show a short list that should be filtered based on user input. Why would it matter if the list is filtered or not when it's short? Choosing something at the bottom of a 10 item list is likely about as annoying as simply writing the whole email address manually and ignoring the datalist feature completely. Has any browsers implemented the UI you are suggesting? Is any planning to? / Jonas
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, 29 Jul 2011, Jonas Sicking wrote: On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 29 Jul 2011, Jonas Sicking wrote: The problem is the other way around. When wanting to show a short list that should be filtered based on user input. Why would it matter if the list is filtered or not when it's short? Choosing something at the bottom of a 10 item list is likely about as annoying as simply writing the whole email address manually and ignoring the datalist feature completely. If 10 items is annoying, then it's not short. Has any browsers implemented the UI you are suggesting? Is any planning to? I've no idea. It's incredibly early days in terms of implementations of these features. We are still looking for better ways of implementing maxlength=, which is something like 15 years old now. It'd be a little premature to dismiss something so early on. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Jul 29, 2011 at 3:42 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 29 Jul 2011, Jonas Sicking wrote: On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 29 Jul 2011, Jonas Sicking wrote: The problem is the other way around. When wanting to show a short list that should be filtered based on user input. Why would it matter if the list is filtered or not when it's short? Choosing something at the bottom of a 10 item list is likely about as annoying as simply writing the whole email address manually and ignoring the datalist feature completely. If 10 items is annoying, then it's not short. You mean long, right? Has any browsers implemented the UI you are suggesting? Is any planning to? I've no idea. It's incredibly early days in terms of implementations of these features. We are still looking for better ways of implementing maxlength=, which is something like 15 years old now. It'd be a little premature to dismiss something so early on. The ability to configure UI has been one of the big problems with the existing set of forms, and is one of the biggest concerns with the new set of forms (in particular the complex widgets like date/time pickers), so your argument that this particular aspect does not need to be configurable from the page seems like something that needs some backing up with more than opinions. / Jonas
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, 29 Jul 2011, Jonas Sicking wrote: On Fri, Jul 29, 2011 at 3:42 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 29 Jul 2011, Jonas Sicking wrote: On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 29 Jul 2011, Jonas Sicking wrote: The problem is the other way around. When wanting to show a short list that should be filtered based on user input. Why would it matter if the list is filtered or not when it's short? Choosing something at the bottom of a 10 item list is likely about as annoying as simply writing the whole email address manually and ignoring the datalist feature completely. If 10 items is annoying, then it's not short. You mean long, right? No, I mean short. I said that it shouldn't matter if you filter or not when the list is short. You said that a list with ten items was annoying. I'm arguing that that means the list is long, and thus not short, and thus should be filtered. My overarching point, however, is that this is a UI issue, and not an authoring issue. Authors should be able to provide either a complete static list of autocomplete suggestions, or a shorter list of relevant suggestions based on the current user input. In both cases, the user agent should be able to prioritise and/or filter the given suggestions in whatever manner makes the lists most helpful to the user. Giving the author the ability to prevent the filtering altogether makes sense if the UA's filtering is not ideal, but it doesn't make sense to put in the standard, since it's not yet at all clear that an ideal filtering is simply impossible. If, in the future, we find that it is in fact impossible for a UA to be clever enough to have good UI whether the list is static or dynamic, short or long, prefiltered or not, then it would make sense to study what further controls we can give authors. It would make a lot of sense to look at this at the same time as we look at other suggested augmentations here, such as the ability for script to provide prefiltered suggestions directly rather than having to manipulate DOM nodes to do so. Has any browsers implemented the UI you are suggesting? Is any planning to? I've no idea. It's incredibly early days in terms of implementations of these features. We are still looking for better ways of implementing maxlength=, which is something like 15 years old now. It'd be a little premature to dismiss something so early on. The ability to configure UI has been one of the big problems with the existing set of forms, and is one of the biggest concerns with the new set of forms (in particular the complex widgets like date/time pickers), so your argument that this particular aspect does not need to be configurable from the page seems like something that needs some backing up with more than opinions. I do not think the premise of this argument is correct. Styling form controls has certainly been something we have failed to provide hooks for, but that's an orthogonal issue, IMHO, and should be resolved using some sort of widget binding solution, not more attributes in the language itself. If we had a widget binding solution then authors with especially complicated needs could just override input and provide an implementation of the widget that did exactly what they wanted. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Jul 29, 2011 at 4:24 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 29 Jul 2011, Jonas Sicking wrote: On Fri, Jul 29, 2011 at 3:42 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 29 Jul 2011, Jonas Sicking wrote: On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 29 Jul 2011, Jonas Sicking wrote: The problem is the other way around. When wanting to show a short list that should be filtered based on user input. Why would it matter if the list is filtered or not when it's short? Choosing something at the bottom of a 10 item list is likely about as annoying as simply writing the whole email address manually and ignoring the datalist feature completely. If 10 items is annoying, then it's not short. You mean long, right? No, I mean short. I said that it shouldn't matter if you filter or not when the list is short. You said that a list with ten items was annoying. I'm arguing that that means the list is long, and thus not short, and thus should be filtered. My overarching point, however, is that this is a UI issue, and not an authoring issue. Authors should be able to provide either a complete static list of autocomplete suggestions, or a shorter list of relevant suggestions based on the current user input. In both cases, the user agent should be able to prioritise and/or filter the given suggestions in whatever manner makes the lists most helpful to the user. Giving the author the ability to prevent the filtering altogether makes sense if the UA's filtering is not ideal, but it doesn't make sense to put in the standard, since it's not yet at all clear that an ideal filtering is simply impossible. If, in the future, we find that it is in fact impossible for a UA to be clever enough to have good UI whether the list is static or dynamic, short or long, prefiltered or not, then it would make sense to study what further controls we can give authors. It would make a lot of sense to look at this at the same time as we look at other suggested augmentations here, such as the ability for script to provide prefiltered suggestions directly rather than having to manipulate DOM nodes to do so. I have no idea how the UA would be smart enough to figure out if filtering makes sense or not based on the set of suggestions. As far as I can see this requires very complex AI which is able to analyze the set of suggestions and see if they are contextual to the entered value or not. Granted, the recent IBM computer Watson did a pretty good job at this on Jeopardy a few months ago, but I think that we're decades from having that amount of computational complexity at our disposal when filtering autocomplete suggestions. I'd be nice if datalist was a viable solution before then. Has any browsers implemented the UI you are suggesting? Is any planning to? I've no idea. It's incredibly early days in terms of implementations of these features. We are still looking for better ways of implementing maxlength=, which is something like 15 years old now. It'd be a little premature to dismiss something so early on. The ability to configure UI has been one of the big problems with the existing set of forms, and is one of the biggest concerns with the new set of forms (in particular the complex widgets like date/time pickers), so your argument that this particular aspect does not need to be configurable from the page seems like something that needs some backing up with more than opinions. I do not think the premise of this argument is correct. Styling form controls has certainly been something we have failed to provide hooks for, but that's an orthogonal issue, IMHO, and should be resolved using some sort of widget binding solution, not more attributes in the language itself. If we had a widget binding solution then authors with especially complicated needs could just override input and provide an implementation of the widget that did exactly what they wanted. Are you suggesting that filter/no-filter should be selected using CSS? That seems outside of what CSS currently does anywhere. / Jonas
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, 29 Jul 2011, Jonas Sicking wrote: I have no idea how the UA would be smart enough to figure out if filtering makes sense or not based on the set of suggestions. You could do something like: - if there are 7 or fewer suggestions, show them all. - if filtering reduces the list to 1 to 7 suggestions, show those. - if there's some way to prioritise the filtered list, show the 7 best results from the filtered list. - otherwise, show everything. Exactly how the filtering is done can vary, in a way similar to how autocomplete dropdowns in browser location bars have pretty involved heuristics for figuring out how to filter to a few results. Are you suggesting that filter/no-filter should be selected using CSS? That seems outside of what CSS currently does anywhere. No, I'm saying it should be done using XBL or its successor. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Jul 29, 2011 at 8:32 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 29 Jul 2011, Jonas Sicking wrote: I have no idea how the UA would be smart enough to figure out if filtering makes sense or not based on the set of suggestions. You could do something like: - if there are 7 or fewer suggestions, show them all. - if filtering reduces the list to 1 to 7 suggestions, show those. - if there's some way to prioritise the filtered list, show the 7 best results from the filtered list. - otherwise, show everything. I assume it's a bug in the above suggestion that if filtering results in more than 7 results, we'd show everything, rather than just the filtered result? If so, this basically comes down to filter if it's more than 7, otherwise don't filter. These sort of magic limits is exactly the type of things that authors are going to end up butting up against and are going to want to configure. I don't see a way that HTML5 currently provides enough data to do any useful prioritization. Exactly how the filtering is done can vary, in a way similar to how autocomplete dropdowns in browser location bars have pretty involved heuristics for figuring out how to filter to a few results. Yes, but we have a *lot* more data available to do that filtering and sorting, compared to just the plain value that we have available for datalist. / Jonas
Re: [whatwg] input element list attribute and filtering suggestions
On Mon, 2 May 2011, Jonas Sicking wrote: On Mon, May 2, 2011 at 3:32 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 31 Dec 2010, Jonas Sicking wrote: The thing that makes this different than Google suggest-style UI is that in the latter case you need a script that continually polls for more appropriate suggestions and updates the list -- for this kind of thing we'd probably want to use a direct API, we wouldn't want to have scripts have to poke at the datalist DOM in real time. Why not? The firefox implementation should allow this (though I haven't tried this myself). Feel free to try it out and let us know how well/poorly it works. I just meant that it would be a poor authoring experience. I agree that it should in theory be possible with the current API; it just seems that if that's the use case we want to address, we should instead just have people point to a URL and be done with it: input type=text autosuggest=/cgi-bin/autocomplete.pl ...or some such. Sure, but that seems like a significantly more complex solution to design. We'd likely have to add features like deciding how many milliseconds to wait for another keystroke before sending the request. We'd also have to come up with a file-format for the response, and a definition of how the typed value is supposed to be sent with the request. Yes. Doing the hard work to make it easier for authors is our job. :-) I'd also be worried about making it possible to write keyloggers on sites that filter out scripts, but do allow form controls to be inserted. These would presumably be forms that cannot be submitted? I'm not sure I understand how this attack scenario would work in practice. On Tue, 3 May 2011, Aryeh Gregor wrote: On Mon, May 2, 2011 at 6:32 PM, Ian Hickson i...@hixie.ch wrote: I just meant that it would be a poor authoring experience. I agree that it should in theory be possible with the current API; it just seems that if that's the use case we want to address, we should instead just have people point to a URL and be done with it: input type=text autosuggest=/cgi-bin/autocomplete.pl ...or some such. This is too inflexible. It splits the logic between the browser and server in a rigid way, and doesn't allow client-side script to have any say. It would be much more useful to have a script API that lets you assign a list of suggestions to an input. Basically the same functionality as datalist, just easier to script. This way, the author has control over when and how the results are fetched and displayed, can use any format on the server side, can retrieve results from the client side if they like, etc. There's no need to use the subjunctive here, by the way. As I said, I did actually write such a search-suggestion thing for MediaWiki using the datalist API, and it works great in Firefox 4 as far as I can tell. It was just complicated unnecessarily by the need to add datalist elements to the DOM instead of plugging a list directly into the input. We could certainly also support scripted delivery of the suggestions. On Tue, 3 May 2011, Jonas Sicking wrote: It seems to me that a simple boolean attribute and a few lines of script solves 80% of the use cases. What boolean attribute would that be? The mozNoFilter attribute we added in Firefox 4. On Wed, 4 May 2011, Aryeh Gregor wrote: I don't see any use-case where you wouldn't want to use mozNoFilter. Why doesn't it just work that way always? On Mon, 9 May 2011, Mounir Lamouri wrote: Basically, when you want to use the datalist to suggest a few things you might not want to filter and when the list is long, you very likely want to filter. You might not want to filter when the list is a real set of suggestions and you can type anything else. For example, a field in a support form can ask you What is your problem? and you could type a brief summary but some pre-written issues will be available. It's equivalent to a select element followed by an input field that you can use if you select other in the list. As I see it, when you filter, you have a very long list and you very likely want the user to select something in the list like a list of bugzilla emails, a list o metro stations, etc. Writing anything not in the list might not work. So why don't you just automatically filter if the list is long, and not filter if the list is short? I don't really understand the reason for this attribute. I haven't added anything to the spec yet. I think mozNoFilter is unnecessary; UAs should be clever enough to determine when the UI would be better with filtering and when it would be better without. This seems rather trivial as it is (just filter when the list is greater than seven, and don't filter the list to zero unless you're confident that none of the suggestions apply at all). I think there is a use case for
Re: [whatwg] input element list attribute and filtering suggestions
On 05/05/2011 01:02 AM, Aryeh Gregor wrote: On Tue, May 3, 2011 at 8:04 PM, Jonas Sickingjo...@sicking.cc wrote: The mozNoFilter attribute we added in Firefox 4. I don't see any use-case where you wouldn't want to use mozNoFilter. Why doesn't it just work that way always? Basically, when you want to use the datalist to suggest a few things you might not want to filter and when the list is long, you very likely want to filter. You might not want to filter when the list is a real set of suggestions and you can type anything else. For example, a field in a support form can ask you What is your problem? and you could type a brief summary but some pre-written issues will be available. It's equivalent to a select element followed by an input field that you can use if you select other in the list. As I see it, when you filter, you have a very long list and you very likely want the user to select something in the list like a list of bugzilla emails, a list o metro stations, etc. Writing anything not in the list might not work. -- Mounir
Re: [whatwg] input element list attribute and filtering suggestions
On Tue, May 3, 2011 at 8:04 PM, Jonas Sicking jo...@sicking.cc wrote: You probably suggested this elsewhere on this list, but this sounds like a *really* interesting idea to me. I'd love to add experimental support for setting a property on the input element directly, which takes a JS object of some sort and builds a list out of that. I linked to my earlier feedback earlier in this thread, but it was buried fairly deep in my post: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024794.html The mozNoFilter attribute we added in Firefox 4. I don't see any use-case where you wouldn't want to use mozNoFilter. Why doesn't it just work that way always?
Re: [whatwg] input element list attribute and filtering suggestions
On Mon, May 2, 2011 at 6:32 PM, Ian Hickson i...@hixie.ch wrote: I just meant that it would be a poor authoring experience. I agree that it should in theory be possible with the current API; it just seems that if that's the use case we want to address, we should instead just have people point to a URL and be done with it: input type=text autosuggest=/cgi-bin/autocomplete.pl ...or some such. This is too inflexible. It splits the logic between the browser and server in a rigid way, and doesn't allow client-side script to have any say. It would be much more useful to have a script API that lets you assign a list of suggestions to an input. Basically the same functionality as datalist, just easier to script. This way, the author has control over when and how the results are fetched and displayed, can use any format on the server side, can retrieve results from the client side if they like, etc. There's no need to use the subjunctive here, by the way. As I said, I did actually write such a search-suggestion thing for MediaWiki using the datalist API, and it works great in Firefox 4 as far as I can tell. It was just complicated unnecessarily by the need to add datalist elements to the DOM instead of plugging a list directly into the input. On Mon, May 2, 2011 at 8:22 PM, Jonas Sicking jo...@sicking.cc wrote: I'd also be worried about making it possible to write keyloggers on sites that filter out scripts, but do allow form controls to be inserted. This has to be a secondary concern, though -- we realistically can't worry *too* much about sites that blacklist attributes or elements in user input instead of whitelisting. Especially when you're talking about allowing form controls, which is uncommon and poses security risks regardless (phishing/CSRF type stuff). All else being equal, we should avoid such new attributes, but not if they're the best solution available for a problem. Otherwise we could really hamper our ability to add new features to the platform, for the sake of a security model that's fundamentally broken anyway. It seems to me that a simple boolean attribute and a few lines of script solves 80% of the use cases. What boolean attribute would that be?
Re: [whatwg] input element list attribute and filtering suggestions
On Tue, May 3, 2011 at 7:16 AM, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, May 2, 2011 at 6:32 PM, Ian Hickson i...@hixie.ch wrote: I just meant that it would be a poor authoring experience. I agree that it should in theory be possible with the current API; it just seems that if that's the use case we want to address, we should instead just have people point to a URL and be done with it: input type=text autosuggest=/cgi-bin/autocomplete.pl ...or some such. This is too inflexible. It splits the logic between the browser and server in a rigid way, and doesn't allow client-side script to have any say. It would be much more useful to have a script API that lets you assign a list of suggestions to an input. Basically the same functionality as datalist, just easier to script. This way, the author has control over when and how the results are fetched and displayed, can use any format on the server side, can retrieve results from the client side if they like, etc. There's no need to use the subjunctive here, by the way. As I said, I did actually write such a search-suggestion thing for MediaWiki using the datalist API, and it works great in Firefox 4 as far as I can tell. It was just complicated unnecessarily by the need to add datalist elements to the DOM instead of plugging a list directly into the input. You probably suggested this elsewhere on this list, but this sounds like a *really* interesting idea to me. I'd love to add experimental support for setting a property on the input element directly, which takes a JS object of some sort and builds a list out of that. On Mon, May 2, 2011 at 8:22 PM, Jonas Sicking jo...@sicking.cc wrote: I'd also be worried about making it possible to write keyloggers on sites that filter out scripts, but do allow form controls to be inserted. This has to be a secondary concern, though -- we realistically can't worry *too* much about sites that blacklist attributes or elements in user input instead of whitelisting. Especially when you're talking about allowing form controls, which is uncommon and poses security risks regardless (phishing/CSRF type stuff). All else being equal, we should avoid such new attributes, but not if they're the best solution available for a problem. Otherwise we could really hamper our ability to add new features to the platform, for the sake of a security model that's fundamentally broken anyway. It seems to me that a simple boolean attribute and a few lines of script solves 80% of the use cases. What boolean attribute would that be? The mozNoFilter attribute we added in Firefox 4. / Jonas
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, 31 Dec 2010, Jonas Sicking wrote:
The thing that makes this different than Google suggest-style UI is
that in the latter case you need a script that continually polls for
more appropriate suggestions and updates the list -- for this kind of
thing we'd probably want to use a direct API, we wouldn't want to have
scripts have to poke at the datalist DOM in real time.
Why not?
The firefox implementation should allow this (though I haven't tried
this myself). Feel free to try it out and let us know how well/poorly it
works.
I just meant that it would be a poor authoring experience. I agree that it
should in theory be possible with the current API; it just seems that if
that's the use case we want to address, we should instead just have
people point to a URL and be done with it:
input type=text autosuggest=/cgi-bin/autocomplete.pl
...or some such.
On Fri, 31 Dec 2010, Jonas Sicking wrote:
I like the idea of bolding the matching parts of the suggestions which
match the typed string. Or at least creating a pseudo-element which
selected the matching substrings such that you could get the behavior
you want using:
input::matching-suggest {
font-weight: bold;
}
Interesting idea (probably more a CSS thing that HTML though, depends on
how we end up specifying widget-specific pseudo-elements).
That aside, I do in general agree that it would be nice to allow markup
inside options. I do wonder if a lot of pages would break if parsing
was changed in such a way.
This has been suggested in the past. Old builds of Mozilla -- I mean,
REALLY old builds of Mozilla, like back in the M3 days, before Mozilla
0.6 -- allowed you to put img in option. We changed that at some
point; I don't recall why but I could guess compat.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Dec 31, 2010 at 3:46 PM, Jonas Sicking jo...@sicking.cc wrote:
I like the idea of bolding the matching parts of the suggestions which
match the typed string. Or at least creating a pseudo-element which
selected the matching substrings such that you could get the behavior
you want using:
input::matching-suggest {
font-weight: bold;
}
Would be great if you could file a bug in bugzilla.mozilla.org to
implement such a feature and cc me.
I think that's too narrow to be really useful as a dedicated feature
for authors (although maybe UAs will want to use it in their default
stylesheets). The number of authors who want to highlight the
matching suggestion but don't want any further markup seems like it
would be too small to justify a special-case feature. Especially
since if you get even slightly sophisticated, you might be returning
results that don't have the given string as an exact substring, e.g.,
if you normalize spacing and punctuation before doing matches (let
alone doing typo fixes and synonym substitutions like Google).
That aside, I do in general agree that it would be nice to allow
markup inside options. I do wonder if a lot of pages would break if
parsing was changed in such a way.
That does seem like a very logical way to do this. It would be cool
if this were possible -- it's a pain to get the absolute positioning
and such right as it stands.
Re: [whatwg] input element list attribute and filtering suggestions
On Thu, Dec 30, 2010 at 4:36 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 23 Sep 2010, Mounir Lamouri wrote: The list attribute on input elements let the author specify a list of pre-defined suggestions via the datalist element (each option of the datalist is a suggestion). It looks like the idea is to have all the suggestions showing like a combobox which is more or less confirmed by Hixie. [http://www.w3.org/Bugs/Public/show_bug.cgi?id=9785] However, it sounds like having a static combobox would only fulfill some use cases (ie. when a very small set of suggestions is defined). In most obvious situations, having a list with all the suggestions would be annoying. So, it might be interesting to have the list filtered with the current element's value to be able to use the list attribute for large list and have a boolean attribute to enable or disable the filtering. There is a distinction between the combo-box style UI of a finite list of suggestions, and Google suggest-style UI -- but that difference is not related to filtering, IMHO. It's more related to the volume of possible data. In both cases you would want filtering for an ideal UI, IMHO. One simple use case would be a city transportation website. If you have to type a station name in a field it might be much more user friendly to have a filtered list. Actually, I do not see any use case of the list attribute without filtering. To me, it seems like a replacement of a select with options and an input fields in the case of none of the above. And I do not think this replacement would be better. I am wondering what were the use cases in mind? The use case is more or less what you describe -- just look around your operating system's configuration UI for instance for lots of examples of this kind of thing. The thing that makes this different than Google suggest-style UI is that in the latter case you need a script that continually polls for more appropriate suggestions and updates the list -- for this kind of thing we'd probably want to use a direct API, we wouldn't want to have scripts have to poke at the datalist DOM in real time. Why not? The firefox implementation should allow this (though I haven't tried this myself). Feel free to try it out and let us know how well/poorly it works. / Jonas
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, 31 Dec 2010 01:36:44 +0100, Ian Hickson i...@hixie.ch wrote: The thing that makes this different than Google suggest-style UI is that in the latter case you need a script that continually polls for more appropriate suggestions and updates the list -- for this kind of thing we'd probably want to use a direct API, we wouldn't want to have scripts have to poke at the datalist DOM in real time. For the Google suggest-style UI you also need to be able to show more than just options. Google has buttons, tables, images, and all kinds of other things in its dropdown. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Dec 31, 2010 at 5:50 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 31 Dec 2010 01:36:44 +0100, Ian Hickson i...@hixie.ch wrote: The thing that makes this different than Google suggest-style UI is that in the latter case you need a script that continually polls for more appropriate suggestions and updates the list -- for this kind of thing we'd probably want to use a direct API, we wouldn't want to have scripts have to poke at the datalist DOM in real time. For the Google suggest-style UI you also need to be able to show more than just options. Google has buttons, tables, images, and all kinds of other things in its dropdown. Indeed. But google is fairly alone in this design. I've seen plenty of other websites with dynamically populated autocomplete lists which doesn't put buttons in the list itself. For example the email autocomplete in bugzilla.mozilla.org. / Jonas
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Dec 31, 2010 at 12:07 PM, Jonas Sicking jo...@sicking.cc wrote: Indeed. But google is fairly alone in this design. I've seen plenty of other websites with dynamically populated autocomplete lists which doesn't put buttons in the list itself. For example the email autocomplete in bugzilla.mozilla.org. Wikipedia's new search suggestions (part of the Vector skin) don't include images or anything, but they do boldface the parts of the suggestion that match what you've typed. They also add an extra option at the bottom to let you actually search for pages containing the term instead of just looking for title matches. So that needs markup too, not just plain text. But I agree that a purely text-based suggestion box would be useful to support anyway. I did try writing this up for MediaWiki -- you can see the code at http://bits.wikimedia.org/skins-1.5/common/mwsuggest.js (my modifications to the preexisting code are in http://www.mediawiki.org/wiki/Special:Code/MediaWiki/61348). But I disabled it because Opera was the only browser implementing datalist at the time, and its implementation had a fatal flaw. Now it's been mostly superseded by the fancier implementation I mention above, but flipping os_use_datalist to true in that file seems to work pretty well in Firefox. The old suggestion system is still used in non-Vector skins for now, so if you have some way to flip the variable, you can try it out on Wikipedia at a URL like http://en.wikipedia.org/wiki/Main_Page?useskin=monobook. Noticeably, the list automatically incorporates extra suggestions based on browser form memory, and uses the system colors instead of site-determined colors. Both of these could be viewed as either good or bad, I guess. The datalist-based solution also has the suggestions line up exactly, while with the old way, it's a few pixels off (at least in Chrome). I provided some spec feedback at the time: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024794.html. I really agree with Hixie that a nicer JS API is necessary if you want authors to actually use datalist this way. It's gratuitously painful to update the list by fiddling with the DOM instead of just using a JavaScript array. Although it's still way, way easier than having to fake the box yourself with absolute positioning. I just enabled the datalist-based suggestions in MediaWiki trunk, for 1.18, since they work nicely for Firefox 4 (I've blacklisted Opera): http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79363. But I don't know how long that suggest framework will survive, given the newer and fancier one that's part of the new Vector skin (for which datalist is too limiting to be useful).
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, Dec 31, 2010 at 11:33 AM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Fri, Dec 31, 2010 at 12:07 PM, Jonas Sicking jo...@sicking.cc wrote:
Indeed. But google is fairly alone in this design. I've seen plenty of
other websites with dynamically populated autocomplete lists which
doesn't put buttons in the list itself. For example the email
autocomplete in bugzilla.mozilla.org.
Wikipedia's new search suggestions (part of the Vector skin) don't
include images or anything, but they do boldface the parts of the
suggestion that match what you've typed. They also add an extra
option at the bottom to let you actually search for pages containing
the term instead of just looking for title matches. So that needs
markup too, not just plain text.
I like the idea of bolding the matching parts of the suggestions which
match the typed string. Or at least creating a pseudo-element which
selected the matching substrings such that you could get the behavior
you want using:
input::matching-suggest {
font-weight: bold;
}
Would be great if you could file a bug in bugzilla.mozilla.org to
implement such a feature and cc me.
That aside, I do in general agree that it would be nice to allow
markup inside options. I do wonder if a lot of pages would break if
parsing was changed in such a way.
/ Jonas
Re: [whatwg] input element list attribute and filtering suggestions
On Thu, 23 Sep 2010, Mounir Lamouri wrote: The list attribute on input elements let the author specify a list of pre-defined suggestions via the datalist element (each option of the datalist is a suggestion). It looks like the idea is to have all the suggestions showing like a combobox which is more or less confirmed by Hixie. [http://www.w3.org/Bugs/Public/show_bug.cgi?id=9785] However, it sounds like having a static combobox would only fulfill some use cases (ie. when a very small set of suggestions is defined). In most obvious situations, having a list with all the suggestions would be annoying. So, it might be interesting to have the list filtered with the current element's value to be able to use the list attribute for large list and have a boolean attribute to enable or disable the filtering. There is a distinction between the combo-box style UI of a finite list of suggestions, and Google suggest-style UI -- but that difference is not related to filtering, IMHO. It's more related to the volume of possible data. In both cases you would want filtering for an ideal UI, IMHO. One simple use case would be a city transportation website. If you have to type a station name in a field it might be much more user friendly to have a filtered list. Actually, I do not see any use case of the list attribute without filtering. To me, it seems like a replacement of a select with options and an input fields in the case of none of the above. And I do not think this replacement would be better. I am wondering what were the use cases in mind? The use case is more or less what you describe -- just look around your operating system's configuration UI for instance for lots of examples of this kind of thing. The thing that makes this different than Google suggest-style UI is that in the latter case you need a script that continually polls for more appropriate suggestions and updates the list -- for this kind of thing we'd probably want to use a direct API, we wouldn't want to have scripts have to poke at the datalist DOM in real time. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] input element list attribute and filtering suggestions
Hi, The list attribute [1] on input elements let the author specify a list of pre-defined suggestions via the datalist element (each option of the datalist is a suggestion). It looks like the idea is to have all the suggestions showing like a combobox which is more or less confirmed by Hixie [2]. However, it sounds like having a static combobox would only fulfill some use cases (ie. when a very small set of suggestions is defined). In most obvious situations, having a list with all the suggestions would be annoying. So, it might be interesting to have the list filtered with the current element's value to be able to use the list attribute for large list and have a boolean attribute to enable or disable the filtering. One simple use case would be a city transportation website. If you have to type a station name in a field it might be much more user friendly to have a filtered list. Actually, I do not see any use case of the list attribute without filtering. To me, it seems like a replacement of a select with options and an input fields in the case of none of the above. And I do not think this replacement would be better. I am wondering what were the use cases in mind? So, the current implementation of the list attribute in Gecko [3] is filtering the list with the element's value by default [4] and we have introduced a mozNoFilter boolean attribute which can be used to have a non-filtered list. Feedbacks are welcome :) [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-list-attribute [2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9785 [3] Available in current Firefox nightlies and will be in beta7. [4] To be exact, the filter is done on the option's label Thanks, -- Mounir
