Fix several problems related to flex-direction: column

[dhdaines]

Fixes: #2222 with the following crucial fixes:

• Due to an unfortunate programming error (probably copy-and-paste gone awry) the left and right margins were being used to calculate the used main size of items even when the main axis was vertical e8ef883
• Flex lines were being calculated using available main size rather than the actual (inner) main size of the flex container bfeefa4
• Flex item cross sizes were being incorrectly calculated, at least for the case where said flex items are themselves flex containers, because this is done using block_level_layout_switch, which in turn calls back into flex_layout, which clobbers any width or height attributes (which would represent the used main size of the item) in the call to resolve_percentages(parent_box, containing_box) in step 3. ce6253f

Also fixes: #1171 with the following fix:

• percentage sizes for flex items were being computed relative to the parent of the flex container for some reason (flex containers, like block containers, form a containing block). also the computed sizes were not actually being used for definite cross sizes. also cross width (i.e. with flex-direction: column) of 'auto' was being treated as 'min-content' for some reason 4771c35

Adds a huge amount of commenting and tracing which should aid in the refactoring of the flexbox code.

Note however that said code is definitely not correct. Most importantly it is not clear (even in the spec) where the inner and outer main sizes are used for flex items, and the code also doesn't do this consistently, so there will be some issues where flex items have definite size or definite flex-basis. We can add more tests... the code coverage is not good!

[dhdaines]

If this is okay for the moment, I would like to do a separate PR to refactor flex_layout given that it is well over a thousand lines long and by design should be decomposed into individual steps. I don't think it necessarily needs to be rewritten given that it follows the algorithm in the spec pretty closely, it's just that many parts of the algorithm are incompletely or incorrectly implemented and need to be unit tested (which can't be done in the current monolithic state of the code).

[dhdaines]

I fixed #1171 here too (it was not the same issue). I'll stop there for now :)

[liZe]

Thanks a lot for this PR! ❤️

I’ll change some little things (mainly remove the debug messages, as explained in #2220) and merge this PR soon!

[dhdaines]

Thanks a lot for this PR! ❤️

I’ll change some little things (mainly remove the debug messages, as explained in #2220) and merge this PR soon!

Thank you! I was going to do that myself eventually but I was on vacation last week. I'll make sure to keep them out of future PRs (perhaps in a separate local branch)