W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2012

Re: [whatwg] input type=barcode?

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 30 Aug 2012 19:44:05 -0300
Message-ID: <CA+c2ei8Uqn3r_Z4jJJ3+hrqM6FgkMrF6+SZC+YJUP-cyPs5u=Q@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: whatwg@lists.whatwg.org, Mounir Lamouri <mounir@lamouri.fr>
On Thu, Aug 30, 2012 at 4:19 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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.

Agreed.

I think while in theory we could rely on UAs to enable barcode entry
anywhere, which definitely would provide the maximum capabilities for
the user. In practice it seems hard to create UI which enables that
while at the same time isn't annoyingly shoving a barcode button in
your face which you generally is not interested in using.

That said, I'm not sure that barcode entry is a commonly enough used
feature that we need to have support for it in HTML. Is anyone
actually interested in implementing barcode support at this time,
whether we add an inputmode or not.

/ Jonas
Received on Thursday, 30 August 2012 22:45:04 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:44 UTC