Talin

@cart 's latest BSN design doc (#14437) diverges from what has been proposed here. I have no particular preference either way, but I do want to highlight the differences: *...

I agree with @nicoburns approach: separate "layout props for child" from "layout props for container". But I'd add one more thing: there should be *four* types of containers: * FlexContainer...

OK, then, how about: * Containers * `FlexLayout` * `GridLayout` * `BlockLayout` * `TextFlowLayout` (assuming you're on board with this idea) * Children * `FlexSize` (containing `flex_grow`, `flex_shrink`, and `flex_basis`.)...

Well, I was just trying to impose some kind of categorization without creating too much duplication. I don't have strong opinions here. In any case, we should either come up...

I'm confused, I thought what I was proposing was compatible with that suggestion: > separate "container" and "child" variants for each layout mode That's what my `FlexLayout`, `GridLayout` was supposed...

I want to point out a trade-off here: many of the use cases for custom attributes can also be accomplished by wrapping the field data in a newtype struct and...

> I can see the attribute accepting a `Attributable` trait or something which takes an instance of the type and returns the computed attribute. It may also be that the...

The range (min/max) is by far the most common attribute in my previous projects, and it's also common in the sense that it's independent of how the field is being...

So is this not going to be in the 0.14 milestone? I could really use this.

I ran into this just now. ``` const arg1 = [[[[0,43.5],[1.7000000000000002,43.5],[1.7000000000000002,44],[0,44],[0,43.5]]]] const arg2 = [[[2.3000000000000003,43],[0.7000000000000001,43],[0.6999999999999998,44],[2.3,44], 2.3000000000000003,43]]] ```