Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
solasluaith
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
1.
▲
by
solasluaith
4y ago
You’re aware that turning on a blue filter at the same brightness level will obviously decrease the overall emittance of the display? Most displays are already way too bright for ideal viewing conditions at maximum brightness, let alone in
2.
▲
by
solasluaith
4y ago
Many differences to my attempt: Luminance is kept different between colours according to some subjective “individuality”, I touched on why I decided against this in another comment. This has rippling effects as instead of being able to just
3.
▲
by
solasluaith
4y ago
The perceptual distance is the same between all colours according to the most recently available scientific data (with a relatively small margin of error for technical reasons). There could be issues with your display calibration (most like
4.
▲
by
solasluaith
4y ago
There’s no set timeline for further implementations. I’ll try to create the most requested ones whenever I can in my free time, but I’m also open for others to contribute!
5.
▲
by
solasluaith
4y ago
Already on my rapidly growing to do list!
6.
▲
by
solasluaith
4y ago
Colorbrewer is safe for CVD but not optimized to be as distinguishable as possible no matter your impairment as far as I’m aware. That’s what I’m trying to do in a different project. Colormaps have very different constraints due to having
7.
▲
by
solasluaith
4y ago
I absolutely agree that intelligent highlighting or added emphasis to at least some part of the code is very worth investigating. I would argue it should probably be used more sparingly than colouring, but could be complementary. By combini
8.
▲
by
solasluaith
4y ago
Oh awesome! I didn’t have time to look that deep into it, sorry for missing that part. Switching to OKLab actually reveals how narrow the bands of available colours can be in the different dimensions and how difficult it would probably be t
9.
▲
by
solasluaith
4y ago
The reasoning on the first two points is the same, yes, simply because I agree with Ethan’s. The two big differences are: I’m aiming for perceptually uniform colour differences instead of the same luminance and my background colours are dir
10.
▲
by
solasluaith
4y ago
I’m on a Mac with a Retina display so that’s probably why I haven’t noticed this issue. I don’t know of any way to account for this off hand though, even if I had noticed it. Is it at least acceptable with the contrast++ version?
11.
▲
by
solasluaith
4y ago
Yes, the blue light content is higher as screens use RGB instead of the full spectrum of light, but for this purpose I care about colour perception and as long as the stimulus in the cones is the same (which it should be if your display is
12.
▲
by
solasluaith
4y ago
Feel free to make either an issue or even a pull request, I’m very much looking for feedback on the implementation! Do you have the same issues with the Dark Contrast++ version?
13.
▲
by
solasluaith
4y ago
I’m not sure if I’m already using the closest colour in terms of luminance or not, I’d have to check. If not, I’m very open to pull requests on the theme, including fundamental reworks. Otherwise there might be an argument whether one would
14.
▲
by
solasluaith
4y ago
I think most of the criticism is fair and to be expected, especially as the design goals are very “opinionated” in a sense and on the other hand, everyone will have a subjective opinion on a colour palette themselves. The original intent wa
15.
▲
by
solasluaith
4y ago
If you care about accessibility and these colours have any sort of function or meaning within the app, I’m afraid I would advise against using these colours as they were created for a quite specific use-case — colouring tokens within “fluid
16.
▲
by
solasluaith
4y ago
I guess there’s an argument to be made to put the “available for” section closer to the top, but the main repository I linked is meant more as a design template that needs all this explanation, the VSCode extension for example is a lot more
17.
▲
by
solasluaith
4y ago
I acknowledge at the bottom that Solarised was one of the inspirations for this and some similar design principles apply in terms of the background colours, but really the motivation was a lot more specific and the construction fundamentall
18.
▲
by
solasluaith
4y ago
Correct, OKlab is nothing fundamentally new in terms of the underlying science as it’s based mainly on CIECAM16, but it makes working with perceptual distances of colours a lot more user friendly.
19.
▲
by
solasluaith
4y ago
The saturation (or to be more accurate in this case, chroma) is actually already as high as possible (unless I’ve made a fundamental mistake) given the constraint that we want it to be uniform across colours and also uniform luminance. sR
20.
▲
by
solasluaith
4y ago
There are a couple of hand picked categorical palettes for visualisations and at least for VSCode (see the issues on the main repo), there are also some themes. None of them are truly optimized as far as I’m aware, just chosen to be good en
21.
▲
by
solasluaith
4y ago
Yes, I’ve even updated the README to specify that accessibility for colour blindness is sadly impossible with these design goals and that they even make the palette particularly unsuitable for affected individuals, for the exact reasons you
22.
▲
by
solasluaith
4y ago
That’s true, it’s just what I prefer and was testing with but the line could probably be omitted.
23.
▲
by
solasluaith
4y ago
My base assumption was to treat code like text and you’re right, this means that smaller tokens are not as salient as larger ones. But if you really wanted to go down that rabbit-hole you’d ideally have to adjust each token individually a
24.
▲
by
solasluaith
4y ago
That’s the great thing about OKLab, it makes this kind of design much easier and more accessible without having to resort to color appearance models like CIECAM16 or even just CIECAM UCS. Beyond luminance, I’m also adjusting for uniform chr
25.
▲
by
solasluaith
4y ago
Awesome, thank you! I’ll give you some comments in the issue you posted.
26.
▲
by
solasluaith
4y ago
Thank you, I might incorporate that into the README at some point!
27.
▲
by
solasluaith
4y ago
In this case, I was trying to keep the actual code as “flat” as possible, while offering exactly that pleasing sense of depth for the UI. For the latter, it could probably be better utilised in the VSCode extension but I hope at least the c
28.
▲
by
solasluaith
4y ago
I was not aware of the new algorithm, thanks for bringing that up! Meeting the minimum values for body text in this new standard is unfortunately straight up impossible if you want to maintain uniform chroma for the syntax colouring as the
29.
▲
by
solasluaith
4y ago
I’m not a vim user but I’ll make a note of this in case I get around to implementing it myself. Realistically I would definitely need to work off of a template like this. Thanks!
30.
▲
by
solasluaith
4y ago
Exactly, the fundamental assumption that I’m making is that all code should have the same level of emphasis — like a regular text — while maintaining the ability to scan for categories of words. If someone disagrees with that assumption, th
More ›