[LayoutNG] Add NGConstraintSpace class definition

third_party/WebKit/Source/core/layout/ng/NGConstraintSpace.h

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef NGConstraintSpace_h
+#define NGConstraintSpace_h
+
+#include "platform/LayoutUnit.h"
+#include "platform/PlatformExport.h"
+
+namespace blink {
+
+class NGDerivedConstraintSpace;
+class NGExclusion;
+
+class PLATFORM_EXPORT NGConstraintSpace {

[ikilpatrick, 2016/07/27 21:14:12]

CORE_EXPORT:)

[ikilpatrick, 2016/07/27 21:14:12]

We'll also want to think about how this will work when passing into a child
which has a different writing mode.

E.g.
<div>
  <div style="writing-mode: vertical; height: 10px">
    a b c d
  </div>
</div>

// Here inline is childDerviedConstraintSpace.blockSize is 100px say.
child.performLayout(childDerivedConstraintSpace);

// Inside layout fn this should map over to inlineSize right?
NGChildLayout::layout(ConstraintSpace cs)
{
  cs.inlineSize()
}

Thought 1: between performLayout & layout we wrap up a "view" object.

class ConstraintSpaceView? : public ConstraintSpace {
public:
  ConstraintSpaceView(ConstraintSpace, Direction);

  // redirect all inline/block calls to correct...
  // ... or crazyer is not allowed to query for these unless going through a
view or something.
};

Thought 2: All constraint spaces need a Direction. But this is confusing in the
call side code?

VERY RAW THOUGHTS.

[eae, 2016/07/27 21:24:16]

I'd argue that we should have constraint spaces be direction agnostic either by
having a view object or by having some shared convenience methods for layout
methods. Either way, the constraint space itself shouldn't have to be aware of
writing modes or directionality.

[eae, 2016/07/27 21:24:16]

Done.

+public:
+    NGConstraintSpace();
+    ~NGConstraintSpace();
+
+    enum NGClearExclusion {
+        ClearNone = 0,
+        ClearFloatLeft = 1,
+        ClearFloatRight = 2,
+        ClearFragment = 4
+    };
+
+    enum NGFragmentationType {
+        FragmentNone,
+        FragmentPage,
+        FragmentColumn,
+        FragmentRegion
+    };
+
+    enum NGExclusionType {
+        ExcludeNone,
+        ExcludeInlineFlow,
+        ExcludeInlineStart,
+        ExcludeInlineEnd,
+        ExcludeInlineBoth
+    };
+
+    NGConstraintSpace();
+    ~NGConstraintSpace();
+
+    LayoutUnit inlineSize() const;
+    LayoutUnit blockSize() const;
+
+    // Some layout modes “stretch” their children to a fixed size (e.g. flex,
+    // grid). These flags represented whether a layout needs to produce a
+    // fragment that satisfies a fixed constraint in the inline and block
+    // direction respectively.
+    bool fixedInlineSize() const;
+    bool fixedBlockSize() const;
+
+    // The size threashold in the inline and block directions respesvitely that

[ikilpatrick, 2016/07/27 21:14:12]

respectively 

+    // triggers the presence of a scrollbar. If exceeded the current layout
+    // should be aborted and invoked again with a constraint space modified to
+    // reserve space for a scrollbar.
+    LayoutUnit inlineOverflowSize() const;
+    LayoutUnit blockOverflowSize() const;

[ikilpatrick, 2016/07/27 21:14:12]

Same as below... any time when there would be different to inline/blockSize?

[eae, 2016/07/27 21:24:15]

Yes. For a regular document the body would have an infinity blockSize but the
blockOverflowSize would be the height of the inner viewport.

Similarly for fixed-size elements with overflow auto.

<div style="height: 200px; overflow: auto">
  <p>Lots of content</p>
</div>

When laying out the paragraph the blockSize would be Infinite while the
overflowBlockSize would be 200. 

+
+    // If specified a layout should produce a Fragment which fragments at the
+    // blockFragmentationSize if possible.
+    LayoutUnit blockFragmentationSize() const;

[ikilpatrick, 2016/07/27 21:14:11]

So when working on the spec I couldn't think of a case where this was different
than the blockSize. Are there any?

If so we can just get away with Fragmentation type below.

[eae, 2016/07/27 21:24:16]

None comes to mind. I'll remove it.

+    NGFragmentationType blockFragmentationType() const;
+
+    void addExclusion(NGExclusion, unsigned options = 0);
+    List<NGExclusion> exclusions(unsigned options = 0) const;
+
+    List<const DerivedNGConstraintSpace> layoutOpportunities(

[ikilpatrick, 2016/07/27 21:14:11]

TODO(layout-dev): move to generator eventually?

+        unsigned clear = ClearNone,
+        NGClearExclusion = ExcludeNone) const;

[ikilpatrick, 2016/07/27 21:14:12]

Is NGClearExclusion meant to be "avoid"?

[ikilpatrick, 2016/07/27 21:14:12]

Do we have any place today where the "step"/"jump-size" is different than 1em?

May want to pass that info in as well (not needed atm).
Would also have to teach it about what 1em means... 

[eae, 2016/07/27 21:24:16]

Not today. I intentionally skipped the step-size argument for now.

[eae, 2016/07/27 21:24:16]

Yeah

+};
+
+class PLATFORM_EXPORT NGDerivedConstraintSpace : NGConstraintSpace {
+public:
+    ~NGDerivedConstraintSpace();
+    LayoutUnit inlineOffset() const;
+    LayoutUnit blockOffset() const;
+
+    // When creating a derived NGConstraintSpace for the next inline level
+    // layout opportunity, inlineSize and blockSize of the NGConstraintSpace
+    // may be different from its parent. These properties hold the inline and
+    // block size of the original NGConstraintSpaces, allowing percentage
+    // resolution to work correctly.
+    LayoutUnit inlineSizeForPercentageResolution() const;
+    LayoutUnit blockSizeForPercentageResolution() const;
+
+private:
+    NGDerivedConstraintSpace();
+};
+
+} // namespace blink
+
+#endif // NGConstraintSpace_h