Build journal: card composition and CSS drift

The articles section is now the center of the home screen. It has a featured item, a list of recent items, and a header that will eventually control the time window. Most of the week went into the layout and the small decisions that make a feed feel like a designed surface rather than a repeated card.

One card, two scales

The featured article needed a larger title than the ordinary cards. The first idea was content projection: let the parent supply the title markup so the same card could carry either size. That worked, but it also showed the cost of the approach. A component that accepts its most important content from outside is harder to understand at the call site, especially when the default is not obvious.

A better long term option might be an input that changes the presentation mode. That keeps the card in control of its own title while allowing the parent to request a larger variant. The lesson is not that content projection is wrong. The lesson is that projection is most useful when the shape of the content genuinely varies, not when one style needs a different font size.

Styles that need permission

The card's internal styles were placed on the host selector so a parent could adjust some of its outer behavior. That made the featured variant easier to position. It also created a subtle coupling. A component with too many host styles is no longer fully independent. The parent has to know which visual properties are part of the contract.

CSS was beginning to drift. Every small change added another class or an override. The project did not need a new framework. It needed a clearer set of visual decisions: spacing scale, type scale, card behavior, and a small number of layout primitives. Without those, the stylesheet becomes a record of every local negotiation.

The unfinished header

The article section header is still incomplete. It needs a way to choose a time window and a clear indication of the current selection. The data path is ready enough to support it, but the interface needs a smaller, calmer design than a toolbar full of controls. A feed is a reading surface first. The filters should support reading, not compete with it.

Notebook note: a component contract includes its styles. If a parent can reach into everything, the component is only reusable in theory.

The next pass

The next week would add the tag store and join the tag list to the API. It would also be a chance to see whether the article and tag patterns could share more without turning into one vague service. That question would follow the project for several weeks.