W3C home > Mailing lists > Public > www-style@w3.org > January 2016

[CSSWG] Minutes Telecon 2016-01-07 [css-round-display] [css-snappoints] [css-grid] [css-multicol]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 7 Jan 2016 05:32:18 -0500
Message-ID: <CADhPm3u9jathW--8Cfn=4Ta8Sm+QW6ac9gW0rY0OVhHB-hbh7Q@mail.gmail.com>
To: www-style@w3.org
Round Display

  - RESOLVED: Have the computed value for polar-angle keywords
              resolve to an angle
  - Several people expressed support for position:
      relative/absolute/fixed/sticky enabling the polar-*
      properties, but at least one implementor needed more time to
      investigate so the group will return to the topic, hopefully
      next week.
  - The group needed BradK to be in the meeting to discuss the
      removal of polar-origin in favor of his center proposal.

Accepting the alternate proposal for snap points

  - MaRakow just came back from vacation today, but promised the
      group something for next week's telecon.


  - RESOLVED: Accept the new text for grid and multi-col changing
              the floor to a required amount. The new text is: "For
              the purpose of finding the number of auto-repeated
              tracks, the UA must floor the track size to a UA-
              specified value to avoid division by zero. It is
              suggested that this floor be ''1px'' or less."
  - The potential options for how to drop repeated grid tracks with
      auto-fit came down to:
          1. Drop all empty columns
          2. Drop empty columns from either end
          3. Drop empty columns from end end.
      - Several people were against 3 because it removed the
          symmetry of the property.
      - The group didn't have a preference between 1 and 2, so
          decided to stay with 1 since that's what's in the spec now.
  - RESOLVED: Change the initial value of align-content to stretch

May F2F

  - There's still no final location for the May F2F.

===== FULL MINUTES BELOW =======

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jan/0023.html

  Rossen Atanassov
  David Baron
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Jihye Hong
  Dael Jackson
  Brian Kardell
  Peter Linss
  Edward O'Connor
  Matt Rakow
  Florian Rivoal
  Alan Stearns
  Ian Vollick
  Greg Whitworth

  Brad Kemper
  Chris Lilley
  Anton Prowse
  François Remy
  Lea Verou
  Johannes Wilm

Scribe: dael

Round Display

Computed value for polar-angle and polar-angle-reverse in the
    animation using 2d rotation transform function

  astearns: Let's start.
  astearns: Does anyone have anything to add to the agenda?
  astearns: I'll take that as a no.

  <jihye> https://lists.w3.org/Archives/Public/www-style/2015Dec/0096.html
  jihye: There is an unclear thing of polar-angle and
         polar-angle-reverse value for transform function.
  jihye: It needs to be decided if polar-angle value turns into an
         angle or a keyword when determining the computed value of
  jihye: In the last telecon fantasai said if the keyword remains as
         a keyword I can't animate between it and another angle
         value. For example animating between rotate polar-angle and
         another rotate is impossible.
  <jihye> If the keyword value remains as a keyword, you can't
          animate between it and another angle value. For example,
          animating between rotate: polar-angle and rotate: 0 isn't
          possible. However, when polar-angle property animates, the
          changes in it affect to the rotation function with the
          keyword value. If the keyword value turns into an angle,
          you can animate between it and a different angle. Thus you
          can animate between rotate: polar-angle and rotate: 0 or
  jihye: If polar angle property animates, the keyword will not
         track the changes in polar-angle property. Did I understand
  TabAtkins: I think so.

  Florian: That's what we said, but I'm not clear why it wouldn't
           track. If it computes to an angle and polar-angle is
           changing, why is it not animating?
  jihye: I was also curious about that. I wrote this (below) in the
         mailing list with some questions.
  <jihye> https://lists.w3.org/Archives/Public/www-style/2015Dec/0267.html
  jihye: When the polar angle value remains as a keyword, animating
         between it and another angle is impossible. Is this because
         it can't be interpolated with another type of computed
  TabAtkins: That's right. But as long as the polar-angle isn't
             determined by layout there's no reason why turning into
             an angle at computed value time shouldn't track. That's
             a new computed dependency, but that's the only
  Florian: Did we get sidetracked along the way? Early on someone
           said it wouldn't track both simultaneously. So if the
           polar-angle animates really fast and you want to go
           between that and an angle, it wouldn't take into account
           that that and the origin would move between itself.
  TabAtkins: That's the same as font-size and an n value. You can
             have animations dependent on each other.
  Florian: I think that was the early comment and then multiple
           people misunderstood that to if you compute to an angle
           then it won't track and that seems wrong. So we should
           compute as an angle.
  jihye: Yes, I agree with that.
  TabAtkins: Yeah.
  astearns: Alright, sounds like we have consensus.

  RESOLVED: Have the computed value for polar-angle keywords resolve
            to an angle

