[CSSWG] Minutes and Resolutions Telecon 2012-07-11


   - RESOLVED: Negative durations are invalid for transitions/animations
   - RESOLVED: move feature requests for new animation APIs to Level 4
   - RESOLVED: Defer the <ident> type until Level 4 of V&U
   - RESOLVED: the request to make a change is rejected; "calc" is required
   - RESOLVED: spaces are required around addition/subtraction operators;
               no change from previous resolution
   - RESOLVED: DoC for css3-values is accepted; move spec to CR
   - RESOLVED: Flex items do not create a pseudo-stacking context at this
   - RESOLVED: non-auto values of z-index create a stacking context on
               flex items even without 'position: relative'

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

   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   David Baron
   Ryan Betts
   Bert Bos
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   John Jansen
   Chris Lilley
   Peter Linss
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/07/11-css-irc
Scribe: SteveZ

No Additions to Agenda

Animations Issues

   Sylvain: Sent call for consensus to make negative duration be invalid
   <smfr> sounds fine
   Sylvain: this should have no impact
   RESOLVED: negative durations are invalid
   <smfr> no
   <oyvind> (hm, is "transition: -2s 1s" invalid? might want to clarify that)

   Sylvain: Level 3 Animations are becoming unprefixed, so think we
            should defer requests for new DOM APIs
   RESOLVED: move feature requests for new APIs to Level 4
   Smfr: Should these be prefixed if an implementation is done in the
         next few months?
   Sylvain: yes, they should be prefixed
   Sylvain: if something is not yet specified then it should be prefixed
            when implemented
   plinss: We can make L4 additions short and advance that quickly.

