- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 30 Aug 2012 08:12:11 -0700
- To: Mounir Lamouri <mounir@lamouri.fr>
- Cc: whatwg@lists.whatwg.org
On Thu, Aug 30, 2012 at 8:07 AM, Mounir Lamouri <mounir@lamouri.fr> wrote: > On 08/27/2012 07:01 PM, Andy Davies wrote: >> On 27 August 2012 20:25, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >>> On Mon, Aug 27, 2012 at 10:56 AM, Ian Hickson <ian@hixie.ch> wrote: >>>>> >>>>> True, so this is perhaps closer to an IME hint, as has been suggested >>>>> for a couple of other input types. >>>> >>>> Do you mean something like inputmode=barcode? Can you elaborate on how >>>> that would work? It's an intriguing idea, but I'm not sure I follow quite >>>> how to specify it. >>> >>> Yes, something like that. In terms of the table in the spec: >>> >>> Keyword: barcode >>> State: Barcode >>> Fallback State: Default >>> Description: Text input in the user's locale, with keys to activate >>> the system's built-in barcode reader to retrieve a value instead. >>> >> >> When you say "barcode" I'm presuming you're referring to barcode in >> all it's forms e.g. barcode, QR code, datamatrix etc? >> >> Some of these can contain up to 4,000 characters but many imagers have >> problems reading them. > > If that's the case, a full widget might make sense and in that case, we > would need an new input type instead of a new inputmode value. I did mean "arbitrary barcode, in any form", but I don't see how that changes anything. There's no difference, input-wise, between a traditional "bar" code and a QR code or something. All of them require a camera and an app capable of interpreting them, so their decoded value can be sent back to the browser. 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. ~TJ
Received on Thursday, 30 August 2012 15:13:10 UTC