Hacker News new | past | comments | ask | show | jobs | submit login

(Original author of css-layout here)

I've spend a few months playing with Cassowary before working on css-layout and had long chats with its creator Greg Badros and the people behind https://gridstylesheets.org/.

Cassowary underlying abstraction is a linear inequation solver. So you give it a bunch of constraints of the form ax + by + cz + d < 0 and it's going to give you values for x, y and z.

## There are two innovations in Cassowary:

1) There's a concept of strength (required, strong, medium, weak) which allows you to define which rules should be dropped in case of conflicts. This is a very different way to think about building UI and was a really fun exercise.

That said, I had to build a dedicated tool to show me which rules where overridden or why otherwise it was very hard to understand what happened when the layout didn't work as I expected.

2) Cassowary is an iterative solver, this means that it's not going to recompute the entire simplex from scratch on every tiny update.

## The biggest issue with Cassowary is that you cannot express everything with a linear system of equations:

The most annoying instance is line breaking. You cannot encode how lines are going to break as a set of linear inequations. In practice, what happens is that you're going to "fake it" by iterating outside of the simplex by first giving it a rough size and then do another pass with the real one. It usually works but you are not guaranteed for it to converge nor to have the optimal layout.

## In practice

It's extremely painful to write all the inequations yourself. If you want to have a container with an item of height 100px with 5px of padding it looks like.

    obj.left = parent.left + 5
    obj.top = parent.top + 5
    obj.right = parent.right - 5
    obj.height = 100
    parent.height = obj + 5
For every single object you need to define 4 inequations to "define": top, left, width and height which is very verbose.

So I started writing abstractions for containers, padding... At some point, I realized that I was just reimplementing flexbox. But it was a worst implementation of flexbox because it didn't properly work with text and was way slower.

The other difficulty is that you need references to all those elements. In order to tell where an element is, you need a reference to your parent. This model doesn't work well with React components where you only shouldn't know about your parent.

## Where it shines

The places where constraint solver shines is when you have a wysiwyg element builder. You have a reference to all the elements as they are visible on-screen so it's very easy to link them and you can show 4 inputs for each constraint.

This is very useful for xcode interface builder and would be a good fit for designer tools like photoshop.

Hopefully this gives some light around why we didn't proceed with cassowary :)




Hey vjeux! I'm sure everyone here on HN would really love the story of how you first implemented css-layout.

You had a really inspiring use of fuzz testing and TDD. You used a hilarious technique to implement it in several languages at once. And I heard a rumor you did it all over your paternity leave?!


HN Comments are ephemeral... this would make a nice blog post!


They may be harder to find, but HN comments are probably less ephemeral that most blogs (that is, HN comments are more long-lasting and at the same "permalink"... seems that plenty of blogs fall off the internet after a few years).


> There's a concept of strength (required, strong, medium, weak) which allows you to define which rules should be dropped in case of conflicts. [...] That said, I had to build a dedicated tool to show me which rules where overridden or why otherwise it was very hard to understand what happened when the layout didn't work as I expected.

That sounds like "strength" was probably the wrong approach. Why not require the developer to simply resolve conflicts? Your set of inequalities are a basic type system and you tried to resolve your type errors by layering some secondary weird "overriding" type system over top. Better to just resolve the errors from the get-go, and when it compiles, you know it will run correctly.

> The most annoying instance is line breaking. You cannot encode how lines are going to break as a set of linear inequations.

Is this discussed anywhere in more detail? It doesn't sound right to me, unless I'm misunderstanding what you mean here.


For 1), those are not bugs but to simulate if then else. If the width is < 800, then do that, else do that. Then problem is that if then else is not linear so you can't express this. What they do is to put bigger weights than anything so the minimization function is going to pick them instead. Because it's using different orders of magnitude, you can only have a few of those categories (4 in this case), afterwards you run into numerical precision issues.

2) The height of a text is not a linear function based on the width of the container. You can't say, the height of the text is 10px * number of characters * width of the container.

Instead, if you add a single more character that makes it go to the next line it's going to add a single lineheight.

So, you can't encode this inside of the simplex and you need to do it as a separate pass.


> Then problem is that if then else is not linear so you can't express this.

It sounds like a limited set of discontinuous functions are needed, like how media queries are used in CSS. The constraints to satisfy are defined by a set of top-level discontinuous functions on environmental parameters, but the set is always fixed so it's pretty simple to detect when you need to switch to a different set of constraints. Wouldn't that suffice?

> The height of a text is not a linear function based on the width of the container. You can't say, the height of the text is 10px * number of characters * width of the container.

For simplicity, let's take the easiest case of a fixed width font and we'll hard wrap at X characters, regardless of whitespace positions. The number of lines L and the height of the text H in px is then given by:

    L = char_px_width * char_count / container_px_per_line
    H = L * char_px_height
Agreed? If so, then that case isn't difficult, but difficulties arise when you want better wrapping behaviour based on whitespace with a non-fixed width font. I agree that doing it precisely with linear equations doesn't seem feasible, but it seems like we can closely approximate it to minimize the reflows needed to converge on the final result.

Suppose we set char_px_height=the widest character of the typeface (ditto for char_px_height) so we overestimate the dimensions needed. A quick google search suggests that the average word length for ordinary English is around 5 characters. So with avg_word_length=5, the above equation changes to something like:

    L = char_px_width * avg_word_length * ceiling(char_count / avg_word_length) / container_px_per_line
This should miss the actual number of lines needed at most by 1, except when dealing with highly irregular text. Then again, the avg_word_length can be constantly adjusted on the fly based on the reflows you have to do, so this should quickly converge too. Does this sound right?

Edit: sorry, that last calculation is obviously wrong, I was rushing out the door. The idea is to estimate number of lines from the average nnumber of words that would fit per line.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: