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: