tree: cdfbf01f12b858df0e57966260835cccc3a5faf8 [path history] [tgz]
  1. api/
  2. custom/
  3. doc/
  4. line/
  5. ng/
  6. resources/
  7. shapes/
  8. svg/
  9. AdjustForAbsoluteZoom.h
  10. BackgroundBleedAvoidance.h
  11. BaselineAlignment.cpp
  12. BaselineAlignment.h
  13. BidiRun.h
  14. BidiRunForLine.cpp
  15. BidiRunForLine.h
  17. CollapsedBorderValue.cpp
  18. CollapsedBorderValue.h
  19. CollapsedBorderValueTest.cpp
  20. ColumnBalancer.cpp
  21. ColumnBalancer.h
  22. ContentChangeType.h
  23. CounterNode.cpp
  24. CounterNode.h
  25. DepthOrderedLayoutObjectList.cpp
  26. DepthOrderedLayoutObjectList.h
  27. FlexibleBoxAlgorithm.cpp
  28. FlexibleBoxAlgorithm.h
  29. FloatingObjects.cpp
  30. FloatingObjects.h
  31. FragmentainerIterator.cpp
  32. FragmentainerIterator.h
  33. FragmentationContext.h
  34. GeneratedChildren.h
  35. Grid.cpp
  36. Grid.h
  37. GridLayoutUtils.cpp
  38. GridLayoutUtils.h
  39. GridTrackSizingAlgorithm.cpp
  40. GridTrackSizingAlgorithm.h
  41. HitTestCache.cpp
  42. HitTestCache.h
  43. HitTestCanvasResult.cpp
  44. HitTestCanvasResult.h
  45. HitTestingTransformState.cpp
  46. HitTestingTransformState.h
  47. HitTestLocation.cpp
  48. HitTestLocation.h
  49. HitTestRequest.h
  50. HitTestResult.cpp
  51. HitTestResult.h
  52. IntersectionGeometry.cpp
  53. IntersectionGeometry.h
  54. LayoutAnalyzer.cpp
  55. LayoutAnalyzer.h
  56. LayoutBlock.cpp
  57. LayoutBlock.h
  58. LayoutBlockFlow.cpp
  59. LayoutBlockFlow.h
  60. LayoutBlockFlowLine.cpp
  61. LayoutBlockTest.cpp
  62. LayoutBox.cpp
  63. LayoutBox.h
  64. LayoutBoxModelObject.cpp
  65. LayoutBoxModelObject.h
  66. LayoutBoxModelObjectTest.cpp
  67. LayoutBoxTest.cpp
  68. LayoutBR.cpp
  69. LayoutBR.h
  70. LayoutButton.cpp
  71. LayoutButton.h
  72. LayoutCounter.cpp
  73. LayoutCounter.h
  74. LayoutCountTest.cpp
  75. LayoutDeprecatedFlexibleBox.cpp
  76. LayoutDeprecatedFlexibleBox.h
  77. LayoutDetailsMarker.cpp
  78. LayoutDetailsMarker.h
  79. LayoutEmbeddedContent.cpp
  80. LayoutEmbeddedContent.h
  81. LayoutEmbeddedContentTest.cpp
  82. LayoutEmbeddedObject.cpp
  83. LayoutEmbeddedObject.h
  84. LayoutFieldset.cpp
  85. LayoutFieldset.h
  86. LayoutFileUploadControl.cpp
  87. LayoutFileUploadControl.h
  88. LayoutFlexibleBox.cpp
  89. LayoutFlexibleBox.h
  90. LayoutFlowThread.cpp
  91. LayoutFlowThread.h
  92. LayoutFrame.cpp
  93. LayoutFrame.h
  94. LayoutFrameSet.cpp
  95. LayoutFrameSet.h
  96. LayoutFullScreen.cpp
  97. LayoutFullScreen.h
  98. LayoutGeometryMap.cpp
  99. LayoutGeometryMap.h
  100. LayoutGeometryMapStep.h
  101. LayoutGeometryMapTest.cpp
  102. LayoutGrid.cpp
  103. LayoutGrid.h
  104. LayoutHTMLCanvas.cpp
  105. LayoutHTMLCanvas.h
  106. LayoutIFrame.cpp
  107. LayoutIFrame.h
  108. LayoutImage.cpp
  109. LayoutImage.h
  110. LayoutImageResource.cpp
  111. LayoutImageResource.h
  112. LayoutImageResourceStyleImage.cpp
  113. LayoutImageResourceStyleImage.h
  114. LayoutInline.cpp
  115. LayoutInline.h
  116. LayoutInlineTest.cpp
  117. LayoutListBox.cpp
  118. LayoutListBox.h
  119. LayoutListItem.cpp
  120. LayoutListItem.h
  121. LayoutListMarker.cpp
  122. LayoutListMarker.h
  123. LayoutMedia.cpp
  124. LayoutMedia.h
  125. LayoutMediaTest.cpp
  126. LayoutMenuList.cpp
  127. LayoutMenuList.h
  128. LayoutMultiColumnFlowThread.cpp
  129. LayoutMultiColumnFlowThread.h
  130. LayoutMultiColumnFlowThreadTest.cpp
  131. LayoutMultiColumnSet.cpp
  132. LayoutMultiColumnSet.h
  133. LayoutMultiColumnSpannerPlaceholder.cpp
  134. LayoutMultiColumnSpannerPlaceholder.h
  135. LayoutObject.cpp
  136. LayoutObject.h
  137. LayoutObjectChildList.cpp
  138. LayoutObjectChildList.h
  139. LayoutObjectInlines.h
  140. LayoutObjectTest.cpp
  141. LayoutPagedFlowThread.cpp
  142. LayoutPagedFlowThread.h
  143. LayoutProgress.cpp
  144. LayoutProgress.h
  145. LayoutProgressTest.cpp
  146. LayoutQuote.cpp
  147. LayoutQuote.h
  148. LayoutReplaced.cpp
  149. LayoutReplaced.h
  150. LayoutRuby.cpp
  151. LayoutRuby.h
  152. LayoutRubyBase.cpp
  153. LayoutRubyBase.h
  154. LayoutRubyRun.cpp
  155. LayoutRubyRun.h
  156. LayoutRubyText.cpp
  157. LayoutRubyText.h
  158. LayoutScrollbar.cpp
  159. LayoutScrollbar.h
  160. LayoutScrollbarPart.cpp
  161. LayoutScrollbarPart.h
  162. LayoutScrollbarTheme.cpp
  163. LayoutScrollbarTheme.h
  164. LayoutSearchField.cpp
  165. LayoutSearchField.h
  166. LayoutSlider.cpp
  167. LayoutSlider.h
  168. LayoutSliderContainer.cpp
  169. LayoutSliderContainer.h
  170. LayoutSliderThumb.cpp
  171. LayoutSliderThumb.h
  172. LayoutState.cpp
  173. LayoutState.h
  174. LayoutTable.cpp
  175. LayoutTable.h
  176. LayoutTableBoxComponent.cpp
  177. LayoutTableBoxComponent.h
  178. LayoutTableCaption.cpp
  179. LayoutTableCaption.h
  180. LayoutTableCell.cpp
  181. LayoutTableCell.h
  182. LayoutTableCellTest.cpp
  183. LayoutTableCol.cpp
  184. LayoutTableCol.h
  185. LayoutTableColTest.cpp
  186. LayoutTableRow.cpp
  187. LayoutTableRow.h
  188. LayoutTableRowTest.cpp
  189. LayoutTableSection.cpp
  190. LayoutTableSection.h
  191. LayoutTableSectionTest.cpp
  192. LayoutTableTest.cpp
  193. LayoutTestHelper.cpp
  194. LayoutTestHelper.h
  195. LayoutText.cpp
  196. LayoutText.h
  197. LayoutTextCombine.cpp
  198. LayoutTextCombine.h
  199. LayoutTextControl.cpp
  200. LayoutTextControl.h
  201. LayoutTextControlMultiLine.cpp
  202. LayoutTextControlMultiLine.h
  203. LayoutTextControlSingleLine.cpp
  204. LayoutTextControlSingleLine.h
  205. LayoutTextFragment.cpp
  206. LayoutTextFragment.h
  207. LayoutTextFragmentTest.cpp
  208. LayoutTextTest.cpp
  209. LayoutTheme.cpp
  210. LayoutTheme.h
  211. LayoutThemeAndroid.cpp
  212. LayoutThemeAndroid.h
  213. LayoutThemeDefault.cpp
  214. LayoutThemeDefault.h
  215. LayoutThemeFontProvider.cpp
  216. LayoutThemeFontProvider.h
  217. LayoutThemeFontProviderDefault.cpp
  218. LayoutThemeFontProviderWin.cpp
  219. LayoutThemeFuchsia.cpp
  220. LayoutThemeLinux.cpp
  221. LayoutThemeLinux.h
  222. LayoutThemeMac.h
  224. LayoutThemeMobile.cpp
  225. LayoutThemeMobile.h
  226. LayoutThemeTest.cpp
  227. LayoutThemeWin.cpp
  228. LayoutThemeWin.h
  229. LayoutTreeAsText.cpp
  230. LayoutTreeAsText.h
  231. LayoutVideo.cpp
  232. LayoutVideo.h
  233. LayoutView.cpp
  234. LayoutView.h
  235. LayoutViewTest.cpp
  236. LayoutVTTCue.cpp
  237. LayoutVTTCue.h
  238. LayoutWordBreak.cpp
  239. LayoutWordBreak.h
  240. ListMarkerText.cpp
  241. ListMarkerText.h
  242. MapCoordinatesFlags.h
  243. MapCoordinatesTest.cpp
  244. MinMaxSize.cpp
  245. MinMaxSize.h
  246. MinMaxSizeTest.cpp
  247. MultiColumnFragmentainerGroup.cpp
  248. MultiColumnFragmentainerGroup.h
  249. MultiColumnFragmentainerGroupTest.cpp
  250. OrderIterator.cpp
  251. OrderIterator.h
  252. OverflowModel.h
  253. OverflowModelTest.cpp
  254. OWNERS
  255. PaginationTest.cpp
  256. PaintContainmentTest.cpp
  257. PointerEventsHitRules.cpp
  258. PointerEventsHitRules.h
  260. ScrollAnchor.cpp
  261. ScrollAnchor.h
  262. ScrollAnchorTest.cpp
  263. ScrollbarsTest.cpp
  264. SubtreeLayoutScope.cpp
  265. SubtreeLayoutScope.h
  266. TableGridCell.cpp
  267. TableGridCell.h
  268. TableLayoutAlgorithm.h
  269. TableLayoutAlgorithmAuto.cpp
  270. TableLayoutAlgorithmAuto.h
  271. TableLayoutAlgorithmFixed.cpp
  272. TableLayoutAlgorithmFixed.h
  273. TextAutosizer.cpp
  274. TextAutosizer.h
  275. TextAutosizerTest.cpp
  276. TextDecorationOffset.cpp
  277. TextDecorationOffset.h
  278. TextDecorationOffsetBase.cpp
  279. TextDecorationOffsetBase.h
  280. TextRunConstructor.cpp
  281. TextRunConstructor.h
  282. TracedLayoutObject.cpp
  283. TracedLayoutObject.h
  284. VerticalPositionCache.h
  285. ViewFragmentationContext.cpp
  286. ViewFragmentationContext.h
  287. VisualRectMappingTest.cpp
  288. WebFontRenderingAndroid.cpp
  289. WebFontRenderingLinux.cpp
  290. WebFontRenderingWin.cpp

