Shared lexicon schemas for long-form publishing on AT Protocol. Uses typescript to json via prototypey.

`site.standard.(palette|theme).basic` should include luma/contrast/bright/dark #3

Open mrpowershell.com
Open opened by mrpowershell.com

The current standard lets you specify a palette, but does not indicate if it is a light or dark palette.

To do this one needs to calculate Luma:

        filter GetLuma {
            $colorString = $_
            # Convert the background color to a uint32
            $rgb = ($colorString -replace "#", "0x" -replace ';') -as [UInt32]
            # then make it into a percentage red, green, and blue.
            $r, $g, $b = ([float][byte](($rgb -band 0xff0000) -shr 16)/255),
                ([float][byte](($rgb -band 0x00ff00) -shr 8)/255),
                ([float][byte]($rgb -band 0x0000ff)/255)
        
            # Calculate the luma of the background color
            [Math]::Round(
                0.2126 * $R + 0.7152 * $G + 0.0722 * $B,
                6
            )
        }

Once one has computed the background color luma, you know if the palette is Bright or Dark.

I normally use a cutoff of: if ($luma -gt 0.4) { "bright" } else {"dark"}

While you're there, calculating Contrast is also pretty straightforward:

[Math]::Abs(($foreground | GetLuma) - ($background | GetLuma))

Why does this matter?

Quite a few reasons, but @media queries and personal preferences spring first to mind.

With at least a Luma value, it's pretty easy to determine if a palette is bright or dark, and this makes it much easier to pick between palettes.

Also, as I write out this issue, I'm realizing it's a good additional justification for why it should be palette, not theme - a theme might include a bright or dark palette, but a palette is either bright or dark.

we considered this. the challenge is where the calculation happens.

if we add luma or contrast to the lexicon, the platform or publication creating the record has to calculate it. not everyone has the tooling to do this easily. we have people manually creating these records for existing off-protocol blogs already. requiring luma calculations adds friction. avoiding calculations is the reason we went with bg/fg and accent bg/fg.

the alternative is having apps calculate luma themselves from the color values. that is straightforward enough for apps to do, and keep records simpler to create. apps that need light/dark mode can derive it. apps that do not can use the existing colors in the record.

I see that problem and agree that calculating luma would be a tax not all developers would be willing to pay.

Let's make them optional fields on whatever palette/theme consensus is reached.

What about keeping it simple and letting publications optionally define a dark theme? Renderers can then check for it's presence when a client is detected as being in dark mode and use it instead. No calculations needed, just leave it up to publication authors to specify a dark version of their own themes.

I suppose that assumes current themes are light, which may not be the case. Either way, the basicTheme object could be updated to optionally accept an object with { dark: <theme>, light: <theme> }, while still allowing the current single theme definition as well.

Since media queries themselves resolve to simply dark or light this feels well-enough aligned with the web platform, without needing to get into luma calculations.

Surely there's something I'm missing here. Let me know!

Sign up or Sign in to add to the discussion.