- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 25 Jul 2012 11:43:51 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: placeholders have no impact on surrounding flex layout
- RESOLVED: Abspos static position defined according to principles
used in normal flow. Editor's to work out exact text.
- RESOLVED: 'order' does not apply to abspos children of a flexbox,
placeholders have all initial/inherited values for properties
- RESOLVED: Fix issue 22
http://lists.w3.org/Archives/Public/www-style/2012Jul/0476.html
====== Full minutes below ======
Present:
César Acebal
Glenn Adams
Rossen Atanassov
Bert Bos
Arron Eicholz
Elika Etemad
Simon Fraser
Daniel Glazman
Peter Linss
Edward O'Connor
Anton Prowse
Florian Rivoal
Alan Stearns
Steve Zilles
Regrets:
David Baron
Ryan Betts
Katie Ellison
Sylvain Galineau
Chris Lilley
<RRSAgent> logging to http://www.w3.org/2012/07/25-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2012Jul/0580.html
Scribe: Florian
Administrative
--------------
<glazou> Extra Agenda item : sunday at TPAC
<glazou> http://wiki.csswg.org/planning/sandiego-2012#participants
<glazou> http://wiki.csswg.org/planning/sandiego-2012#agenda
glazou: please register yourselves and add agenda items on the wiki
glazou: also, what about sunday on tpac
stevez: w3c can't pay for sunday, budget is 2000 euros
steveZ: Adobe is willing to pay for 1/4
SteveZ: who else?
tab: I'll check, we may be able to contribute
SteveZ: maybe microsoft could join too?
arronei: I'll talk to sylvain
fantasai: I'll check
florian: I'll check too
Stevez: Apple?
hober: I'll ask
glazou: how about catering
Bert: budget included coffee and lunch
organizations will donate to W3C, W3C will reserve the room
Flexbox
-------
<TabAtkins> http://wiki.csswg.org/topics/flex-abspos-placeholders
TabAtkins: what happens when a flex items gets absolutely positioned
TabAtkins: current spec says we get a place holder, which interacts
normally with the rest of flex elements
TabAtkins: noticeable when using space between, etc
TabAtkins: may we could do the same as tables
TabAtkins: there are several options, check the wiki
TabAtkins: the simple proposal is proposal A
fantasai: implementers don't like proposal B
fantasai: initial commenter didn't like C
fantasai: because it impacts layout of the content of the flexbox
fantasai: and that's normally not what placeholders do
florian: There was someone mentioning [something about transforms].
TabAtkins: I'm for A
TabAtkins: this is simplest
TabAtkins: we have alternative proposals, but they're more complex,
and there's no clear use case
fantasai: A or E (variant of C)
tab: E is too complex
florian: didn't Morten propose a variant of B
fantasai: that's D
TabAtkins: also a bit complex, not obvious use cases
SteveZ: what's important is that abspos items don't cause spacing
differences
tab: that's everything but C
Scribe: fantasai
fantasai: Morten responds that E is better than A or B
fantasai: He doesn't like A because "it sounds like a bug report"
fantasai: i.e. the author would expect the static position to be
somewhat accurate
fantasai: it might be more useful for vertical flexboxes rather than
horizontal ones
fantasai: you can abspos something to the side, and have the main
content flow down, e.g.
fantasai: Morten listed C > D/E > B > A
szilles: This isn't an implementer issue
szilles: The way I understand it is that the main-axis position may
be useful to someone
TabAtkins: That would be option C, because others are arbitrary
discussion of other cases that are complicated, e.g. bidi
szilles: Your (Tab) position is that coming up with something that
handles the static position is complicated and hard to
implement so why bother.
TabAtkins: yes
anton: I think there's an author expectation that static position works,
simply because it always has until now
anton: We have to choose between two aims here.
anton: Don't like placeholders to impact layout
anton: but also want static position to work
anton: they are both expectations that people have
Rossen: I agree with Anton, and to me static position makes a lot of
sense when you're talking about document layout and attaching
things to the flow
Rossen: But for app layout, static position is meaningless
Rossen: not used anywhere
Rossen: If you want something to stick to any particular position
Rossen: Would most likely include it as part of the item itself, so
would tag along with item
Rossen: So don't see what we would bring to the users, to implement
static position
Rossen: For implementation, easier to do origin of the flexbox
Rossen: Haven't seen any compelling use cases for it
fantasai: In Mozilla's implementation, we have a list of flexbox
children. Placeholders for abspos are interspersed in this
list. They can't be on a separate list because otherwise
if you relpos all non-abspos children, you won't know the
right painting order.
fantasai: When doing layout, we'd have to skip the placeholders as
we walk the list, e.g. for justification, anyway.
Whether the placeholder's final position is explicitly
shifted to the top left corner, or left as-is is a minor
thing.
fantasai: So A and E would, I suspect, be equally difficult.
TabAtkins: A is easiest from a spec perspective, even if it's not
easiest by implementation
florian: spec authors are last on the priority list
anton: Nobody's said anything about any of them being impossible to implement
Rossen: Even from our POV, implementing one vs other (A vs other) would
have some better perf characteristics during content updates,
but that's about it
Rossen: computing either position is not a problem
Rossen: Not very difficult to implement
glazou: I'm with Anton, author expectation is quite important
glazou: We are doing things in CSS these days that were quoted as
"impossible" by browsers earlier
glazou: complexity of implementation is an argument, but not the ultimate one
glazou: Readability of spec and expectation of authors seems more important.
<Bert> (With regions, grid templates, and flexboxes, the list of elements
to justify may have little relation to the source tree. It's a
list in some overlaid structure, a "shadow tree" (not necessarily
even a tree).)
TabAtkins: Unless we apply a bunch of properties to placeholders, in
non-complex cases the static position will be completely
arbitrary
TabAtkins: Placeholder just goes to order of zero, then that will have
no relation to order author intends there
TabAtkins: people seem to be very reluctant to apply properties to
placeholders
Florian: Have we talked enough that we can straw poll?
szilles: Would like to make one comment.
szilles: If you pick D then the positioning of abspos under ordering is
not completely arbitrary.
szilles: gets glued to next flex item
Anton: It's slightly arbitrary, but static position is always slightly
arbitrary
szilles: It's at least predictable
glazou: Let's try doing a straw poll
glazou: We have 5 options A-E
fantasai: I think B, D, and E are different ways of expressing the same thing
Straw Poll
glazou: want A, then D, but going to abstain
glenn: abstain
plinss: abstain
Florian: C or E
szilles: D, then A
hober: abstain
anton: D, then A
<Bert> Bert: A or D
smfr: abstain
césar: abstain
fantasai: not C
arron: abstain
tab: A or C
rossen: abstain
* scribe missed a few abstentions there
glazou: poll is not very conclusive
szilles: All answers, except one or two Cs, were advocating no traceable
effect of using abspos
Rossen: I strongly support that
RESOLVED: placeholders have no impact on surrounding flex layout
fantasai: I think B, D, and E are roughly the same, they're trying to
accomplish the same thing but expressed differently
fantasai: only might be different in edge cases, which we could discuss
fantasai: edge cases are
fantasai: a) between flex items, glued to next or previous
fantasai: b) if it's at a wrap point, does it wrap with the next, or
wrap with the previous
Anton: I would vote next in both cases
TabAtkins: given both are completely scrambled up by order, it's completely
arbitrary
fantasai: this is after reordering
fantasai: c) if no flex items, where does it go
* TabAtkins notes that deciding on issue A lets us ignore all of these
questions.
Rossen: Should go exactly where the first flex item would have gone
Rossen: If trying to keep as close as possible to flow layout
Rossen: In flow layout, is it with the next or previous item? Does it
stick to wrapping or not?
Rossen: Use those rules
<SteveZ> +1 for Rossen's reasoning
Rivoal: I'm ok with that reasoning, and if everybody agrees, we can resolve
on that and have the editors go off and spec that, whichever it is
Rossen: Shouldn't something like this go in the positioning spec?
Anton: In normal layout, says "position as if it were not floated and
position was static"
Rossen: Would hope that all static positions be put into css3-positioning
TabAtkins: Would prefer not have this be undefined right now
fantasai: I think we want to define it here
Rossen's Principles are, do the same thing you'd do in normal flow layout
Rossen: Either going with precise position, or origin
Rossen: For grid, we take the origin of the current cell
Rossen: In grid, you can have static auto position
Rossen: but you can define grid column and grid row, which will put you
in a particular grid cell
Rossen: you get something better than origin of the grid
Rossen: But it's still origin of the cell
Rossen: Now if you have 5 items in that cell, we won't do anything better
than 0 0
fantasai: items in the same cell stack on top of each other anyways
* glazou wonders if he should thank you all for such a conference call
right after my summer break :-D
Florian: This gives me another argument against A. More likely to wind
up with things on top of each other if you're not careful
TabAtkins: That's the definition of abspos: things wind up on top of
each other if you're not careful.
Straw Poll A vs. Rossen's Principles
glazou: A
plinss: abstain
glenn: abstain
Florian: Rossen
Alan: Rossen
szilles: Rossen
hober: abstain
Anton: Rossen
Bert: abstain
smfr: abstain
César: abstain
fantasai: abstain
Arron: Rossen
Tab: A
Rossen: Rossen
Consensus on Rossen
Florian: Can we let the editors now figure this out?
RESOLVED: Abspos static position defined according to Rossen's principles
above, editor's to work out exact text
* krit won't be on he call any longer. Maybe transform discussion can
continue on mailing list.
Next issue
http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-17
fantasai: Question is, does 'order' affect the absolutely-positioned
child, either wrt painting order or wrt static position
Florian: If we went with A, I'd say no, but given we're not going with
A, I think 'order' is useful.
TabAtkins: The issue is, we literally do nothing for placeholders anywhere
else
TabAtkins: e.g. we don't honor 'float' or 'clear' when computing static
positions
No strong opinions
szilles: I would go for not honoring it
szilles: Best way to keep things consistent
<TabAtkins> Note that *not* ordering it makes "Rossen's principles" much
less coherent.
Florian: I can go with that
RESOLVED: 'order' does not apply to abspos children of a flexbox,
placeholders have all initial/inherited values for properties
http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-22
fantasai: At TPAC resolved to change 'order' to <integer>, but Tab
forgot to edit this in.
TabAtkins: Question is do we reverse the resolution or edit it in
szilles: When do two numbers equal each other?
RESOLVED: Fix issue 22
fantasai: That's all the issues
Editors to edit all the issues, post text for review, and decide on CR
next week
Received on Wednesday, 25 July 2012 18:44:19 UTC