Blink Layout

The Source/core/layout directory contains the implementation of layout objects. It covers the following document lifecycle states:

  • LayoutSubtreeChange (InLayoutSubtreeChange and LayoutSubtreeChangeClean)
  • PreLayout (InPreLayout)
  • PerformLayout (InPerformLayout)
  • AfterPerformLayout (AfterPerformLayout and LayoutClean)

Note that a new Blink layout system is under development. See the LayoutNG design document.

The layout code is maintained by the layout team.

Scroll origin vs. offset vs. position

When a LayoutBox has scrollable overflow, it is associated with a PaintLayerScrollableArea. PaintLayerScrollableArea uses a “scroll origin” to represent the location of the top/left corner of the content rect (the visible part of the content) in the coordinate system defined by the top/left corner of the overflow rect, when the box is scrolled all the way to the beginning of its content.

For content which flows left-to-right and top-to-bottom, the scroll origin will be (0, 0), i.e., the top/left of the content rect is coincident with the top/left of the overflow rect when the box is scrolled all the way to the beginning of content.

For content which flows right-to-left (including direction:ltr, writing-mode:vertical-rl, and flex-direction:row-reverse), the x-coordinate of the scroll origin will be positive; and for content which flows bottom-to-top (e.g., flex-direction:column-reverse and vertical writing-mode with direction:ltr), the y-coordinate of the scroll origin will be positive.

