- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 30 Aug 2012 12:19:30 -0700
- To: Mounir Lamouri <mounir@lamouri.fr>
- Cc: whatwg@lists.whatwg.org
On Thu, Aug 30, 2012 at 11:59 AM, Mounir Lamouri <mounir@lamouri.fr> wrote: > On 08/30/2012 12:12 PM, Tab Atkins Jr. wrote: >> It shouldn't be a new input type, because it's not a *type* of value. >> Barcodes are simple a wrapper for a value, to make it more easily >> machine-readable. Scanning a barcode is an input mode for a value, >> just like typing or speaking it is. > > Indeed. But then I wonder why it should be an inputmode because there is > no reason why you couldn't use a barcode in any field. inputmode being > an hint for the UA about the input that should be used, which means the > UA would be asked to use a barcode app for certain fields and not > others. I don't really see a use case for that. > > However, I think some users might want to use barcodes in some > situations (without any opt-in from the webpage). Like to put an URL or > an email address in a field. But in that case, it seems more like simple > <input type={url,email}>'s. I wonder if we couldn't leave this as UA > implementation details for URL and email fields? You're correct that potentially any field could be entered via barcodes. As I explained in my initial email, though, the point is to provide a suggestion for fields that you *intend* to be commonly filled with a barcode. This is precisely the case that inputmode is *designed* to address - *any* field could *potentially* want latin-prose, or numeric, or kana. The inputmode argument, though, provides a hint that the user is *likely* to want to enter this input's value with a particular mode. ~TJ
Received on Thursday, 30 August 2012 19:20:45 UTC