Flex shorthand in UseWebDefaults should set basis to 0 instead of auto #1523

Open
opened 2023-12-16 00:16:20 -08:00 by NickGerleman · 3 comments
NickGerleman commented 2023-12-16 00:16:20 -08:00 (Migrated from github.com)

Since UseWebDefaults was added with 62f47190fb, 62f47190fb/yoga/Yoga.c (L493)

https://www.w3.org/TR/css-flexbox-1/#flex-common says that zeroing is the right interpretation, so UseWebDefaults does the wrong thing seemingly.

Since UseWebDefaults was added with https://github.com/facebook/yoga/commit/62f47190fb2c13d47b13efacfc237f30ab312b51, https://github.com/facebook/yoga/blob/62f47190fb2c13d47b13efacfc237f30ab312b51/yoga/Yoga.c#L493 https://www.w3.org/TR/css-flexbox-1/#flex-common says that zeroing is the right interpretation, so UseWebDefaults does the wrong thing seemingly.
NickGerleman commented 2023-12-16 00:18:41 -08:00 (Migrated from github.com)

UseWebDefaults is going to be in a weird place in general with static and block in the mix.

UseWebDefaults is going to be in a weird place in general with static and block in the mix.
nicoburns commented 2023-12-18 04:27:33 -08:00 (Migrated from github.com)

What is the value in Yoga supporting the shorthand syntax? Why not just stick to the longhand syntax and let the layers above Yoga lower the shorthand into the longhand?

What is the value in Yoga supporting the shorthand syntax? Why not just stick to the longhand syntax and let the layers above Yoga lower the shorthand into the longhand?
NickGerleman commented 2023-12-18 19:22:28 -08:00 (Migrated from github.com)

It’s a good question.

Yogas api has historically supported length shorthands through different “edges”, e.g. all vs horizontal vs left. It will then resolve based on specificity.

That’s convenient in not letting the underlying framework need to manage extra state, and the resolved value can depend on things like ltr vs rtl, but if means Yoga must store the information (probably more efficiently than the host would too).

Beyond what we’d do with a clean slate though, I’ve been aiming to avoid non-trivial breaks to the public api (though I introduced plenty of more trivial ones for the next release).

It’s a good question. Yogas api has historically supported length shorthands through different “edges”, e.g. all vs horizontal vs left. It will then resolve based on specificity. That’s convenient in not letting the underlying framework need to manage extra state, and the resolved value can depend on things like ltr vs rtl, but if means Yoga must store the information (probably more efficiently than the host would too). Beyond what we’d do with a clean slate though, I’ve been aiming to avoid non-trivial breaks to the public api (though I introduced plenty of more trivial ones for the next release).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DaddyFrosty/yoga#1523
No description provided.