[CSSWG] Minutes and Resolutions 2012-06-27

Summary:
   - RESOLVED: All elements, regardless of 'display' value, are
               promoted to being flex items when placed in a flex
               container.
   - RESOLVED: calc inside calc allowed
   - RESOLVED: publish updated CR of CSS3 Backgrounds
   - Discussed edits to CSS2.1 wrt "formatting context" terminology,
     and whether 'overflow' applies to table elements.

Note: 4th of July telecon is *not* cancelled.

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

Present:
   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   David baron
   Ryan Betts
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Koji Ishii
   John Jansen
   Brad Kemper
   Peter Linss
   Alex Mogilevsky
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Alan Stearns
   David Storey
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/06/27-css-irc

Scribe: Florian

Administrative
--------------

   glazou: I'll be away for 3 weeks, and peter also on the 11th of July
   glazou: suggested replacement chair: Chris

   glazou: next call is on US Independence day, can we have a call?
   many: yes

Transforms, transitions, animations
-----------------------------------

   smfr: on transform, update from last week:
   smfr: IE and mozilla don't transform the background with attachment
         fixed
   florian: opera is transforming the background, and scrolling it in
            in parallel with the element, not parallel with the page
   smfr: IE and mozilla do that too
   dbaron: IE and moz draw the background as if there was no transform,
           and then transform
   smfr: if you use the transform to flip things upside down, the
         background is going to scroll backward, which is weird
   dbaron: they should put the background on an ancestor
   dbaron: it is ok, as fixed background are really meant for the root
           elements
   florianr: agree, we don't care too much about what happens on
             non-root elements
   smfr: should we define it then
   florian: not expected use case, but will probably be used, so we
            should define
   dbaron: we should define, to avoid people depending on a behavior
           we wouldn't want
   smfr: I would prefer to define it in a way that means you don't
         have to repaint the background when you scroll the page
   dbaron, tab: sounds acceptable
   ACTION smfr write a proposal about fixed background and transforms
   <trackbot> Created ACTION-481

   glazou: anything else?
   smfr: there is a little terminology issue, relating to containing
         blocks
   smfr: very tricky, would appreciate any help on fixing it
   sylvaing: animation, still 46 bugs
   dbaron: no news on transitions, still have to go through the hard
           issues

Flexbox
-------
Scribe: Sylvain

   <glazou> http://wiki.csswg.org/topics/css3-flexbox-flexbox-replaced-children
   Tab: still like proposal A
   florian: the reason I don't like A is that it's inconsistent
   florian: what happens with regular elements differs from what happens
            to the special-cased elements
   florian: for buttons et al. you can't turn this behavior off
   * fantasai is happy with anything except C
   florian: either we need an opt out and B is fine, or we don't and D works
   tab: D is not very flexible.
   tab: B is more work that seems necessary
   * alexmog is unhappy with anything except C
   tab: A special-cases elements because these elements are special cases
   tab: other document languages might have such cases but there is no
        good way to address this without defining new concepts
   smfr: could we make anonymous flex item containers for these elements?
   tab: in some cases this wouldn't work well e.g. the anonymous container
        would be stretched but not its content

   glazou: many diverging opinions, it's time for a straw poll
   <glazou> http://wiki.csswg.org/topics/css3-flexbox-flexbox-replaced-children
   florian: B or D (no objection to others)
   rbetts: abstain
   glazou: D
   alexmog: C then D ... and not A
   stearns: not A
   sylvaing: abstain
   koji: abstain
   brad: D
   dstorey: abstain
   plinss: C, not A
   rossen: C and then D, not A
   arronei: not A
   johnjan: C
   antonp: prefer B or D, not C
   smfr: abstain
   glenn abstain
   szilles: abstain
   dbaron: abstain
   tab: A or D
   hober: abstain
   fantasai: not C
   <fantasai> sounds like we can eliminate A
   glazou: let's straw poll C vs. D
   florian: D
   rbetts: D
   glazou: D
   alan: abstain
   sylvaing: C
   koji: abstain
   brad: D
   dstorey: D
   brad: D
   plinss: abstain
   rossen: C
   arronei: C
   john: C
   antonp: D
   smfr: C
   glenn: abstain
   szilles: abstain
   dbaron: D
   tab: D
   hober: abstain
   alexmog: C, but ok with D
   fantasai: D
   * bradk doesn't like 'display: flex-item'
   fantasai: Several "not C"s, but no "not D"s
   RESOLVED: Proposal D for handling of replaced elements as flexbox items

Formatting Contexts (2.1)
-------------------------
Scribe: fantasai

   <glazou> http://wiki.csswg.org/topics/overflow-formatting-context
   antonp: Just waiting for review from a couple people on this
   antonp: haven't heard back from dbaron
   florian: resolution was accept unless dbaron says no
   dbaron: you should just go ahead without me
   antonp: Rossen replied on the list, haven't heard back after response

