Summary:
For some reason this Universal.csproj wasn't pulled from rozele PR.. i added the missing files.
Added badges for build and nuget for more exposure.
Ignore a failing unit test on MacOS for a green build.
Closes https://github.com/facebook/yoga/pull/464
Reviewed By: emilsjolander
Differential Revision: D4670392
Pulled By: splhack
fbshipit-source-id: 9ea3150b92039cab87ce8696db983fdf373c5388
Summary: I accidentally used pngs for the bintray badges. This renders ugly sometimes. This corrects that.
Reviewed By: emilsjolander
Differential Revision: D4666641
fbshipit-source-id: df53f08a77be3067804d7671d673146f208a24fd
Summary: This adds bintray badges to the readme, and creates a readme for the android code.
Reviewed By: emilsjolander
Differential Revision: D4666314
fbshipit-source-id: a2549374f3e9c39c260160d1e32fb37801ff4208
Summary: Adds the Travis build badge for the android target to the README.md
Reviewed By: emilsjolander
Differential Revision: D4571693
fbshipit-source-id: a5110dac7d86989cc4a14b858c63d59332072869
Summary:
Hey there, congrats on the launch - we use React Native at Artsy, and I've been wondering about what Yoga + Jest Snapshots for RN looks like but haven't had the time to explore that yet.
With https://github.com/CocoaPods/cocoadocs.org/pull/501 I added the ability to customize the location of the README for the front-page of the CocoaPods site. That is being deployed as I speak, so it should be available the next time you decide to ship a version of Yoga.
I also fixed the capitalisation of CocoaPods, and removed a redundant CocoaPods badge on your initial README.
Closes https://github.com/facebook/yoga/pull/366
Reviewed By: emilsjolander
Differential Revision: D4488011
Pulled By: dshahidehpour
fbshipit-source-id: 6c0c4efc23a69e1fcb936214b159b49217218b49
Summary:
Benchmarks are not located in folder benchmark. So rename folder
and buck target from 'benchmarks' to 'benchmark'.
Closes https://github.com/facebook/yoga/pull/339
Reviewed By: gkassabli
Differential Revision: D4420355
Pulled By: emilsjolander
fbshipit-source-id: 7a1bc6ece7f4b64c7cac506357e265c1b4790a4f
Summary: Add notice in readme to prepare open source for large renaming diffs.
Reviewed By: splhack
Differential Revision: D4240761
fbshipit-source-id: 4c8070a06c3ac009b67eb7bef5de11ce3ab3e4d8
Summary:
When trying to integrate this into an Xcode project that already included CSSLayout.[c|h], we were getting a linker error.
Upon digging in, I found out that Xcode was becoming confused because the imports of the uikit library and the c library are both `#import <CSSLayout/CSSLayout.h>`. So, it needed a new name.
Reviewed By: emilsjolander
Differential Revision: D4162621
fbshipit-source-id: b5f7624eb29f1b9eaebbed5104ec9ea8a12ad2e5
Summary:
- Update README for gentest
- Fix gentest.rb for the right working dir
Reviewed By: emilsjolander
Differential Revision: D4065863
fbshipit-source-id: 5c6bd9d18779c05c1de24c06a83b148889facb6b
Summary: Update readme adding UIKit and fixing things that have changed
Differential Revision: D4015068
fbshipit-source-id: 213a60bea6f16ca01a4e613c8e3563f7c354ca8e
Summary:
This PR adds the C# version of the `CSSNode` API calls where it currently has only Java and C versions.
Closes https://github.com/facebook/css-layout/pull/225
Reviewed By: lucasr
Differential Revision: D3936431
Pulled By: emilsjolander
fbshipit-source-id: 689cb359c204c6c52e04e031c66615fb04c001af
Summary: Modify test generation script to be able to generate multiple test cases
Reviewed By: lucasr
Differential Revision: D3714577
fbshipit-source-id: d2bc2155712f946c5a24231a9532d2acc097524c
Summary: Java instructions were missing from the readme. Add a quick note about how to run tests in java.
Reviewed By: lucasr
Differential Revision: D3648981
fbshipit-source-id: d9009a60bb1bb0837722f914981ef4e31f0adb68
Summary: Update readme with info about building and github markdown syntax
Differential Revision: D3613284
fbshipit-source-id: 1f57009ccf02a48fe100f675ce08503e15cb6c22
The primary goals of this change are:
- Better conformance to the W3C flexbox standard (https://www.w3.org/TR/css-flexbox-1/)
and a clear articulation of the areas where it deviates from the spec.
- Support for flex-shrink.
- Conformance with layout effects of "overflow: hidden".
Specifically, here are the limitations of this implementation as compared to the W3C
flexbox standard (this is also documented in Layout.js):
- Display property is always assumed to be 'flex' except for Text nodes, which
are assumed to be 'inline-flex'.
- The 'zIndex' property (or any form of z ordering) is not supported. Nodes are
stacked in document order.
- The 'order' property is not supported. The order of flex items is always defined
by document order.
- The 'visibility' property is always assumed to be 'visible'. Values of 'collapse'
and 'hidden' are not supported.
- The 'wrap' property supports only 'nowrap' (which is the default) or 'wrap'. The
rarely-used 'wrap-reverse' is not supported.
- Rather than allowing arbitrary combinations of flexGrow, flexShrink and
flexBasis, this algorithm supports only the three most common combinations:
- flex: 0 is equiavlent to flex: 0 0 auto
- flex: n (where n is a positive value) is equivalent to flex: n 0 0
- flex: -1 (or any negative value) is equivalent to flex: 0 1 auto
- Margins cannot be specified as 'auto'. They must be specified in terms of pixel
values, and the default value is 0.
- The 'baseline' value is not supported for alignItems and alignSelf properties.
- Values of width, maxWidth, minWidth, height, maxHeight and minHeight must be
specified as pixel values, not as percentages.
- There is no support for calculation of dimensions based on intrinsic aspect ratios
(e.g. images).
- There is no support for forced breaks.
- It does not support vertical inline directions (top-to-bottom or bottom-to-top text).
And here is how the implementation deviates from the standard (this is also documented in
Layout.js):
- Section 4.5 of the spec indicates that all flex items have a default minimum
main size. For text blocks, for example, this is the width of the widest word.
Calculating the minimum width is expensive, so we forego it and assume a default
minimum main size of 0.
- Min/Max sizes in the main axis are not honored when resolving flexible lengths.
- The spec indicates that the default value for 'flexDirection' is 'row', but
the algorithm below assumes a default of 'column'.
also, on line 134, I could be wrong, but be wary of this sentence: "No C implementation of this function is provided in provided..." Perhaps this is a mistake.
thanks for all the awesome code!
