Cascade»Blog

UI Debug System, CSS Engine and The Death of Janus

Hi y'all. Been working on the CSS engine and a debug system for it.

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!


Simon Anciaux,
Since html and css seem quite complicated to get right, did you consider creating your own spec/format/architecture to better fit your needs ? Do you have a requirement for this tool to work with html and css ?
Stas Lisetsky,
Yes, from the beginning I wanted to avoid the direct implementation of css, so I ended up with a reasonable layout engine. Also we might want to add more target layout formats in the future (like mobile UI) or extend the app to be more like a regular 2d/CAD editor, so we wanted to keep a simple general-purpose engine, not heavily influenced by CSS-like stuff.

And yes, for current version, one of the main requirements is good compatibility with the CSS spec. So I decided to have 2 separate engines.

One - exact css implementation. And another - for everything else: debug UI, non-html UI elements. Possibly some objects that dont have to be dispalyed with the css engine (like vector shapes maybe?)

Spec IR xD