Re: [whatwg] input type=barcode?
2012-09-07 07:35 Europe/Helsinki: Ian Hickson: On Thu, 30 Aug 2012, Jonas Sicking wrote: I think while in theory we could rely on UAs to enable barcode entry anywhere, which definitely would provide the maximum capabilities for [...] In this respect it's similar to the WebKit-proprietary x-webkit-speech attribute on input. In fact, this suggests that if other browsers are interested in supporting speech input, maybe we should standardise it as an inputmode value, e.g. inputmode=speech. Possible the inputmode= attribute in that case could be switched to a list of tokens, so you could in fact do inputmode=latin-prose speech or inputmode=numeric barcode in order to provide the user agent with more flexibility in the UI. While I agree that inputmode attribute should be made a space separated list of tokens, I'd avoid stuff like latin-prose. Expected input language should be specified via lang or xml:lang attributes instead. Examples of somewhat sensible inputmode values for input type=text: - unicode or text - numeric (prefer numeric input but allow any text) - barcode - speech or voice (prefer voice input) - word - sentence - letters (e.g. letters voice means spell by letter) - ascii (prefer real 7 bit ascii over unicode text) The inputmode word vs sentence vs letters could be used for e.g. hinting predictive text input to now suggest/auto-correct words when single letters (some kind of code) is expected. However, it's far from clear if this is worth WHATWG specification right yet. All these features could be nice but unless UA vendors are going to implement at least some of these, there's no point. -- Mikko
Re: [whatwg] input type=barcode?
On Fri, Sep 7, 2012 at 12:21 PM, Mikko Rantalainen mikko.rantalai...@peda.net wrote: However, it's far from clear if this is worth WHATWG specification right yet. All these features could be nice but unless UA vendors are going to implement at least some of these, there's no point. There's inputmode in the specification already precisely because of vendor interest. -- http://annevankesteren.nl/
Re: [whatwg] input type=barcode?
On Fri, Sep 7, 2012 at 6:35 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 30 Aug 2012, Jonas Sicking wrote: 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. Agreed. I think a UA that wanted to support this would want to know which attributes to provide the feature for. In this respect it's similar to the WebKit-proprietary x-webkit-speech attribute on input. In fact, this suggests that if other browsers are interested in supporting speech input, maybe we should standardise it as an inputmode value, e.g. inputmode=speech. Possible the inputmode= attribute in that case could be switched to a list of tokens, so you could in fact do inputmode=latin-prose speech or inputmode=numeric barcode in order to provide the user agent with more flexibility in the UI. There seems to be some overlap, at least in semantics, with the capture attribute described in HTML Media Capture[1] and recently filed for inclusion in the Living Standard HTML spec[2]. Anyway these two concepts can be reconciled or their distinction clarified? --tobie --- [1]: http://dev.w3.org/2009/dap/camera/ [2]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17879
Re: [whatwg] input type=barcode?
On Thu, Aug 30, 2012 at 5:44 PM, Jonas Sicking jo...@sicking.cc wrote: 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. It'd be straightforward on Android: long-touch the speech-input button (microphone icon) on the virtual keyboard to open a key list--a standard UI idiom on that platform--and put it in there, or in one of the other buttons. But yeah, until they actually do that in the first place, there's not much point to specifying a hint that basically says so you might want to make the barcode UI more prominent for this input. (There's lots of barcode reading software on Android, but I don't think there's an API to hook it up to existing input methods. I think you'd have to release a whole standalone input method to implement it. I could be wrong, I'm not up to date on newer Android APIs.) -- Glenn Maynard
Re: [whatwg] input type=barcode?
On Mon, 27 Aug 2012, Tab Atkins Jr. wrote: On Mon, Aug 27, 2012 at 10:56 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 3 Aug 2011, Tab Atkins Jr. wrote: On Wed, Aug 3, 2011 at 8:50 AM, Randy ra...@prowebdesign.nl 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. 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. I think that makes sense. On Thu, 30 Aug 2012, Jonas Sicking wrote: 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. Agreed. I think a UA that wanted to support this would want to know which attributes to provide the feature for. In this respect it's similar to the WebKit-proprietary x-webkit-speech attribute on input. In fact, this suggests that if other browsers are interested in supporting speech input, maybe we should standardise it as an inputmode value, e.g. inputmode=speech. Possible the inputmode= attribute in that case could be switched to a list of tokens, so you could in fact do inputmode=latin-prose speech or inputmode=numeric barcode in order to provide the user agent with more flexibility in the UI. 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. I agree. Until there is interest from a browser vendor ready to implement, or Web pages that are doing it themselves via getUserMedia(), we should probably not bother to add these features. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=barcode?
Working in Web applications solutions, I would really love such input type or mode Jonas asked if it was used enough. I would say for what I know that many applications propose to read barcodes: - to give informations about a product (either in business application or to give informations to consumers) - to trace a parcel sent by mail to check where it is until it reached its destination - to trace wood to guaranty its legality and that it's a sustainable one- to scan a contact card - to have a security guard checking in different station points during a patrol - to get discounts or specific offers from a flash code - to play games like geocaching or once with augmented reality Considering UA proposed interface, many at least 3 or 4 input mode could be used 1) by default the text mode with the alternative audio mode as it is more and more proposed in mobiles 2) if a camera is available, this mode can be proposed either by default or because the user choose this mode 3) if a barcode reader is available on the device, either natively or via USB / Bluetooth, this other mode can also be proposed In the preferences of the UA, the user could define its preferred default mode If not defined in the preferences, a dialog can propose all those available with a checkbox to remember the choice As for today a Web developer can use getUserMedia() to access to the camera or use the experimental USB/Bluetooh API proposed by Google Its last solution will often be to do an hybrid application to be sure that anyone can have a good user experience to scan the barcodes. Some of my concerns with those solutions: - USB/Bluetooth API may never become standard, - the user can not define globally what would be his preferred input mode (camera or barcode reader) Alexandre Morgaut Wakanda Community Manager 4D SAS 60, rue d'Alsace 92110 Clichy France Standard : +33 1 40 87 92 00 Email :alexandre.morg...@4d.com Web : www.4D.com
Re: [whatwg] input type=barcode?
On Fri, 31 Aug 2012 12:26:23 +0200, Alexandre Morgaut alexandre.morg...@4d.com wrote: Working in Web applications solutions, I would really love such input type or mode 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). 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. 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. 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. 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? 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. 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. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] input type=barcode?
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
Re: [whatwg] input type=barcode?
On 08/27/2012 07:01 PM, Andy Davies wrote: On 27 August 2012 20:25, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Aug 27, 2012 at 10:56 AM, Ian Hickson i...@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. -- Mounir
Re: [whatwg] input type=barcode?
On Thu, Aug 30, 2012 at 8:07 AM, Mounir Lamouri mou...@lamouri.fr wrote: On 08/27/2012 07:01 PM, Andy Davies wrote: On 27 August 2012 20:25, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Aug 27, 2012 at 10:56 AM, Ian Hickson i...@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
Re: [whatwg] input type=barcode?
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?
--
Mounir
Re: [whatwg] input type=barcode?
On Thu, Aug 30, 2012 at 11:59 AM, Mounir Lamouri mou...@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.
~TJ
Re: [whatwg] input type=barcode?
On Thu, Aug 30, 2012 at 4:19 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Aug 30, 2012 at 11:59 AM, Mounir Lamouri mou...@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
Re: [whatwg] input type=barcode?
On Wed, 3 Aug 2011, Tab Atkins Jr. wrote: On Wed, Aug 3, 2011 at 8:50 AM, Randy ra...@prowebdesign.nl 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. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=barcode?
On Mon, Aug 27, 2012 at 10:56 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 3 Aug 2011, Tab Atkins Jr. wrote: On Wed, Aug 3, 2011 at 8:50 AM, Randy ra...@prowebdesign.nl 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. 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. ~TJ
Re: [whatwg] input type=barcode?
On 27 August 2012 20:25, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Aug 27, 2012 at 10:56 AM, Ian Hickson i...@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. BTW there's an interesting introduction to barcodes from Data Logic here: https://easeofaccess.scanning.datalogic.com/public/marketlit/Send.aspx?file=EB-THEARTOFTHECODE-EN Cheers Andy
Re: [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
Re: [whatwg] input type=barcode?
On Fri, May 4, 2012 at 3:28 PM, Ian Hickson i...@hixie.ch wrote: 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. No more or less than input type=text method=numeric (or inputmode or whatever we're planning on calling the attribute) / Jonas
Re: [whatwg] input type=barcode?
2011/8/3 Kornel Lesiński kor...@geekhood.net: On Wed, 03 Aug 2011 16:26:41 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: What do you think? 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. It actually seems relatively useful, given that I use the barcode/QRCode reader in my phone quite a lot. Niche needs + inter-app communication sounds like something Web Intents could do (http://webintents.org). This was my first reaction too. 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. / Jonas
Re: [whatwg] input type=barcode?
On Wed, 2011-08-03 at 17:21 +0200, Anne van Kesteren wrote: On Wed, 03 Aug 2011 16:52:03 +0200, Mikko Rantalainen mikko.rantalai...@peda.net wrote: What do you think? 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. 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). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] input type=barcode?
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). 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). Yucca
Re: [whatwg] input type=barcode?
On Wed, 03 Aug 2011 16:52:03 +0200, Mikko Rantalainen mikko.rantalai...@peda.net wrote: What do you think? 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] input type=barcode?
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. See also: http://en.wikipedia.org/wiki/Barcode --Original Message-- From: Anne van Kesteren Sender: whatwg-boun...@lists.whatwg.org To: WHATWG To: Mikko Rantalainen Subject: Re: [whatwg] input type=barcode? Sent: Aug 3, 2011 17:21 On Wed, 03 Aug 2011 16:52:03 +0200, Mikko Rantalainen mikko.rantalai...@peda.net wrote: What do you think? 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. -- Anne van Kesteren http://annevankesteren.nl/ --- Sent from my BlackBerry
Re: [whatwg] input type=barcode?
On Wed, Aug 3, 2011 at 8:50 AM, Randy ra...@prowebdesign.nl 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. True, so this is perhaps closer to an IME hint, as has been suggested for a couple of other input types. ~TJ
Re: [whatwg] input type=barcode?
On Wed, Aug 3, 2011 at 8:21 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 03 Aug 2011 16:52:03 +0200, Mikko Rantalainen mikko.rantalai...@peda.net wrote: What do you think? 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. It actually seems relatively useful, given that I use the barcode/QRCode reader in my phone quite a lot. ~TJ
Re: [whatwg] input type=barcode?
On Wed, 03 Aug 2011 16:26:41 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: What do you think? 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. It actually seems relatively useful, given that I use the barcode/QRCode reader in my phone quite a lot. Niche needs + inter-app communication sounds like something Web Intents could do (http://webintents.org). -- regards, Kornel Lesiński