Values and Units

   <smfr> http://dev.w3.org/csswg/css3-values/issues-lc-2012
   Fantasai: Propose to defer resolving the case issue on idents
             (CSS and User defined) until level 4
   <fantasai> by deferring the definition of <ident>
   smfr: worried that animations may start having user ids and would not
         like to see these being different
   fantasai: deferring does not mean not working on it; it means resolving
             the issue in conjunction with the active specs, like animation
   fantasai: This means removing the type from V&U from Level 3; CSS 2.1
             has its own definition for counters
   fantasai: We can work on solving the issue for Animations and Counter
             Styles, but inline the definition until we factor it out
             in css4-values
   RESOLVED: Deferring the type until Level 4 of V&U

   <dbaron> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-36
   Issue 36: removing "calc" and using bare parens
   Florian: stay with what we have and require "calc" part of "calc()"
   Tab: Does the working group agree with the editors request to reject?
   Multiple people say they prefer calc()
   Florian: fantasai preferred parens?
   Fantasai: I prefer just using parens, but do not object to requiring
             "calc" if that's the WG's preference
   RESOLVED: the request to make a change is rejected; "calc" is required
   <nimbu> (what would bare calc look like?)
   <hober> nimbu: (10px + 10%) instead of calc(10px + 10%)

   <dbaron> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-35
   <fantasai> Issue 35, changing tokenization of DIMENSION so units can
              no longer contain - so that white space can be dropped
              between +/- and operands
   Tab: there may have been prefixed units in the past and this change
        would invalidate this
   dbaron: This is one of the top author complaints about calc(), it trips
           up a lot of people who don't understand why it doesn't work.
   dbaron: I'm inclined to say we should try to fix it
   dbaron: It means we'd have a problem with keywords that have hyphens
           in calc(), things like min-content
   Tab: I really want to extend in that direction
   Florian: It would make the grammar more complex, but we could work around
            it by having different parsing rules for numeric and keyword types
   <ChrisL> that is why SVG had camelCase property names (except for ones
            already defined by CSS) - to avoid the hyphen being seen as a minus
   * sylvaing agrees with dbaron that it is a major stumbling block when
              learning the feature
   Tab: This would require different tokenization for calc
   Florian: This is not a huge deal
   Tab: there is only one unique tokenization today: that is an+b for nth child
   Florian: the Opera lexer is already context sensitive
   * fantasai suggests not trying to figure out exact changes on this call
   <sylvaing> +1 to fantasai, dbaron
   * ChrisL agrees, send in a concrete proposal in email
   dbaron: OK with rejecting change because I do not have an answer for what
           to do
   Tab: We could conceivably change this in the future
   Sylvain: Sensitive to the usability issue, but this is not the time to
            make a change. We need a proposal to make it work
   Florian: this can be fixed in the future without breaking existing documents
   Sylvain: users can tell that their calc expressions do not work so they
            should not be confused about what is failing
   Fantasai: Note, such a change wouldn't break forwards compat of a style
             sheet, but would affect backwards compat.
   fantasai: Existing browsers (e.g. IE10) do require the spaces;
             if we change it later, someone will write calc() without
             spaces (e.g. for IE11), and it won't work in older browsers.
             They won't expect there to be a problem because IE10 supports
             calc(); the change in allowed syntax that makes it not work
             is very subtle.
   Sylvain: either way we decide, IE10 is not going to change here
   RESOLVED: spaces are required; no change from previous resolution

   Bert: need to send followup email to the response to issue 22, since the response is no longer correct
   <ChrisL> agree that it is minor but needs to be closed off properly
   ACTION fantasai send followup to v&u issue 22
   <trackbot> Created ACTION-483
   Bert: on Issue 22 there is a message that says the resolution is 27 bits
         and we have changed out mind so there should be a message to say that

   RESOLVED: The DoC is accepted (as edited re issue 22 above)
   <ChrisL> yay
   RESOLVED: V&U is taken to CR


   PLinss: Expect to have a final venue by the end of this week for the
           San Diego meeting
   <dbaron> I might be more likely to join an event on Sunday than on
            Thursday, but it's somewhat uncertain.  (I may well have a
            bunch of meetings to call in to on Thursday and Friday.)
   PLinss: Trying to put an event (Sailing) on Thursday; HP will contribute
           some, but we would need to pay to participate
   <ChrisL> my regrets for san diego
   * sylvaing suspects plinss meant Tuesday since the meeting is Monday-Wednesday
   * plinss meant Thursday… we'll be actually working Tuesday :-)


   <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012

   Painting Order
   <fantasai> Issue #5
   <fantasai> http://wiki.csswg.org/topics/flex-item-painting
   Issue 5: Painting order: blocks and table cells vs inline blocks
   alex: I think this is a more generic question, not specific to flexbox
   alex: applies e.g. to grid as well
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2012Jul/0257.html
    alex: is every new layout model use pseudo-stacking context?
   Alex: DBaron do you want it to behave like floats
   dbaron: I have mixed feelings about it. Would have been better if we
           did that originally, but maybe better to have inline-* does
           it and other things don't
   fantasai: that would decide flexbox vs. inline flexbox, but doesn't
             tell you about items wrt each other
   alex: float behavior is special, it's different from text
   alex: above text or below text
   alex: others are things that may overlap due to negative margins, etc.
   alex: vertical flexbox is similar to block flow, if it makes sense
         for block would make sense for flexboxes
   Fantasai: The behavior here is weird because floats needed to be above
             the background of items that were later in the doc tree
   alex: would help to have a use case that would make a difference one
         way or another
   DBaron: I do not have a use case that would distinguish either way
   Fantasai: I cannot think of a single use case that would be better with
             block behavior, but I can imagine some where pseudo-stacking
             would be better
   fantasai: so based on that I would say it should be a pseudo-stacking
   ?: Can you give an example?
   Fantasai: I have a flex-box with a bunch of cards that overlap a bit
             and I open up one that the user is hovering over
   fantasai: would want the text of each card to be right over its bg,
             not over the bg of the card on top of it.

   Anton: I think it makes sense to make flexbox a pseudo-stacking context.
   Anton: In block layout, you don't really see the individual blocks,
          you see the content as a continuous flow. So the painting behavior
          there makes sense.
   Anton: In the new layout models, we are going to view the pieces as
          basically independent of each (say in grid)
   Anton: I have yet to grasp the range of use case for flex-box and cannot
          yet see how flex-box should behave:
   Alex: I propose moving this issue to grid and then use what we decide
         there back to flex-box
   Alex: I do not think that there are a lot of cases for overlapping items
         in flex-box; for grid on the other hand we do want overlapping items
   fantasai: I think for grid, if you expect to have overlapping, then you
             *really* want them to be pseudo-stacking contexts
   alex: So let's resolve for both grid and flexbox as pseudo-stacking
   <dbaron> So it sounds like we're converging on Proposal B.
   Anton: it is the safer way to go with the pseudo-stacking behavior

   PLinss: we cannot envision all the use cases so we should not make
           decisions based on what we can see.
   PLinss: I can see people wanting the behavior in both ways
   PLinss: I think the behavior is controllable
   Florian: we are just discussing the default behavior
   Anton: It's already controllable with position:relative

   fantasai: This relates to issue 16, on whether z-index should just work
             on flex items
   <fantasai> auto would have no effect
   <fantasai> integer would mean form a stacking context
   <fantasai> note, that this only lets you switch into having a stacking
              context vs not, can't switch between pseudo-stack or not
   Fantasai: That would give a switch for stacking context, but not
             pseudo-stacking context
   Florian: I'm leaning towards No, not pseudo-stacking context. Yes,
            z-index just works.
   DBaron: I cannot think of any case where a user wanted that behavior
           rather than accidentally depending on it
   Alex: I cannot think of any such case either, but am not sure there
         would not be one
   * sylvaing this discussion assumes the scope of use-cases to be known
              AND that users understand stacking.
   Alex: I would leave the current definition (agreeing with Florian)
         because we know what it does and do not have examples that show
         a need to change
   RESOLVED: no pseudo-stacking context at this point; z-index creates a
             regular stacking context
   Anton: User were taught that z-index only works with relative positioning
          and this changes that rule
   Anton: This is more of a cognitive (mental model) problem than a
          practical problem
   Florian: This is not a new problem, however.

   Issue 12
   alex: Need to use max(min, basis) for wrapping
   Tab: size used for line wrapping is clamped by min and max
   Alex: If you have a bunch of buttons, if there is space, then they
         should go to the next line; if not enough space, then shrink
   Tab: we should examine more intelligent controls in level 4
   RESOLVED: No change for Issue 12

   Tab: one more issue to resolve to go to CR
   Florian: No, we also need a new name for 'order'
   Tab: I object to change of the name, "order"
   Florian: We resolved last week to change the name of "order"
   Tab: I OBJECT to such a change
   <sylvaing> +1

Florian: please add the topics I mentioned last week to next week's agenda
Meeting Adjourned at 10:03

Received on Wednesday, 11 July 2012 20:38:26 UTC