Merge pull request #298 from Coffey-Labs/docs-catchup
Catch the README and FEATURES up with the themes and 0.16.21
This commit is contained in:
+30
-7
@@ -365,7 +365,15 @@ same query string — so what it builds can be read, edited and learned from.
|
||||
these headers shows nothing.
|
||||
- **Message body theming** is off by default — sender HTML is left exactly as it
|
||||
was designed, on a light card. One setting lets mail that brings no colours of
|
||||
its own follow the app's theme instead.
|
||||
its own follow the app's theme instead. That is a low bar in practice: one
|
||||
`color:#FFFFFF` on one button label opts a whole message out, so for mail
|
||||
built from a template it changed nothing. A second setting, off unless the
|
||||
first is on, forces the theme over the sender's own colours. It tells a
|
||||
*sheet* the design sits on, like a white wrapper table, from a *painted
|
||||
surface* like a button or a banner, by relative luminance: the first is
|
||||
neutralised so the bright card goes away, the second is kept whole so its
|
||||
label stays readable on it. Nothing the sender wrote is removed, so the
|
||||
switch is reversible, and print is unaffected either way.
|
||||
|
||||
### Conversations
|
||||
|
||||
@@ -1019,11 +1027,17 @@ at two.
|
||||
| **Gruvbox** | |
|
||||
| **Rosé Pine** | Dawn as its light half |
|
||||
| **Tokyo Night** | Day as its light half |
|
||||
| **Catppuccin** | Mocha and Latte |
|
||||
| **Solarized** | Light and dark are both original to it, and share one set of accents |
|
||||
| **Ayu** | |
|
||||
| **Kanagawa** | Wave, with Lotus as its light half |
|
||||
| **Everforest** | The medium-contrast variant of each side |
|
||||
| **Primer** | The colours behind GitHub's design system. Named for the system, not for GitHub, which has not endorsed anything here |
|
||||
|
||||
Every one has both halves, so the top-bar toggle only ever changes the side and
|
||||
never the colours. Accent colours still sit on top of any of them.
|
||||
|
||||
The four borrowed palettes are the work of their own projects and are used
|
||||
The ten borrowed palettes are the work of their own projects and are used
|
||||
under the MIT licence — see [NOTICE](NOTICE). Only the published colour values
|
||||
are used, taken from each project's own repository; the values as fetched are
|
||||
recorded in `.palette-sources/palettes-upstream.md`.
|
||||
@@ -1037,11 +1051,20 @@ anything that falls short, towards white on a dark ground and towards black on
|
||||
a light one so the hue survives. The script refuses to write a palette that
|
||||
would not pass.
|
||||
|
||||
That check is not a formality. **Every one of the nine palette halves needed at
|
||||
least one lift**, because these palettes are designed for code editors rather
|
||||
than for prose at this size: Dracula's comment grey is 3.03:1 on its own
|
||||
background, and Rosé Pine's gold is 2.7:1 on Dawn. Shipping them as published
|
||||
would have quietly ended the WCAG AA claim two sections down.
|
||||
That check is not a formality. **Twenty-one of the twenty-two palette halves
|
||||
needed at least one lift**, because these palettes are designed for code
|
||||
editors rather than for prose at this size: Dracula's comment grey is 3.03:1 on
|
||||
its own background, and Rosé Pine's gold is 2.7:1 on Dawn. Shipping them as
|
||||
published would have quietly ended the WCAG AA claim two sections down.
|
||||
|
||||
Body text is lifted the same way, which it was not at first. It used to be
|
||||
checked and then either accepted or rejected, and that rule would have turned
|
||||
away five of the six palettes added in September 2026: most of them target
|
||||
around 4.5:1 for body text, their own goal, where ihasmail asks 7:1 of the text
|
||||
a reader looks at all day. Rejecting a palette over a bar its designers never
|
||||
aimed at is the wrong answer when the same arithmetic already adjusts muted
|
||||
text, links and accents. Solarized Light moves 4.13 to 7.07 that way; Primer
|
||||
needed nothing in either half.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -71,6 +71,7 @@ More, including the mobile layout, on [ihasmail.org](https://ihasmail.org/#scree
|
||||
- **Settings that follow the account**, not the browser — kept in a `settings.json` in the account's own JMAP Files, so ihasmail itself stays stateless
|
||||
- **Runs read-only** — one optional write path, and with it switched off the container needs no volume and no writable root. `IMMUTABLE=1` is checked at startup rather than trusted, so a half-applied switch refuses to boot instead of failing quietly. See [Running immutably](#running-immutably)
|
||||
- **Nine new interface languages** — German, Spanish, French, Dutch, Portuguese (Brazil), Russian, Ukrainian, Simplified Chinese and Japanese, alongside English and separate from the date-and-time locale. Every one is marked **Beta**: they were made by AI and no native speaker has read them yet, which Settings says plainly, with a link for reporting anything wrong
|
||||
- **Twelve themes** — Classic and ihasmail's own, plus Catppuccin, Dracula, Gruvbox, Rosé Pine, Tokyo Night, Solarized, Ayu, Kanagawa, Everforest and Primer, each with the light and dark half its own project publishes. Palette and light-or-dark are separate choices, and the accent colour still sits on top of any of them. Only published colour values are used, taken from each project's own repository; the shades between them are derived and every text colour is measured against the surface it sits on, so a palette that would not meet the contrast this app claims is not written at all — see [Themes](FEATURES.md#themes)
|
||||
- **On a phone** — swipe a message to archive or delete it (either direction, your choice), hold one to select it, hold a folder for its menu, pull the list to refresh, swipe back from a conversation
|
||||
- **Platform** — installable PWA, Web Push with ihasmail closed, `mailto:` handler, no credentials in the browser, strict CSP, SSRF-safe image proxy
|
||||
|
||||
@@ -86,6 +87,17 @@ wrong guess had somewhere to fall back to, so it failed *quietly* — and that
|
||||
reached production. With one supported generation a wrong guess is a loud error
|
||||
on the first call.
|
||||
|
||||
**Validated against 0.16.21**, released 6 September 2026: the app was run
|
||||
against a real instance of it and the mail, calendar and contacts paths were
|
||||
exercised by hand. Four of that release's JMAP changes are visible to a client
|
||||
— an occurrence of a recurring event is now identified by its recurrence id
|
||||
rather than by its position in the series, so an id held across a write no
|
||||
longer silently names a different date; `Calendar/get` and `AddressBook/get`
|
||||
return every property when none are named; EventSource advertises its ping
|
||||
interval in seconds rather than milliseconds; and a calendar write that asks
|
||||
for scheduling messages is refused when the account may not send them. The mock
|
||||
reproduces all four.
|
||||
|
||||
- Still on 0.15? The last release that runs on it is tagged [`stalwart-0.15-support`](https://github.com/Coffey-Labs/ihasmail/releases/tag/stalwart-0.15-support).
|
||||
- Upgrading? [stalwart-migrator](https://github.com/Coffey-Labs/stalwart-migrator) does it in place, checkpointing every phase and validating afterwards. The live instance moved 0.15.5 → 0.16.19 with eight seconds of downtime and nothing lost.
|
||||
|
||||
@@ -362,9 +374,17 @@ without a real mailbox. It reproduces the things a naive fake would get wrong,
|
||||
because each cost a live debugging session: `urn:stalwart:jmap` advertised
|
||||
**per-account** rather than session-level, identity signatures capped at 2047
|
||||
**bytes**, and `CalendarEvent/set` speaking Stalwart's vocabulary rather than
|
||||
RFC 8984's. Two switches: `MOCK_NO_FUTURE_RELEASE=1` advertises FUTURERELEASE
|
||||
RFC 8984's. Three switches: `MOCK_NO_FUTURE_RELEASE=1` advertises FUTURERELEASE
|
||||
and then drops every hold; `MOCK_NO_REGISTRY=1` omits the Stalwart capability so
|
||||
the sign-in refusal can be tested.
|
||||
the sign-in refusal can be tested; and `MOCK_NO_SCHEDULING_SEND=1` refuses a
|
||||
calendar write that asks for scheduling messages, the way an account without
|
||||
that permission is refused.
|
||||
|
||||
It tracks the current release rather than 0.16 in general, and each behaviour
|
||||
is confirmed against a real server before it is copied here — the comments say
|
||||
which version and on what date. Where a release changes something a client can
|
||||
see, the mock changes with it, and the test that pinned the old behaviour is
|
||||
rewritten rather than deleted, so the reversal stays on the record.
|
||||
|
||||
### Version numbers
|
||||
|
||||
|
||||
Reference in New Issue
Block a user