autocomplete attribute in form widgets

[Jacopo Cappellato]

I'd like to add support for the autocomplete attribute in form widgets.
The attribute autocomplete="on/off" is supported by most browsers in
input fields of type "password" and "text" and also in the "form"
element and it controls the autocomplete features of the browser.

If it ok to add this to the widgets framework? To which elements (I'd
say "form", "text" and "password")?

Jacopo

[David E Jones]

This sounds good, but it might be confusing. The first thing I thought  
of (ie after reading your first sentence) was some sort of AJAX-backed  
auto-complete that uses server-side data.

I think there is another term for this, like "autofill" or something.  
If we do add an attribute for it in the form widget we should preface  
it with something like "client-" or even "browser-" to make the intent  
clear.

We could also just throw it in and not make it configurable, but I  
don't think I like that option because many (I'd say most...) sites  
want to leave this option to their users. In fact, and I hate to say  
this, but when I hear clients request things like this the first thing  
that crosses my mind is to wonder if they really understand what  
browsers do and how this whole "interweb" thing works.

-David


On Jan 23, 2008, at 9:21 AM, Jacopo Cappellato wrote:

> I'd like to add support for the autocomplete attribute in form  
> widgets.
> The attribute autocomplete="on/off" is supported by most browsers in  
> input fields of type "password" and "text" and also in the "form"  
> element and it controls the autocomplete features of the browser.
>
> If it ok to add this to the widgets framework? To which elements  
> (I'd say "form", "text" and "password")?
>
> Jacopo

[Jacopo Cappellato]

What about:

client-autofill-fields = "true/false" for the form's attribute

client-autofill-field = "true/false" for the text and password fields
(or without the last -field... ?)

?


David E Jones wrote:

>
> This sounds good, but it might be confusing. The first thing I thought
> of (ie after reading your first sentence) was some sort of AJAX-backed
> auto-complete that uses server-side data.
>
> I think there is another term for this, like "autofill" or something. If
> we do add an attribute for it in the form widget we should preface it
> with something like "client-" or even "browser-" to make the intent clear.
>
> We could also just throw it in and not make it configurable, but I don't
> think I like that option because many (I'd say most...) sites want to
> leave this option to their users. In fact, and I hate to say this, but
> when I hear clients request things like this the first thing that
> crosses my mind is to wonder if they really understand what browsers do
> and how this whole "interweb" thing works.
>
> -David
>
>
> On Jan 23, 2008, at 9:21 AM, Jacopo Cappellato wrote:
>
>> I'd like to add support for the autocomplete attribute in form widgets.
>> The attribute autocomplete="on/off" is supported by most browsers in
>> input fields of type "password" and "text" and also in the "form"
>> element and it controls the autocomplete features of the browser.
>>
>> If it ok to add this to the widgets framework? To which elements (I'd
>> say "form", "text" and "password")?
>>
>> Jacopo

[David E Jones]

That's more clear. You could leave the term "autocomplete", especially  
if that's what the HTML attribute is called, and with the prefix it is  
easier to understand (sorry, what I wrote was probably confusing).

-David


On Jan 23, 2008, at 10:12 AM, Jacopo Cappellato wrote:

> What about:
>
> client-autofill-fields = "true/false" for the form's attribute
>
> client-autofill-field = "true/false" for the text and password fields
> (or without the last -field... ?)
>
> ?
>
>
> David E Jones wrote:
>> This sounds good, but it might be confusing. The first thing I  
>> thought of (ie after reading your first sentence) was some sort of  
>> AJAX-backed auto-complete that uses server-side data.
>> I think there is another term for this, like "autofill" or  
>> something. If we do add an attribute for it in the form widget we  
>> should preface it with something like "client-" or even "browser-"  
>> to make the intent clear.
>> We could also just throw it in and not make it configurable, but I  
>> don't think I like that option because many (I'd say most...) sites  
>> want to leave this option to their users. In fact, and I hate to  
>> say this, but when I hear clients request things like this the  
>> first thing that crosses my mind is to wonder if they really  
>> understand what browsers do and how this whole "interweb" thing  
>> works.
>> -David
>> On Jan 23, 2008, at 9:21 AM, Jacopo Cappellato wrote:
>>> I'd like to add support for the autocomplete attribute in form  
>>> widgets.
>>> The attribute autocomplete="on/off" is supported by most browsers  
>>> in input fields of type "password" and "text" and also in the  
>>> "form" element and it controls the autocomplete features of the  
>>> browser.
>>>
>>> If it ok to add this to the widgets framework? To which elements  
>>> (I'd say "form", "text" and "password")?
>>>
>>> Jacopo
>

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
>
> This sounds good, but it might be confusing. The first thing I thought  
> of (ie after reading your first sentence) was some sort of AJAX-backed  
> auto-complete that uses server-side data.
>
> I think there is another term for this, like "autofill" or something.  
> If we do add an attribute for it in the form widget we should preface  
> it with something like "client-" or even "browser-" to make the intent  
> clear.

Yes, autofill is the most used word for that, adding more information seems wise.

Jacques
 

[Jacopo Cappellato]

Jacques Le Roux wrote:

> From: "David E Jones" <[hidden email]>
>>
>> This sounds good, but it might be confusing. The first thing I
>> thought  of (ie after reading your first sentence) was some sort of
>> AJAX-backed  auto-complete that uses server-side data.
>>
>> I think there is another term for this, like "autofill" or something.  
>> If we do add an attribute for it in the form widget we should preface  
>> it with something like "client-" or even "browser-" to make the
>> intent  clear.
>
> Yes, autofill is the most used word for that, adding more information
> seems wise.
>

Ah ah... sorry Jacques, I got your comment too late and I've committed
the version with the "autocomplete" word... If it is going to cause
confusion I will change it back to autofill, but maybe we can postpone
this decision.
Thanks for your advices,

Jacopo


> Jacques
>