> 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 ac

> 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.)