In my experience product quality is an extremely poorly understood concept in organisations.

Typically there isn’t a shared understanding of what it means. Different people have different mental models. As a result two people may both believe they are improving product quality, but believe the other people are working on something futile.

Let’s see what Wikipedia has to say:

In business, engineering, and manufacturing, quality has a pragmatic interpretation as the conformity of something (goods or services); it is defined as being suitable for the intended purpose (fitness for purpose) while satisfying customer expectations.

Great - thanks for that word soup.

As an exercise for you the reader - ask yourself how you define quality in your product. Ask your colleagues. Better yet, if you really want a fun exercise, ask your leadership - see if they come up with a similar word soup.

Your answers will likely vary wildly. Instead many organisations will agree on some vanity metrics. These might include:

• Number of bugs open
• Latency at the 99%-ile
• User churn rate
• CSAT (Customer Satisfaction Score)

These metrics aren't bad in themselves, but they are proxies for quality.

You might be thinking to yourself - “Okay smarty-pants, what is quality then?” I'd argue it is very simple, but difficult to measure.

Product quality is how the customer feels about your product - what emotions does your product produce when used?

That's it. That's the whole ball game. If you squint other definitions match this, but not before they've confused the hell out of everyone.

Now we get to the hard bit. What emotions do you want your customer to feel about your product?

Broadly speaking emotions can be grouped into “positive” (delight, pride, interest) and “negative” (annoyance, irritation, fear, worry).

The first thing you probably want to optimize for is to ensure your product doesn’t trigger any major negative emotions. A single major negative emotion can completely crowd out a dozen positive ones.

For example - if you produce a phone which spontaneously combusts - even if the customer really loved the design/color - they’d be hard pressed to ever trust your brand again.

A great recent example is Engineering Explained’s review of the Lucid Air. I implore you to watch this video, and see the range of negative emotions. He bought this car and genuinely believed this was the “best engineered vehicle the world has ever seen”. Jason likely was excited/elated/etc by his new purchase. Only for a wave of negative emotions to push those out.

What does this mean for you?

You should deeply care when customers are frustrated/irritated/annoyed by your product. If you are trying to improve product quality, this is the first thing you should focus on. Have a product that doesn’t reliably turn on the lights when asked? You should probably fix that before anything else. Have a product that takes 10 seconds to respond to a query? You should probably fix that.