An idea about using polar positioning as a part of absolute

  astearns: The second item on the agenda, BradK asked to move to
            next week because he can't attend. Is that okay?
  jihye: Okay.
  Rossen: Can we discuss without him and make the resolution pending
  astearns: Is there anyone who understands bradk's position well
            enough to represent him?
  jihye: There were several discussions about his idea with him and
  Florian: I think I can mostly, but there is one part where I don't
           agree so I may not represent that one well, but I can try.
  astearns: Do you want to? Do you think we can make progress

  <jihye> * position: relative/absolute/fixed/sticky enables polar-*
              properties. (polar-angle, polar-distance,
              polar-origin, polar-anchor)
          * If top/left/bottom/right is non-auto, polar-* properties
              are ignored.
          * polar-origin: auto is as same as polar-origin: 50% 50%
          * polar-anchor: auto is as same as polar-anchor: 50% 50%
  jihye: I think...I am curious about the other person's thought
         about using polar-positioning in another positioning value.
         The final position of the discussion was what I pasted
  jihye: We agreed to use polar-positioning when position is
         relative, absolute, fixed, or sticky because there can be
         several use cases that are outside of absolute polar. Are
         there thoughts on this?
  Florian: This would work...if you are in one of these absolute-ish
           or relative-ish positioning mode and you set
           polar-distance to non-auto you snap to polar-positioning,
           but auto is the old way of doing things.
  Florian: To me it seems useful.
  Florian: Having the choice between absolute and fixed sounds nice.
           Relative and sticky is nice too, though it's a different

  Florian: Does anyone else have an opinion?
  smfr: As an impl I want it something like relative so if you want
        fixed or sticky it should be in a container. I don't like
        snapping with a behavior that happens to trigger.
  Florian: The coordinate system you use would have to be
           rectangular or whatever. It's still the same positioning
           if it's relative etc.
  smfr: So you set polar, figure out the position, and position
        relative to the containing block in the normal way?
  Florian: Yes.
  smfr: I have to think some more.

  Florian: To put everything on the table, the second part of the
           argument is we wouldn't need the polar-origin and drop it
           in favor of center which positions to the center of the
           element. center:center would be the same as polar-
           origin, but it would also work for non-polar.
  TabAtkins: We have centering random elements in the alignment.
  Florian: That's my position, but what I said was BradK's.
  Florian: His center positions things by the center. So aligned to
           the vertical center and left side is hard now.
  TabAtkins: But again, the alignment property would do that.
  Florian: Would it?
  TabAtkins: Yeah. You use justify or align: self. Center one, left
             the other.
  Florian: What you said aligns the left side to the left side.
           Brad's proposal puts the *center* of the element at the
           left side of the containing block.
  TabAtkins: That seems less...until I see a use case I don't think
             we need to optimize for making an element overflow.
  Florian: I'd tend to agree.
  Florian: I don't share his opinion so I can't argue it.

  astearns: Other opinions on dealing with the auto values? The
            first part on the discussion.
  astearns: smfr, said you needed to think more. If you have time it
            would be great to have you look on the list. If other
            implementors have opinions, get to the list. We'll talk
            next week with BradK
  smfr: Sounds good

Accepting the alternate proposal for snap points

  MaRakow: I'm not in the office yet, I've been on holiday for three
           weeks. I'll have something to show next Wednesday
  astearns: Is that acceptable to everyone?
  TabAtkins: I'm not happy to wait an additional week since we've
             already gone past where we want a decision, but there's
             nothing else we can do so sure.
  * fantasai notes that we have resolutions on the technical changes
  <Florian> +1 to Tab

  Rossen: I have a quick question to other browsers you're siting.
          Who is blocked on this not being there?
  TabAtkins: Everybody.
  Rossen: That was to the other browsers.
  TabAtkins: Well we're blocked.
  Rossen: Webkit and Gecko?
  dbaron: We shipped what was in the old spec when we didn't like it.
          We're afraid to change until we're convinced it's stable
          and others will change.
  Rossen: That matches my understanding.
  TabAtkins: That's why I'm frustrated. We had agreement two months
             ago and we're waiting on someone doing the work. There
             is non-interoperable content on the web. You can't use
             snap points.
  Rossen: I'm also unhappy. Let's put that aside. I'm trying to find
          out what is the urgency and who is blocked most. There was
          urgency voiced in Paris about the competing spec to be
          finished and wrapped up by TPAC. At TPAC when we sampled
          the same question and asked for the urgency, there wasn't
          huge urgency by webkit or gecko. I'm not trying to
          diminish what you said. That's why I'm going to them to
          find out if they're blocked with devs waiting to finish or
          will they start work when the spec is ready.
  smfr: We shipped prefixed old spec. No one is working on snap
        points now.
  Rossen: That was my understanding from TPAC
  TabAtkins: We're in a holding pattern with an implementation of
             the new spec. As soon as the WG signs off we're ready
             to go. Whatever we implement won't be interoperable.
  Rossen: That's clear.

  Rossen: There's a commitment from MaRakow that we'll have the new
          spec next week.
  TabAtkins: I want an explicit that we'll go to this next week. We
             agreed on the details. I don't want to show up next
             Wednesday and need time to review. That happened for
             two years.
  MaRakow: Two years ago Google didn't want it and wasn't interested.
           I'm not sympathetic. I understand it needs to be done
           soon. I want it done. It will be ready. I wanted it done
           two years ago.

  Florian: One thing I want to clarify about a danger to not doing
           it fast, it's currently not interoperable...is that good
           because there cannot be any web content using it or are
           we seeing an body of web content building up, and locking
           us into one of the variants of the old solution?
  fantasai: There's a risk, there always is.
  astearns: Next week we'll get out of the holding pattern. We
            should go on.

Grid Topics

Flooring track sizes at a UA-defined minimum for the purpose of
    finding the number of repetitions in auto-fill cases

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Dec/0157.html
  astearns: This is a hold over from last year's meeting.
  astearns: Is it TabAtkins or fantasai that wants this?
  TabAtkins: This was applying a min-size to auto-repeat. Does
             anything need to be decided?
  Rossen: I don't recall us resolving.

  TabAtkins: Okay. auto-repeat has a space to fill, you give it a
             track list, and it tries to fill. If it's 0px you can
             end up with infinite.
  TabAtkins: So we now have a UA defined minimum, we recommend 1px
             because it's nice and small. And we need to apply that
             to multi-col because it has the same problem.
  TabAtkins: Unless there's an alternative, we can resolve on this.
  Rossen: I'm okay with the change. My only ask is we make 1px
          clearly that in the spec so it's easier to text instead of
          it being suggested and everyone does their thing.
  TabAtkins: Okay.

  RESOLVED: Accept the new text for grid and multi-col changing the
            floor to a required amount. The new text is: "For the
            purpose of finding the number of auto-repeated tracks,
            the UA must floor the track size to a UA-specified value
            to avoid division by zero. It is suggested that this
            floor be ''1px'' or less."

  fantasai: The current minimum in Mozilla is 1/60 px.
  Rossen: That's why I brought it up.
  astearns: Who will change multicol?
  Florian: I will.
  TabAtkins: I will.
  Florian: I'll leave it to TabAtkins

