[whatwg] input type=barcode?

On Wed, 3 Aug 2011, Mikko Rantalainen wrote:
> 
> A form author expects user to enter some kind of code (e.g. driver id 
> number, bank transfer code, product serial for warranty etc.) that is 
> accompanied with a barcode on paper. The end user finds it hard to 
> manually type the code.
> 
> Possible solution:
> 
> The form could hint the user agent about this by using type "barcode" 
> for an input element.
> 
> Possible user agent support:
> 
> (1) Allow using barcode scanner to enter the code (could already work 
> with existing user agents in case of a model that emulates a keyboard 
> because unknown input type is treated like a text input)
> 
> (2) Allow using webcam as barcode scanner with the UA handling the 
> camera operation. This would be safer than allowing the web site to 
> access the camera by itself to implementing the barcode scanning with 
> site specific code (because untrusted web site could use the camera for 
> something else but barcode scanning if access to camera is granted).
> 
> (3) Allow using 3rd party software to query barcode code. E.g. Android 
> phones may have a camera barcode scanner installed which can be used by 
> other software (e.g. web browser) to acquire the barcode.
> 
> Obviously the implementations could support various barcode formats 
> including currently popular QR-code.
> 
> The user agent should submit the text read from the code. (I think that 
> binary codes should not be allowed, only text that can be expressed in 
> Unicode.)
> 
> The backwards compatibility would be automatically available because 
> using manually entered text input for the barcode code is okay.

In general there's no reason the browser couldn't accept input from a 
barcode reader for any input, even a colour picker if there's some sort of 
colour barcode format. We don't have a special input type for keyboards vs 
mice vs trackballs vs touch screen devices vs speech recognition vs chord 
keyboards vs eye tracking. Why would we do something special for barcode 
readers? They're just another input device.


On Wed, 3 Aug 2011, Anne van Kesteren wrote:
> 
> Implementing this seems rather complicated for such a niche use. It also 
> seems better to let sites handle this by themselves so these physical 
> codes can evolve more easily.

On Wed, 3 Aug 2011, Kornel Lesi?~Dski wrote:
> 
> Niche needs + inter-app communication sounds like something Web Intents 
> could do (http://webintents.org).

Certainly Web Intents would be a relevant feature here.


On Fri, 5 Aug 2011, Jonas Sicking wrote:
>
> Something like <input type=text method=barcodereader> could allow the 
> browser to use a built-in barcode reader if it has one, or fire up a web 
> app using webintents/webactivities which would use the camera to read 
> the barcode.

It wouldn't allow it any more than it is already allowed.


On Thu, 4 Aug 2011, Henri Sivonen wrote:
> 
> I don't know how niche thing it is to actually own a dedicated USB 
> barcode reader, but where I live, using at least one Web app that 
> supports bar code reading (by having a text input requiring the bar code 
> reader can emulate a keyboard) is as mainstream as Web app usage gets 
> (banking).

That's already supported, though.


On Thu, 4 Aug 2011, Jukka K. Korpela wrote:
> 
> Agreed, but barcodes are a technical aspect of input rather than data 
> type comparable to type=email, type=url etc. As you say, when barcode 
> input is an option, it's also an option to use normal keyboard input 
> (though a browser could well use e.g. restricted on-screen keyboard if 
> it knows what to expect). Moreover, the word "barcode" has multiple 
> meanings.
> 
> So I think that if the input of data commonly available as simple linear 
> barcodes deserves a type of its own in HTML, it should be analyzed which 
> logical data type would be involved.
> 
> For example, the GTIN product codes (still often called EAN codes 
> especially when in barcode format, or TUN or DUN codes) are in wide and 
> increasing use and might be considered for inclusion. A browser could 
> implement an input type for them using a barcode reader when available, 
> otherwise using some method for input of digits together with checksum 
> checking. This would be useful, though I don't know whether it's worth 
> the specification and implementation effort (and things like this won't 
> be really useful except after several years when all significant 
> browsers have real support).

Things like the checksum checking can easily be done in the page itself. I 
don't see that there's much need for the UA to do it natively.


On Wed, 3 Aug 2011, Randy wrote:
>
> On top of that, the vast majority of these readers just translate it 
> back to text. It's just another input "device", as barcodes are fixed 
> (and sometimes standardized) fonts.

On Wed, 3 Aug 2011, Tab Atkins Jr. wrote:
> 
> True, so this is perhaps closer to an IME hint, as has been suggested 
> for a couple of other input types.

I agree that this seems like, at most, an input mode hint.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 4 May 2012 15:28:00 UTC