During the first layout pass, the code incorrectly believes that the element ends up in the next column (or page), and eats the margin. Apart from broken layout, this may even cause an assertion failure: ASSERTION FAILED: currentMinSpaceShortage != LayoutUnit::max() ../../Source/WebCore/rendering/RenderMultiColumnSet.cpp(112) : bool WebCore::RenderMultiColumnSet::calculateBalancedHeight(bool) ... because the column heights don't become tall enough in the initial balancing pass.
Created attachment 214152 [details] Test case
Corresponding bug in Blink: http://code.google.com/p/chromium/issues/detail?id=353587
Created attachment 228054 [details] Patch
@dave - can you review this, please? I couldn't really avoid fixing this one while working on spanners support.
Comment on attachment 228054 [details] Patch r=me
Comment on attachment 228054 [details] Patch Clearing flags on attachment: 228054 Committed r166938: <http://trac.webkit.org/changeset/166938>
All reviewed patches have been landed. Closing bug.
This was landed back in April, but it appears to still be broken. See: http://stackoverflow.com/questions/23745077/block-elements-inside-multicolumn-layout-padding-issue-in-chrome-ie http://jsfiddle.net/6cVqZ/
That's unrelated to this bug, but it seems that someone answered your stackoverflow question while I was gone. The clue is to use break-inside:avoid . This property doesn't yet exist in Blink, though (and I assume the same is still the case for WebKit as well). You have to say li { -webkit-column-break-inside:avoid; } instead.