In all cases, the term ‘scrollOffset’ (or just ‘offset’) is used to represent the distance of the scrolling viewport from its location when scrolled to the beginning of content, and it uses type ScrollOffset. The term ‘scrollPosition’ (or just ‘position’) represents a point in the coordinate space defined by the overflow rect, and it uses type FloatPoint.

For illustrations of these concepts, see these files:

doc/ltr-tb-scroll.png doc/rtl-bt-scroll.png doc/rtl-tb-scroll.png

When computing the scroll origin, if the box is laid out right-to-left and it has a scrollbar for the orthogonal direction (e.g., a vertical scrollbar in a direction:rtl block), the size of the scrollbar must be added to the scroll origin calculation. Here are two examples -- note that it doesn't matter whether the vertical scrollbar is placed on the right or left of the box (the vertical scrollbar is the |/| part):

                |          |/|          |
                |          |/|          |
                |          |/|          |
direction:rtl   |          |/|   box    |
                |          |/|          |
                |          |/|          |

                      overflow rect

                |            |          |/|
                |            |          |/|
                |            |          |/|
writing-mode:   |            |    box   |/|
  vertical-rl   |            |          |/|
                |            |          |/|

                      overflow rect

Coordinate Spaces

Layout and Paint work with and frequently refer to three main coordinate spaces (really two, with one variant):

  • Physical coordinates: Corresponds to physical direction of the output per the physical display (screen, printed page). Generally used for painting, thus layout logic that feeds into paint may produce values in this space. CSS properties such as top, right, bottom, and left are in this space. See also the ‘flipped block-flow direction’ variant space below.

  • Logical coordinates: Used in layout to allow for generalized positioning that fits with whatever the writing-mode and direction CSS property values may be. Properties named with before, after, start or end are in this space. These are also known respectively as ‘logical top’, ‘logical bottom’, ‘logical left’, and ‘logical right’.

  • Physical coordinates with flipped block-flow direction: The same as ‘physical coordinates’, but for writing-mode: vertical-rl where blocks are laid out right-to-left, block position is “flipped” from the left to the right side of their containing block. This is essentially a mirror reflection horizontally across the center of a block's containing block.

    For writing-mode values other than vertical-rl there is no change from physical coordinates.

    Layout and paint logic reference this space to connote whether “flipping” has been applied to the values. Final painted output for “flipped block-flow” writing mode must, by definition, incorporate flipping. It can be expensive to look up the writing mode of an object. Performing computation on values known to be in this space can save on the overhead required to unflip/reflip.

