I've been working on CSS Layout as a library recently[0] (we have Flexbox and CSS Grid support so far). It seems to me that librifying everything (much like is already done with JS engines) could be a good approach to making building a new browser engine more accesible.
Because that way any one wanting to build a new one can starting by pulling in a bunch of libraries (layout, rendering, etc), and then just customise the bits they need (ideally publishing them as a new iteroperable library that others can also use).
> It seems to me that librifying everything (much like is already done with JS engines) could be a good approach to making building a new browser engine more accesible. ... Because that way any one wanting to build a new one can starting by pulling in a bunch of libraries (layout, rendering, etc), and then just customise the bits they need (ideally publishing them as a new iteroperable library that others can also use).
I think that you are right; this is what will be needed. However, that alone won't do because it is also needing to write them to be good, and not too slow/inefficient and not too incapable of doing many customization stuff.
And, ensure things are properly separated. (Looking at your examples, it seems like it is properly separated, to me. You can define styles independently of parsing them, which improves efficiency as well as allowing adding other steps in between such as "meta-CSS" if desirable.)
In some cases, it may be desirable to modify parts of the libraries, although then it may be necessary to maintain a fork of that library, which is not always desirable.
(For example, I may want to add proper support for non-Unicode text, and being able to customize text layout functions, including all possible text directions (vertical, horizontal, boustrophedon, etc). Adding other CSS rules might also be needed for some other purposes, too. And then, we will also need to do accessibility features.)
(I like to use C programming; looking in issues, it look like they might be added, so that can be good; unfortunately, Rust has a Unicode string type and this can be problematic even if using C, unless the Rust programming is done very carefully to avoid this problem.)
We are planning to add a C API to Taffy, but tbh I feel like C is not very good for this kind of modularised approach. You really want to be able to expose complex APIs with enforced type safety and this isn't possible with C.
Question about implementation: while you are not building a browser (so I expect HTML is out of your scope) are you able to use an existing testsuite to compare your implementation?
We have our own test suite (orginally derived from the test suite of Meta's Yoga layout library [0]) which consists of text fixtures that are small HTML snippets [1] and a test harness [2] that turns those into runnable tests, utilising headless chrome both to parse the HTML and to generate the assertions based on the layout that Chrome renders (so we are effectively comparing our implementation against Chrome). We currently have 686 generated tests (covering both Flexbox and CSS Grid).
We would like to run the Web Platform Test suite [3] against Taffy, however these are not in a standard format and many of the tests require JavaScript so we are not currently able to do that.
Because that way any one wanting to build a new one can starting by pulling in a bunch of libraries (layout, rendering, etc), and then just customise the bits they need (ideally publishing them as a new iteroperable library that others can also use).
[0] https://github.com/DioxusLabs/taffy