Unfortunately, it looks like their definition of brightness is a floating point number, and that's the only thing their API exposes. Hopefully future versions of the standard will be updated to better match the real world.
What we perceive as brightness is (a) the number of photons of each wavelength that (b) intersect a given point in space and (c) are exiting in a given direction. Obviously, all of this information can't be encoded in digital form. There's simply too much data to encode, let alone measure accurately. But reducing the data to a simple 1D number renders the data almost useless.
No website will be able to achieve good results if the dynamic color scheme is based on a single number.
That's also why the WebUSB spec is exciting. I don't have to wait for this spec to be drafted, or for browsers to support it, or to live with any shortcomings it ships with. I'm free to create.
There is an opportunity here, but to understand this space, you have to dive into it. There are some excellent books on the subject of colorimetery, but a quick bootstrapped understanding might look like:
1. Your eyes are designed to fool you.
2. How your eyes fool you is determined entirely by the photons that enter it.
3. Each of these photons has a wavelength. The more of them at a given wavelength, the more your perception shifts.
4. What you perceive as color is a combination of wavelengths. But -- critically -- these combinations affect each other. It is not true to say that the more photons that arrive at a given wavelength, the more intensely you perceive that wavelength. It causes a shift in your perception, but this shift is not necessarily a simple increase in brightness.
These are first principles, and it's a very brief sketch of the problem. But everything else follows from this. What ambient light sensors currently do, how APIs are designed, etc is all secondary. The problem is both as simple and as difficult as outlined above.
Now, you can say that this isn't worth tackling, or that the current systems are good enough, and so on. But you'd be missing out on quite an experience. Seeing the type of results you can get from a perfectly calibrated environment is really mindblowing. And the interesting part is, it's impossible for me to describe these results in text, or by showing you a photo, or a video, for the same reason you can't describe an Oculus experience. You have to be there.
Personally, I find colorimetry one of the most intellectually fun and gratifying areas of science.
I feel like something along those lines must already exist for a number of uses.
The trouble is, "whether or not it looks good" is also determined by your environment. Some people have crappy monitors, some people have perfect monitors, sometimes it's nighttime, sometimes your room is being lit by the early morning sun. When you look at a screen, all of these factors combine, and leaves you with the impression that something looks good or looks bad.
It gets worse. When you look at a monitor, what's behind your monitor is usually the most important thing. I.e. is the wall in front of you white, or green? Is it dark, or lit by the sun? That's going to affect how you see what's on the monitor. What's behind you is irrelevant, because you can't see it! It doesn't matter at all if the wall behind you is white or black, except insofar as it affects the colors of the wall in front of you. So not only do you need to account for all of the factors outlined above, but the damn thing needs to be aimed properly. I'm pretty sure that the right answer will look something like a sensor that mounts to the back of a laptop screen. But it also needs a sensor pointed at your face, and another sensor pointed straight at your monitor. Only at that point do you begin to have enough information to start writing a program that can make correct decisions.
Fiendishly difficult, no? Quite fun in any case.
Beyond that, I don't understand any of the other objections. Low level code in a high level language is one definition of power.
I'm not saying its a bad idea, just that this direct path in implementation is.
There are many other (better) ways of implementing it, like the Mozilla light sensor API. If that doesn't satisfy you, you should create a new spec for light sensors combined with a practical implementation and then push W3C to use your spec over Mozilla's.
It's actually more powerful than monitor calibration. Calibration doesn't account for the viewing condition (the brightness of your environment) whereas this hardware can.
It should really be the responsibility of the OS only... and browsers should all be ICC aware to begin with (a few years ago, only Safari was)
Why not WebSATA? WebPCI?
There are certainly a few key actors who would benefit from such a standard (benefits could be time to market), I'm just not sure it's enough benefits for the end user to justify a new standard!
Simple. Deliver a native application with your device sensor that the user has to install (maybe it could even be automatically installed through PnP). This application would provide a webserver on localhost which exposes the lighting information to interested websites. And in contrast to the WebUSB thing it would mediate the access to the USB device (lots of browser windows and processes can get the information instead of only a single one) and it would guarantee that only the relevant information is forwarded and not arbitrary data on an USB channel.
I'm a big fan of native apps over web app. But web apps have a huge practically that's hard to ignore.
And you still have the question on how the web app comes to the user: Through a dedicated intranet site? Makes sense if more than one user requires it, but the effort seems similar as packaging a native application and rolling it out automatically through the ITs deployment system. If only very few users (maybe only a single one) requires that hardware both approaches have a high overhead and supporting the device will be most likely rejected.
Getting this web app directly from a third party site will be mostly out of question for the companies you are talking about. Besides the security implications then we also talk about reliability problems ("I can't use my USB device because internet is down...")
If you look at the spec it doesn't directly access hardware and it even acknowledges doing so could be a big security issue. You interface with an abstraction that sits above the hardware that won't give you direct access but, instead, access to a subset of options that pass through the abstraction.
> Through a dedicated intranet site? Makes sense if more than one user requires it, but the effort seems similar as packaging a native application and rolling it out automatically through the ITs deployment system.
I'm not sure how you can compare the rollout of a native application to all user computers versus publishing within an intranet. They are not even in the same league in terms of deployment. Intranet is far, far easier. The native application has to be pushed out, installed and verified. A web app simply has to have its link emailed to users. Hell you could even push out a bookmark over many IT management systems (which is far easier than dealing with pushing out an application).
Yes, it increases the attack surface. This is a real danger, and should not be taken lightly. But no one is taking it lightly.
Another danger, which I haven't seen mentioned yet, is that it increases your fingerprint. If a website can list the Web USB devices currently connected, that's a way to deanonymize you.
But if you set aside those negative qualities, WebUSB, I think, is one of the more important features on the horizon.
For example, I could build and ship a light sensor. The idea is that you'd connect it to your laptop, and websites would be able to react to your environment's lighting + your current screen brightness. Think dynamic color schemes that always look good no matter what kind of monitor you're using, or whether it's night or day. This is only possible with hardware; no amount of software will make this feature available. And I can't think of any convenient way to do it other than WebUSB.