[CSSWG] Minutes San Fransisco F2F 2017-11-06 Part II: Backgrounds, Grid [css-backgrounds] [css-grid]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Backgrounds

  - RESOLVED: Text color has no effect on background-clip.
  - RESOLVED: text-decorations should be considered as part of the
              text shape for background-clip purposes.

CSS Grid

  - RESOLVED: Option D: percentage gaps in shrink-wrapped grids
              contribute 0 and layout as 0. (Issue #509:
              https://github.com/w3c/csswg-drafts/issues/509 )
  - RESOLVED: Percentage tracks sized as percentage resolve the same
              way for columns and rows, which involves a second layout
              pass in some cases.
  - The request for "Equal Gutters in both axes" feature
      (https://github.com/w3c/csswg-drafts/issues/1116 ) was presented
      and those interested continued talking over lunch.


Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda

Scribe: TabAtkins

CSS Backgrounds

background-flip and text-underline
  github: https://github.com/w3c/csswg-drafts/issues/900

  fremy: It seems we always consider underlines as part of the text
  fremy: So for background-clip: text, you draw the background only
         under the text of the element. Intention is you set the text
         to transparent, so the background layer fills in for the text.
  fremy: In Firefox though, the color of the text doesn't matter for
         the shape, but the transparency of the underline is applied
         as an opacity on the background.
  fremy: So if people use color:transparent, the underline is too, and
         the background under the underline becomes transparent.
  fremy: I don't think this makes sense... Edge is not doing this.
  TabAtkins: This sounds like accidentally over-applying an opacity
  fremy: I think it would be good to specify the behavior.

  smfr: Related, the fill and stroke module will someday handle this,
        right? Should we even specify this, given that it'll be
  (We need to spec this for Web-compat; it's going in an appendix.)

  TabAtkins: So back to Fran├žois's point - settle that text color
             shouldn't have any effect on background
  fremy: And that text-decoration should be included as part of the
         text shape.

  RESOLVED: text color has no effect on background-clip.
  RESOLVED: text-decorations should be considered as part of the text
            shape for background-clip purposes.

  <AmeliaBR> I would definitely expect background-clip: text to
             include the underline area. Looks like browsers do that
             even when the underline is from a parent element:

CSS Transform

Transforms 3d contexts
  github: https://github.com/w3c/csswg-drafts/issues/1944

  trchen: In CSS, having a stacking context does not guarantee an
          element to be a containing block for every descendant
  trchen: And being a containing block doesn't imply being a stacking
  trchen: 3d context is a stacking concept - it decides which planes
          need to be 3d-sorted against each other
  trchen: But at the same time we define 3d context of elements based
          on containing block
  trchen: Causes "3d context penetration problem"
  trchen: Element can be flattened by another element that's not part
          of its containing block chain
  trchen: We're working on a project in Blink to simplify compositing
          code, found some ill-defined corner cases
  trchen: Planning to have a breakout session tomorrow afternoon?
  smfr: Would like to have a browser vendor rep from each for the
        breakout tomorrow.
  [discuss details of the breakout]

CSS Grid
  scribe: bkardell

Percentages gaps and intrinsic size
  github: https://github.com/w3c/csswg-drafts/issues/509

  <fantasai> all options for percentage gaps listed in
      A = contribute back-computation ratio, resolve as percent
      B = contribute zero, resolve as percent
      C = contribute auto, resolve as percent
      D = contribute zero, resolve as zero
      E = contribute auto, resolve as auto
      F = contribute zero, resolve as percent (for column-gap) or zero
          (for row-gap)
  fantasai: I think we agreed to eliminate C and E.

  lajava: We have two different issues
  lajava: We have undefined width and height
  lajava: The issue we are discussing now is for grid gaps

  lajava: fantasai listed different options after some discussion
  lajava: Our discussion from blink/webkit: we prefer to keep existing
          behavior: keep treating them as 0 for intrinsic size/layout
  (i.e. lajava is requesting option F)
  lajava: In the issue there is an explanation
  lajava: We think that what happens in Firefox is broken with that
  lajava: If we don't do that for margins, we should be consistent
  lajava: We have to decide from the options fantasai listed and agree
          to do it the same
  fantasai: My concern with f) in that list is that it has been a goal
            of grid to have symmetric behavior in both axis
  lajava: Related to that, we think there are issues to do that with
          tracks as well
  lajava: It's not impossible, but there is no browser doing that
  lajava: All of the browsers consider cols and rows differently
  lajava: so I'm not sure that should be important in solving for gaps
          - perhaps we decide not to do it for the tracks

  rachelandrew: There are issues teaching this to authors. Generally
                people understand when you say this will resolve to 0,
                the goal of having symmetrical gaps would be nice.
  rachelandrew: If we can't have them symmetrical, having the rows go
                to 0 makes sense.
  lajava: I agree with that
  dholbert: Are we just talking about intrinsically resized grids
  lajava: d) tries to resolve the same way in both axis
  rachelandrew: If we didn't have percentage gaps, if we changed
                existing behavior ...?
  <astearns> so rachelandrew is for F, not D
  jensimmons: If you had that situation in the inline direction where
              you didn't have an explicit width those gaps would also
              resolve to 0, it's just not a common use case
  jensimmons: If you said you want this to be 100x100px - in both
              directions the gap would be 10
  jennsimmons: I don't know if what you are describing is that the
               algorithm is doing the math diff?

  Scribe: frremy

  lajava: There are two reasons we don't want back compute for the gaps
  lajava: Backcomputing when the percentages are close or bigger than
          100% the solution isn't that great
  lajava: The second reason is that we decided not to do that for
          margins, and so we would like to work the same for gaps
  dholbert: Well, on that, I think margins are just a legacy thing
  TabAtkins: I would be opposed to anything that could yield to sizes
             bigger than the max size a browser can allocate
  TabAtkins: It's very easy to end up in such cases with back-computing
  Rossen: +1

  Rossen: For this issue, the currently listed options are on the
          screen, and the github
  <frremy> Igalia would prefer B, D, or F
  lajava: Yes
  Rossen: Edge's preference would be to keep symmetry
  Rossen: If resolving in one of the pass is not possible, though,
          resolving to zero as usual is fine
  Rossen: F is therefore not a great solution
  Rossen: Between B and D, I would like to hear more opinions

  TabAtkins: B is expensive, there might be fragmentation issues
  Rossen: Which fragmentation issue?
  TabAtkins: Could contribute, but we could discuss this later when
             this comes up

  dholbert: What would happen for auto grid with percent columns?
  Rossen: Let's say you have a 2x2 grid that has to shrink in both
  <gregwhitworth> here's the example Rossen is stating:
  Rossen: If that grid had a size, we would compute properly and
          things would be symmetric
  Rossen: but if the grid is floated, we will have to compute
          percentages has zero to find the size of the float
  Rossen: but in the second pass, we are given a choice
  Rossen: Either add the gaps and overflow slightly
  Rossen: or you can continue to resolve to zero
  Rossen: This is the difference between B and D
  lajava: Igalia doesn't mind B but the problem is that if you are
          auto and overflow by default, that seems counter-intuitive
  Rossen: The only con of D seems that some authors could be unhappy
          about this
  Rossen: but I would like to make sure that is really the case
  Rossen: because authors can still use other units, or give a
          specified size to the grid.

  fantasai: (reading a summary of the A-F proposals)
  <fantasai> A = contribute back-computation ratio, resolve as percent
  <fantasai> B = contribute zero, resolve as percent
  <fantasai> NOT C = contribute auto, resolve as percent
  <fantasai> D = contribute zero, resolve as zero
  <fantasai> NOT E = contribute auto, resolve as auto
  <fantasai> F = contribute zero, resolve cols as percent & rows as
  <fantasai> NOTE: only for intrinsically-sized grids explicit /
                   stretch-fit grids always resolve
  <fantasai> Cons:
  <fantasai> A = contribution can explode grid
  <fantasai> B = unhappy authors with overflowing grids
  <fantasai> C = super broken
  <fantasai> D = unhappy authors missing % column-gap?
  <fantasai> E = even more broken
  <fantasai> F = B + D + asymmetrical

  [Rossen + florian discussing why A cannot be fixed (aka, see
      previous times this was discussed)]

  jensimmons: Using percentages for gaps for auto-sized things is not
  jensimmons: because they will see their gap change size when the
              content changes
  jensimmons: so they will realize this is not what they wanted
  fantasai: Yeah, I can see that happening, I'm getting convinced by D
            too now
  Rossen: Proposed resolution: gaps expressed in percentages resolved
          and layout-ed as 0 in auto-sized directions

  rachelandrew: There might be a few people that are going to hit this
                problem if they try to replace parts of an existing
                layout they cannot entirely control.
  fantasai: But this would apply to cases where the grid is
            shrinkwrapped, not to cases that have a definite
            containing block
  rachelandrew: Yes, but I don't know how common that would be
  iank: We are at 0.1% of all pages for grid all up
  iank: so I guess this case wouldn't be frequent at all once you
        consider it has to be also using percentage gaps, in a
        shrink-wrapped context
  Rossen: But the conversation is about porting content that currently
          uses percentages to grids
  Rossen: though I don't really see how they can achieve this today in
          a way that works in all browsers
  jensimmons: I think those cases are very fragile currently, they use
              margins/paddings on floats
  jensimmons: but in those cases usually, the container has a width,
              even if it is 100%
  rachelandrew: (general feeling of doubt, but I didn't catch the
                exact words)
  dholbert: So this would only happen about floated grids, and abspos
  dholbert: but in a flexbox, you are suppose to layout as having a
            definite size after flexing, so percentages would work
            there right?
  TabAtkins: Correct.

  [rachelandrew & jensimmons talking about author's work to port
      existing things, ex: new york times shipping grid inside

  Rossen: So, would your doubts be enough to raise an exception today?
  rachelandrew: No, I just wanted to shed some light on this, we can
                come back on this if needed
  Rossen: Any objection?

  RESOLVED: Option D: percentage gaps in shrink-wrapped grids
            contribute 0 and layout as 0.

Percentage tracks
  github: https://github.com/w3c/csswg-drafts/issues/1921

  lajava: To keep things symmetric, we tried to add cases to resolve
          percentages for height of rows
  lajava: But we don't have min-content phase in the block direction,
          like we do for width
  lajava: So we would need to duplicate a second pass to make this
  lajava: So 1st we would like this recorded clearly in the spec if
          that is required
  lajava: And all browsers would have to change their implementation.
  florian: And why not just follow what browsers already have
  Rossen: The change would be relatively straightforward, it's no big
  florian: But we would possibly break content, right?
  Rossen: Everything we do ends up breaking someone's content, I don't
          think this would be an issue here.
  lajava: Well, we are still unsure about what would happen in more
          complex cases like in orthogonal flows
  lajava: but at the very least it would require a second pass, once
          you know the intrinsic height.

  Rossen: Any opinion from Mozilla?
  Rossen: There is still time to fix, but window is closing.
  dholbert: I don't have a strong opinion, and Mats hasn't commented
            on the issue.
  dholbert: I don't like adding new layout steps usually.
  Rossen: But it's easy to know if you need to do it beforehand
  Rossen: only do it if you have percentage-sized row tracks.
  dholbert: But if it is an orthogonal flow, you have to re-layout
            entirely right?
  lajava: Yes, but this already happens anyway.

  Rossen: Any objection?

  RESOLVED: Percentage tracks sized as percentage resolve the same way
            for columns and rows, which involves a second layout pass
            in some cases.

"Equal Gutter" with justify-content
  github: https://github.com/w3c/csswg-drafts/issues/1116

  Request is for next level...
  fantasai: Users often want row-gaps and col-gaps to be equal
  fantasai: but they also want the horizontal gaps to fill the
            remaining space once you've put as many columns as
            possible in the width direction.
  fantasai: They can do that using justify-content
  fantasai: but they cannot transfer this size in the other direction.
  fantasai: This is basically a request for thoughts on the topic.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/1116#issuecomment-288472394
  <fantasai> Just to summarize, the example is
  <fantasai> definite width, auto height grid container
  <fantasai> auto-fill columns e.g. 100px
  <fantasai> auto-placed items
  <fantasai> place-content: space-between
  <fantasai> The spacing produced by space-between is not equal in
             both axes.

  jensimmons: So is the idea { row-gap: as-column-gap } ?
  TabAtkins: Pretty much.
  <leaverou> Possibly silly idea, but what if there was a unit for
             horizontal gap? Are fractions of that useful or only the
             whole horizontal gap?
  <TabAtkins> So far the only request is matching, but if fractions
              are desired later, our eventual solution for "put
              keywords in calc()" will handle that.

  (general discussion, but it was tough to minute)

  fantasai: The tricky thing is that two things control the gap size.
  fantasai: The gap property
  fantasai: and the alignment properties
  fantasai: you do have to consider both to get the desired effect
  fantasai: and there are interesting cases of space-evenly which
            creates a gap before the first column and after the last
            column, we will need to define what to do about that.
  <fantasai> the gap properties only distribute space between the
             columns, but alignment can do other things
  florian: And the proposed syntax would allow to also define
           alignment in the direction in which you said to copy.
  florian: I think we should have a more restrictive syntax that
           doesn't allow the impossible cases would be better
  florian: but I don't have a concrete proposal right now.

  jensimmons: Just to clarify, the alignment do not update the gap,
              they add a gutter right?
  fantasai: Yes, but visually it looks like the same thing.
  jensimmons: So it looks like we want something to transfer the
              gutter not the gap.
  dholbert: Maybe some align: symmetrical then?
  dholbert: Alignment properties already are allowed to increase a gap.
  dholbert: It would be possible to also shrink the gap to make it
            match, that doesn't sound unreasonable.
  <dholbert> Or possibly not shrink, but grow-or-leave-the-same (to
  <dholbert> *(to avoid violating author expectations that
             "grid-row-gap: 100px" should actually insert at least
             100px of space)
  Rossen: Alright, I think we should probably break out to lunch, and
          have people interested in this proposal talk with each other.

  Rossen: Let's get back here at 1:30

<br type=lunch>

Received on Tuesday, 5 December 2017 00:29:35 UTC