Another issue is that it discards the color pair if the generated coordinates fall outside 100% sRGB. The problem here is that many low-end laptop displays cover significantly less than 100% sRGB, but come with the correct primaries in the EDID, thus causing browsers to display colors correctly if they can and clip colors if they can't. Colors too close to the sRGB boundary will be clipped in your game - different colors generated, different colors when converted to sRGB, same color on the screen because it is out of the screen gamut. Maybe it makes sense to avoid colors with more than 60% saturation?
I hope you post this again when you do - I was presented with the "0.00080" difference a couple times, and it looks like this is where it becomes actually impossible because of this issue.
Are you using Oklab channels to measure delta-E / difference? If so, Oklab is a hacky way to approximate a real colorspace with just one matrix multiplication, the channels have no meaning and are not related to delta-E. Use real Lab*, it'll take 10 minutes with an LLM.
EDIT: Just read the blog post. I thought HSL was bad for design, Oklab is much worse. It just goes right ahead and reuses color science terms so it sounds it got it all right. (dEOK existing and its "JND" being 0.02 absolutely made my head spin. None of this is recognizable to a color scientist)
>dEOK existing and its "JND" being 0.02 absolutely made my head spin. None of this is recognizable to a color scientist
isnt it just because the lightness scale is 0-1 instead of 0-100? i would like to learn more about this, and your comments are contrary to what i see on, for example, https://www.w3.org/TR/css-color-4/
"In CIE Lab color space, where the range of the Lightness component is 0 to 100, using deltaE2000, one JND is 2. Because the range of Lightness in Oklab and OkLCh is 0 to 1, using deltaEOK, one JND is 100 times smaller."
if youd rather just point in the direction of where to read more, that would be fine too. i assumed (wrongly?) that the CSS color specification would be accurate. or, at least, accurate enough to not make heads spin. (any ideas on why w3 got it so wrong? or why they would use OKlab at all, if it is as utterly awful as you imply?)
> "In CIE Lab color space, where the range of the Lightness component is 0 to 100, using deltaE2000, one JND is 2. Because the range of Lightness in Oklab and OkLCh is 0 to 1, using deltaEOK, one JND is 100 times smaller."
It's very correct - but the implications must not be clear.
In the CIELAB space (read: a scientific space), JND is 2. (3 is color science version, but a minor quibble)
In OKLab space, we'll say it's the same, and then account for normalized lightness.
Oklab's lightness isn't CIELAB's lightness, neither are their dimensions the same, so it's like saying "when we measure in kilometers, a Just Noticable Distance is 2 meters. Miles is scaled differently then normalized, but we'll just say it's 2 yards." (and that's being too kind, in practice, 2m ~= 2 yards, and I don't want to give the impression it's a simple linear scaling difference. The example is meant to communicate they're different dimensions entirely)
> i assumed (wrongly?) that the CSS color specification would be accurate. or, at least, accurate enough to not make heads spin. (any ideas on why w3 got it so wrong? or why they would use OKlab at all, if it is as utterly awful as you imply?)
The thrust of my comment isn't that Oklab is so awful it should be banned, in fact, it's specifically mentioned as better than the incumbent. However, continued reusing of color science terminology, and people assuming that it then applies, is both remniscent of HSL and may worse intellectual poverty for software engineers, even the well-intentioned and studied, as it sounds unobjectionable at its face, but would be batshit insane if applied to synonymous areas of science that affect daily life (ex. distance)
awesome, i appreciate the reply, thanks. most of this is all foreign to me, so i am missing a lot of the knowledge most of the things im finding & reading assume i have. the analogy helps.
Cheers, email in bio if you ever wanna shoot something off someone / get a hyper opinionated take (got lucky enough to be paid to cut through this jungle for ~2 years)
Right. The average score is under different test conditions. Obviously this game is a little silly version with very little accuracy to the lab testing, but hopefully it gets people thinking about this stuff a bit more! Which given your investigations into this, I would say it has succeeded.
I'm colorblind, but I ended up getting a 0.0028 "much better than average" score. Hmm... Fun site!
To promote some further reading:
OKLab isn't actually a perceptually uniform colorspace. It's better than others, but it was specifically chosen as a tradeoff between accuracy and speed (hence the name OK). When you start digging this deep, you quickly learn that we have yet to invent any perceptually uniform colorspaces; even the most precise models we have end up using fits and approximations. Color has some really inconvenient properties like depending strongly on brightness and background. Frankly, given the differences in human biology (having orders of magnitude differences in relative numbers of each cone, for instance), it's surprising we agree as much as we do! Human color perception is an endless pit of complexity.
(Note, I don't say any of this to detract from what you've built here, merely expand. Your site is awesome and I love it!)
JND is an average. A lot of people will do a lot worse. The measure, as I understand it, is also under different test conditions, while this is a game where people are on their own and able to - for example - tilt their head trying to find the exact angle to see the difference.
It’s not executing JS. The names map to JS methods but both the HTML and JS call into C++ (or rust or swift whatever the browser is written in). Arbitrary JS code execution cannot occur. Of course if you’re ingesting user generated content you should not allow these attributes on buttons (but for proper security you should already have an allow-list of tags and attributes on any user generated content).
Author here. I am not affiliated with Google. My current employer is GitHub, and this was incubated in the OpenUI working group. Open source & the open Web are still very much alive!
BroadcastChannel is a better solution for a couple of reasons. Service Workers are better at intercepting network requests and returning items from a cache, there’s some amount of additional effort to do work outside of that. The other thing is they’re a little more difficult to set up. A broadcast channel can be handled in a couple lines of code, easily debuggable as they run on the main thread, and they’re more suited to the purpose.
I disagree. You can just postMessage to communicate with the service worker and therefore I imagine the code using broadcast channel to be actually quite similar.
About debugging, service workers are easily debuggable, though not on the main thread as you already mentioned.
While it hasn't been expressly resolved by the HTML working group to not propose new attributes with dashes, and while I don't speak for everyone in the HTML working group, I would assert that many members would object to a proposed attribute that included a dash (including myself).
There is also a proposal in the works to allow web developers to define custom attributes - much like custom elements - which would likely follow the same or similar rules around dashes, at which point I imagine the HTML spec would guarantee that no dashes would be used in "built in" attributes.
New attributes have been proposed that reasonably _could_ have had a dash, for example `popovertargetaction`, but instead they were compounded to one word precisely to cave out this path.
There are template languages that extend the HTML syntax but render to valid HTML, and I imagine this kind of guarantee of future naming scheme is important to ensure the extended syntax does not have the potential to conflict with new attributes added to the HTML specs.
> proposal in the works to allow web developers to define custom attributes
Looks like this is it:
Proposal: Custom attributes for all elements, enhancements for more complex use cases
Searching for "dash" does bring up a thread of discussion around whether to require dashes or not.
---
I wonder if starting the custom attribute with a dash is allowed or not. Searching around, I see colon ":" and underscore "_" are OK, but dash "-" or period "." is only allowed after the first character.
> Any namespace-less attribute that is relevant to the element's functioning, as determined by the element's author, may be specified on an autonomous custom element, so long as the attribute name is XML-compatible and contains no ASCII upper alphas.
Oh I didn't realize I was speaking to the author of the article! I enjoyed it very much, it was thought-provoking, educational, and made me wonder about new ways of integrating HTML and CSS beyond classes.
One aspect of Tailwind that I'm not satisfied with is editor integration, in particular linting, hints, autocomplete. There are editor extensions for this, but it feels too cramped working inside the `class` value, a single space-separated string.
Custom elements and attributes could enable a better editing experience, for example autocomplete suggestions can be specific to attribute name; or if the attribute is known to have a color as value, the editor can provide a color picker to fill in the value.
They key difference is that an attribute can only appear once on an element, and consequently only have one of its variants present. Classes can present multiple variants at once.
At a surface level `<div class="Card" data-size="big">` isn't really any better `<div class="Card big">`. But `<div class="Card" data-size="big" data-size="small">` is not valid HTML - the second attribute is discarded. While `<div class="Card big small">` has no such contract, and as such is valid HTML and the CSS is unlikely to account for it, perhaps doing surprising things.
This is what BEM solves. You do not have class="Card big" but class="Card Card_big". And if you care about modifier conflicts you may always define a rule .Card_big.Card_small { /* whatever makes sense */ } and not rely on a random application of attributes.
I’ve been working on https://webcomponents.guide/ with some fellow experts in order to improve the documentation side of things. Hoping to offer guidelines and best practices to limit the amount of searching and experimentation required. Please take a look and provide feedback if you can!
That’s what CSS parts and slots are for. Your component can style its own boundaries, provide parts to allow customisation, and use slots to inject components that are styled from outside (be it another ShadowDOM or the light DOM)
Yep, though what I’m getting at is that those slots/parts better give you near-infinite flexibility. Because if you encounter a scenario where the slots don’t provide what you need, then you’re screwed.
Source: I fought with Ionic code for months over this. Really soured me on native encapsulation, but I see the benefits still. I just think it has to be approved very very very carefully.
reply