Files
yoga/README.md

158 lines
6.3 KiB
Markdown
Raw Normal View History

2015-05-08 13:42:55 -07:00
css-layout [![Build Status](https://travis-ci.org/facebook/css-layout.svg?branch=master)](https://travis-ci.org/facebook/css-layout)
2014-04-06 18:41:56 -07:00
==========
2016-01-13 14:15:48 +00:00
This project implements a subset of CSS including flexbox and the box model using pure JavaScript, then transpiled to C, Java and C#. The goal is to have a small standalone library to layout elements. It doesn't rely on the DOM at all.
2014-04-06 18:43:46 -07:00
The Java, C and JavaScript version of the code is available via [npm](https://www.npmjs.com/package/css-layout) or directly from the `dist` folder of this repo. The JavaScript version is also available via [cdnjs](https://cdnjs.com/libraries/css-layout).
2014-10-30 09:28:03 -07:00
In order to make sure that the code is correct, it is developed in JavaScript using TDD where each commit adds a unit test and the associated code to make it work. All the unit tests are tested against Chrome's implementation of CSS.
2014-04-16 17:35:25 -07:00
The JavaScript version has been implemented in a way that can be easily transpiled to C and Java via regexes. The layout function doesn't do any allocation nor uses any of the dynamic aspects of JavaScript. The tests are also transpiled to make sure that the implementations are correct everywhere.
2014-10-29 08:58:36 -07:00
2014-04-16 17:35:25 -07:00
Usage
-----
A single function `computeLayout` is exposed that
2014-04-16 17:35:25 -07:00
- takes a tree of nodes: `{ style: { ... }, children: [ nodes ] }`
- computes the layout and writes it back to the node tree.
2014-04-16 17:35:25 -07:00
2014-10-08 09:35:44 -07:00
For example,
2014-04-16 17:35:25 -07:00
```javascript
// create an initial tree of nodes
var nodeTree = {
"style": {
"padding": 50
},
"children": [
{
"style": {
"padding": 10,
"alignSelf": "stretch"
}
}
]
};
// compute the layout
computeLayout(nodeTree);
// the layout information is written back to the node tree, with
2016-06-03 22:19:03 +01:00
// each node now having a layout property:
// JSON.stringify(nodeTree, null, 2);
{
"style": {
"padding": 50
},
"children": [
{
"style": {
"padding": 10,
"alignSelf": "stretch"
},
"layout": {
"width": 20,
"height": 20,
"top": 50,
"left": 50,
"right": 50,
"bottom": 50,
"direction": "ltr"
},
"children": [],
"lineIndex": 0
}
],
"layout": {
"width": 120,
"height": 120,
"top": 0,
"left": 0,
"right": 0,
"bottom": 0,
"direction": "ltr"
}
}
2014-04-16 17:35:25 -07:00
```
2014-10-29 09:07:22 -07:00
Supported Attributes
--------------------
Name | Value
----:|------
width, height | positive number
minWidth, minHeight | positive number
maxWidth, maxHeight | positive number
2014-10-29 09:07:22 -07:00
left, right, top, bottom | number
margin, marginLeft, marginRight, marginTop, marginBottom | number
padding, paddingLeft, paddingRight, paddingTop, paddingBottom | positive number
borderWidth, borderLeftWidth, borderRightWidth, borderTopWidth, borderBottomWidth | positive number
flexDirection | 'column', 'row'
justifyContent | 'flex-start', 'center', 'flex-end', 'space-between', 'space-around'
alignItems, alignSelf | 'flex-start', 'center', 'flex-end', 'stretch'
Alter layout engine to conform closer to W3C spec The primary goals of this change are: - Better conformance to the W3C flexbox standard (https://www.w3.org/TR/css-flexbox-1/) and a clear articulation of the areas where it deviates from the spec. - Support for flex-shrink. - Conformance with layout effects of "overflow: hidden". Specifically, here are the limitations of this implementation as compared to the W3C flexbox standard (this is also documented in Layout.js): - Display property is always assumed to be 'flex' except for Text nodes, which are assumed to be 'inline-flex'. - The 'zIndex' property (or any form of z ordering) is not supported. Nodes are stacked in document order. - The 'order' property is not supported. The order of flex items is always defined by document order. - The 'visibility' property is always assumed to be 'visible'. Values of 'collapse' and 'hidden' are not supported. - The 'wrap' property supports only 'nowrap' (which is the default) or 'wrap'. The rarely-used 'wrap-reverse' is not supported. - Rather than allowing arbitrary combinations of flexGrow, flexShrink and flexBasis, this algorithm supports only the three most common combinations: - flex: 0 is equiavlent to flex: 0 0 auto - flex: n (where n is a positive value) is equivalent to flex: n 0 0 - flex: -1 (or any negative value) is equivalent to flex: 0 1 auto - Margins cannot be specified as 'auto'. They must be specified in terms of pixel values, and the default value is 0. - The 'baseline' value is not supported for alignItems and alignSelf properties. - Values of width, maxWidth, minWidth, height, maxHeight and minHeight must be specified as pixel values, not as percentages. - There is no support for calculation of dimensions based on intrinsic aspect ratios (e.g. images). - There is no support for forced breaks. - It does not support vertical inline directions (top-to-bottom or bottom-to-top text). And here is how the implementation deviates from the standard (this is also documented in Layout.js): - Section 4.5 of the spec indicates that all flex items have a default minimum main size. For text blocks, for example, this is the width of the widest word. Calculating the minimum width is expensive, so we forego it and assume a default minimum main size of 0. - Min/Max sizes in the main axis are not honored when resolving flexible lengths. - The spec indicates that the default value for 'flexDirection' is 'row', but the algorithm below assumes a default of 'column'.
2016-04-26 16:35:46 -07:00
flex | number
2015-02-22 09:25:54 -08:00
flexWrap | 'wrap', 'nowrap'
2014-10-29 09:07:22 -07:00
position | 'relative', 'absolute'
Alter layout engine to conform closer to W3C spec The primary goals of this change are: - Better conformance to the W3C flexbox standard (https://www.w3.org/TR/css-flexbox-1/) and a clear articulation of the areas where it deviates from the spec. - Support for flex-shrink. - Conformance with layout effects of "overflow: hidden". Specifically, here are the limitations of this implementation as compared to the W3C flexbox standard (this is also documented in Layout.js): - Display property is always assumed to be 'flex' except for Text nodes, which are assumed to be 'inline-flex'. - The 'zIndex' property (or any form of z ordering) is not supported. Nodes are stacked in document order. - The 'order' property is not supported. The order of flex items is always defined by document order. - The 'visibility' property is always assumed to be 'visible'. Values of 'collapse' and 'hidden' are not supported. - The 'wrap' property supports only 'nowrap' (which is the default) or 'wrap'. The rarely-used 'wrap-reverse' is not supported. - Rather than allowing arbitrary combinations of flexGrow, flexShrink and flexBasis, this algorithm supports only the three most common combinations: - flex: 0 is equiavlent to flex: 0 0 auto - flex: n (where n is a positive value) is equivalent to flex: n 0 0 - flex: -1 (or any negative value) is equivalent to flex: 0 1 auto - Margins cannot be specified as 'auto'. They must be specified in terms of pixel values, and the default value is 0. - The 'baseline' value is not supported for alignItems and alignSelf properties. - Values of width, maxWidth, minWidth, height, maxHeight and minHeight must be specified as pixel values, not as percentages. - There is no support for calculation of dimensions based on intrinsic aspect ratios (e.g. images). - There is no support for forced breaks. - It does not support vertical inline directions (top-to-bottom or bottom-to-top text). And here is how the implementation deviates from the standard (this is also documented in Layout.js): - Section 4.5 of the spec indicates that all flex items have a default minimum main size. For text blocks, for example, this is the width of the widest word. Calculating the minimum width is expensive, so we forego it and assume a default minimum main size of 0. - Min/Max sizes in the main axis are not honored when resolving flexible lengths. - The spec indicates that the default value for 'flexDirection' is 'row', but the algorithm below assumes a default of 'column'.
2016-04-26 16:35:46 -07:00
overflow | 'visible', 'hidden'
2014-10-29 09:07:22 -07:00
Alter layout engine to conform closer to W3C spec The primary goals of this change are: - Better conformance to the W3C flexbox standard (https://www.w3.org/TR/css-flexbox-1/) and a clear articulation of the areas where it deviates from the spec. - Support for flex-shrink. - Conformance with layout effects of "overflow: hidden". Specifically, here are the limitations of this implementation as compared to the W3C flexbox standard (this is also documented in Layout.js): - Display property is always assumed to be 'flex' except for Text nodes, which are assumed to be 'inline-flex'. - The 'zIndex' property (or any form of z ordering) is not supported. Nodes are stacked in document order. - The 'order' property is not supported. The order of flex items is always defined by document order. - The 'visibility' property is always assumed to be 'visible'. Values of 'collapse' and 'hidden' are not supported. - The 'wrap' property supports only 'nowrap' (which is the default) or 'wrap'. The rarely-used 'wrap-reverse' is not supported. - Rather than allowing arbitrary combinations of flexGrow, flexShrink and flexBasis, this algorithm supports only the three most common combinations: - flex: 0 is equiavlent to flex: 0 0 auto - flex: n (where n is a positive value) is equivalent to flex: n 0 0 - flex: -1 (or any negative value) is equivalent to flex: 0 1 auto - Margins cannot be specified as 'auto'. They must be specified in terms of pixel values, and the default value is 0. - The 'baseline' value is not supported for alignItems and alignSelf properties. - Values of width, maxWidth, minWidth, height, maxHeight and minHeight must be specified as pixel values, not as percentages. - There is no support for calculation of dimensions based on intrinsic aspect ratios (e.g. images). - There is no support for forced breaks. - It does not support vertical inline directions (top-to-bottom or bottom-to-top text). And here is how the implementation deviates from the standard (this is also documented in Layout.js): - Section 4.5 of the spec indicates that all flex items have a default minimum main size. For text blocks, for example, this is the width of the widest word. Calculating the minimum width is expensive, so we forego it and assume a default minimum main size of 0. - Min/Max sizes in the main axis are not honored when resolving flexible lengths. - The spec indicates that the default value for 'flexDirection' is 'row', but the algorithm below assumes a default of 'column'.
2016-04-26 16:35:46 -07:00
- Rather than allowing arbitrary combinations of `flex-grow`, `flex-shrink`, and `flex-basis` the implementation only supports a few common combinations expressed as a single number using the `flex` attribute:
css-layout `flex` value | W3C `flex` short-hand equivalent
---|---
n (where n > 0) | n 0 0
0 | 0 0 auto
-1 | 0 1 auto
2016-06-03 22:19:03 +01:00
2014-10-29 09:07:22 -07:00
- `inherit` value is not implemented because it's a way to disambiguate between multiple colliding rules. This should be done in a pre-processing step, not in the actual layout algorithm.
2014-04-16 17:35:25 -07:00
Default values
--------------
2014-09-11 10:47:43 -07:00
Since we are only using flexbox, we can use defaults that are much more sensible. This is the configuration to use in order to get the same behavior using the DOM and CSS. You can try those default settings with the [following JSFiddle](http://jsfiddle.net/vjeux/y11txxv9/).
2014-04-16 17:35:25 -07:00
```css
2014-09-11 10:47:43 -07:00
div, span {
2014-04-16 17:35:25 -07:00
box-sizing: border-box;
position: relative;
2014-10-08 09:35:44 -07:00
2014-04-16 17:35:25 -07:00
display: flex;
flex-direction: column;
2014-10-08 09:35:44 -07:00
align-items: stretch;
2014-04-16 17:35:25 -07:00
flex-shrink: 0;
align-content: flex-start;
2015-02-22 09:25:54 -08:00
border: 0 solid black;
margin: 0;
padding: 0;
Alter layout engine to conform closer to W3C spec The primary goals of this change are: - Better conformance to the W3C flexbox standard (https://www.w3.org/TR/css-flexbox-1/) and a clear articulation of the areas where it deviates from the spec. - Support for flex-shrink. - Conformance with layout effects of "overflow: hidden". Specifically, here are the limitations of this implementation as compared to the W3C flexbox standard (this is also documented in Layout.js): - Display property is always assumed to be 'flex' except for Text nodes, which are assumed to be 'inline-flex'. - The 'zIndex' property (or any form of z ordering) is not supported. Nodes are stacked in document order. - The 'order' property is not supported. The order of flex items is always defined by document order. - The 'visibility' property is always assumed to be 'visible'. Values of 'collapse' and 'hidden' are not supported. - The 'wrap' property supports only 'nowrap' (which is the default) or 'wrap'. The rarely-used 'wrap-reverse' is not supported. - Rather than allowing arbitrary combinations of flexGrow, flexShrink and flexBasis, this algorithm supports only the three most common combinations: - flex: 0 is equiavlent to flex: 0 0 auto - flex: n (where n is a positive value) is equivalent to flex: n 0 0 - flex: -1 (or any negative value) is equivalent to flex: 0 1 auto - Margins cannot be specified as 'auto'. They must be specified in terms of pixel values, and the default value is 0. - The 'baseline' value is not supported for alignItems and alignSelf properties. - Values of width, maxWidth, minWidth, height, maxHeight and minHeight must be specified as pixel values, not as percentages. - There is no support for calculation of dimensions based on intrinsic aspect ratios (e.g. images). - There is no support for forced breaks. - It does not support vertical inline directions (top-to-bottom or bottom-to-top text). And here is how the implementation deviates from the standard (this is also documented in Layout.js): - Section 4.5 of the spec indicates that all flex items have a default minimum main size. For text blocks, for example, this is the width of the widest word. Calculating the minimum width is expensive, so we forego it and assume a default minimum main size of 0. - Min/Max sizes in the main axis are not honored when resolving flexible lengths. - The spec indicates that the default value for 'flexDirection' is 'row', but the algorithm below assumes a default of 'column'.
2016-04-26 16:35:46 -07:00
min-width: 0;
2014-04-16 17:35:25 -07:00
}
```
- `box-sizing: border-box` is the most convenient way to express the relation between `width` and `borderWidth`.
- Everything is `display: flex` by default. All the behaviors of `block` and `inline-block` can be expressed in term of `flex` but not the opposite.
- All the flex elements are oriented from top to bottom, left to right and do not shrink. This is how things are laid out using the default CSS settings and what you'd expect.
- Everything is `position: relative`. This makes `position: absolute` target the direct parent and not some parent which is either `relative` or `absolute`. If you want to position an element relative to something else, you should move it in the DOM instead of relying of CSS. It also makes `top, left, right, bottom` do something when not specifying `position: absolute`.
Native Usage Notes
------------------
The C equivalent of `computeLayout` is [`layoutNode`](dist/css-layout.h#L1378).
In order for layout to properly layout reflowable text, the `measure` function must be set on the `css_node` structure. The property can be found in [`css-layout.h`](dist/css-layout.h#L146). This function must take a void pointer to a `context` that will affect the size of the node and the `width` as computed by the layout engine, and must return a `css_dim_t` structure defining the actual needed size of the node. For the most part, the `context` field can be the text inside the node. No C implementation of this function is provided in provided - it depends on your use of css-layout. However an implementation of the function in JavaScript can be used for reference in the [test utilities](src/Layout-test-utils.js#L383).
Development
-----------
The core logic resides with `Layout.js`, which is transpiled into equivalent C and Java implementations.
2015-08-12 08:45:41 +01:00
The JavaScript build process is managed via Grunt. The build performs linting, runs the tests against Chrome, transpiles and packages the code (JavaScript and Java) into the `dist` folder. For JavaScript, the build output uses the Universal Module Format (UMD) so that it can be used via AMD / RequireJS, CommonJS or included directly into an HTML page.
2015-08-12 08:45:41 +01:00
While developing you can just run the lint / Chrome-based tests a follows:
2015-08-12 08:45:41 +01:00
```
grunt test-javascript
```