Example with writing-mode: vertical-rl; direction: ltr:

                   'top' / 'start' side

                    block-flow direction
          <------------------------------------ |
          ------------------------------------- |
          |        c   |          s           | |
'left'    |        o   |          o           | |   inline     'right'
   /      |        n   |          m           | |  direction      /
'after'   |        t   |          e           | |              'before'
 side     |        e   |                      | |                side
          |        n   |                      | |
          |        t   |                      | |
          ------------------------------------- v

                'bottom' / 'end' side

Another example -- consider a relative-positioned element:

html {
    writing-mode: vertical-rl;
<div id="container" style="background-color: lightBlue; width: 300px; height: 200px;">
  <div id="relpos" style="position: relative; top: 50px; left: -60px; width: 70px; height: 80px; background-color: red;"></div>

The final location of these within an 800x600 frame is as:

container: (492, 8  300x200)
relpos:    (662, 58 70x80)

See the diagram for full detail on dimensions of the involved elements.

Determining the paint invalidation rect for relpos via mapToVisualRectInAncestorSpace() involves walking up the layout tree from relpos flipping the rect within its container at each box. Below we sketch each step as we recurse toward the top of the document, with ‘this’ on the left, the current rect being mapped on the right, and explanation beneath each:

LayoutBlockFlow (relative positioned) DIV id='relpos'   0,0    70x80

    Apply the relative position of 'relpos' while flipping within
    'container' to respect writing mode.

    170 = 300 (container width) - 70 (relpos width) - 60 (relpos left)
    50 = relpos top

LayoutBlockFlow DIV id='container'                      170,50 70x80

    Since body has the same width as container, flipping has
    no effect on the rect in this step.

LayoutBlockFlow BODY                                    170,50 70x80

    Flip within the html block, which is symmetrically 8px larger than body
    due to default margin.

LayoutBlockFlow HTML                                    178,58 70x80

    Flip the rectangle within the view.

    662 = 800 (view width) - 316 (html width) + 178 (current rect left)

LayoutView #document                                    662,58 70x80

Since relative-positioned elements are positioned via physical coordinates, and flipping at each step mirrors the position based on the width of the containing box at that step, we can only compute the final physical pixels in screen space for a relative-positioned element if we walk up the full layout tree from the starting object to the topmost view as described above.

For more examples of writing mode and direction combinations, see this demo page though note horizontal-bt is obsolete.

Flipped Block-Flow Coordinates

The nature of “flipping” a value as a mirror reflection within its containing block is such that flipping twice with the same container will produce the original result. Thus when working on involved logic it can be easy to accidentally flip unnecessarily, since flipping (say) one too many times can be “corrected” by flipping again. This can obviously lead to confusing and less performant code, so care should be taken to understand and document any changes to flipping logic.

Blink test coverage for features used in vertical writing modes, and vertical-rl in particular, may not be as comprehensive as for horizontal writing mode. Keep this in mind when writing new functionality or tests by making sure to incorporate coverage for all writing modes when appropriate.

Values are generally transformed into flipped block-flow coordinates via a set of methods on the involved layout objects. See in particular flipForWritingMode(), flipForWritingModeForChild().

InlineBox::flipForWritingMode() variants flip the input value within the inline box's containing block.

LayoutBox::flipForWritingMode() variants flip the input value within the referenced box.

LayoutBox::flipForWritingModeForChild() variants flip the input value within the referenced box, offsetting for the specified child box's current x-position and width. This is useful for a common pattern wherein we build up a point location starting with the current location of the (child) box.

For LayoutBox and InlineBox classes and subclasses:

  • physicalLocation() returns the physical location of a box or inline in the containing block. (0,0) is the top-left corner of the containing block. Flipping is performed on the values as needed. For LayoutBox, if the containing block is not passed to physicalLocation(), looking it up requires walking up the layout tree, which can be expensive. InlineBox::physicalLocation() is expensive only if the InlineBox is in flipped block-flow writing mode.
  • location() returns the location of a box or inline in the “physical coordinates with flipped block-flow direction” coordinate space. (0,0) is the top-left corner of the containing block for writing-mode in normal blocks direction (horizontal-tb and vertical-lr), and is the top-right corner of the containing block for writing-mode in flipped block-flow direction (vertical-rl).

Note there are two primary similar, but slightly different, methods regarding finding the containing block for an element:

  • LayoutObject::container() returns the containing block for an element as defined by CSS.
  • LayoutObject::containingBlock() which returns the enclosing non-anonymous block for an element. If the containing block is a relatively positioned inline, it returns that inline's enclosing non-anonymous block. This is the one used by physicalLocation().

There are other containing block methods in LayoutObject for special purposes such as fixed position, absolute position, and paint invalidation. Code will sometimes just refer to the ‘containing’ element, which is an unfortunately ambiguous term. Paying close attention to which method was used to obtain the containing element is important.

More complex web platform features such as tables, flexbox, and multicol are typically implemented atop these primitives, along with checks such as isFlippedBlocksWritingMode(), isLeftToRightDirection(), and isHorizontalWritingMode(). See for example LayoutTableSection::logicalRectForWritingModeAndDirection(), LayoutFlexibleBox::updateAutoMarginsInCrossAxis() or LayoutMultiColumnFlowThread::flowThreadTranslationAtPoint().

Geometry mapping

TODO(wkorman): Elaborate on:

  • mapToVisualRectInAncestorSpace()
  • mapAncestorToLocal()
  • Widget and FrameView trees. Note the former will be done away with at some point per
  • GeometryMapper (or just point to its section in paint README). For now, see the Web page geometries design document.


TODO(wkorman): Provide an overview of scrolling. For now, the BlinkOn talk on Scrolling in Blink is a good overview.

Root layer scrolling is an ongoing refactoring of Blink's scrolling architecture, which makes the root PaintLayer responsible for the scrolling that was previously done by FrameView. For more details, see: Root Layer Scrolling.


Here we provide a brief overview of key terms relevant to box flow, inline flow, and text orientation. For more detail see CSS Writing Modes Level 3.

The CSS Logical Properties Level 1 specification represents the latest CSSWG thinking on logical coordinate space naming. CSSWG has standardized on block-start, block-end, inline-start, and inline-end, or just start and end when the axis is either implied or irrelevant.

Note that much of the Blink code base predates the logical properties specification and so does not yet reference logical direction consistently in the stated manner, though we would like to head in that direction over time. See also the physical, flow-relative, and line-relative abstract box terminology specification.

  • writing-mode: either horizontal or vertical, with vertical having either left-to-right or right-to-left block flow. Geometry is transposed for vertical writing mode. See calls to transposed{Rect,Point,Size}().
  • direction/dir: “inline base direction” of a box. One of ltr or rtl. See calls to isLeftToRightDirection().
  • text-orientation: orientation of text in a line. Only relevant for vertical modes.
  • orthogonal flow: when a box has a writing mode perpendicular to its containing block. This can lead to complex cases. See specification for more.