One grey rectangle on a code-hosting site was four separate bugs

The top of a code-hosting site rendered as a row of pale grey blocks on a dark bar, with the menu labels cut off halfway through their own words. It looked like one bug. It was four, and the only way to tell them apart was to walk every element sitting under that grey block and ask each one, on the real page, what the reference browser computed for it and what we did. The first: a button that clears its own background with the single most common reset on the web, `background: none`, kept the default grey the browser gives every button. A shorthand is supposed to reset everything it controls, and this one was not resetting the colour. The obvious fix is a trap -> the test for whether a value carries a colour knew a list of colour names and nothing about the modern colour functions, so a first attempt at it quietly erased any colour written as oklch or lab or a mix, which is a far more visible break than the one being fixed. So the rule was inverted: clear the colour only when every part of the value is provably NOT one -> an image, a position, a repeat -> and treat anything it does not recognise as possibly a colour, left alone. The second only appeared once the first was fixed: a box whose background is written as fully transparent lost its border entirely. A see-through colour was being treated as a colour that paints, taking a branch that then drew nothing and skipped the border on the way. That is why a circular avatar with a coloured ring around it, the commonest place an author writes `transparent`, came out with no ring at all. The two ship together because the second was unreachable until the first was fixed. The third is the one that clipped the labels. A code-hosting site sizes every one of those menu buttons through a design-system variable that, as it happens, is not defined on the page at all. The standard is exact about this: a value that leans on a missing variable is thrown out whole, and the property falls back to what it would inherit. We were substituting an empty string instead, so the font size came out as nothing and the text was measured and laid out at no size, which is why each label was cut short. It now does what the standard says -> the declaration is dropped, the inherited value is put back, and a shorthand written that way takes all of its pieces down with it rather than keeping the half that happened to parse. The fourth: a button told to lay its label and a chevron out in a row was filling the whole width available to it instead of hugging its contents, four hundred pixels where the reference browser gives it a hundred. A button sizes to its content whatever layout mode it is put in, and now it does. The engine's own test suite grew by twenty-eight cases across these, each written so it fails without its fix, and the whole gate holds at 6370 of 6370. One piece of that navigation bar is deliberately left for next time and named honestly: the button now computes the right font and the right background, matching the reference browser exactly on the live page, but still sits narrower than it should because it is being squeezed below its own minimum width as a flex item -> a floor the engine already has, not yet reaching this particular nesting.