On 31 août 2012, at 14:19, Odin Hørthe Omdal wrote: > > Thing is, we don't need this on the web platform until some user agent > actually supports giving input by a "reader" (don't even have to restrict > it to barcode, it can be whatever).
Well we recently allowed the Web platform to get access to new input interfaces like the camera and the microphone http://www.w3.org/TR/html-media-capture/ (And by the way I appreciate that Opera is one of the UA already supporting getUserMedia() ) The Web platform is becoming one of the preferred Application platforms. So I think it worth to work on its current limitations. > To the website it will in fact just look like a very fast user typed in > the data (or pasted it in). So this is possible to do already. Possible for simple barcodes with visible number (when they are not damaged) but harder for QR Codes And it's not always very accessible because, in the application world, the way you will use it doesn't always allow the use of a keyboard and/or a microphone I'm also sure you'll understand that sometime "very fast" input interfaces are very important > <input type=barcode> makes very little sense imho, because what you want > to input is always a number or some text. *How* you input that data > shouldn't be any of the web site's business. Yes, for pure barcode, the Web site or Web app will receive text data If the goal is extended to support QR code then this one can contain: - structured data like vCard, vCal which could be interfaced in JS with the contact (http://www.w3.org/TR/contacts-api/) and calendar (http://www.w3.org/TR/calendar-api/) device APIs - Binary data (see: http://en.wikipedia.org/wiki/QR_code ), which could be interpreted differently depending on the media-type specified in the "accept" attribute, the good news is that HTML5 already started to provide some APIs to handle Binary data (see arraybuffer, Blob, TypedArrays, objectURL, Canvas...) - most of the time they represent URL, but using URL schemes, there role is sometime specified as phone number ("tel:") or sms ("sms:") Structured data and Binary data are compatible in HTML forms using the form-data media type So yes the "type" attribute should be reserved to the describe the final data role. The barcode reader interface should be specified in another attribute like "capture" On our forum, the support of another kind of input interface was asked: RFID My answer was that in pure JS a USB RFID reader could be currently accessed via the experimental API provided by Chrome, but also that regarding how WebRTC and device API are discussed, higher level APIs would probably be considered.(It doesn't mean that those API would be usable on every device, as it depends on their material) > If I want to type in the number on the barcode manually instead of > scanning it, I should be allowed to do that. If the royal mail service in > Norway haven't set inputmode to barcode/reader on their <input type=text> > box for inputting tracking code, the user agent is still *totally* able > (and allowed) to push in data from a barcode reader there still. That's why I said that the user agent should allow in its preferences to specify the preferred input interface for barcodes and that if no camera nor barcode reader were available, the keyboard and/or microphone should of course be proposed > Quite frankly, there is no need to spec stuff like this now, as long as > it's not being used at this time. Why hint about something that doesn't > exist in user agents? Well, barcode are already very much used in mobile devices apps. Some web apps already provide such things but its very more complicated than from native apps, and of course the user experience suffer from that. I think that that using mechanisms like the one of Web intents to ask the device to use dedicated input interfaces for data from barcode or RFID (or any other ones) may be a good approach We can wait to write the specification, but I think that to have at least one User Agent implementing it first, it's easier to talk about it first. I don't think any User agent already support the calendar API, but there is already a draft... > Right now we don't have _any_ inputmode hints at all. It's still possible > to provide inputs to <input> fields from voice-to-text, from keyboard, > from touchscreens with on-screen keyboards, pre-filling etc. Well, in some mobiles, we start to see a microphone icon in some text fields allowing the user to talk instead of using a keyboard When there is a <input type="image"> field in a Web Form, the user can in some implementations choose one from the filesystem, the camera, or even sometimes some other web service > Basically, there is no need to say anything about a barcode reader, if you > have one in your user agent, just use it... It will work already. Sorry, I may misunderstand what you mean... I think the goal of whatwg is to enhance the Web platform and encourage UA vendors to participate in a living standard, not to push people using some proprietary API in specific User agents. Kind regards, Alexandre Alexandre Morgaut Wakanda Community Manager 4D SAS 60, rue d'Alsace 92110 Clichy France Standard : +33 1 40 87 92 00 Email : [email protected] Web : www.4D.com