Dropping empty repeated tracks

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Dec/0155.html
  TabAtkins: So the auto-fit value repeats a bunch and only uses as
             many as you need. It's based on some use cases where
             you want the grid to not be the full size with lots of
             empty space. The definition of an empty track is clear.
             But where do we drop from?
  TabAtkins: Currently it's just the end of the list.
  fantasai: I think we currently drop all the empty tracks. Mats
            asked about only dropping end, not middle.
  Rossen: They layout result from both will be identical.
  TabAtkins: No.
  TabAtkins: If you say you're repeating a 50px track and only have
             something in 1 and 3. If you drop the last you'll have
             an empty.
  Rossen: Correct.

  Rossen: The two things that stand out is 1) having the space
          repeater where only non-empty are entered would make
          having a good OM later more difficult if we're not keeping
          the repetition. 2) keeping the pattern of repetition is
          more predictable and it's easier to signal to content
          authors you're doing something unexpected.
  TabAtkins: We dropped repetition patterns so that doesn't matter
             for this case.

  astearns: I like the characteristic of having a stable layout as
            you add or remove things from a grid template like this.
            Having things collapse because you removed an item is
  TabAtkins: There's another value that doesn't drop anything at the
             end of placement.
  TabAtkins: Temporally in the algorithm.

  fantasai: So what we have is auto-fill and you can choose one size
            that will repeat to fill space. You can keep as many
            columns as fit or drop any columns empty after we've
            filled. So you have a catalog and you're trying to fit
            as many columns. But you only have 2 items and there's
            room for 10 you drop the others to center.
  fantasai: We don't have concrete cases for leaving gaps in the
            middle, but that's what we're trying to answer. Instead
            of automatically created tracks, if you place things and
            have empty tracks, do you drop them? So can anyone come
            up with a reason to leave a track in the middle empty?
  fantasai: If there's a reason we can decide if we should drop them.
            If there isn't a reason to want them, we have an
            arbitrary decision. A use case would help us make a
            useful decision.
  <gregwhitworth> http://threesjs.com/ imagine these are using
                  repeat for creating the tracks
  astearns: gregwhitworth posted a link to a game grid, but I'm not
            sure you would use a repeat there. I assume it's a 4x4
  fantasai: It wouldn't be auto repeating.

  Rossen: Is the dropping specify that it's an empty column across
          all rows?
  fantasai: Yes. You can't drop a track if there's stuff in it.
  <fantasai> spec link - https://drafts.csswg.org/css-grid/#repeat-notation

  astearns: I have this grid and I've placed an item in track 1 and
            track 3 and I get a two track thing because the center
  astearns: I would prefer not dropping empty in the middle because
            I've defined that this is track 3.
  Rossen: That's why I brought up the OM. If you're using the tracks
          as identifies you don't have the second and that's off.
  fantasai: If you have tracks 2 and 4 with stuff, you would drop
            track 1 and 5?
  Rossen: Just 5.
  fantasai: I think plinss brought up a desire to have it symmetric
            and just 5 is asymmetric.
  astearns: I'm suggesting we take the author's intent. I asked for
            things in track 2 and 4 so I'm expecting 4 tracks.
  fantasai: But you...you wouldn't use auto repeat if you knew how
            much space. So we have a conflict between the obvious
            which is only drop the end and the guiding principle of
  Florian: Numbers aren't symmetric.
  fantasai: The numbering system can work from both directions. The
            system we have for positioning is very symmetric and
            that's a good thing.
  fantasai: Sticking with that is better than guessing author intent.
            I think keeping the symmetry is stronger. But I don't
            have an opinion on dropping middle.
  TabAtkins: The use case for this isn't positioning things
             explicitly. This is for auto-placement of a bunch of
             items and you just want to have it not be extra big.
  astearns: And you could have voids in the middle?
  TabAtkins: There should not be. I have to really think if there
             are things in the algorithm that could lead to that.
             This is really defining error behavior.
  fantasai: The author could have decided to use auto-fill and
            explicit placement.
  TabAtkins: You're using the grid wrong in that case.
  Rossen: That's why I'd prefer predictability.

  fantasai: If you want to not hide anything you wouldn't use this
            keyword. This is to drop extra columns that aren't being
            used so you can center if you don't have enough columns
            to fill the space.
  <fantasai> 'auto-fill' will not drop columns
  <fantasai> 'auto-fit' will drop empty columns so that you can
             align the remainder
  TabAtkins: This is anti-predictable because it's meant to respond
             to content. You can't predict the number of columns in
             the general case.
  TabAtkins: Even if we just drop on the end, your track positioned
             with negatives will show up more unpredictably.
  fantasai: This is after placement. Nothing will change.

  fantasai: So the options are:
  <fantasai> 1. Drop all empty columns
  <fantasai> 2. Drop empty columns from either end
  <fantasai> 3. Drop empty columns from end end.
  fantasai: I'm somewhat against 3, but okay with 1 or 2.
  astearns: 2 is both ends?
  fantasai: Yeah.
  astearns: I don't have a strong opinion.
  astearns: If we're going to drop columns at all, maybe go with #1
  Rossen: Or make it a feature of the feature.
  astearns: No switches!
  astearns: If this is an anti-predictable feature, maybe several.
  fantasai: There's a don't drop empty columns or drop empty columns
            and you choose that up front.

  Rossen: To resonate dholbert, from an implementor point of view if
          you've implemented dropping any columns, implementing
          dropping the end later should be trivial.
  Rossen: I'm okay going the most restrictive and going where
          feedback suggests.
  astearns: Other opinions?
  fantasai: Let me pull up the e-mail. I think Mats preferred not
            the middle.
  Rossen: Is that because the extra lines of code?
  fantasai: No, I think he implemented dropping all the tracks. And
            dholbert was expecting on the end.
  Rossen: Okay, sorry.
  fantasai: Okay.

  Rossen: Do we need a resolution?
  fantasai: I don't have a preference. I can try and collect more
            feedback. Otherwise as a WG we don't have a preference
            between 1 and 2
  astearns: I prefer choosing one or the other.
  TabAtkins: You prefer someone to have a preference.
  astearns: Yes.
  TabAtkins: So let's resolve on 1.
  astearns: I'm happy enough to do that now.
  astearns: fantasai do you want more feedback?
  fantasai: The spec currently has option 1. I'll see if someone
            comes up with a reason to go with 2. We don't have a
            good use case.
  astearns: So I guess we don't need a resolution.

