Re: [compositing] Incorrect recommended implemntation of mix-blend-mode: saturation

Hi, I would just like to put into perspective the comments you've both made
about "adobe" products being the background for people who will with deal
the ramifications of this specification. The web is expressly open and
free. In perfect contrast, Adobe is expressly copyrighted and expensive.
I've made it 32 years without needing an adobe product to produce anything.
90% of the people who will deal with `mix-blend-mode: saturation` as web
developers in the next decade will not have used an adobe product to
produce anything. I can say this with confidence because 90% of software
developers (at least in Australia) are between the ages of 7 and 17, and
are build simple web pages as part of our school curriculum.

Ignoring children, I will concede that almost every designer I've worked
with will use either illustrator or photoshop for their roughing-in
prototypes, so they will likely either be coming from a adobe background or
will learn to use an adobe product in some capacity during their career.
But the designer to developer ratio is around 1:20 in my experience; and
developers are writing way more css.

Similar critique applied whatever else you're referring to as graphic
design software, I've personally never used any of it, and I would expect
that the majority of others who are building web pages in the next decade
won't have used it either. Unless we're referring to MS Paint, but I'm
fairly sure MS Paint doesn't want to be capable of thinking about
blend-modes.

On Sat, Apr 3, 2021 at 3:45 AM Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Fri, Apr 2, 2021 at 9:40 AM Callum Morrisson
> <morrisson.callum@gmail.com> wrote:
> >
> > It's unclear why you would think adobe products should dictate a web
> standard. The colorspaces in web development (atleast at the minute) are
> RGB and/or HSL. Within that frame of reference, "adobe" and this
> bastardised version of saturation make no sense. Similarly the idea that
> Luminance should be derived from the YIQ color space also seems to make no
> sense (I went down a rabithole looking for where those magic numbers come
> from, and the Y(Luma) in YIQ seems to be it).
>
> Note that the definition of Luminance and Saturation here have nothing
> to do with LCH. LCH is actually based on measuring human vision, and
> converting to it from RGB requires some non-trivial matrix math, which
> is definitely not going on here. Everything in this spec is RGB-based.
>
> The spec's notion of Saturation isn't quite HSL saturation (HSL
> saturation is (max - min) / (max + min), or a slight variant if the
> color is lighter than 50%), but it's close. The spec's notion of
> Luminance is a reasonably common quick-and-dirty approximation of
> human-vision luminance based on RGB channels; it's not accurate, but
> it's close and fast to compute.
>
> Using Adobe's definitions here made sense, because between PDF,
> Photoshop, and other tools, and the large swathe of non-Adobe graphics
> tools that nevertheless want to present similar options to aid in
> usability, these definitions should be familiar to designers coming
> from such software. There doesn't seem to be a great reason to be
> gratuitously different, particularly since the math underlying HSL
> isn't very human-compatible in the first place. It does mean that if
> you're trying to reason about what exactly will happen to an image by
> thinking about its HSL colors you'll be slightly misled, yes, but
> that's a tradeoff we felt was reasonable to make given the concordance
> with existing graphic design software.
>
> ~TJ
>

Received on Friday, 2 April 2021 22:52:11 UTC