[whatwg] input element list attribute and filtering suggestions

[Jonas Sicking]

On Tue, May 3, 2011 at 7:16 AM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Mon, May 2, 2011 at 6:32 PM, Ian Hickson <ian at 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 <jonas at 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