Implement Layout Containment

third_party/WebKit/Source/core/layout/LayoutBlock.cpp

 /*
  * Copyright (C) 1999 Lars Knoll (knoll@kde.org)
  *           (C) 1999 Antti Koivisto (koivisto@kde.org)
  *           (C) 2007 David Smith (catfish.man@gmail.com)
  * Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 Apple Inc. All rights reserved.
  * Copyright (C) Research In Motion Limited 2010. All rights reserved.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
  * License as published by the Free Software Foundation; either
@@ skipping 989 matching lines @@
 
     IntRect inflatedRect = pixelSnappedBorderBoxRect();
     LayoutTheme::theme().addVisualOverflow(*this, inflatedRect);
     addVisualOverflow(LayoutRect(inflatedRect));
 }
 
 bool LayoutBlock::createsNewFormattingContext() const
 {
     return isInlineBlockOrInlineTable() || isFloatingOrOutOfFlowPositioned() || hasOverflowClip() || isFlexItemIncludingDeprecated()
         || style()->specifiesColumns() || isLayoutFlowThread() || isTableCell() || isTableCaption() || isFieldset() || isWritingModeRoot()
-        || isDocumentElement() || isColumnSpanAll() || isGridItem() || style()->containsPaint();
+        || isDocumentElement() || isColumnSpanAll() || isGridItem() || style()->containsPaint() || style()->containsLayout();
 }
 
 void LayoutBlock::updateBlockChildDirtyBitsBeforeLayout(bool relayoutChildren, LayoutBox& child)
 {
     if (child.isOutOfFlowPositioned()) {
         // It's rather useless to mark out-of-flow children at this point. We may not be their
         // containing block (and if we are, it's just pure luck), so this would be the wrong place
         // for it. Furthermore, it would cause trouble for out-of-flow descendants of column
         // spanners, if the containing block is outside the spanner but inside the multicol container.
         return;
@@ skipping 929 matching lines @@
 
 int LayoutBlock::columnGap() const
 {
     if (style()->hasNormalColumnGap())
         return style()->fontDescription().computedPixelSize(); // "1em" is recommended as the normal gap setting. Matches <p> margins.
     return static_cast<int>(style()->columnGap());
 }
 
 void LayoutBlock::computeIntrinsicLogicalWidths(LayoutUnit& minLogicalWidth, LayoutUnit& maxLogicalWidth) const
 {
+    // Layout-contained elements don't consider their contents for preferred sizing.
+    if (style()->containsLayout())
+        return;
+
     if (childrenInline()) {
         // FIXME: Remove this const_cast.
         toLayoutBlockFlow(const_cast<LayoutBlock*>(this))->computeInlinePreferredLogicalWidths(minLogicalWidth, maxLogicalWidth);
     } else {
         computeBlockPreferredLogicalWidths(minLogicalWidth, maxLogicalWidth);
     }
 
     maxLogicalWidth = std::max(minLogicalWidth, maxLogicalWidth);
 
     if (isHTMLMarqueeElement(node()) && toHTMLMarqueeElement(node())->isHorizontal())
@@ skipping 260 matching lines @@
     return -1;
 }
 
 int LayoutBlock::inlineBlockBaseline(LineDirectionMode lineDirection) const
 {
     // CSS2.1 states that the baseline of an 'inline-block' is:
     // the baseline of the last line box in the normal flow, unless it has
     // either no in-flow line boxes or if its 'overflow' property has a computed
     // value other than 'visible', in which case the baseline is the bottom
     // margin edge.
+    // We likewise avoid using the last line box in the case of layout containment,
+    // where the block's contents shouldn't be considered when laying out its
+    // ancestors or siblings.
 
-    if (!style()->isOverflowVisible() && !shouldIgnoreOverflowPropertyForInlineBlockBaseline()) {
+    if ((!style()->isOverflowVisible() && !shouldIgnoreOverflowPropertyForInlineBlockBaseline()) || style()->containsLayout()) {

[ojan, 2015/12/18 18:21:14]

I think this is the right behavior, although I'm not confident the current spec
covers this. Might want to run this by Tab. If this is handled by the current
spec, I think it at least deserves an explanatory note.

[leviw_travelin_and_unemployed, 2016/01/12 19:36:31]

I did add some info to the above comment to try and tackle this. My feeling was
the spec does cover this, albeit obliquely. It says the contents shouldn't
effect layout, and this ensures that's the case, and that's what I tried to
elude to. +tabatkins to comment.

         // We are not calling LayoutBox::baselinePosition here because the caller should add the margin-top/margin-right, not us.
         return lineDirection == HorizontalLine ? size().height() + marginBottom() : size().width() + marginLeft();
     }
 
     if (isWritingModeRoot() && !isRubyRun())
         return -1;
 
     if (childrenInline()) {
         if (!firstLineBox() && hasLineIfEmpty()) {
             const FontMetrics& fontMetrics = firstLineStyle()->fontMetrics();
@@ skipping 640 matching lines @@
 void LayoutBlock::showLineTreeAndMark(const InlineBox* markedBox1, const char* markedLabel1, const InlineBox* markedBox2, const char* markedLabel2, const LayoutObject* obj) const
 {
     showLayoutObject();
     for (const RootInlineBox* root = firstRootBox(); root; root = root->nextRootBox())
         root->showLineTreeAndMark(markedBox1, markedLabel1, markedBox2, markedLabel2, obj, 1);
 }
 
 #endif
 
 } // namespace blink