Skip to content
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

Initial (very rudimentary) flexbox implementation. #7154

Closed
wants to merge 5 commits into from

Conversation

@zentner-kyle
Copy link

zentner-kyle commented Aug 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

Review on Reviewable

@highfive
Copy link

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
Copy link

highfive commented Aug 11, 2015

warning Warning warning

  • These commits modify unsafe code. Please review it carefully!
  • These commits modify layout code, but no reftests are modified. Please consider adding a reftest!
@pcwalton
Copy link
Contributor

pcwalton commented Aug 11, 2015

Wow! I'll take a look at this tomorrow.

@zentner-kyle zentner-kyle force-pushed the zentner-kyle:flexbox branch 2 times, most recently from 9c4783b to 47a6a0e Aug 11, 2015
@zentner-kyle
Copy link
Author

zentner-kyle commented Aug 13, 2015

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?

@pcwalton
Copy link
Contributor

pcwalton commented Aug 13, 2015

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.

Copy link
@pcwalton

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.

Copy link
@pcwalton

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.

Copy link
@pcwalton

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.

Copy link
@pcwalton

pcwalton Aug 13, 2015

Contributor

Does TableRowFlow actually have any float related logic?

This comment has been minimized.

Copy link
@zentner-kyle

zentner-kyle Aug 15, 2015

Author

Surprisingly, yes. However, it's relatively minimal (mostly a call to kid.place_float_if_applicable()).

@pcwalton
Copy link
Contributor

pcwalton commented Aug 13, 2015

Layout looks good modulo a few nits. I'm going to bump the properties.rs.mako review over to @SimonSapin

r? @SimonSapin

@SimonSapin
Copy link
Member

SimonSapin commented Aug 13, 2015

New properties and values should be marked "experimental". That should be easy for longhand properties (adding experimental=True at the right place), but for longhands (flex: …) or values (display: flex) you may need to add some Mako template support, or just call ::util::opts::experimental_enabled() directly.

@jdm
Copy link
Member

jdm commented Aug 13, 2015

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.

@metajack
Copy link
Contributor

metajack commented Aug 13, 2015

This came up in the meeting a few weeks ago. Either @SimonSapin or @mbrubeck had some changes they planned to put behind -e until they were more fully baked.

@SimonSapin
Copy link
Member

SimonSapin commented Aug 13, 2015

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, unimplemented!(), …) or give arbitrarily wrong results.

(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.

Copy link
@SimonSapin

SimonSapin Aug 14, 2015

Member

Does this warn, when type is i32? (Trivial cast, or something like that.)

This comment has been minimized.

Copy link
@zentner-kyle

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.

Copy link
@SimonSapin
// 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.

Copy link
@SimonSapin

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.

Copy link
@zentner-kyle

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.

Copy link
@SimonSapin

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.

Copy link
@SimonSapin

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.

@SimonSapin
Copy link
Member

SimonSapin commented Aug 14, 2015

(Done reviewing properties.mako.rs up to 47a6a0e.)

@bors-servo
Copy link
Contributor

bors-servo commented Aug 17, 2015

The latest upstream changes (presumably #7222) made this pull request unmergeable. Please resolve the merge conflicts.

@paulrouget
Copy link
Contributor

paulrouget commented Aug 21, 2015

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: attempted to divide by zero)).

Hope this will help for future work on flexbox model.

Kyle Zentner added 2 commits Jul 18, 2015
This commit doesn't implement any flexbox behavior at all.
It just constructs FlexFlow's, which act just like the BlockFlow from
which they "inherit."
Kyle Zentner added 3 commits Aug 11, 2015
These tests (flex_row_direction.html and flex_column_direction.html) are
correct, but only test the small amount of current flexbox
functionality.
@zentner-kyle zentner-kyle force-pushed the zentner-kyle:flexbox branch from 47a6a0e to 4141ea9 Aug 21, 2015
bors-servo pushed a commit that referenced this pull request Aug 21, 2015
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 -->
bors-servo pushed a commit that referenced this pull request Aug 21, 2015
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 -->
bors-servo pushed a commit that referenced this pull request Aug 21, 2015
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 -->
@bors-servo
Copy link
Contributor

bors-servo commented Aug 22, 2015

The latest upstream changes (presumably #7312) made this pull request unmergeable. Please resolve the merge conflicts.

@zentner-kyle
Copy link
Author

zentner-kyle commented Aug 22, 2015

This is effectively merged due to #7312, so I'm closing this.

Thanks Simon and Patrick!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

8 participants
You can’t perform that action at this time.