Changing initial value of 'align-content' for grid containers to
    match Flexbox

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Oct/0026.html
  TabAtkins: Right now if you have a grid that's smaller than the
             container it defaults to start, start. Flexbox defaults
             to stretch. Javier in Chrome thinks this inconsistency
             odd and would like both to have stretch.
  TabAtkins: Stretch only effects auto-sides grid tracks, so that's
             the only change.
  fantasai: And if you don't have a container fixed to be larger you
            won't have an effect. So auto-size grid containers don't
            have an effect.
  TabAtkins: So this effects grid containers set larger than grid
             inside and the grid has at least one auto-track
  fantasai: I'm in favor of consistency. In the past there wasn't a
            way to handle stretch in the past, but there is now.
  <astearns> +1 for consistency
  TabAtkins: The original decision wasn't intentional exclude, it
             was because we couldn't. Does anyone object to the
             consistency change?
  Rossen: Sounds okay.

  RESOLVED: Change the initial value of align-content to stretch

May F2F

  astearns: That's the end of the agenda.
  Rossen: Did we ever settle the May F2F location?
  astearns: No.
  Rossen: I remember we decided west coast, but nothing more.
  plinss: I have an inquiry to see if I can host, but no reply.
  Rossen: We should solve that by end of month.

  Florian: So we said west coast, even just CA. Is it HP or someone
           else, or just HP possible to host?
  Rossen: Did we ever settle on CA or all of west coast?
  Florian: I think so, but may be wrong.
  Rossen: So I'll let the people from southern west coast explore
  astearns: So hopefully we'll hear something soon.

  Rossen: One more quick item. I e-mailed the list from TPAC about
          specs we agreed to update. Please give that a look and
          update items as you find time
  astearns: And if we don't have an update soon, we'll bug people.

  astearns: Thanks everyone for calling in, we'll talk next week.
Received on Thursday, 7 January 2016 10:33:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:35 UTC