Add <meta> tag for `theme-color` attribute

[privorotskii]

Fixes issue

• Add theme-color tag
  • Update it's content based on --land-color CSS property

Motivation

• The motivation is to add the styling of top bar for Chrome on Android
  • note Chrome on Android supports it only within light theme
  • note Safari also supports this tag, but it colors top bar without this tag by itself

Screenshot or video

Chrome Android:

Before	After

Safari (no changes):

Before	After

Checklist

• [x] Don’t rush. Check all changes in PR again.
• [x] Think about changing documentation.
  • If you added a script to scripts/, add a comment with a description.
  • If you added a new folder, add its description to the project’s README.md.
  • If you added config, describe how we use this tool in the config’s comment.
  • If you added something to the project’s architecture, describe it in the project’s README.md.
  • Try to focus on “why?”, not “how?”.
• [x] If you added a new dependency, check our requirements.
• [ ] Think about testing
  • If you added a feature, add unit tests.
  • If you added a new state to the UI, add visual tests.
  • If you fixed the bug, think about preventing bug regression in the future.
• If you changed web client:
  • [x] Think about moving code to core/. What code will also be useful on other platforms?
  • [x] Run pnpm size and check the difference in the JS bundle size. Is it relevant to the changes? Change the limit in web/.size-limit.json if necessary.
  • [x] Think about keyboard UX. Is it easy to use the new feature with only one hand on a keyboard? Is it easy to understand what keys to press?
  • [x] Think about HTML semantics.
  • [x] Think about accessibility. Check a11y recommendations. Think about how screen reader users will use the tool. Is it easy to use on a screen with bad contrast?
  • [x] Think about translations. Will
  • [x] Think about right-to-left languages. What parts of the screen should be mirrored for Arabic or Hebrew languages?
• If you changed the colors token in the web client:
  • [x] Think about app loading styles inlined in index.html.
• If you changed core/:
  • [x] Think about making types more precise. Can you better explain data relations by type?
  • [x] Think about conflict resolution. We don’t need some very smart changing merging; just 2 changes of the same item on different clients should not break the database. What if the user changes an item on one machine and removes it on another?
  • [x] Think about log and storage migration.
• If you changed English translations:
  • [x] Change translation ID if you change the meaning of the text.

[privorotskii]

Hey @ai, I think I'm a bit stuck here Here's what I tried and why it didn't work out:

• #idea Just use the var(--land-color) as a tag content
  • #issue Neither Safari nor Chrome support var as a content.
  • Which, probably, makes sense from some point of view — is HTML tag, HTML itself doesn't know about CSS functions
• #idea Use two tags, one for dark theme, one for light theme
  • #note We can do that using the media attribute, e.g. <meta name="theme-color" media="(prefers-color-scheme: light)" content="..." />
  • #issue We have not only dark or light themes, we also have different pages — slow and fast which have different --land-color property we'd like to use
• #idea Use JS to get the computed value of the --land-color
  • #issue The --land-color has value using color-mix function which isn't supported by this tag

So what I did in order to get the working version is taking the actual background colors via colorPicker and converting them to oklch. I added those values as new CSS properties, but it doesn't feel like a good way to handle it:

• It reduces the sense of using color-mix for the --land-color since it's actually the same color, but in different notation which is harder to edit
• It's now needed to keep in mind to update this variable if the --land-color is updated, which is not obvious and could be missed at some point
• Not sure, but it could be probably different colors with --land-color, some discrepancies in the convertation process could arise

Does it make sense to do it this way or it's better to wait for better support from browsers? Or are there any better ideas? I'm open to any discussions and suggestions

[ai]

Good research 👍. I suggested a way to avoid browsers limits.

[ai]

Next time, don’t forget to run pnpm test before creating PR.

[privorotskii]

@ai I did, it passes for me on this branch. Was something wrong after merging? Asking in case it behaves differently on different machines or not

[ai]

Size Limit was wrong.

https://github.com/hplush/slowreader/actions/runs/8507486659

Maybe after rebasing on new main branch.