Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upInitial (very rudimentary) flexbox implementation. #7154
Conversation
highfive
commented
Aug 11, 2015
|
Thanks for the pull request, and welcome! The Servo team is excited to review your changes, and you should hear from @metajack (or someone else) soon. |
highfive
commented
Aug 11, 2015
|
Wow! I'll take a look at this tomorrow. |
9c4783b
to
47a6a0e
|
Thanks for the feedback! I think I've addressed the above comments? There weren't any on the later changes. Yes, flex-done.rs was accidentally included. Is rebasing mid-review like this an acceptable workflow? |
|
Yup, works for me. I'll finish the review ASAP. |
| fn build_display_list_for_flex(&mut self, | ||
| display_list: Box<DisplayList>, | ||
| layout_context: &LayoutContext) { | ||
| // Draw the rest of the block. |
This comment has been minimized.
This comment has been minimized.
pcwalton
Aug 13, 2015
Contributor
There may not be any need for this function—just call build_display_list_for_block directly in FlexFlow::build_display_list. Unless there will actually need to be special painting behavior for flexbox in the future?
|
|
||
| let main_mode = match flex_style(&fragment).flex_direction { | ||
| flex_direction::T::row_reverse => Mode::Inline, | ||
| flex_direction::T::row => Mode::Inline, |
This comment has been minimized.
This comment has been minimized.
pcwalton
Aug 13, 2015
Contributor
nit: you can use or-patterns (flex_direction::T::row_reverse | flex_direction::T::row => ...) to avoid a little bit of code duplication here
| main_mode: main_mode | ||
| }; | ||
|
|
||
| this |
This comment has been minimized.
This comment has been minimized.
pcwalton
Aug 13, 2015
Contributor
No need for the this temporary; just write BlockFlow { ... } as the last expression.
|
|
||
| // TODO(zentner): This function should actually flex elements! | ||
| // Currently, this is the core of TableRowFlow::assign_block_size() with | ||
| // float related logic stripped out. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
zentner-kyle
Aug 15, 2015
Author
Surprisingly, yes. However, it's relatively minimal (mostly a call to kid.place_float_if_applicable()).
|
Layout looks good modulo a few nits. I'm going to bump the r? @SimonSapin |
|
New properties and values should be marked "experimental". That should be easy for longhand properties (adding |
|
I thought we only cared about marking things experimental that are not actually standardized and therefore shouldn't be exposed to regular web content, not merely incomplete things. |
|
This came up in the meeting a few weeks ago. Either @SimonSapin or @mbrubeck had some changes they planned to put behind |
|
Maybe we can rename "experimental" or have more than one flag, but the idea is that the barrier to entry for pref’ed-off things can be lower than otherwise. You can land piece-by-piece unfinished things that can panic (assertion errors, (I’m not saying at all that this PR is bad! I haven’t looked in details yet. But it doesn’t need to get everything right the first time.) |
| if !(${condition}) { | ||
| return Err(()) | ||
| } | ||
| Ok(SpecifiedValue::Specified(value as ${type})) |
This comment has been minimized.
This comment has been minimized.
SimonSapin
Aug 14, 2015
Member
Does this warn, when type is i32? (Trivial cast, or something like that.)
This comment has been minimized.
This comment has been minimized.
zentner-kyle
Aug 15, 2015
Author
That would make sense, but I don't think redundant / trivial casts ever do warn. At least, there aren't any warnings when I build this file using ./mach build, and http://is.gd/9aTZQ1 doesn't show any warnings when compiling.
This comment has been minimized.
This comment has been minimized.
| // Flex item properties | ||
| ${integer_type_or_auto("order", "i32", "Specified(0)")} | ||
| ${integer_type_or_auto("flex-grow", "u32", "Specified(0)", "value >= 0")} | ||
| ${integer_type_or_auto("flex-shrink", "u32", "Specified(1)", "value >= 0")} |
This comment has been minimized.
This comment has been minimized.
SimonSapin
Aug 14, 2015
Member
Does the layout code support all of these? It’s better not to parse properties or values for which we don’t have any support. (And adding @supports rules will make this more important.)
This comment has been minimized.
This comment has been minimized.
zentner-kyle
Aug 15, 2015
Author
Right now, almost none of these are supported (with the exception of flex-direction). However, I do intend to add support for most of them when I can. Should I remove them, or somehow feature gate them (besides using experimental=True)?
Also, I just realized that align-self is not in the right location in this list, it should be with the other flex item properties.
This comment has been minimized.
This comment has been minimized.
SimonSapin
Aug 15, 2015
Member
Yes, please remove the parsing of unsupported properties. Especially since they are one-line macro calls, they’re easy to add back when support is added.
| let flex_basis = if flex_basis.is_ok() { | ||
| flex_basis | ||
| } else { | ||
| flex_basis::parse(context, input) |
This comment has been minimized.
This comment has been minimized.
SimonSapin
Aug 14, 2015
Member
Each of these four foo::parse() calls needs to be wrapped in input.try(|input| …) to avoid silently ignoring part of the input when they return Err.
|
(Done reviewing |
|
|
|
Very excited to see this initial PR. For the record, here is a basic HTML template showing how we use flexbox model in browser.html: #7304 (works well in Firefox 43, appears to crash with this PR (panic: Hope this will help for future work on flexbox model. |
Initial (very rudimentary) flexbox implementation. This is #7154 with two additional commits (that I did rather than ask @zentner-kyle to do it because it was a bit tricky.) r? @pcwalton for the last two commit r=me+pcwalton in #7154 for earlier commits. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7312) <!-- Reviewable:end -->
Initial (very rudimentary) flexbox implementation. This is #7154 with two additional commits (that I did rather than ask @zentner-kyle to do it because it was a bit tricky.) r? @pcwalton for the last two commit r=me+pcwalton in #7154 for earlier commits. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7312) <!-- Reviewable:end -->
Initial (very rudimentary) flexbox implementation. This is #7154 with two additional commits (that I did rather than ask @zentner-kyle to do it because it was a bit tricky.) r? @pcwalton for the last two commit r=me+pcwalton in #7154 for earlier commits. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7312) <!-- Reviewable:end -->
|
|
|
This is effectively merged due to #7312, so I'm closing this. Thanks Simon and Patrick! |
zentner-kyle commentedAug 11, 2015
This "flexbox implementation" is essentially a copy-and-paste / meld of code from various Flow types.
All of the flexbox related CSS properties should be parsed correctly. All of the children of the flex container (flex items) are (correctly) made into unfloated blocks. If the flexbox is a row or reverse-row, the total inline size is evenly distributed among the children, and they are laid out horizontally. Otherwise, the flexbox acts like a block with unfloated children.
I'd like to improve upon this code in a later pull request.
Closes #6636. I think?
r? @pcwalton