W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2006

[whatwg] <input type="text" accept="">

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 1 Jun 2006 00:41:12 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0606010027230.22058@dhalsim.dreamhost.com>
On Wed, 31 May 2006, L. David Baron wrote:
>
> On Wednesday 2006-05-31 19:51 +0000, Ian Hickson wrote:
> > 
> > The Mozilla guys propose (in bug 339127) to make the accept="" attribute 
> > on <input> elements also apply to types other than type=file, with the 
> > same meaning as we currently have on <textarea>. Their particular use case 
> > is to use this as a hook for showing or hiding the spell-check UI.
> > 
> > What do people think? Good idea? Bad idea?
> 
> This seems like a bad idea to me.
> 
> We might want to use the accept attribute in the future to indicate what
> types of content can be sent, and thus what types of input the user
> agent should allow.  Overloading that to get a boolean for whether
> spellchecking should be enabled seems broken.
> 
> I'd rather see a new attribute for this.

Well, we want to avoid adding attributes for each feature (spellcheck=on 
autoindent=on syntaxhighlight=on syntaxcheck=off, as browsers add each 
feature) -- instead it is better, IMHO at least, to let the UA determine 
how it should behave based on some semantic information, such as, in this 
case, the type that is expected to be entered.

I don't see why the same attribute _shouldn't_ be used to determine the 
type of data to allow, and whether to do spell checking or not. After all, 
whether to spell-check is directly related to what kind of data it is.

Do you have a better idea which doesn't require one attribute per feature 
but still uncouples this feature from the "type"?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 31 May 2006 17:41:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:27 UTC