[CSSWG] Minutes and Resolutions 2012-07-25


   - 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

====== Full minutes below ======

   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

   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


   <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


   <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
   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
   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
   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
   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
   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
   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
   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
   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
   TabAtkins: e.g. we don't honor 'float' or 'clear' when computing static
   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

   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