CourtBouillon

A Fresh New Flex Layout

That’s a Long Story

The Flex layout has a long history in WeasyPrint.

In 2017, some of our users wanted WeasyPrint to get support of the new shiny Flex layout, that all the cool CSS kids were using at the moment. This layout was supported in major browsers since at least 2015 (Edge being the last one), and it was slowly but massively adopted by web creators.

It was time to implement the Flex layout in WeasyPrint. These users even helped us to write code, but of course, things are never easy…

At this moment, apart from tables, WeasyPrint was only able to handle the common block and inline layouts. Adding a new type of layout is not an easy task, and as it was the first time, a lot of mistakes were made. But well, in version 0.42, the day after Christmas 🎁 2017, WeasyPrint had an initial support of Flex. That happened at the same time we dropped Python 2 support, what an amazing time to be alive…

Flex support was working, but only for simple cases. It was useful for many users, but that was not enough. A lot of tickets have then been opened, some of them have been closed, but some were almost impossible to fix with the current implementation. The many shortcuts and workarounds we used in the code were nice to deliver a first version fast, but as always: not following the specification really closely was a bad idea.

Rewriting the Flex layout has since then been a kind of running gag: always high on our ToDo-list 📋, but never on top. Reality is that this kind of features requires a lot of time, but as you can imagine it’s almost impossible to find 2 consecutive weeks of free time in our schedule.

To find a lot of time, we needed a sponsor. That worked very well with the Grid layout, because we had a sponsor… and the Flex experience of what not to do when implementing new layouts 😁.

That’s why we proposed the NLnet foundation to help us on this topic. They were very excited by the idea, and even asked us if they could help on other important complex topics. That’s how we agreed on 3 different features: Flex layout, PDF/UA, CMYK.

So… What’s New?

After many days reading the specification (almost as interesting as a novel), reading the specification, writing some code, reading the specification, adding some tests, reading the specification, and reading the specification, we finally managed to reach many goals:

• We closed 18 issues, including a lot of bugs, but also nice features like gap.
• Closing these issues helped to fix unrelated bugs, for example for inline tables, preferred sizes, floats, formatting structure… We even fixed a bug in one of our samples!
• We added 123 tests to our test suite.
• 346 flex layout tests from the W3C test suite were passing in version 64, they are now 470 (out of 810). Many of the failing issues left are not related to flex layout but to other unsupported features (XHTML syntaxes, right-to-left and vertical text mainly).
• We pushed 47 commits in 3 weeks.
• We rewrote about 35% of the flex layout code, and the flex.py file is now 180 lines shorter (we removed a lot of comments copied from the specification).
• The overall diff stat is +517-684 lines for code in 11 files, and +1324-343 lines for tests in 3 files. We basically removed broken code and transformed it into passing tests! 😄

What was amazing during this 3-week period is that we’ve been able to stay focus on the Flex layout without being disturbed by other external events. This was the only way to get this work done: being focus on one goal gave us a unique possibility to be productive, which is almost impossible on our free time, when we always prioritize our clients.

Coding in these conditions is a real pleasure. Code quality, testing coverage, comments, architecture solidity… All the metrics are higher, and we can really feel the difference.

Of course, there will be bugs. But we are now confident 💪 in the Flex layout, just as we were when we released the Grid layout. So… Don’t wait, test it!

What’s More?

Improved Right-to-Left Text Support

Version 65 brings big changes to the support of right-to-left text. WeasyPrint now follows the dir HTML attribute instead of automatically finding the main direction of text, bringing more control to users and following the specification.

Other bugs have been fixed for right-to-left text, including justification, PDF text selection, and trailing spaces management. WeasyPrint is not ready yet to handle complex bidirectional or vertical text cases, but it’s been reported to work well for many different languages. Don’t hesitate to report bugs if you have problems with right-to-left text!

Modernized User Agent Stylesheet

Just like any browser, WeasyPrint comes with a standard stylesheet that defines common rules: <div> tags are blocks, <table> tags are tables, and so on.

This stylesheet, called the user agent stylesheet, has been modernized. For users, it shouldn’t change much: the rules are almost the same as they were, even if we enabled a couple of new features such as case-insensitive HTML attributes matching.

We now use modern selectors, like the :is() and :has() pseudo-classes for example. The stylesheet is smaller, easier to understand and maintain, and should be slightly faster.

This change is part of the invisible but important regular maintenance work done on WeasyPrint. We try hard to keep our code clean, closer to the recent Python, HTML, CSS, SVG, PDF versions. Web technologies evolve quickly, and we do our best to be part of this evolution!

And More…

We can’t list here all the changes brought to you by version 65, but here are some features and bug fixes that could be useful for you:

• @font-face rules now support the unicode-range property;
• non-breaking spaces are now justified, just as normal spaces;
• embedded fonts now have a more specific and reliable name;
• more complex cases involving nested SVG text anchors have been fixed.

What’s Next?

We hope you’ll have fun with this new version and that all these new features will be useful for you!

What’s next? Thanks to NLnet, version 66 will bring a better support of PDF/UA, for improved accessibility. That’s an amazing feature we’re really proud and excited to work on. If you’re interested in testing this feature, don’t hesitate to contact us! 💌

If you use WeasyPrint in critical applications, you should consider subscribing to our consulting packages. They give you priority access to our support service and customized answers to technical questions, for a given number of topics per month. That’s the best way to get a reliable and fast support, and be sure that you’ll continue to benefit from WeasyPrint’s great features happily ever after! 🚀

If you’re interested in participating in WeasyPrint, opening issues and pull requests is a good way to start. If you want to dive into the code, a list of good first issues is waiting for you! Choose your favorite issue and write a short comment, we’ll be happy to help you.

And of course you can also become a sponsor on OpenCollective, it really helps us to maintain WeasyPrint and to provide high-quality software.