-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Import yoga tests #320
Import yoga tests #320
Conversation
7866d71
to
4b879d0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should throw together a quick README.md for the impoort-yoga-tests crate, describing its purpose and instructions for getting it working.
The convention where tests that begin with an x are ignored should also be documented: at a glance, I can't figure out where this is being done.
.collect(); | ||
|
||
for fixture in yoga_fixtures { | ||
if !taffy_fixture_names.contains(&fixture.name) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if the fixtures are updated but not renamed? Won't they get out of sync with this strategy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't they get out of sync with this strategy?
Yes. They likely already are. This is at least a quick way to get us tests we were entirely missing though. I guess we'll need to actually parse the HTML/CSS to sync updates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. What's the cost to rebuilding them completely every time?
(We should document this conversation in a comment if we decide to keep this behavior).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the cost to rebuilding them completely every time?
As in treating Yoga's version as the source of truth and overwriting any changes we might have made? There's no technical blocker on that. I think the main problem with that would be that it would make it hard for us to maintain any changes that we actually need. As an example: I removed whitespace from a couple of tests when I added support for sizing text nodes. It would be nice if there was a single source of truth though, and I suppose that could be managed by just being selective with when we sync and which changes we commit when we sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds reasonable: I'm fine with whatever you pick here.
4b879d0
to
2e8f922
Compare
test_fixtures/android_news_feed.html
Outdated
<div layout="width: 1080; height: 444; top: 0; left: 0;" style="flex-shrink: 0; " > | ||
<div layout="width: 1080; height: 444; top: 0; left: 0;" style="align-content: stretch; " > | ||
<div layout="width: 1080; height: 226; top: 0; left: 0;" style="align-content: stretch; " > | ||
<div layout="width: 1044; height: 202; top: 24; left: 36;" style="flex-direction: row; align-items: flex-start; align-content: stretch; margin-top: 24px; margin-start: 36px; " > |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "margin-start" here is not a valid CSS property, and Yoga's test generator did some funky things with it. But it's effectively the same as "margin-inline-start" for any case that isn't a vertical writing direction (which I don't think Yoga or Taffy support).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should be cleaned up soon in the Yoga source, there is a PR I had cleaned up some of these in the newer PR this imports from, but I discovered I needed to update the test generator to properly translate it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that's useful to know. Taffy actually doesn't support margin-inline-start
either (it has margin-left
). I'm guessing Yoga also doesn't support this and the test generator just converts it to left/right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a test run overwriting all of Taffy's test with Yoga's (where there as an equivalent) to see what the diff would be like, and there were quite a few differences. In addition to the start/end vs. left/right thing, the main one's were due to Yoga defaulting to flex-direciton: column
while Taffy defaults to flex-direction: row
. Many of a Taffy's tests had an explicit flex-direction added to account for this. And some of them had width/height swapped to account for it in a different way. I suspect we'll need to add explicit flex-direction
everywhere if we want to unify the test suites.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that's useful to know. Taffy actually doesn't support
margin-inline-start
either (it hasmargin-left
). I'm guessing Yoga also doesn't support this and the test generator just converts it to left/right?
Yoga does have support for flow-relative margin, padding, etc. The API at the Yoga level looks like YGNodeStyleSetMargin
, accepting a YGEdge
, which can be (in order of precedence) a cardinal direction (e.g. YGEdgeLeft
), a flow-relative direction (e.g. YGEdgeStart
), an axis (e.g. YGEdgeHorizontal
), or YGEdgeAll
.
React Native historically historically mapped YGEdgeStart
to marginStart
, etc, but we recently added marginInlineStart
, marginBlockStart
, etc to be conformant with browsers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't you need a flow-relative direciton AND an axis to fully specify an edge? (YGEdgeStart by itself is ambiguous. You'd need YGEdgeInlineStart, no?).
Start/End only ever refer to the horizontal axis, and just picks Left/Right based on RTL. But yeah, the style has distinct inputs for padding, margin, etc per YGEdge, and a specific precedence when multiple inputs are present which may overlap the same physical edge. It would be reevaluated if laid out as RTL. Yoga also weirdly treats both YGEdgeLeft and YGEdgeStart as effecting the right side of a box with flexDirection: "row-reverse" which is inconsistent with browsers.
Yoga's precedence logic based on specificity is one difference from browsers, where CSS properties are ordered and if there is overlap, the last assignment wins (e.g. "margin" takes precedence over "marginLeft" if it comes after).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps it would make sense to make this the default specifically for the test suite? (updating the test fixtures accordingly so that the actual tests don't change).
I think updating that would probably make sense. If you're having to add column direction, was Yoga's test generator doing that in the outer HTML too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're having to add column direction, was Yoga's test generator doing that in the outer HTML too?
I haven't actually checked that yet. I've gone through and added all the flex-direction: column
s. But actually, all of those tests were already passing. So it's possible that the missing flex-directions weren't actually making a meaningful difference to the tests. I'd still be more comfortable if the tests are unambiguously specified though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Start/End only ever refer to the horizontal axis, and just picks Left/Right based on RTL.
Ah, I guess that makes sense given that IIRC Yoga supports RTL but not vertical writing modes. The variants are confusingly named though! I'm guessing that might the sort of thing it might be more possible to make breaking changes to (as it will turn into a compile error)?
Yoga also weirdly treats both YGEdgeLeft and YGEdgeStart as effecting the right side of a box with flexDirection: "row-reverse" which is inconsistent with browsers.
That is weird. As documented in #307, it does work that way for the flex-start
alignment value, but there is also a separate start
which isn't affected by the the flex-direction
, and it definitely shouldn't do that for left
!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're having to add column direction, was Yoga's test generator doing that in the outer HTML too?
@NickGerleman I looked into this, and the stylesheet that Yoga uses when generating tests applies this default. See https://github.com/facebook/yoga/blob/main/gentest/test-template.html#L28
9507561
to
bac71f1
Compare
89c8647
to
99b56ca
Compare
f5421b1
to
33b6737
Compare
33b6737
to
7f7b0c6
Compare
@alice-i-cecile Requested changes made. Filtering out tests beginning with |
cb6733d
to
8a139da
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work as usual! The increased test coverage is surely going to be valuable in guiding rework and new features.
Objective
Fixes #285.
Changes made
Notes