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