From this you can start building proxy metrics. E.g. latency at the 99%-ile might matter! (Especially if it's 10 seconds!) But it might not matter anymore once it's below 200ms. (What matters performance wise is a whole separate blogpost which I should write someday).

The rate of incoming bug reports is also typically a good metric. “How fast are people filing bugs compared to the last version?” (Assuming the way people file bugs between versions is exactly the same).

An important thing to note here is that if a customer feels no emotion that is a good thing. If a customer successfully pays some bill and feels absolutely nothing, that’s great! It means that the experience was frictionless and you made it as easy as possible.

Minor annoyances are also okay. If an animation occasionally stutters or a setting is buried a couple of levels deep, that’s usually fine—as long as the majority of your customers aren’t experiencing it. You shouldn’t go on a crusade to ensure there are absolutely no negative emotions, you need to spend your time wisely, focus on the major/severe issues (even if limited to a few customers) or widespread ones.

Once a product has a solid foundation (your customer doesn’t want to throw your product out a window), you can start to care about the minor annoyances if needed, and the positive emotions.

A design refresh can really matter! It can take something boring to use and make it delightful (think about how fun tapping a like button was the first time popping up little hearts). But this shouldn’t be at the cost of making the product harder to use and frustrating customers.

Marketing really matters too! It can predispose the customer into feeling excitement or anticipation when first using your product. This is also why the OOBE (Out of Box Experience) is so important. Your first interaction with the product predisposes the customer.

However a common trap for organisations is to believe that the positive emotions e.g. triggering delight is the only thing that matters, and believe that if customers “love” a product enough they will overlook the desire to throw it out the window.

This isn’t the case.

So what should you do? Firstly make sure that everyone has a shared understanding of what you are optimizing for. As I’ve argued for here I think a customer's emotions define product quality. But you should get everyone singing from the same hymn sheet.

Next ensure that your proxy metrics (latency, churn, bug rate) actually match this shared understanding. One metric I hate for example is open bugs, the metric you should actually care about is incoming bug rate (even if those issues are merged into others).

Finally, when it comes to prioritization, use this quality framework to advocate for what your customer actually needs - rather than a vanity project that will be deprecated in six months.

Questions/thoughts/comments? Reach out to me on BlueSky.

This started off as a general "2025 in-review" but ended up too boring and too long, so here are just a handful of things I'm proud of last year. These aren't necessarily the most important work I did, or the most "impactful", but things that gave me joy, and hopefully will pay dividends in the future.

flex-wrap: balance

I spent a month or so implementing flex-wrap: balance. A lot of this time was just spending time trying to understand different academic papers which implement different solutions to the Knuth-Plass line-breaking problem.

In the end, some of the solutions were too difficult to understand (research papers often gloss over important details, have poorly named variables, and also have bugs), so I ended up implementing something different/new instead. I primarily did this so that it will be maintainable, at some point someone might find an issue with the algorithm I used and will need to fix it.

I settled on something that was O(N) in the common case, and I think converges to O(Nlog(N)) in the worst case (the naive solution is O(N^2) which is truly the worst complexity).

Many people have wanted this feature since ~forever - hopefully we can give this to developers soon.

I use flex-wrap: balance in my other blog post this year to build an image gallery with flex.

Flexbox Precision Issues

Rounding errors typically don't matter that much for most applications. They do in layout engines, however, as it often results in a "gap" between the content of an element, and the element's border. This (rightfully) infuriates people.

Web layout engines use fixed-point arithmetic, (instead of floating-point) so when you divide a layout number by an integer you end up with a remainder.

Fixed-point is used as floating-point gets more inaccurate the further away from zero you get leading to gaps and other layout issues (someday I'll write a "floating-point is the worst" blog post).

Previously we discarded this remainder, and as such resulted in gaps when you used justify-content: space-between on a flexbox as one example.

I implemented a "diffuser" which can diffuse/distribute the remainder over N buckets in a "nice" way. Under the hood this uses the core component of Bresenham's line drawing algorithm which is a fun 2D graphics cross-over.

The other precision issue I worked on was rounding issues within the floating-point calculation of how flex-grow/flex-shrink are used. The solution I ended up with is actually used within Gecko's flex implementation; in hindsight, I should have read that first.

It works by calculating the fraction of the remaining available space (instead of the total available space), which converges without underflow or overflow.

Fixing both these precision issues resulted in a non-trival number of bugs fixed.

The SVG Viewport Dependence Optimization

This was my first substantial optimization change for the year, as well as a nice win code complexity wise. In the end it was only worth about 0.1% on Speedometer3 but removed a bunch of complex logic maintaining HashMap on a hot codepath.

This optimization essentially removed a HashMap containing elements which had geometry which depended on the SVG viewport (<rect width="50%">) as one example. It replaced it with a couple of bits computed during layout instead.

Many performance/code-complexity improvements I've made within Blink have been just removing HashMaps. It’s an interesting phenomenon, lots of developers will reach for HashMaps as they are "fast" O(1) insertion/removal is hard to beat, but often the slowness is caused by a piece of code looping over every element within the map (making it just a fancy list at that point), or a HashMap placed on a hotpath where the insert and contain operations eat CPU cycles.

The logic for maintaining these HashMaps are often very complex and fragile, and in my experience leads to bugs in browser engines.

Maybe one day I'll write a "HashMaps are the worst" blog post detailing this further.

Fixing <video> with aspect-ratio: 4/3 auto

There has been a relatively bad bug in Blink with the <video> element and the aspect-ratio property, namely we ignored the aspect-ratio coming from a video once it had loaded.

The issue with fixing this bug was that every engine did something different, and since time immemorial the <video> element has had a default aspect-ratio of 2:1.

There were many web-platform-tests asserting this behaviour, as everyone actually did the same thing for the basic case.

The final fix was very straight-forward, but first required getting everyone to agree that everyone was wrong, and us proving that the proposed change was web-compatible (fortunately Hyrum's Law didn't apply today).

Other engines implementing "block-in-inline"

A few years ago we removed a significant code-complexity burden from Blink which is known as "inline-splitting". We inherited this from WebKit and caused major issues for us (and a security issue or two). The CSS2 spec also (unhelpfully) suggests that engines should implement this problem this way.

Why it's bad is a whole "Ian rants at you for an hour" type scenario - so let's not get into that today.

We've since ripped this code out, and now both WebKit and Servo appear to be implementing this approach as well last year (hurray!) and this should fix some well known bugs.

I don’t think I can claim the original idea, (it potentially was a suggestion from an EdgeHTML engineer), but I believe it is evidence that working in the open, and writing down how/why you did something can help out others in the same space later on.

Merging Anonymous Table Parts

My final piece of work in 2025 was trying to fix a cluster of issues caused by not merging anonymous table-parts correctly.

When you have an element with display: table-cell it implicitly creates a table, table-section, table-row surrounding it. If you have two display: table-cells next to each other they belong to the same anonymous table, etc.

We had a long standing issue that when you removed or changed the display of an element, we didn't "merge" these contiguous anonymous table objects correctly.

There have been attempts to fix this within Blink before, but ended up causing crashes and other issues. I spent a bunch of pre-work fixing things that might have caused crashes previously, and landed a patch to merge these objects. This should be out in the wild in February (so fingers crossed), and should fix a non-trivial amount of bugs for web-developers.

There are lots of other things I did work-wise that didn't make the cut (helping ship width:stretch, CSS anchor positioning fixes, various performance optimizations, removing -webkit-box quirks).

Let's see where 2026 takes us!

There are lots of different ways to construct image galleries on the web. When building these it's desirable to:

• Maintain the aspect-ratio of the images.
• Reduce/remove any "whitespace"/"free-space" present (ideally you want all the images to fill the entire space available) aka full-bleed.

These two constraints are often at odds with each other. Google photos has previously described in detail how they have previously tried to solve this. A simple solution which web-developers often use is a wrapping flexbox, however this often leaves whitespace at the end of each flex-line (leaving a ragged edge).

There is a solution to this by using the flex-grow property (potentially one of the few reasons to use flex-grow with a non-zero or one value).

.gallery {
  display: flex;
  flex-wrap: wrap;
  flex-wrap: balance; /* "balance" will be better once available. */
  gap: 24px;
}

/*
  This assumes the content is of the form <img width=100 height=100>
  However, it can be adjusted on any content via. the aspect-ratio property.
*/
img {
  --ar: attr(width type(<number>)) / attr(height type(<number>));
  width: calc(20% * var(--ar));
  height: auto;
  flex-grow: calc(var(--ar));
}

That's it!

What is this magic?!?

How this works is a little quirky:

1. The images in their initial form (with width: 20%) will look something like this:

   

   First we calculate the aspect-ratio from the width and height attributes on the image, via. the new attr() function available in CSS:

   img {
     --ar: attr(width type(<number>)) / attr(height type(<number>));
   }

   attr() is currently only available in Chromium based browsers, but could be set manually via script.

2. We use this aspect-ratio to override the width of the images. By setting the width proportional to the apsect-ratio (calc(20% * var(--ar))), we ensure that every image will have the same height before wrapping and growing. For example:

   

   At this stage we are left with images which all have the same height, but have a ragged edge once broken into lines.

3. We then use flex-grow so that each image will grow proportionally to its aspect-ratio. This ensures that each image will keep the same height as others on the line, but will fill the remaining space.

   

   Each line will end up with a slightly different size, but all the images keep their aspect-ratio!

Downsides?

Like anything there are some potential downsides.

• We are ignoring the pixel sizes of the images, it's possible under this scheme to scale up an image past its natural pixel size (causing pixelation).

• Due to the way flex line-breaking works, it's possible for a single image to be placed on a single line. This often looks bad, but will be mostly fixed once flexbox receives flex-wrap: balance.

  Chromium/Blink has an implementation of flex-wrap: balance behind chrome://flags/#enable-experimental-web-platform-features.

Both of these issues can be mitigated by adding something like:

img {
  max-width: min(100%, calc(50% * var(--ar)));
}

This will prevent images with too much space on a line from growing too much. But will potentially leave some space on the line.

Questions?

If you have any suggestions/comments/questions or a cool name for this technique feel free reach to me on Bluesky.

A JSFiddle of this approach can be found here.

Images used in the demo(s) are from Lorem Picsum.

A live demo is below: