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

Lachlan Hunt wrote:
> L. David Baron wrote:
>> 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.
> 
> AIUI, the accept attribute is just describing what type of input to 
> allow.  In this example, when text/plain is specified, the UA has just 
> automatically determined that spell checking would be helpful for the 
> user.  Similarly, if text/html, application/javascript or */*+xml were 
> specified, the browser could provide syntax checking.

I agree.

> I don't think the spec should explicitly define type="text/plain" as 
> meaning UAs should provide spell checking, it can just provide that as 
> an example of something a UA can do with it.

That would be a nice example. Make sure that you mention that spell 
checker should be enabled only if spell checker supports the 
language the content is supposed to be written with. If UA only 
supports spell checking for English and you have
<input accept="text/plain" lang="fi" />
then the spell checker should be disabled.

> What should the UA do with accept="text/plain;charset=X", where X is 
> some charset that potentially differs from the page's encoding?
> 
> e.g. if the page were served as text/html;charset=UTF-8 and contained
> <input type="text" accept="text/plain;charset=ISO-8859-1">
> 
> Then how would that interact with <form accept-charset="X">?

I'd expect the UA to warn the user if he uses characters outside the 
intersect of ISO-8859-1 and X (that is, the input is expecting 
characters from ISO-8859-1 character set and the UA is expected to 
encode those characters with encoding X. I'd assume that ISO-8859-1 
in the 'accept' parameter tries to hint that the backend is able to 
support ISO-8859-1 characters only.

In more general sense, if you have HTTP header Content-Type: 
text/html;charset=H for the page source, accept-charset="F" in the 
form element and accept="text/plain;charset=I" in the input field 
then "allowed" characters should be those that can be found in all 
the character sets H, F and I. The idea is that storage backend is 
only able to support I, user input should be transferred with 
charset F to the server and the output is later (probably) going to 
be displayed with charset H, too, so using characters outside those 
character sets is going to raise problems later on.

If I were to decide everybody would be forced to use either UTF-8 or 
UCS-4...

-- 
Mikko

Received on Thursday, 1 June 2006 07:01:24 UTC