[whatwg] input type=barcode?

[Tab Atkins Jr.]

On Thu, Aug 30, 2012 at 8:07 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:
> On 08/27/2012 07:01 PM, Andy Davies wrote:
>> On 27 August 2012 20:25, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>>> On Mon, Aug 27, 2012 at 10:56 AM, Ian Hickson <ian at 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