- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 8 Jun 2014 19:30:19 -0400
- To: www-style@w3.org
Flexbox
-------
- RESOLVED: Close issue on whether 'flex-basis: auto' should resolve
at computed value time. Clarify that the flex-basis auto
flips to width/height at used value time.
- The flex resolution algorithm has been redrafted since the LCWD to
be closer to the structure of the earlier CR draft while preserving
the changes to handle flex values continuously approaching zero.
(Various technical errors reported in the LCWD have also been fixed.)
The editors are requesting review from those interested.
- Some concerns about handling the static positions of absolutely-positioned
child of were discussed:
- The group basically agreed to switch the flexbox/grid static position
model to match a 0x0 static position placeholder box, but then also
define that, depending on the alignment properties, the abspos child
aligns relative to its static position differently.
- This should give the same layout results as what's in the spec
right now.
- A final resolution was held off until a decision could be made if the
start point should be a box or a point.
===== FULL MINUTES BELOW ======
Present:
Bruno Abinader
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Adenilson Cavalcanti
Dave Cramer
Elika Etemad
Daniel Glazman
Dongwoo Joshua Im
Koji Ishii
Dael Jackson
Philippe Le Hegaret
Chris Lilley
Peter Linss
Shinyu Murakami
Edward O'Connor
Simon Pieters
Liam Quin (phone only)
Andrey Rybka
Simon Sapin (phone only)
Dirk Schulze (phone only)
Alan Stearns
Shane Stevens
Jet Villegas
Steve Zilles (phone only)
5 observers in the back
Regrets:
Anton Prowse
Lea Verou
Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: Dael
Agenda
------
This discussion to set the agenda held no technical details.
Please see the IRC log for full minutes:
http://krijnhoetmer.nl/irc-logs/css/20140519#l-45
Flexbox
-------
glazou: Let's start with flexbox
TabAtkins: Okay.
<fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325
TabAtkins: So fantasai do we have anything except auto?
fantasai: We got a few comments this week, but they're editorial.
fantasai: We can't do CR right now, but we do have the issue of
the computation of auto.
TabAtkins: Let's do that one quick.
<fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325#issue-13
<TabAtkins> http://dev.w3.org/csswg/css-flexbox/#flex-basis-property
TabAtkins: 'flex-basis: auto' is confusing right now.
TabAtkins: If auto is the specified value of flex-basis it means you
use the size property (width/height) in that dimension.
Question is when it turns into that value because it needs
to do that to compute.
TabAtkins: Right now it's not very clear.
TabAtkins: I proposed we should change so it transforms at computed
value time.
TabAtkins: So a 'flex-basis: auto' would become the appropriate
width/height value, but the confusing bit is that that
could also be 'auto'.
fantasai: We discussed this two years ago.
fantasai: We concluded that because auto means two things, if flex-basis
is inherited we get odd behavior.
fantasai: If you inherit the 'auto' keyword from your parent,
you don't necessarily get 'auto' behavior -- you get whatever
is specified for your width/height property.
fantasai: But 'flex-basis' is a non-inherited property. Practically no one
except QA is going to inherit 'flex-basis'.
fantasai: So in theory confusing, but the lack of resolution for
getComputedStyle is probably more confusing.
dbaron: Does resolution of inheritance happen prior to the computation phase?
TabAtkins: Yes. Similar to cascade.
dbaron: I've always thought that was wrong and it's not how we implemented.
fantasai: So do we need to fix cascade?
dbaron: I think that while there are two ways to explain it, it doesn't
matter as long as any computed value computed to itself.
dbaron: Now we're making that not true. So now location in cascade
matters, which means implementations might not match since they
assumed equivalence.
TabAtkins: So you're saying you processed at value computation.
dbaron: Yes. I don't know if that's what other implementors do and
I don't know how to test for it in a black box.
TabAtkins: Shane says he thinks they have the same implementation.
TabAtkins: We can change cascade.
dbaron: Testing is worthwhile.
TabAtkins: But you say it's not detectable except with flex.
dbaron: Implementors might have to change their cascade to deal
with it.
fantasai: Before we have a used value of flex-basis.
TabAtkins: It wasn't stated, but implied.
TabAtkins: We want to do it at computed time so it's right.
TabAtkins: We can still decide this independently.
dbaron: It's odd for other reasons.
TabAtkins: You can't feed GCS into style immediately
TabAtkins: But we can't change that now. I made that mistake years
ago.
fantasai: Or we leave things as is.
TabAtkins: Once we get usedStyle...
TabAtkins: So are we okay with that weirdness of setting to
computed value?
dbaron: I'd prefer a used value time thing.
TabAtkins: Is it okay for use to resolve to an end value?
dbaron: How would that happen?
TabAtkins: I guess it would resolve to used value of width
TabAtkins: That's probably ok.
zcorpan: I didn't follow what you said
TabAtkins: We can't change the name of flex-basis auto value
zcorpan: But you can change behavior.
TabAtkins: Yes.
TabAtkins: I was wanting to keep things that went to length to be
at computed value time, but it's not huge.
fantasai: So close no change?
TabAtkins: Well, close and actually specify that flex-basis is
resolved at used value time.
fantasai: Close, clarify, no change.
TabAtkins: Yep.
TabAtkins: That's acceptable to me.
TabAtkins: We're good. So the proposed resolution would be close
this, spec properly that the flex-basis auto flips to
width/height at used value time.
glazou: Any objections?
RESOLVED: Close issue, spec properly that the flex-basis auto
flips to width/height at used value time
glazou: Next issue?
fantasai: There's one from Greg Whitworth that we have to think
through.
fantasai: The rest is editorial.
TabAtkins: Greg posted one that we didn't get to that we'll have
to work on tonight.
TabAtkins: I'd like to discuss the algorithm changes.
TabAtkins: The only major change since CR was...I said at last F2F
I wanted to change the algorithm so that as the value
approached 0 it was nice.
TabAtkins: It ended up being a bit of a rewrite, and recently
dholbert came up with a way to have the same effect,
but in a way that's closer to the original language.
TabAtkins: I think it's right, but if anyone is interested in
algorithms please make sure that it maintains proper
behavior.
TabAtkins: That's the only issue left. I have both versions in
spec and flagged. We're trying to switch to the CR
version.
TabAtkins: It looks like the old one, but approaches 0 properly.
fantasai: We folded the changes from the LC comments into both versions.
dbaron: This confuses me because you're talking about CR predating
LC.
TabAtkins: We're trying to go for 9.7.2, it should be equivalent
to 9.7.1
TabAtkins: We need to address Greg's issue tonight and make
editorial changes. I think we can ask for CR tomorrow.
TabAtkins: I think that's all on Flexbox right now.
glazou: Okay.
glazou: We'll move to transitions.
Rossen: One question. Where did we leave auto for absolutes?
TabAtkins: Would you like to discuss that? It's no change.
Rossen: It's still open on the list. We can do it now or just us
discuss it later.
TabAtkins: Let's do it here.
TabAtkins: Right now we have spec that grid and flex are similar
for static positions of absolutely positioned child of
flexbox.
TabAtkins: The model now is you act as if the abspos is the only
child, and where it goes according to the alignment
properties is the static position.
TabAtkins: If you set self-justify: center you'll have a thing
where the abspos is centered in the flex container.
TabAtkins: Rossen said that was confusing since you're not
getting size from the flex container.
TabAtkins: He thinks that should only apply if the flex container
is the containing block for the abspos.
TabAtkins: I don't have strong option, but I'm okay if we make
this work in the containing block case, but I also
don't have the problem with the existing.
fantasai: I prefer that the static position be the same calculation
for all children of the flex container, regardless of whether
their containing block is the flex container or some other
ancestor.
fantasai: Everywhere else if you compute static position of an abspos,
that's the position regardless of containing block.
fantasai: I want the static position of the item to not depend on
what its containing block is (like everywhere else).
fantasai: If we do this, we have to calculate different ways, depending.
fantasai: I don't think that's a good inconsistency.
Rossen: I agree. I don't want something different based on the
containing block.
Rossen: This is what was introduced in grid first. When we did it
we wanted to align grid items in grid.
Rossen: However, that was only abspos items in the grid, with the
grid as the containing block.
Rossen: That kind of violated the rule fantasai stated.
Rossen: Basically, the problem is with abspos layout, you compute
the static position where the element's natural position
would have been.
Rossen: Then the participation of the element is done and you
don't need to reconsider its hypothetical position.
Rossen: Once you're in the abspos's containing block, you figure
out where the item will be and then you size the item.
Rossen: The problem with the way we have spec'ed auto position,
you have to go back and fudge with static position to
make it work so item appears centered in the flex box.
Rossen: Even though the position between flex and the item is
distant.
Rossen: What we wanted to propose is to not find the static
position, but to find where the static position applies.
Rossen: So instead of static as the origin you can say it in
relation to the box.
Rossen: So you can work around the static position and center
around it.
Rossen: Instead of, after you've computed, reverse engineering
the position.
Rossen: When I mentioned this on the mailing list, I said we
should do this in position spec.
fantasai: So, you (Rossen) conceive of static position as a point
to which the abspos start, start corner is attached.
Rossen: Isn't it?
fantasai: In the other models you don't do it that way. It's a box,
not a point.
fantasai: So you say static position is start, start and you have
a small abspos wrt its container. It's aligned inside the
box in the start-start corner. Fine.
fantasai: But if you align the item to the center, it won't be centered;
and if you align it to the end it will hang outside the box.
This is asymmetric and won't be useful.
fantasai: It would be better if alignment kept the item inside the
box.
dbaron: I think Rossen is describing a different way to get the
same result.
dbaron: I'm skeptical about this in the whole, and want to know
about use cases.
TabAtkins: Largely it's so that you can achieve centering with
abspos.
TabAtkins: Treating static more naively, it seems dumb. It's not
what you would want in any case.
TabAtkins: If you say just container center and it only uses that
and goes to the side, it sounds stupid
TabAtkins: In terms of author expectations, this is better.
<dbaron> I'd be happy with just start, start corner.
fantasai: If we want to do dumb, then just use the start, start corner.
fantasai: This is trying to make it smarter, but ends up weird and not useful.
fantasai: Either we should do something useful, or we should do
something dumb and predictably useless.
fantasai: Trying to make it kinda smart but failing to be useful,
is not useful.
dbaron: I'm okay with start, start corner.
dbaron: This is a lot of code, but right now you have the flexbox
model and you can escape into the old model, oh, and you
can overlap your content.
TabAtkins: Okay.
dbaron: Is the disagreement the way to formulate?
TabAtkins: I think so. I think his code assumes a simpler order.
Rossen's ultimate model let's us position static
naively and end in the right place
dbaron: You may see static pos computation as a separate thing
that can happen later.
dbaron: I'm happy with Rossen's since it might be easier to
implement.
TabAtkins: The only things that play off are realpos, which isn't
a thing.
TabAtkins: It shouldn't have any detectable differences...
dbaron: Famous last words.
fantasai: I think if you want to compute static position, that if
you store it, instead of a point, store as a box.
Rossen: What's the relation between that and the box?
fantasai: You store as a rectangle so in the case of most things
it's a 0 height, but depending on if you are, it'll be
that or the size of the 0 height.
fantasai: Then it'll happen at the time of positioning. For flex
it would be a flex container.
dbaron: I don't think it makes sense as a rectangle
dbaron: To fit into existing method you want an x coordinate and
left-right-center alignment and a y coordinate with top-
center-bottom alignment.
Rossen: Which is what we did in grid.
TabAtkins: Was this originally in grid and we changed it?
TabAtkins: Are we okay with reformulating in those terms, assuming
positioning will do this process later and better?
fantasai: Can we discuss the rectangle later, with a white board?
TabAtkins: Yes.
Rossen: When you start counting all the modes you'll have fun
with a rectangle. As an implementor I promise that a
point will be conceptually easier.
Rossen: I'm sure with a white board we can solve this in a few
minutes.
TabAtkins: So for now let's resolve for what Rossen said.
fantasai: I don't want center and off to the side stuff.
Rossen: Let me repeat.
TabAtkins: Rossen wants identical behavior in a different way.
TabAtkins: Let me write out this resolution.
<TabAtkins> Proposed resolution: Switch the flexbox/grid abspos
model to be more naive, just positioning a 0x0 box as
currently specified, but then also define that, based
on alignment, the abspos child aligns relative to its
static position differently. Same layout results
should be achieved.
<TabAtkins> Such that "justify-content: center" puts the static
pos in the center of the flexbox, and the abspos
aligns its *center* with the static pos, rather than
its start edge.
TabAtkins: Okay.
TabAtkins: Rossen is that right?
Rossen: Yep.
fantasai: So maybe we have both models in the spec, one as a note
so people can think about it.
fantasai: I think for authors it would be easier to talk about
aligning the abspos within the box, but for implementors
we can formulate in terms of static position point.
TabAtkins: So. That sound fine for now?
Rossen: For now. I think we're going in the right direction.
TabAtkins: Now we can do transforms.
Received on Sunday, 8 June 2014 23:30:47 UTC