Values and Units: vmax
----------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012May/1198.html
   fantasai: We have vmin, request was to add vmax
   hober: Are their use cases?
   tab: person posting didn't give a precise example, but did say there
        were some
   florian: if you think of it as cover vs contain, makes sense
   tab: Once you have vmin, vmax is trivial
   RESOLVED: Add vmax

   http://lists.w3.org/Archives/Public/www-style/2012Jun/0446.html
   * hober Yo dawg, I heard you like calc(), so I put a calc() in your
           calc() so you can do math while you do math
   * sylvaing we need to calc deeper
   florian: calc() inside calc() makes sense to me
   florian: unless we want to open debate of whether calc exists at all
            and just use bare parens
   glazou: Are there any objections to calc() inside calc()?
   silence
   RESOLVED: calc inside calc allowed

   fantasai: the other issue that's open is precision
   http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-25
   fantasai: I think Tab and I whiteboarded a proposal, but I don't know
             where it is.
   fantasai: Don't think this should hold up CR, though
   florian: agreed

CSS3 Background
---------------

   fantasai: wanted to update the CR, dbaron had an issue on animations
             line
   fantasai: seems like a lot of mostly redundant info, was wondering
             if we can keep that in the transitions spec
   dbaron: yeah, can probably keep in transitions spec

   florian: There are a number of background properties that take a list
   florian: if there are fewer than images, then repeat the list
   florian: computed value is as specified
   florian: ... trigger a transition
   florian: does adding to the list trigger a transition, even if no
            layers are added?
   Tab: It would be a null transition
   florian: would send out events, though
   florian: Seems more natural for computed value to reflect the value
            we're using in theory
   fantasai: would you truncate the specified value if it's too long then?
   florian: yes?
   dbaron: i think this is too late to change it
   dbaron: we do this computed value line across 3-4 specs now
   dbaron: too late to change them
   fantasai: if no one has other changes to make, suggest publishing
             update to CR

   florian: Another question...
   florian: background-position, syntax where you say 'right 10px'
            is equivalent to 'calc(100%-10px)'
   florian: probably too late to change that though
   florian: Mozilla shows that in its computed value
   fantasai: that's incorrect per spec...

   RESOLVED: publish updated CR of CSS3 Backgrounds

CSS2.1 Formatting Contexts reprise
----------------------------------

   Rossen: Just read anton's reply
   Rossen: My issues with the proposal was the fact that when you read
           2.1 sections 9.2.1
   <Rossen> http://www.w3.org/TR/CSS21/visuren.html#inline-boxes
   Rossen: talks about when an inline level box is created
   <Rossen> http://www.w3.org/TR/CSS21/visuren.html#inline-formatting
   rossen: inline-table and inline-block generate inline-level boxes,
           which participate in inline formatting context
   rossen: we have 9.... that talks about inline formatting context,
           but doesn't say what establishes it
   rossen: neither 9.4.2 nor 9.2.2
   rossen: Because of this I can easily deduce that an inline formatting
           context can be created by an inline non-replaced element
   rossen: issues I raised would become a problem
   rossen: ok with proposed definitions, as long as we take an action
           to clarify exactly what you said
   rossen: and state when an inline formatting context is created
   rossen: want to be assured that an inline elements don't establish
           an inline formatting context
   fantasai: "An inline box is one that is both inline-level and whose
              contents participate in its containing inline formatting
              context." (9.2.2)
   fantasai: implies that the inline box doesn't create an inline
             formatting context for its contents
   rossen: if we add to beginning of inline formatting context
           "inline formatting context is established by ...." then
           there will be no ambiguity
   antonp: "A block container box either contains only block-level
           boxes or establishes an inline formatting context and
           thus contains only inline-level boxes."
   antonp: before nothing said what establishes an inline formatting
           contexts
   antonp: I understand your concern that it's not 100% clear that an
           inline box does /not/ establish an IFC
   rossen: if that's clarified, then all my concerns are invalid
   rossen: so if we're ok with adding this clarification, then I don't
           have a problem

   rossen: there's a behavior difference...
   rossen: it appears that Gecko has overflow for table
   antonp: according to the email, behavior is 50/50
   antonp: among 4 key implementations
   antonp: Øyvind sent an email that there's a difference as to whether
           overflow is applied to table box or table wrapper box
   fantasai: so do we accept the edits or no?
   rossen: I'm ok with this
   rossen: concerned about change of behavior in implementations
   antonp: Isn't it the case that IE won't have to change?
   rossen: IE as of 9 and 10 will have that change
   rossen: I guess we didn't see any records that this is breaking
           anything when we changed it
-smfr
   florian: if we have implementations on either side, defining behavior
            of table is something we should do anyway
   rossen: only question is, do we want scrollers on tables or no?
   rossen: should we accept this, then?
   rossen: anyone object to overflow on tables?
   rossen: curious about other implementers
   dbaron and florian don't know
   dbaron: I'd need to look into it.
   tab: I know someone does overflow on <tbody>
   dbaron: I believe we stopped doing that, but I'm not sure
   rossen: easy enough to call it out explicitly as either yay or nay
           wrt overflow
   rossen: my proposal is to go with majority of implementations
   fantasai: so we have an action item to figure out what that is
   <fantasai> http://test.csswg.org/shepherd/testcase/overflow-applies-to-013/
   glazou: ok, will deal with that later

Meeting closed.

Received on Wednesday, 27 June 2012 22:09:09 UTC