I am aware, since I was looking forward to it in 115. Unfortunately, I kind of suspect it might not really be on the way, as last time I looked into it it seemed like it was in a bad state. I guess it's not a big deal, though.
This article mentions a notable limitation of the HSL colour model:
> Perceived brightness is not at all uniform at equal starting points, it depends on the hue, as well as the saturation.
…but it doesn't mention an (under-discussed) solution available: using a better colour model. OKLCH uses similarly understandable coordinates, "chroma" being roughly the same concept as "saturation", but is designed to avoid just this kind of problem. That is, if you change the "hue" coordinate, you can reasonably expect the perceived lightness and chroma of the resulting colour not to change. Where such a colour does not exist, e.g. a blue with the same lightness and chroma as #FFFF00 yellow, it's simply out of gamut.
There's a colour picker web app[0] that shows the boundaries of the space along with smaller spaces like sRGB, and it's helpful for getting a feel for it. It also links to a post[1] laying out the reasons to use OKLCH in web projects (it's now supported by all three major engines), and the post[2] introducing OKLAB (same space, different coordinate system) is heavy on technical details.
Thank you for sharing. I've published a small case-study[0] working with OKLCH with Angular Material which is a large UI library for the Angular framework.
Edit: What I find particulary difficult with OKLCH is sharing it across projects (think Android, iOS, and Web). I have tried figuring out solutions in Style Dictionary where I could generate colors and manually convert them to Hex or HSL for other platforms but the solution needs a fair amount of complexity that I am not willing to work with.
This is great. I keep making attempts trying to understand CIELAB and similar, with perceived brightness as my main concern. OKLAB looks like it’s exactly what I need.
oklch.com is an absolutely fantastic resource, thank you for sharing it.
I was able to see how limited our devices are when it comes to high chroma colors and I was only able to select purple. We are fooling ourselves and our users if we keep using HSL and think it’s acceptable.
Nice that it tells you that some colour is not available in your current gamut but it is in e.g P3... which reminded me that my monitor is P3-able but I forgot to set the proper profile!
I think your point is that bad PR affects your decision not to use Intuit's products, but I'd argue they're a perfect example of bad PR not being a problem. They have sensationally bad PR, yet they're worth >$100B, one of the 100 most valuable companies in the world, and they dominate their category.
So many people don’t understand this. “There’s no such thing as bad PR” doesn’t mean you won’t lose customers - it just means that for every 1 lost, 10 more are gained due to simple exposure/awareness.
I know that OsmAnd has fairly granular routing preferences, including a "preferred terrain" setting with "hilly", "less hilly", and "flat" options (as well as a "use elevation data" option which I don't quite understand).
Common licenses specifically go out of their way not to imply such a contract. This is the start of the all-caps portion of the MIT License [0]:
> THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO […] FITNESS FOR A PARTICULAR PURPOSE
…and the GPL has nearly the same text in section 15. [1]
Yeah, but also common licenses are set by the distributor. (which they're also evidently free to secretly change?)
I want the other side of the deal: a default license implicit in the existence of software that can't be traded away without an explicit contract that involves something like an exchange of money, which a federal agency will safeguard against violations of. If an extension changes its behavior nefariously people should go to jail. If Google safeguards an extension that changes it's behavior nefariously then Google should go to company jail. (or, like, be fined and forced to comply).
(admittedly, this is hopeless idealism. But still.)
There are a couple of ways they can try to detect devtools being opened. As the sibling comment implies, the most popular way is to detect a sudden viewport resize, and you can avoid that by ensuring your devtools are set to open in a new window before opening them.
The only other ways I'm aware of are:
- Detecting the keyboard shortcut, ⌘⌥i or equivalent, which you can avoid by using the browser menu, and
- More riskily, evaluating a `debugger` statement and detecting whether evaluation paused. I'm not sure you could do anything about this one, but it would certainly be obvious to you whether it was happening.
Well, to answer this question if someone comes looking: there's no official aarch64 widevine release, but chromeos just started shipping a 64bit arm version of widevine in the last month. But that version is incompatible with the 16k page size kernel that asahi ships with. There was a report in the asahi irc channel that a manually patched libwidevinecdm.so works.
