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

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

From: Michel Fortin <michel.fortin@michelf.com>
Date: Wed, 31 May 2006 22:08:00 -0400
Message-ID: <7C3815C8-3305-40E4-86A4-EC325B346E34@michelf.com>
Le 31 mai 2006 ? 15:51, Ian Hickson a ?crit :

> 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?

It seems like a good idea to me, but I think we should make sure it  
can be used for other means that enabling/disabling spell checking.  
Given that I can read in the spec that "user agents may use this  
attribute to provide more appropriate editors, syntax highlighting,  
spelling checkers, etc."[1], this seems to be already addressed.

Since you're reviewing this, I have some issues/commentary to I'd  
like to put to your attention:

*  Very often, "HTML content" in a textarea is just a snippet, not
    a full document. What should we expect of the content of an
    <input> or a <textarea> with accept="text/html"?

*  Going a little further, should there be a way to tell which elements
    are allowed and which are disallowed within an HTML snippet? I  
suppose
    it may complicate things a little too much. But this remains one
    of the things most often found around a textarea and, yet, there  
is no
    semantical way of passing this useful information which could be  
used by
    a potential "more appropriate editor" or to syntax highlighting.  
A way
    of passing such things as parameters may be a good idea.

I also see that Brett Wilson (Google) on Bugzilla[2] mentions  
multiple accept types while the current WA spec disallows this (for  
<textarea>[1]). I think the later (with only one type) is the better,  
unless there is a way for the server to know which type it receives.  
Otherwise, the server would have to rely on sniffing, which can be  
ambiguous, especially with plain text and HTML (Is "12<a b=30>12"  
text or HTML content? Or the content of this email with <tags> all  
around?).

  [1]: http://www.whatwg.org/specs/web-forms/current-work/#extensions1
  [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=339127


Michel Fortin
michel.fortin at michelf.com
http://www.michelf.com/
Received on Wednesday, 31 May 2006 19:08:00 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:46 UTC