annevk
commented
4 years ago It might be a good idea to run something like this through https://discourse.wicg.io/ first.
Open ndesmic opened 4 years ago
annevk
commented
4 years ago It might be a good idea to run something like this through https://discourse.wicg.io/ first.
ndesmic
commented
4 years ago It might be a good idea to run something like this through https://discourse.wicg.io/ first.
Thanks, forgot to reference my post: https://discourse.wicg.io/t/proposal-element-for-qr-code-barcodes/4673/2
gjvnq
commented
4 years ago How about a "standard" JS API instead of a new element?
Something like: ('L' here is the error correction level)
<canvas onload="document.WebBarcodes.QRCode('my text', 'L')">How about a "standard" JS API instead of a new element?
Something like: (
'L'here is the error correction level)<canvas onload="document.WebBarcodes.QRCode('my text', 'L')">
I guess that would lose a lot of the benefits.
1) Performance - You need to load scripts before you can present the QR code. The UA could also do a better job of using threads, not blocking and preserving layout stability. Things DIY implementations will likely struggle with. 2) Accessibility - Some of the benefits like being able to easily full-size, turn on the screen and make the screen easier to read can't be done with a generic canvas because ATs won't have enough context. 3) Harder to use - HTML has a lower bar of entry. In particular it can easily be integrated with other markup types like markdown and a variety of social media, safely, without needing scripts. Certainly people will want JS access for advanced use cases, but I'd like to lead with the most basic user-friendly features. 4) UAs without scripts - It's highly common to use QR in print environments which may not use or have need of javascript.
gjvnq
commented
4 years ago You are right about these points.
What are the priority barcode formats to support? (Aside from QRCode, obviously)
My suggestions:
For 2D barcodes, in order: QRCode, Data Matrix, PDF417.
For 1D barcodes, in order: Code 128, EAN-13, EAN-8, EAN-2 and EAN-5 addons.
wwardaww
commented
4 years ago Maybe we can make options like that:
<barcode type="qr">
<a href:"mailto:exapmle@test.com">Mail Me</a>
<a href:"tel:+11111111">Call Me </a>
<barcode> when you scan the barcode on your phone, one pop-up can be appears including theese options
ndesmic
commented
4 years ago You are right about these points.
What are the priority barcode formats to support? (Aside from QRCode, obviously)
My suggestions:
For 2D barcodes, in order: QRCode, Data Matrix, PDF417.
For 1D barcodes, in order: Code 128, EAN-13, EAN-8, EAN-2 and EAN-5 addons.
This I cannot say and why it would be nice to have input from others. I simply don't know exactly how people might use such a thing or what's in use today. It may also be up to browser vendors to decide what they do and do not support since they may not want the overhead of less common formats or ones nobody asks for. I would say the minimum should include QR as that seems to be by far the most common. Even with just that I think this could be viable but it would be best to leave the door open.
Maybe we can make options like that:
<barcode type="qr"> <a href:"mailto:exapmle@test.com">Mail Me</a> <a href:"tel:+11111111">Call Me </a> <barcode>when you scan the barcode on your phone, one pop-up can be appears including theese options
I'm not sure I understand. The idea here would not be to define any layer on top of a barcode but just an API to generate them. So if you wanted to communicate HTML to another device, it would be up to you do encode and decode it with your app. If you mean using inner html as a fallback, yes, that would be the expected thing for UAs that don't support the feature.
ststimac
commented
2 years ago I think since this has quite a bit of discussion going and can be moved to the site / converted to a discussion
QR codes are pretty standard for transmitting small amounts of data. They can be seen many web-based applications especially for tasks like ticketing, payment, customer loyalty ids, pairing devices, and printing labels. In fact, these have become even more important post-COVID to make more things contact-less to mitigate spread of the virus.
QR codes are one of the few ways in which web pages can communicate data (albeit small) with local devices. Making this easier helps open up more opportunities in this area (I’m currently looking at sharing WebRTC SDP via QR to pair devices without a server). It's also one of the few avenues not completely dragged down with security concerns.
There’s a lack of symmetry with ShapeDetector API which can read barcodes and QR codes but we can’t easily generate them.
Existing 3rd party libraries can be large and complex (writing your own is very difficult). Since the libraries are so large it almost always makes sense to generate the image server-side and send it unless you are generating a lot of barcodes. If this was native to the platform we could be sending small payload strings rather than whole images.
QR is supported by most devices and makes a good fallback for things like NFC.
Better accessibility, so that users can understand that the element is displaying a scannable code and what type and the contents (URL, text, etc). In the case of users using a screen reader the screen is usually off, the UA could decide to briefly turn the screen on upon interaction with the element. It could also full-size it and increase screen brightness to make it quicker and easier for a scanner to read it. UAs could also provide the ability to copy the contents to the clipboard, something not easily possible with raw images.
QR codes are ubiquitous such nearly all modern phones naively support reading them in the camera app. Their usage seems common enough to warrant inclusion in the platform.
Rough Ideas:
The element a type attribute that could be one of any number of visual barcodes that the UA supports, should be using the same list as ShapeDetector.
Somehow you pass the encoding params per type (error correction level, etc).
Data is encoded in a string attribute
Customization is pretty common in use-cases I've seen, perhaps CSS parts to customize the modules/bars + Make the element a valid CanvasImageSource for heavier canvas-based customization.
Images can works as fallbacks similar to video/pictures for UAs that don't understand the element or don't support the desired format.
Canvas can work as well for polyfill-based fallbacks or completely custom types but these can still be enhanced with accessibility potential above, nearest-neighbor default scaling etc).
Sources: