Roadmap

[nicoburns]

I thought it might be useful to track possible future feature work in a more structured way (grouped into categories).

See also: the Taffy Project Board

0.11

• Support Display::Contents #533
• Support position: static (absolute position relative a non-parent ancestor) #212
• content_size for internal nodes incorrectly includes the node's left/top border. #871

Future

CSS layout algorithms

• Flexbox
• Support CSS Block layout (Display::Block) #405
• Float Layout #437
• Support CSS Table layout (Display::Table) #467
• Support CSS Grid #204
• Support CSS Grid Level 2 (Subgrid) #468
• Support CSS Grid Level 3 (Display:GridLanes aka Masonry layout) #910
• Support Display::Contents #533
• Anchor Positioning Layout #703

Other CSS layout features

• Support box-sizing: content-box #289
• Negative margins in flexbox result in incorrect layout #706
• CSS Grid: Support named grid lines and grid areas #750
• Support direction property (right-to-left layout) #213
• Intrinsic sizing keywords (min/max/fit-content) for width/height #751
• Implement the "safe" alignment variants #550
• Support align-content in Block layout #709
• Support Calc val #225
• Support writing-mode property (vertical inline axis) #752
• Support Overflow::Auto #560
• Better baseline alignment support (particularly measure function support for baseline alignment)

API Enhancements

• Add examples of text layouting #216
• "Traitify" the Style struct #568
• Expose computed grid-template and grid-placement values #714
• Provide a builder pattern interface to the construction layout tree #275

Non-CSS layout features

• Support for stretch for width/height and possibly margin/inset
• Support Morphorm/Subform layout #308
• Sciter's "flex flow" layout (https://sciter.com/docs/flex-flow/flex-layout.htm)
• AutoLayout / Cassowary
• Hstack/Vstack/Zstack

FFI / Bindings for other languages

• C bindings #399 (widely useful)
• Wasm bindings #241 (Web/Node.js/Deno) Useful for examples/playground. Also enables Node.js where Taffy may be useful for TUIs. Deno even has GUI bindings)
• Swift/Objective-C (for iOS/macOS)
• Kotlin/Java (for Android)
• C++ (widely useful, and we could expose our full LayoutTree API to C++ if we wanted to. Could enable cool use cases like close integration with layout code written in C++)
• C# (Unity uses Yoga for layout. Could also be used in Xamarin)

[shirakaba]

Just to note that with bindings to C++ (or technically Objective-C, though would limit to iOS/macOS), it would become possible to create bindings for JSI (JavaScript Interface; a library originally designed by Meta and Microsoft for React Native).

JSI is a common interface for performing simple operations that make use of native data (e.g. calling functions, exposing HostObjects) on any JS engine. The idea is that instead of calling (for example) V8 APIs directly, you'd call the engine-agnostic JSI APIs and a corresponding V8 call would be made by the engine-specific implementation of the JSI.

As engine-specific implementations are already available for V8, JSC, and Hermes, it would allow exposing Taffy to each of them with reduced maintenance burden. The advantage over WASM is that it would work on JS engines not supporting WASM (even if only due to JIT being disabled, e.g. the App Store).

It's something I'd have an interest in helping with once C++ bindings were made! Spare time willing, of course.

[inobelar]

I think, that pure C public interface (for FFI) is a key for making bindings for various other languages. It is common solution/strategy implemented in many projects, even in Yoga (written internally in C++, with C public interface, which used in Java/C#/JavaScript(WASM)/ObjC bindings)

[nicoburns]

I think, that pure C public interface (for FFI) is a key for making bindings for various other languages. It is common solution/strategy implemented in many projects, even in Yoga (written internally in C++, with C public interface, which used in Java/C#/JavaScript(WASM)/ObjC bindings)

Agreed that a C interface ought to be priority as it can serve as the foundation for the others (and more easily allow 3rd parties to bind to Taffy in lieu of 1st party bindings.)

@shirakaba Presumably C bindings would work for you?

[herefishyfish]

Could the JSI bindings used by https://github.com/triniwiz/nativescript-mason be reused @shirakaba?

[triniwiz]

@shirakaba in the mason lib the iOS side is pretty much the c bindings you're looking for, wish I had a little more time to port it.

[nicoburns]

@triniwiz How come you're using cxx and jsi for Android and cbindgen and swift for iOS? They seem like completely different approaches...

[triniwiz]

It's due to how the JSI is setup in NativeScript for iOS but I'm thinking I could move things around to give me an ease up

[shirakaba]

Could the JSI bindings used by https://github.com/triniwiz/nativescript-mason be reused @shirakaba?

Oh, I hadn't realised that was @triniwiz's approach! Yeah, something exactly like that 😂🙇‍♂️

[shirakaba]

@shirakaba Presumably C bindings would work for you?

Presumably! Although I defer to Osei at this point as he seems to have got it bridged all the way to iOS/Android already.