A list of titles and addresses is what a browser's own bookmark bar does. The
reason to keep pages here is that they have been fetched and archived, and a
grid of covers is the cheapest way to show that.
── Which picture, and the trade it costs ──
A crawled bookmark carries two: `content.imageUrl`, the page's own og:image, and
a `screenshot` asset Karakeep took and stores itself. The screenshot is better -
archived, cannot rot, never leaves the house - and it is unreachable from an
`<img>`: Officer authenticates with a bearer token in a header and a browser
cannot put a header on an image request, so the asset route answers 401 from
markup. Fetching each as a blob would work and costs a request, a decode and an
object URL per card.
So the origin's image, with referrerPolicy="no-referrer" so those sites learn
nothing about where the request came from, and loading="lazy" so a long grid does
not fetch a hundred at once. The honest cost, written at the point of use:
viewing your bookmarks makes requests to the sites they point at. Proxying the
archived asset is the fix if that ever matters.
── The empty state is three states ──
Not crawled yet, crawled with nothing to find, and a picture that failed to load.
The first is temporary and the others are not, so it says "fetching…" and the
header counts how many are still going. Measured on the live instance while
writing this: 6 of 50 crawled, the rest pending - so a fresh import spends a
while looking like a broken panel unless it explains itself.
Grid is auto-fill on a minimum width rather than a column count, because this is
one pane of a layout the owner can drag and the columns have to follow the width
it is actually given.
pastilhas
da94c6d7ff