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
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.

sign up or login to add to the discussion
Labels

None yet.

assignee

None yet.

Participants 2
AT URI
at://did:plc:hlchta7bwmobyum375ltycg5/sh.tangled.repo.issue/3mbup5yxfeu22