gioser

tawasuyu/taffy

A high performance rust-powered UI layout library

Rust 709HTML 662Markdown 12TOML 62348 Definitions

⎇ e2b3b2401f1f9bc4b4da89a5da1fc95525725891 RELEASES.md Markdown · 366 lines · 23.9 KB History raw

Grid: Rename Flex to Fraction (#350) 71027a8de · Nico Burns ·

1# Release Notes
2
3## 0.3.0-alpha2 (unreleased)
4
5### Added
6
7- A new style helper `evenly_sized_tracks(count: u16)` has been added which creates a grid template containing `count` evenly sized tracks (rows or columns)
8
9### Changed
10
11- `experimental_grid` feature named to just `grid`
12- `grid` feature enabled by default
13- `GridPlacement::Line` now stores a `GridLine` newtype wrapper around an `i16` rather than a raw `i16`. If you are using the style helpers then this change will not affect you.
14- *BREAKING:* `Position` is now renamed to `Inset` and is now in line with [CSS inset specs](https://developer.mozilla.org/en-US/docs/Web/CSS/inset)
15- *BREAKING:* `PositionType` is now renamed to `Position` and is now in line with [CSS position specs](https://developer.mozilla.org/en-US/docs/Web/CSS/position)
16- `MaxTrackSizingFunction::Flex` is now called `MaxTrackSizingFunction::Fraction`. The `flex()` helper is now called `fr()`. A new `flex()` helper has been added which create a `minmax(0, Nfr)` track.
17
18### Fixes
19
20- Flexbox nodes sized under a min-content constraint now size correctly (#291)
21- Aspect ratio is now applied correctly in many circumstances
22- Absolutely positioned items now apply margins correctly
23- Min/max size are now applied correctly
24- Inset applied incorrectly to relatively positioned flexbox children when both `top` and `bottom` or `left` and `right` were specified (#348)
25
26### Removed
27
28- Removed `top_from_points`, `bot_from_points`, `top_from_percent`, and `bot_from_percent` methods removed from `Rect<Dimension>`. These functions were incredibly specific for an unusual use case, so we would be surprised if anyone was using them. Please use the new style helpers instead.
29- Removed `min_main_size`, `max_main_size`, `min_cross_size`, `max_cross_size`, and `cross_size` methods from `Style`. Use the more general `cross` and `main` methods directly on the `size`, `min_size`, and `max_size` properties instead.
30- Removed `main_margin_start`, `main_margin_end`, `cross_margin_start`, `cross_margin_end` from `Style`. Use the more general `main_start`, `main_end`, `cross_start`, and `cross_end` on the `margin` property instead.
31
32## 0.3.0-alpha1
33
34This is the first in a series of planned alpha releases to allow users of Taffy to try out the new CSS Grid layout mode in advance of a stable release. We hope that by marking this is alpha release we are clearly communicating that this a pre-release and that the implementation is not yet of production quality. But we never-the-less encourage you to try it out. Feedback is welcome, and bug reports for the Grid implementation are being accepted as of this release.
35
36~**Note: CSS Grid support must be enabled using the `experimental_grid` feature. For the time being this feature is not enabled by default.**~ From `0.3.0-alpha2`, the CSS Grid feature is now enabled by default.
37
38### New Feature: CSS Grid (Experimental)
39
40We very excited to report that we have an initial version of the CSS Grid layout available. This is in addition to the existing Flexbox layout support, and the two modes interoperate (although this interaction has not been extensively tested). You can set a node to use Grid layout by setting the `display` property to `Display::Grid`.
41
42#### Learning Resources
43
44Taffy implements the CSS Grid specification faithfully, so documentation designed for the web should translate cleanly to Taffy's implementation. If you are interested in learning how to use CSS Grid, we would recommend the following resources:
45
46- [CSS Grid Garden](https://cssgridgarden.com/). This is an interactive tutorial/game that allows you to learn the essential parts of CSS Grid in a fun engaging way.
47- [A Complete Guide To CSS Grid](https://css-tricks.com/snippets/css/complete-guide-grid/) by CSS Tricks. This is detailed guide with illustrations and comphrehensive written explanation of the different Grid propertie and how they work.
48
49#### Supported Features & Properties
50
51In addition to the usual sizing/spacing proerties (size, min_size, padding, margin, etc), the following Grid style properties are supported on Grid Containers:
52
53| Property                  | Explanation                                                                                    |
54| ---                       | ---                                                                                            |
55| [`grid-template-columns`] | The track sizing functions of the grid's explicit columns                                      |
56| [`grid-template-rows`]    | The track sizing functions of the grid's explicit rows                                         |
57| [`grid-auto-rows`]        | Track sizing functions for the grid's implicitly generated rows                                |
58| [`grid-auto-columns`]     | Track sizing functions for the grid's implicitly generated columns                             |
59| [`grid-auto-flow`]        | Whether auto-placed items are placed row-wise or column-wise. And sparsely or densely.         |
60| [`gap`]                   | The size of the vertical and horizontal gaps between grid rows/columns                         |
61| [`align-content`]         | Align grid tracks within the container in the inline (horizontal) axis                         |
62| [`justify-content`]       | Align grid tracks within the container in the block (vertical) axis                            |
63| [`align-items`]           | Align the child items within their grid areas in the inline (horizontal) axis                  |
64| [`justify-items`]         | Align the child items within their grid areas in the block (vertical) axis                     |
65
66And the following Grid style properties are supported on Grid Items (children):
67
68| Property                  | Explanation                                                                                    |
69| ---                       | ---                                                                                            |
70| [`grid-row`]              | The (row) grid line the item starts at (or a span)                                             |
71| [`grid-column`]           | The (column) grid line the item end at (or a span)                                             |
72| [`align-self`]            | Align the item within it's grid area in the inline (horizontal) axis. Overrides `align-items`. |
73| [`justify-self`]          | Align the item within it's grid area in the block (vertical) axis. Overrides `justify-items`.  |
74
75[`grid-template-columns`]: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-template-columns
76[`grid-template-rows`]: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-template-rows
77[`grid-auto-rows`]: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-auto-rows
78[`grid-auto-columns`]: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-auto-columns
79[`grid-auto-flow`]: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-auto-flow
80[`gap`]: https://developer.mozilla.org/en-US/docs/Web/CSS/gap
81[`align-content`]: https://developer.mozilla.org/en-US/docs/Web/CSS/align_content
82[`justify-content`]: https://developer.mozilla.org/en-US/docs/Web/CSS/justify_content
83[`align-items`]: https://developer.mozilla.org/en-US/docs/Web/CSS/align-items
84[`justify-items`]: https://developer.mozilla.org/en-US/docs/Web/CSS/justify-items
85[`grid-row`]: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-row
86[`grid-column`]: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-column
87[`align-self`]: https://developer.mozilla.org/en-US/docs/Web/CSS/align-self
88[`justify-self`]: https://developer.mozilla.org/en-US/docs/Web/CSS/justify-self
89
90The following properties and features are not yet supported, but are planned for the near future:
91
92- Baseline alignment
93- `fit-content()` with a percentage argument.
94- `repeat()` with integer repetition (but users of Taffy can just expand these definition manually)
95
96The following properties and features are not supported, and there are no immediate plans to implement them:
97
98- Subgrids
99- Named grid lines
100- Named areas: `grid-template-areas` and `grid-area`
101- `grid-template` or `grid` shorthand
102
103#### Example
104
105See [examples/grid_holy_grail.rs](https://github.com/DioxusLabs/taffy/blob/main/examples/grid_holy_grail.rs) for an example using Taffy to implement the so-called [Holy Grail Layout](https://en.wikipedia.org/wiki/Holy_grail_(web_design)). If you want to run this example, the don't forget the enable the CSS Grid cargo feature:
106
107```bash
108cargo run --example grid_holy_grail --features grid
109```
110
111### New Feature: Style Helpers
112
113Ten new helper functions have added to the taffy prelude. These helper functions have short, intuitive names, and have generic return types which allow them to magically return the correct type depending on context. They make defining styles much easier, and means you won't typically need to use types like `Dimension` or `TrackSizingFunction` directly.
114
115For example, instead of:
116
117```rust
118let size : Size<Dimension> = Size { width: Dimension::Points(100.0), height: Dimension::Percent(50.0) };
119```
120
121you can now write
122
123```rust
124let size : Size<Dimension> = Size { width: points(100.0), height: percent(50.0) };
125```
126
127And that same helper function will work other types like `LengthPercentage` and `MinTrackSizingFunction` that also have a `Points` variant. There are also generic impl's for `Size<T>`, `Rect<T>` and `Line<T>` which means if your node is the same size in all dimensions you can even write
128
129```rust
130let size : Size<Dimension> = points(100.0);
131```
132
133The following functions work for `Dimension`, `LengthPercentageAuto`, `LengthPercentage`, `AvailableSpace` and for Grid track sizing functions
134
135- `points(f32)` - Generates a `Points` variant with the specified value
136- `zero()` - Generates a `Points` variant with the value `0.0`.
137
138The following functions work for `Dimension`, `LengthPercentageAuto`, `LengthPercentage` and for Grid track sizing functions
139
140- `percent(f32)` - Generates a `Percent` value
141- `auto()` - Generates an `Auto` variant
142
143The following functions work for `AvailableSpace` and grid track sizing functions:
144
145- `min_content()` - Generates an `MinContent` variant
146- `max_content()` - Generates an `MaxContent` variant
147
148The following functions currently work only for grid track sizing functions:
149
150- `flex(f32)` - Genrates a `Flex` variant with the specified flex fraction
151- `fit_content(LengthPercentage)` - Generates a `FitContent` variant with the specified limit. Nest `points` or `percent` inside this function to specified the limit.
152- `minmax(MinTrackSizingFunction, MaxTrackSizingFunction)` - Generates a track sizing function with different min and max sizing functions. Nest `points`, `percent`, `auto`, `min_content`, `max_content`, or `flex` to specify the min and max functions.
153- `repeat(GridTrackRepetition, Vec<TrackSizingFunction>)` - Genereate an auto-repeating track definition.
154
155### Breaking API changes
156
157#### Changes to alignment style types
158
159- `AlignContent` and `JustifyContent` has been merged.
160  - `JustifyContent` is now an alias of `AlignContent` and contains the `Stretch` variant.
161  - This variant will be *ignored* (falling back to `Start`) when applied Flexbox containers. It is valid value for Grid containers.
162- `AlignItems` and `AlignSelf` have been merged.
163  - The `Auto` variant of `AlignSelf` has been removed. You should now use `Option::None` if you wish to specify `AlignSelf::Auto`.
164  - `AlignSelf` is now an alias of `AlignItems`.
165  - `JustifyItems` and `JustifySelf` aliases have been added. These properties have no affect on Flexbox containers, but apply to Grid containers.
166- `Default` impls have been removed from all alignment types. This is because the correct default varies by property, and the types are now shared between multiple properties. The `Style` struct still has a default for each alignment property, so this is considered unlikely to affect you in practice.
167
168#### Strict style types
169
170- New types `LengthPercentage` and `LengthPercentageAuto` have been added.
171  - `LengthPercentage` is like `Dimension` but only contains the `Points` and `Percent` variants, which allows us to increase type safety for properties that don't support the `Auto` value.
172  - `LengthPercentageAuto` is currently identical to `Dimension` but will allow us to expand dimension in future to support values like `MinContent`, `MaxContent` and `FitContent`.
173- Some style properties have been updated to use either `LengthPercentage` or `LengthPercentageAuto` instead of `Dimension`. You will need to update your code, but it is recommended that you use the new style helpers (see above) rather than using the new types directly (although you certainly can use them directly if you want to).
174
175#### Changes to `LayoutTree`
176
177- Added generic associated type to `LayoutTree` for a `ChildIter`, an iterator on the children of a given node.
178- Changed the `children` method of `LayoutTree` to return the `ChildIter` generic associated type to allow for custom tree storage implementations which do not store the children of a node contiguously.
179- Added `child_count`  method to `LayoutTree` for querying the number of children of a node. Required because the `children` method now returns an iterator instead of an array.
180- Added `is_childless` method to `LayoutTree` for querying whether a node has no children.
181
182#### `AvailableSpace` has been moved
183
184The `AvailableSpace` enum has been moved from the `layout` module to the `style` module. If you are importing it via the prelude then you will unaffected by the change.
185
186### Fixes
187
188- Fix case where column-gap style could be used in place of row-gap style (when using a percentage gap with an indefinite container size)
189
190## 0.2.2
191
192### Fixes
193
194- Border or padding on the horizontal axis could, in some cases, increase the height of nodes.
195
196## 0.2.1
197
198### Fixes
199
200- In case of conflicts, `min_size` now overrides `max_size` which overrides `size` (#261). This is the behaviour specified in the CSS specification, and was also the behaviour in Taffy `v0.1.0`, but a regression was introduced in Taffy `v0.2.0`.
201- `taffy::compute_layout` has been made public allowing Taffy to be used with custom storage (#263)
202
203## 0.2.0
204
205### New features
206
207#### Flexbox "gap" and `AlignContent::SpaceEvenly`
208
209The [gap](https://developer.mozilla.org/en-US/docs/Web/CSS/gap) property is now supported on flex containers. This can make it much easier to create even spacing or "gutters" between nodes.
210
211Additionally we have a `SpaceEvenly` variant to the `AlignContent` enum to support evenly spaced justification in the cross axis (equivalent to  `align-content: space-evenly` in CSS)
212
213#### Debug module and cargo feature
214
215Two debugging features have been added:
216
217- `taffy::debug::print_tree(&Taffy, root)` - This will print a debug representation of the computed layout of an entire node tree (starting at `root`), which can be useful for debugging layouts.
218- A cargo feature `debug`. This enabled debug logging of the layout computation process itself (this is probably mainly useful for those working taffy itself).
219
220### Performance improvements
221
222A number of performance improvements have landed since taffy 0.1:
223
224- Firstly, our custom `taffy::forest` storage implementation was ripped out and replaced with a much simpler implementation using the `slotmap` crate. This led to performance increases of up to 90%.
225- Secondly, the caching implementation was improved by upping the number of cache slots from 2 to 4 and tweaking how computed results are allocated to chache slots to better match the actual usage patterns of the flexbox layout algorithm. This had a particularly dramatic effect on deep hierachies (which often involve recomputing the same results repeatedly), fixing the exponential blowup that was previously exhibited on these trees and improving performance by over 1000x in some cases!
226
227#### Benchmarks vs. Taffy 0.1
228
229| Benchmark | Taffy 0.1 | Taffy 0.2 | % change (0.1 -> 0.2) |
230| --- | --- | --- | --- |
231| wide/1_000 nodes (2-level hierarchy) | 3.5458 µs | 4.3571 µs | +23.333% |
232| wide/10_000 nodes (2-level hierarchy) | 36.418 µs | 42.967 µs | +17.357% |
233| wide/100_000 nodes (2-level hierarchy) | 1.8275 ms | 3.9096 ms | +112.26% |
234| deep/4000 nodes (12-level hierarchy)) | 5.1845 s | 15.318 µs | -100.000% |
235| deep/10_000 nodes (14-level hierarchy) | 75.978 s | 40.315 µs | -100.000% |
236| deep/100_000 nodes (17-level hierarchy) | - | 2.7644 ms| - |
237| deep/1_000_000 nodes (20-level hierarchy) | - | 1.2130 s| - |
238
239(note that the table above contains multiple different units (milliseconds vs. microseconds vs. nanoseconds))
240
241As you can see, we have actually regressed slightly in the "wide" benchmarks (where all nodes are siblings of a single parent node). Although it should be noted our results in these benchmarks are still very fast, especially on the 10,000 node benchmark which we consider to be the most realistic size where the result is measured in microseconds.
242
243However, in the "deep" benchmarks we see dramatic improvements. The previous version of Taffy suffered from exponential blowup in the case of deeply nested hierachies. This has resulted in somewhat silly improvements like the 10,000 node (14-level) hierachy where Taffy 0.2 is a full 1 million times faster than Taffy 0.1. We've also included results with larger numbers of nodes (although you're unlikely to need that many) to demonstrate that this scalability continues up to even deeper levels of nesting.
244
245#### Benchmarks vs. [Yoga](https://github.com/facebook/yoga)
246
247Yoga benchmarks run via it's node.js bindings (the `yoga-layout-prebuilt` npm package), they were run a few times manually and it was verified that variance in the numbers of each run was minimal. It should be noted that this is using an old version of Yoga.
248
249| Benchmark | Yoga | Taffy 0.2 |
250| --- | --- | --- |
251| yoga/10 nodes (1-level hierarchy) | 45.1670 µs | 33.297 ns |
252| yoga/100 nodes (2-level hierarchy) | 134.1250 µs | 336.53 ns |
253| yoga/1_000 nodes (3-level hierarchy) | 1.2221 ms | 3.8928 µs |
254| yoga/10_000 nodes (4-level hierarchy) | 13.8672 ms | 36.162 µs |
255| yoga/100_000 nodes (5-level hierarchy) | 141.5307 ms | 1.6404 ms |
256
257(note that the table above contains multiple different units (milliseconds vs. microseconds vs. nanoseconds))
258
259While we're trying not to get too excited (there could easily be an issue with our benchmarking methodology which make this an unfair comparison), we are pleased to see that we seem to be anywhere between 100x and 1000x times faster depending on the node count!
260
261### Breaking API changes
262
263#### Node creation changes
264
265- `taffy::Node` is now unique only to the Taffy instance from which it was created.
266- Renamed `Taffy.new_node(..)` -> `Taffy.new_with_children(..)`
267- Renamed `Taffy.new_leaf()` -> `Taffy.new_leaf_with_measure()`
268- Added `taffy::node::Taffy.new_leaf()` which allows the creation of new leaf-nodes without having to supply a measure function
269
270#### Error handling/representation improvements
271
272- Renamed `taffy::Error` -> `taffy::error::TaffyError`
273- Replaced `taffy::error::InvalidChild` with a new `InvalidChild` variant of `taffy::error::TaffyError`
274- Replaced `taffy::error::InvalidNode` with a new `InvalidNode` variant of `taffy::error::TaffyError`
275- The following method new return `Err(TaffyError::ChildIndexOutOfBounds)` instead of panicking:
276  - `taffy::Taffy::remove_child_at_index`
277  - `taffy::Taffy::replace_child_at_index`
278  - `taffy::Taffy::child_at_index`
279- `Taffy::remove` now returns a `Result<usize, Error>`, to indicate if the operation was sucessful (and if it was, which ID was invalidated).
280
281#### Some uses of `Option<f32>` replaced with a new `AvailableSpace` enum
282
283A new enum `Taffy::layout::AvailableSpace` has been added.
284
285The definition looks like this:
286
287```rust
288/// The amount of space available to a node in a given axis
289pub enum AvailableSpace {
290    /// The amount of space available is the specified number of pixels
291    Definite(f32),
292    /// The amount of space available is indefinite and the node should be laid out under a min-content constraint
293    MinContent,
294    /// The amount of space available is indefinite and the node should be laid out under a max-content constraint
295    MaxContent,
296}
297```
298
299This enum is now used instead of `Option<f32>` when calling `Taffy.compute_layout` (if you previously passing `Size::NONE` to `compute_layout`, then you will need to change this to `Size::MAX_CONTENT`).
300
301And a different instance of it is passed as a new second parameter to `MeasureFunc`. `MeasureFunc`s may choose to use this parameter in their computation or ignore it as they see fit. The canonical example of when it makes sense to use it is when laying out text. If `MinContent` has been passed in the axis in which the text is flowing (i.e. the horizontal axis for left-to-right text), then you should line-break at every possible opportunity (e.g. all word boundaries), whereas if `MaxContent` has been passed then you shouldn't line break at all..
302
303#### Builder methods are now `const` where possible
304
305- Several convenience constants have been defined: notably `Style::DEFAULT`
306- `Size<f32>.zero()` is now `Size::<f32>::ZERO`
307- `Point<f32>.zero()` is now  `Point::<f32>::ZERO`
308- `Size::undefined()` is now `Size::NONE`
309
310#### Removals
311
312- Removed `taffy::forest::Forest`. `taffy::node::Taffy` now handles it's own storage using a slotmap (which comes with a performance boost up to 90%).
313- Removed `taffy::number::Number`. Use `Option<f32>` is used instead
314  - the associated public `MinMax` and `OrElse` traits have also been removed; these should never have been public
315- Removed unused dependencies `hashbrown`, `hash32`, and `typenum`. `slotmap` is now the only required dependency (`num_traits` and `arrayvec` are also required if you wish to use taffy in a `no_std` environment).
316
317### Fixes
318
319- Miscellaneous correctness fixes which align our implementation with Chrome:
320
321  - Nodes can only ever have one parent
322  - Fixed rounding of fractional values to follow latest Chrome - values are now rounded the same regardless of their position
323  - Fixed computing free space when using both `flex-grow` and a minimum size
324  - Padding is now only subtracted when determining the available space if the node size is unspecified, following [section 9.2.2 of the flexbox spec](https://www.w3.org/TR/css-flexbox-1/#line-sizing)
325  - `MeasureFunc` (and hence `NodeData` and hence `Forest` and hence the public `Taffy` type) are now `Send` and `Sync`, enabling their use in async and parallel applications
326- Taffy can now be vendored using `cargo-vendor` (README.md is now included in package).
327
328## 0.1.0
329
330### 0.1.0 Changed
331
332- the `order` field of `Layout` is now public, and describes the relative z-ordering of nodes
333- renamed crate from `stretch2` to `taffy`
334- updated to the latest version of all dependencies to reduce upstream pain caused by duplicate dependencies
335- renamed `stretch::node::Strech` -> `taffy::node::Taffy`
336
337### 0.1.0 Fixed
338
339- fixed feature strategy for `alloc` and `std`: these can now be compiled together, with `std`'s types taking priority
340
341### 0.1.0 Removed
342
343- removed Javascript / Kotlin / Swift bindings
344  - the maintainer team lacks expertise to keep these working
345  - more serious refactors are planned, and this will be challenging to keep working through that process
346  - if you are interested in helping us maintain bindings to other languages, [get in touch](https://github.com/DioxusLabs/taffy/discussions)!
347- the `serde_camel_case` and `serde_kebab_case` features have been removed: they were poorly motivated and were not correctly additive (if both were enabled compilation would fail)
348- removed the `Direction` and `Overflow` structs, and the corresponding `direction` and `overflow` fields from `Style`
349  - these had no effect in the current code base and were actively misleading
350
351## stretch2 0.4.3
352
353This is the final release of `stretch`: migrate to the crate named `taffy` for future fixes and features!
354
355These notes describe the differences between this release and `stretch` 0.3.2, the abandoned crate from which this library was forked.
356
357### Changed
358
359- updated [assorted dependencies](https://github.com/vislyhq/stretch/commit/a6491117379cea52dedc9584d892594a143e8cb0)
360
361### Fixed
362
363- fixed an exponential performance blow-up with deep nesting
364- fixed percent height values, which were using parent width
365- recomputing layout no longer moves children of non-zero-positioned parent
366- fixed broken Swift bindings

RELEASES.md

Release Notes

0.3.0-alpha2 (unreleased)

Added

Changed

Fixes

Removed

0.3.0-alpha1

This is the first in a series of planned alpha releases to allow users of Taffy to try out the new CSS Grid layout mode in advance of a stable release. We hope that by marking this is alpha release we are clearly communicating that this a pre-release and that the implementation is not yet of production quality. But we never-the-less encourage you to try it out. Feedback is welcome, and bug reports for the Grid implementation are being accepted as of this release.

Note: CSS Grid support must be enabled using the experimental_grid feature. For the time being this feature is not enabled by default. From 0.3.0-alpha2, the CSS Grid feature is now enabled by default.

New Feature: CSS Grid (Experimental)

We very excited to report that we have an initial version of the CSS Grid layout available. This is in addition to the existing Flexbox layout support, and the two modes interoperate (although this interaction has not been extensively tested). You can set a node to use Grid layout by setting the display property to Display::Grid.

Learning Resources

Taffy implements the CSS Grid specification faithfully, so documentation designed for the web should translate cleanly to Taffy's implementation. If you are interested in learning how to use CSS Grid, we would recommend the following resources:

Supported Features & Properties

In addition to the usual sizing/spacing proerties (size, min_size, padding, margin, etc), the following Grid style properties are supported on Grid Containers:

PropertyExplanation
grid-template-columnsThe track sizing functions of the grid's explicit columns
grid-template-rowsThe track sizing functions of the grid's explicit rows
grid-auto-rowsTrack sizing functions for the grid's implicitly generated rows
grid-auto-columnsTrack sizing functions for the grid's implicitly generated columns
grid-auto-flowWhether auto-placed items are placed row-wise or column-wise. And sparsely or densely.
gapThe size of the vertical and horizontal gaps between grid rows/columns
align-contentAlign grid tracks within the container in the inline (horizontal) axis
justify-contentAlign grid tracks within the container in the block (vertical) axis
align-itemsAlign the child items within their grid areas in the inline (horizontal) axis
justify-itemsAlign the child items within their grid areas in the block (vertical) axis

And the following Grid style properties are supported on Grid Items (children):

PropertyExplanation
grid-rowThe (row) grid line the item starts at (or a span)
grid-columnThe (column) grid line the item end at (or a span)
align-selfAlign the item within it's grid area in the inline (horizontal) axis. Overrides align-items.
justify-selfAlign the item within it's grid area in the block (vertical) axis. Overrides justify-items.

The following properties and features are not yet supported, but are planned for the near future:

The following properties and features are not supported, and there are no immediate plans to implement them:

Example

See examples/grid_holy_grail.rs for an example using Taffy to implement the so-called Holy Grail Layout. If you want to run this example, the don't forget the enable the CSS Grid cargo feature:

cargo run --example grid_holy_grail --features grid

New Feature: Style Helpers

Ten new helper functions have added to the taffy prelude. These helper functions have short, intuitive names, and have generic return types which allow them to magically return the correct type depending on context. They make defining styles much easier, and means you won't typically need to use types like Dimension or TrackSizingFunction directly.

For example, instead of:

let size : Size<Dimension> = Size { width: Dimension::Points(100.0), height: Dimension::Percent(50.0) };

you can now write

let size : Size<Dimension> = Size { width: points(100.0), height: percent(50.0) };

And that same helper function will work other types like LengthPercentage and MinTrackSizingFunction that also have a Points variant. There are also generic impl's for Size<T>, Rect<T> and Line<T> which means if your node is the same size in all dimensions you can even write

let size : Size<Dimension> = points(100.0);

The following functions work for Dimension, LengthPercentageAuto, LengthPercentage, AvailableSpace and for Grid track sizing functions

The following functions work for Dimension, LengthPercentageAuto, LengthPercentage and for Grid track sizing functions

The following functions work for AvailableSpace and grid track sizing functions:

The following functions currently work only for grid track sizing functions:

Breaking API changes

Changes to alignment style types

Strict style types

Changes to LayoutTree

AvailableSpace has been moved

The AvailableSpace enum has been moved from the layout module to the style module. If you are importing it via the prelude then you will unaffected by the change.

Fixes

0.2.2

Fixes

0.2.1

Fixes

0.2.0

New features

Flexbox "gap" and AlignContent::SpaceEvenly

The gap property is now supported on flex containers. This can make it much easier to create even spacing or "gutters" between nodes.

Additionally we have a SpaceEvenly variant to the AlignContent enum to support evenly spaced justification in the cross axis (equivalent to align-content: space-evenly in CSS)

Debug module and cargo feature

Two debugging features have been added:

Performance improvements

A number of performance improvements have landed since taffy 0.1:

Benchmarks vs. Taffy 0.1

BenchmarkTaffy 0.1Taffy 0.2% change (0.1 -> 0.2)
wide/1_000 nodes (2-level hierarchy)3.5458 µs4.3571 µs+23.333%
wide/10_000 nodes (2-level hierarchy)36.418 µs42.967 µs+17.357%
wide/100_000 nodes (2-level hierarchy)1.8275 ms3.9096 ms+112.26%
deep/4000 nodes (12-level hierarchy))5.1845 s15.318 µs-100.000%
deep/10_000 nodes (14-level hierarchy)75.978 s40.315 µs-100.000%
deep/100_000 nodes (17-level hierarchy)-2.7644 ms-
deep/1_000_000 nodes (20-level hierarchy)-1.2130 s-

(note that the table above contains multiple different units (milliseconds vs. microseconds vs. nanoseconds))

As you can see, we have actually regressed slightly in the "wide" benchmarks (where all nodes are siblings of a single parent node). Although it should be noted our results in these benchmarks are still very fast, especially on the 10,000 node benchmark which we consider to be the most realistic size where the result is measured in microseconds.

However, in the "deep" benchmarks we see dramatic improvements. The previous version of Taffy suffered from exponential blowup in the case of deeply nested hierachies. This has resulted in somewhat silly improvements like the 10,000 node (14-level) hierachy where Taffy 0.2 is a full 1 million times faster than Taffy 0.1. We've also included results with larger numbers of nodes (although you're unlikely to need that many) to demonstrate that this scalability continues up to even deeper levels of nesting.

Benchmarks vs. Yoga

Yoga benchmarks run via it's node.js bindings (the yoga-layout-prebuilt npm package), they were run a few times manually and it was verified that variance in the numbers of each run was minimal. It should be noted that this is using an old version of Yoga.

BenchmarkYogaTaffy 0.2
yoga/10 nodes (1-level hierarchy)45.1670 µs33.297 ns
yoga/100 nodes (2-level hierarchy)134.1250 µs336.53 ns
yoga/1_000 nodes (3-level hierarchy)1.2221 ms3.8928 µs
yoga/10_000 nodes (4-level hierarchy)13.8672 ms36.162 µs
yoga/100_000 nodes (5-level hierarchy)141.5307 ms1.6404 ms

(note that the table above contains multiple different units (milliseconds vs. microseconds vs. nanoseconds))

While we're trying not to get too excited (there could easily be an issue with our benchmarking methodology which make this an unfair comparison), we are pleased to see that we seem to be anywhere between 100x and 1000x times faster depending on the node count!

Breaking API changes

Node creation changes

Error handling/representation improvements

Some uses of Option<f32> replaced with a new AvailableSpace enum

A new enum Taffy::layout::AvailableSpace has been added.

The definition looks like this:

/// The amount of space available to a node in a given axis
pub enum AvailableSpace {
    /// The amount of space available is the specified number of pixels
    Definite(f32),
    /// The amount of space available is indefinite and the node should be laid out under a min-content constraint
    MinContent,
    /// The amount of space available is indefinite and the node should be laid out under a max-content constraint
    MaxContent,
}

This enum is now used instead of Option<f32> when calling Taffy.compute_layout (if you previously passing Size::NONE to compute_layout, then you will need to change this to Size::MAX_CONTENT).

And a different instance of it is passed as a new second parameter to MeasureFunc. MeasureFuncs may choose to use this parameter in their computation or ignore it as they see fit. The canonical example of when it makes sense to use it is when laying out text. If MinContent has been passed in the axis in which the text is flowing (i.e. the horizontal axis for left-to-right text), then you should line-break at every possible opportunity (e.g. all word boundaries), whereas if MaxContent has been passed then you shouldn't line break at all..

Builder methods are now const where possible

Removals

Fixes

0.1.0

0.1.0 Changed

0.1.0 Fixed

0.1.0 Removed

stretch2 0.4.3

This is the final release of stretch: migrate to the crate named taffy for future fixes and features!

These notes describe the differences between this release and stretch 0.3.2, the abandoned crate from which this library was forked.

Changed

Fixed