Here's a little video of that + some live UI editing.
This system is not unlike Chrome Dev Tools, but I also added zoom and UI resize to check for pixel-level errors and responsive behaviours. You can browse the html tree (not DOM!) to see how the selected element is drawn, which is very useful for debugging (helps to see how child-elements affect the parent's size, how wrapping works etc.)
I can also select the tree node and trigger a break on it inside the enigne. Super useful.
It's a lot of work to implement the CSS engine. I literally have to decipher the spec paragraph-by-paragraph using an intermediate representation.

Also, at first I wanted to use my engine for all the CSS rules. But is was bad. I had to add workarounds to make CSS's way of doing things work, which contaminated my API with unnecessary things. Also the resulting CSS behaviour was not really 100% adhering to the spec, which would have caused compatibility issues in the future. Also it was harder to debug. CSS uses its own nomenclature like "line-boxes", "block context" etc. etc. And I had to reinterpret all those things in terms of my engine API, which made the implementation and debugging much, much harder.
And thus I gave up and decided to have 2 completely independent engines. That had 2 consequences. I had to finally admit that I am making a full-on web browser. And secondly - (which is a good thing) I eliminated a bunch of complexity and got rid of the Janus problem. For example, with a single engine, if I move/resize an object with mouse I had to translate its properties each frame to the language of CSS (position became top/left coordinate etc.) and vice-versa: if I open a CSS properties editor and set a "top" value to 10px - these changes would have to be applied to my engine object.
It was not good. There were these priority and synchronization issues all the time. And now I'm just editing html/css always.
So this is where I'm at. There's a lot of work, and I'm slooooowly moving forward.
Thanks and see you next time!