[whatwg] [WF2] Objection to autocomplete Attribute
Ian Hickson
ian at hixie.ch
Wed Mar 23 10:02:05 PST 2005
On Thu, 24 Mar 2005, Lachlan Hunt wrote:
>
> I recommend at least moving that statement to the note at the end of the
> section, perhaps changing it to something like this:
>
> # A UA may allow the user to disable support for this attribute. Support
> # for the attribute *should* be enabled by default, as there are
> # significant security implications for the user if support for this
> # attribute is disabled.
Ok, I changed the must to a should. But I left the bit about not making it
trivially disablable.
> However, I would like to point out that user agents that don't allow the
> user to override autocomplete, are in direct violation of the User Agent
> Accessibility Guidelines 1.0, Guideline 5 [1]:
>From a browser vendor point of view, if the alternatives are:
a. Allow users to use autocomplete on all sites, but don't let users
use bank sites at all, or
b. Allow sites to specify when autocomplete should be unavailable, and
let users use their bank sites,
...I can tell you the choice is easy.
> In a previous post, Ian Hickson also wrote:
> > Deprecating the feature would indicate that there is a chance the feature
> > will be dropped in a future version, which there isn't.
>
> Why isn't there a chance it will be removed? I accept it being included
> as a way to document what UAs should support, but not as an attribute
> that authors should ever use; and I hope, if this spec is ever accepted
> by the W3C or other standards organistion, that it is removed before it
> becomes anything official.
While I agree that competent users are important, and the spec should
cater for them (which is why I've agreed to change all these "must"s to
"should"s despite the realities of the situation), the fact is that most
users _aren't_ technically proficient, and for those users Web authors
have, IMHO, a legitimate reason to try to protect their users from mis-
configured public terminals.
The "autocomplete" attribute is now defined in terms of semantics: it
means the field is sensitive. I think that's quite a legitimate thing to
be able to specify.
> Do you realise how difficult it is going to become, and thus how much
> more innaccessible the web will become, if such authors find that this
> attribute is approved by a standards organistion?
I honestly don't see that authors would want to use autocomplete="off".
But if you think about it, if they do, that might actually be good on the
long term: browsers will eventually be forced to stop supporting it,
having more pressure from their users than from the banks.
Popup windows are similar: Users got so annoyed by them that the pressure
from users ended up overriding the pressure from advertisers.
> > It would also make any site using the feature non-conformant,
>
> So what? Any site using it now is non-conformant, what difference does
> it make?
It's like making file sharing illegal. You make a bunch of people into
law-breakers, for no good reason.
> > which is pointless: the sites are going to use these features
> > regardless, why make people have to violate the spec to do so.
>
> Then why is the size attribute deprecated now? Sites are going to use
> it regardless of the ability to specify such details using stylesheets,
> just like people continue to use <font>, <b>, etc, why make people have
> to violate the spec to do so?
Because there they don't _have_ to use it. They can get the same effect
without using the deprecated features.
> The point is: "Documents must not use deprecated features. User agents
> should support deprecated features." That statement, from appendix C,
> applies to both the size and autocomplete attributes equally, so please
> deprecate autocomplete.
I disagree that autocomplete is as bad as you make out.
If you don't want it, then disable support in your UA.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list