I truly admire the consistent care Josh puts in to his work.
The great content and didactics aside, it is the bomb proof interactive elements that do it for me. More often than not, sliders don’t work on phones and/or break scrolling. Not here.
Whatever the opposite of web dev blog spam is, Josh is the poster child for it. He could easily not add the interactive elements and his content would still be well written and informative, but instead he goes all in on everything he does. I really hope he is making a full time career of of this, because if anyone deserves to it's him. I am grateful for how much I've learned from his blog and course.
HSL came in clutch when I designed my website (https://joeldueck.com) to change colors based on the outside temperature. (See the slider at the bottom)
A script maps the temperature in °f to a value between 0 and 360, and this value is used for the Hue paramater in CSS hsl() colors.
That's not quite true. The NES could reregister colors in the middle of a scanline to get additional colors up to 410 onscreen at once. https://ahefner.livejournal.com/11670.html
Ah, memories of playing with similar tricks to do split-screen modes on BBC computers. Did it myself for a display when I wanted the full 8 colours¹ for an image (I was drawing fractal things) but decent resolution text for the display of parameters at the bottom.
Some games did this to great effect, like Elite which had mode 4 (mid res, mono) on top for the ship view and mode 5 (low res, 4 colour) for the controls [or in the version enhanced for the extra capability of the BBC Master, mode 1 (mid res 4 colour) & mode 2 (low res 8 colour¹)]. There was one driving game that didn't flip modes but did flip pallets to get more than 4 colours on a mode 1 screen display and that even loaded some code into a strip of the display memory that always shows blue sky (just setting all the pallet entries to blue so the data wasn't visible).
I don't think the technique was fast enough on those machines to work more granularly than per row (or per few rows) though, so no expanding the pallet over the space of one scan line.
--
[1] The BBC supported a mode with 16 pallet entries, but only 8 colours as the other 8 were used for flashing pairs, and those 8 were fixed as the standard primary mixes² instead of anything more flexible
[2] You could change what colours mapped to each pallet entry though - I once saw an attempt to get more colours by flipping the pallet between two options each screen refresh, essentially temporal dithering like some LCD panels did to fake 8-bit colour from a 6-bit panel, this actually worked but was too flickery to be really useful though.
Why is it that Safari gets dragged for not supporting an endless rabbit hole of “web app” standards, and nobody cares that Chrome and Firefox haven’t found the time to get P3 color working in five or six years?
> Why is it that Safari gets dragged for not supporting an endless rabbit hole of “web app” standards
Because there's a contingent of loud HNers who reflexively drag Apple and Safari because they believe:
A. Apple is intentionally limiting Safari to protect its App Store business
B. Apple is some kind of illegal monopoly for only allowing (for now) WebKit as the browser engine on iOS and iPadOS; therefore Apple is evil.
C. Safari is still the buggy and slow to adopt web standards browser from 5 years ago, even though most of them haven't used or tested against it since then. Some of these people claim Safari is the new IE; either they have amnesia or weren't doing web development when IE 6 was the bane of every developer's existence; otherwise they would know better.
D. All the above… and more.
> nobody cares that Chrome and Firefox haven’t found the time to get P3 color working in five or six years?
Unfortunately because Chrome has approximately 70% of the browser market and Firefox's marketshare is in the single digits, if a feature doesn't ship in either browser, it's like the feature itself doesn't exist.
Same thing with the :has() selector… the most anticipated CSS feature probably ever. Safari shipped it in March of 2022 and usual suspects acted like it was no big deal. Chrome didn't ship it until the end of August and Firefox still hasn't shipped.
And even though progressive enhancement is a thing, many of the most vocal posters on HN don't seem to practice it.
They could use the following media query to test for a P3 display, supported by Chrome and Safari:
What lead you to believe nobody cares? One of my biggest complaints about Firefox is it is still in the stone ages of doing ANYTHING outside or sRGB, even video. Chrome at least has long had video and image support and has been working heavily on canvas, CSS, and WebGL color space implementations for display-p3 and rec.2020 as well as participating in the standardization of it. The hard part here is it has to work on more than the way their OS does wide gamut with a single color alternate color space.
An overly-simplistic explanation may be that most engineers don’t care about “how red a red is”, whereas most designers are super interested in their reds being very red.
Both camps can be very vocal, but most of us probably hover around other engineers and sparingly around designers.
> An overly-simplistic explanation may be that most engineers don’t care about “how red a red is”
It certainly is overly-simplistic.
The Display P3 color space is about 50% larger than sRGB… there are many thousands of colors that occur naturally that can't be displayed in the sRGB color space, yet our cameras and phones have been capturing these colors for years.
Not being able to display graphics and images at full fidelity is a form of information loss and most engineers shouldn't be okay with that.
Apple's article "Improving Color on the Web (July 1, 2016)" [1] where they describe how a 2015 iMac and a 2016 iPad Pro had the ability to support Display P3 and how it's supported in the operating system and browser.
The demo picture includes someone's orange sneakers standing on grass; many of the green colors of the grass are outside the sRGB color space. Sure, most browsers will display the closest color it can display but the picture isn't as good as it should be.
Lost among the recent fuss about image support (JPEG XL, AVIF, WebP) is being able to use better color spaces natively without having to attach or embed a Display P3 color profile (which regular JPEG requires) which are often stripped out by CMSes and unaware web developers.
Using Display P3 would probably save online merchants millions of dollars in support costs and returns since fabric dyes are often outside of the sRGB color space and can't be displayed accurately for those customers using (at least today) Chrome or Firefox on non-iOS devices.
What's odd is the latest Pixels from Google don't seem to support Display P3 but every device from Apple except the entry level iPads do. The iPhone 7 from 2016 supports Display P3.
> Not being able to display graphics and images at full fidelity is a form of information loss and most engineers shouldn't be okay with that.
Ultimately, I think it depends pretty highly on the definition of “okay” (as far as the web is concerned, we’ve historically always been okay with many levels of compromise), but I don’t think I’m off the mark in suggesting that the in the hierarchy of concerns of the typical web developer (whatever that may be), P3 color simply isn’t ranked very highly. So “doesn’t care” probably isn’t an entirely accurate way of painting it, but like I said…it’s an over-simplified explanation.
Personally, I like to think that I’m pretty aesthetically inclined compared to a lot of my peers, but this is actually the first I’ve even heard of Safari supporting it!
I think it's also an example of skating to where the puck is going… clearly Apple understood the importance of better color support on the web was going to be important nearly 10 years ago and started working on the hardware and software that would enable it to happen.
> Chrome and Firefox haven’t found the time to get P3 color working in five or six years?
The irony: Chrome and Firefox do support Display P3 on iOS because they use WebKit as their rendering engine. And yet Chrome doesn't support Display P3 on Android…
I don't like when color pickers have a square area, it looks confusing. If you have a triangle it's probably clearer, for example with hwb one corner is for white, another for black, another for the pure color. It works for other 3D color models like hsl https://caub.github.io/color-wheel/build/
> If so, it likely means that your monitor or browser doesn't support wide-gamut color formats. You might have better luck checking on your mobile device!
Does this work on Android for anyone? I tried in chrome on a Pixel 6a, and the two red squares look identical to me.
The only display color setting I found in the android setting was a choice between "natural", "boosted" or "adaptive" but none worked, and I found no settings like "sRGB" or "P3" for screen. Any other setting I may be missing?
> Does this work on Android for anyone? I tried in chrome on a Pixel 6a, and the two red squares look identical to me.
The Pixel 6a hardware doesn't support DCI-P3 Wide Color Gamut; the last Pixel to support this was the 4 XL [1].
Even if your hardware supported DCI-P3, browser support is required; mobile Chrome doesn't support it yet and it's still behind a flag on desktop Chrome, according to Can I Use.[2]
Works for me on a 2018 Moto w stock Android 10.
My color options are (translated) natural, boosted and saturated, w saturated active. Seems to be the factory default.
> Works for me on a 2018 Moto w stock Android 10. My color options are (translated) natural, boosted and saturated, w saturated active. Seems to be the factory default.
Since there's no mainstream browser for Android that supports Display P3, it's unlikely that you're seeing the correct image.
There's a test image as part of this excellent article on color; you'll know right away if your hardware and browser supports Display P3 or not [1].
I'm using Safari on a 2017 iMac, so I can see the Display P3 images.
I thought so too. Clicking around, I had a hunch when I saw "lightseagreen" that these were the old X11 colors, and went looking for "lemonchiffon" to confirm it. (From the text though it sounds like there are other sources as well.)
> Unlike with Sass variables/functions, which compile away into hardcoded values, CSS variables are dynamic. We can tweak any of these values using JavaScript, and all the other ones will automatically update.
Might someone share a link - with a high signal to noise ratio - to a CodePen or tutorial that demos / gives examples of this? Perhaps some use cases as well?
I'm intrigued, but not experienced enough to know the best place(s) to start.
I explained why "we" (web developers) should want CSS custom properties (also known as CSS variables) versus Sass-style variables a couple of weeks ago when the CSS Working Group asked for feedback on nesting syntax.
I included a couple of links to high signal-to-noise ratio articles on the advantages and use cases of CSS variables [1].
He popped up on one side when I was in the middle of the article and said "Hope I did not startle you. May I interest you in my newsletter?". I said "No thanks" and he went away.
And when I reached the end of the article, there he was again -- sitting on a small mound, and waiting patiently for me to finish reading and get there eventually.
Somehow it felt very "natural" that he would wait for me at the end -- knowing I would meet him there again, just in case if he could be of any help.
Loved the little touch. Not sure if the author/designer meant it this way though.
The "named colors" example of darkgray being "lighter" than gray disrupted my reading, because darkgray is obviously and significantly darker than gray on my system.
Was this comment written by ChatGPT? Because it has the same level of casual tautology (The first sentence especially; "the reason it's lighter is because defined that way") and confidently incorrect information.
The whole gray/dark gray thing has practically nothing to do with sRGB, it's an artifact of one being an X11 color and one not.
The great content and didactics aside, it is the bomb proof interactive elements that do it for me. More often than not, sliders don’t work on phones and/or break scrolling. Not here.