@ondrej.rytir I think there are a couple of issues here, so let's unpack the problem a bit. (And if I'm misunderstanding your questions, please let me know.)
First is the tactical issue of removing columns from a grid in Subform: what happens when you delete a column (or row) that has content in it? Adding columns is pretty straightforward, everything just shifts over a little bit. But that doesn't work when you remove one.
- We could just prohibit this behavior. If there's content in a column, the app tells you that you can't delete that column.
- We could try to intelligently reorder the content based on the new column configuration, but it's pretty tricky to know the designer's intent. (more on this in a bit)
- We could just let the content in the deleted column stay as-is, thus overflowing (breaking) the grid container.
- We could throw an error on any elements that reference the now-deleted column. (This is what we do now in Subform)
None of these options are perfect. We picked #4 because:
- Grid content not referencing the now-deleted column still displays properly
- No content "breaks" the grid
- Subform doesn't prevent you from doing something you might want to do
- It makes it pretty obvious which element(s) need to be updated to fit the new grid configuration.
That said, you can only delete or insert columns or rows from the end of the grid right now. It's not hard to imagine wanting grids to behave a little like spreadsheets, where you can insert, delete, or reorder a column or row anywhere. But that adds even more complexity to reflowing content, so we're avoiding it for the time being.
Second is the larger strategic issue of defining multiple grid layouts for different device sizes. This relates to the breakpoints discussion. The designer ostensibly wants to specify two things: 1) how the grid configuration changes and 2) how the content inside of the grid on that particular screen adapts to the new grid.
Maybe there could be some way to index the blocks (modules) based on priorities and when you reduce number of columns they would get consolidated and sorted by this index. Zero would mean to discard the block.
So this relates to the aforementioned "We could try to intelligently reorder the content based on the new column configuration, but it's pretty tricky to know the designer's intent." Something like the priority weighting that you mention here could work, but it adds a lot of cognitive overhead to the designer. What happens when there are priority conflicts? Do you have to set priorities even when you have no intention of changing the grid configuration? Etc.
Priorities are one of the downsides of constraint-based layout solvers and we're been able to avoid them to good effect, so far.
Introducing this sort of conditional logic, in whatever form, is also something we want to avoid in Subform. It's very easy to end up with a complex set of rules that are hard to debug, hard to communicate to developers, can have unintended side effects, make it more difficult to work with components, etc.
At a certain point, we’re just making a lousy simulacrum of code—and that’s not the strength of a visual, direct-manipulation tool.
We think the best way to work is to just be explicit about different layout configurations. If there are three grid configurations then those should be specified separately, either as different states or artboards.
The nice thing about the layout engine is that you aren't designing to a specific device size, but rather a specific layout configuration. A 12 column grid will adapt to a 375px wide or 1920px wide artboard. In Subform, you can keep playing with sizes and determine where you think the layout stops working. (This is often referred to as "content-based breakpoints.") Then it's time to think about how the layout can work with a 8 column or 4 column grid, etc.
This extends not just to the grid, but the actual content of the design, as well. Rather than trying to codify conditional logic that tells a navigation to change when the viewport is less than an arbitrary width, the navigation should just have two states. The 4 column grid layout would then use the "condensed" state, for example.