W3C home > Mailing lists > Public > www-style@w3.org > December 2017

[CSSWG] Minutes San Fransisco F2F 2017-11-06 Part I: Sizing [css-sizing]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 4 Dec 2017 19:28:09 -0500
Message-ID: <CADhPm3sCDa0Uj3p4EE6GyoX-WBNJSzKn3tEOm5CWWPOCkGMq9A@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - RESOLVED: When finding the min-content size of a replaced element
              with no intrinsic size, if there is a specified min-width
              or min-height use that rather than 300px/150px.
              (Adjusting a previous resolution on issue #951:
              https://github.com/w3c/csswg-drafts/issues/951 )
  - RESOLVED: Add textarea content-based sizing to Sizing L4.
  - TabAtkins will add auto sizing of iframes into the WICG, since
      there are complexities involving interaction with media queries,
      security, and layout engine architectures that need to be worked
      out in detail, and solutions might involve non-CSS technology (
      HTML, HTTP).
  - RESOLVED: Don't remove stretch / fit-content from min-width/height.
  - Discussed the proposal to address issue #1865,
      Intrinsic size of 'overflow: auto/scroll' and its impact on
      auto-sized grid/flex item ancestors:
  - RESOLVED: Pending approval from dbaron, the group accepts the
              proposed text to define which replaced elements are
              affected by width: % rule zeroing min-content
              with an addendum to add "button-like" things to the list.
  - RESOLVED: Move definition of the min-width:auto keyword to Sizing.
  - RESOLVED: Move the box-sizing property from UI 4 to Sizing.


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

  Rachel Andrew, Invited Expert
  Rossen Atanassov, Microsoft
  L. David Baron, Mozilla
  Christian Biesinger, Google
  Tantek Çelik, Mozilla
  Dave Cramer, Hachette Livre
  Emil Eklund, Google
  Elika Etemad, Invited Expert
  Javier Fernandez, Igalia
  Rob Flack, Google
  Simon Fraser, Apple
  Chris Harrelson, Google
  Daniel Holbert, Mozilla
  Jihye Hong, LGE
  Koji Ishii, Google
  Brian Kardell, JS Foundation
  Brad Kemper, Invited Expert
  Ian Kilpatrick, Google
  Tomoya Kimura, VOYAGER Japan
  Vladimir Levantovsky, Monotype
  Chris Lilley, W3C
  Peter Linss, Invited Expert
  Myles Maxfield, Apple
  Xidorn Quan, Mozilla
  Simon Pieters, Invted Expert
  Naina Raisinghani, Google
  François Remy, Microsoft
  Melanie Richards, Microsoft
  Florian Rivoal, Vivliostyle
  Alan Stearns, Adobe
  Surma, Google
  Dave Tapuska, Google
  Lea Verou, Invited Expert
  Jet Villegas, Mozilla
  Greg Whitworth, Microsoft
  Eric Willigers, Google

Scribe: gregwhitworth


max-content size of percentage-sized replaced elements
  github: https://github.com/w3c/csswg-drafts/issues/1722

  Rossen: max-content size of replaced elements
  fantasai: We discussed what to do with replaced elements that is
            percentage sized that has an intrinsic aspect ratio.
  fantasai: *gives an example*
  fantasai: If there is a specified min-width or min-height use that
            rather than the intrinsic aspect ratio in that dimension.
  dbaron: The effect that that would have is that if your min-width or
          min-height is smaller than the intrinsic size in that
          direction then you use that.
  dholbert: If it's not min-width/height of auto?
  fantasai: Yes.
  dbaron: What you're saying is if min-width/height are non-auto you'd
          use them in the aspect ratio?
  fantasai: Yes.

  dbaron: There are some weird interactions around this.
  dbaron: It seems worth trying.
  dbaron: I think someone should try it before committing.
  dbaron: I'm worried about web compat.
  fantasai: This scenario is not a very common case.
  fantasai: I don't know why you'd be doing this.
  dbaron: The main case I can think of is SVG.
  Rossen: Currently that will work.
  dholbert: In FF that doesn't work.
  fantasai: So it isn't interoperable right now
  fantasai: so...
  fantasai: let's give it a try.
  dbaron: Put it into the spec with the note to provide feedback.

  tantek: We're changing a resolution right?
  fantasai: Right, from a few months ago.
  tantek: I'm worried about back compat.
  tantek: They may have implemented.
  fantasai: They haven't, that's the point.
  * dholbert thinks the resolution from a few months ago was in
  <dholbert> Firefox bug related to this is
  <AmeliaBR> There are some examples in this pen, if you want to look
             at current behavior: https://codepen.io/AmeliaBR/pen/brdBvQ
  <tantek> thank you AmeliaBR !
  tantek: When we had box sizing for SVG things we had all kinds of
          interop issues.

  Rossen: who's going to write the test cases.
  Rossen: I hear some concerns about compat
  Rossen: but also given the fact there is no interop on the issue
          then we should resolve on something that makes more sense.
  Rossen: any objections?
  <tantek> no objection, now that we have a test case to check impls

  Rossen: resolved
  Rossen: Please bring the test cases forward when you start working
          on the actual text.

  RESOLVED: If there is a specified min-width or min-height use that
            rather than the intrinsic aspect ratio in that dimension.

Auto resizing of iframes and textarea based on content size
  github: https://github.com/w3c/csswg-drafts/issues/1771

  TabAtkins: There have been many requests for textarea and iframes
             resize on content.
  TabAtkins: We talked it over and thought, yeah probably ok.
  TabAtkins: We started experimenting with this.
  TabAtkins: figure our some mechanism content based sizing for
             textarea and iframes
  TabAtkins: We learned some issues implementing seamless with iframes
             due to COR leaking information.
  TabAtkins: We suspect we'd walk up the frame tree until we hit a
             fixed size to resolve the MQs.
  TabAtkins: Someone from Mozilla implemented this.
  <tantek> would really like this as a content author
  <tantek> for iframes in particular
  <tantek> The iframe use-case for me is known width (set by
           container), auto (preferably auto-expanding) height

  dbaron: We got the spec to say that's how media queries work, but
          seamless was removed.
  dbaron: We have code for it - but it's not necessarily something you
          can write up in a spec.
  dbaron: You need to figure out how to spec it, it does some very
          interesting things.
  iank: What type of interesting things?
  dbaron: I'd need to look, like it tries to do layout, and then tries
  Rossen: We used to have a technology that would allow you to do
          layout based on then content size and we killed it
  Rossen: performance becomes a concern for those.
  Rossen: When you consider extensions they try to size the box, and
          it's shrink to fit it becomes very bad for perf.
  Rossen: Our experimentation for this suggests it was bad, but maybe
          you'll find something.
  TabAtkins: They're both pretty separate features anyways.

  TabAtkins: Are we ok experimenting in this space?
  TabAtkins: The textarea would go into sizing 4.

  smfr: We've had the auto sizing of the iframe, even cross-origin.
  smfr: It makes your frame layout outside in rather than inside out.
  smfr: We've had quite a few media query bugs.
  smfr: We ran into media query cycles.
  TabAtkins: That means that you weren't doing media queries the way
             we defined.
  smfr: It does bring about nasty things in the code.
  TabAtkins: How is this different from regular layout
  smfr: You can avoid laying out the iframe, if you have to you have
        to dirty the other nodes.
  TabAtkins: ok, let's talk about this later.

  dbaron: I think the media query problems you had were due to doing
          what authors weren't expecting.
  TabAtkins: This would be opt in.
  tantek: How do you trigger behavior in iOS?
  smfr: You always get it.
  smfr: Users don't experience nested scrollers, we always wanted page
        scrolling to win so you don't get trapped.
  tantek: Width is expected and height is auto.
  smfr: Yes.

  Rossen: ok, so - it seems that Google wants to experiment with this
          - Apple has it and wants to remove it
  Rossen: Do you want a resolution?
  TabAtkins: The textarea one is simple enough to go into sizing 4.
  TabAtkins: The iframe one can go in WICG.
  Rossen: Any objections to adding textareas to CSS Sizing L3?
  fantasai: Yes.
  TabAtkins: I said 4.
  Rossen: Ok, L4.
  fantasai: ok - I'm ok with that.
  fantasai: we can add a note for L3 that this is upcoming
  Rossen: Changes to sizing L4.

  RESOLVED: Add textarea sizing to Sizing L4

  *discuss whether to do in WICG*
  *TabAtkins to spin up a WICG regarding auto sizing of iframes*
  <tantek> I'm a bit surprised that we're not even putting into a WD
           something that's been shipping in iOS for 10 years

Restricting stretch and fit-content to width and height
  github: https://github.com/w3c/csswg-drafts/issues/1913

  TabAtkins: I missed the telecon.
  dbaron: I'm a bit hesitant as it exposes primitives to the system
          but yeah you can't use it over here.
  dbaron: I don't feel that strongly though.
  TabAtkins: We didn't feel that strongly either but it felt like more
             effort than warranted.
  TabAtkins: We use min in weird ways, fit-content especially
  fantasai: It's fine but we couldn't figure out how to use the
            stretch as a minimum
  fantasai: Question was, Do we need this?
  fantasai: If we don't we don't need to put the effort in for testing

  Rossen: So do we keep it?
  florian: Do authors have any opinions?

  jensimmons: fantasai can you explain what this is?
  fantasai: Would you ever use min-width or min-height of 100%, it
            does effectively that.
  jensimmons: I'm sure people do use that.
  fantasai: If that seems like a reasonable thing to use.
  <gsnedders> I've definitely used min-height: 100%; height: 0; in
              some cases.
  cbiesinger: Seems useful, might want to fill a screen but grow if
              more content.

  dbaron: The other question is would you want to use them inside a
          calc() expression for min-width and min-height.
  jensimmons: I am hesitant to remove it

  RESOLVED: Keep them as they are in the spec (don't remove them)

Intrinsic size of 'overflow: auto/scroll' and its impact on auto-sized
    grid/flex item ancestors
  github: https://github.com/w3c/csswg-drafts/issues/1865

  fantasai: Grid and flexbox show this issue, where people have an
            element with a scrollbar and they put it among a whole
            bunch of other content
  fantasai: It forces that has a min-content size which defeats the
            purpose of the scrolling the author defined
  fantasai: this leads to a lot of confusion for authors
  fantasai: They're already handling their overflow and it would be
            nice if they just worked
  fantasai: Filed this issue to allow us to come up with a way
            for this to work as expected.

  fantasai: I was talking with cbiesinger on Saturday, thought about
            having the min-content zero'd out on scroll containers
  fantasai: The min-content contribution which has overflow be 0, but
            not the logical height since that would require re-layout
            of all surrounding content to determine the min and max
  fantasai: it's an idea, we're looking for other ideas also.

  dbaron: The thing with overflow that is not visible the size is the
          content within it, it has to propagate through it if it's
          the only thing.
  dbaron: I tend to think, that there is not going to be a thing that
          we can do to solve this with a property that allows them to
          choose the thing that they want.
  dbaron: I think there are two different scopes.
      1. intrinsic control intrinsic width that has overflow
      2. properties that allow assignment to the intrinsic widths
  dbaron: The advantage of the first one is it gives more room for
          auto behaviors that do the right thing
  dbaron: The advantage of the second is it is strictly more powerful

  fremy: I wanted to note that we had a similar issue in the table
  fremy: If you have a % height and you're overflowing in a non
         visible way we should resolve to 0
  fremy: the author intent is pretty clear here
  fremy: To me this makes sense and is generalized
  fantasai: For grid and flex items specifically the automatic minimum
            size is not triggered on items that are overflow !=
            visible, but their content still does impact the
            min-content contribution.
  cbiesinger: You said that the single items need the content
              contribution to propagate through.
  dbaron: Because people will use 'overflow: hidden' to hide things
          rather than scroll it.
  fantasai: That's a good point

  dbaron: You're talking about zeroing out the min-content sizes.
  <fremy> @dbaron: overflow hidden is excluded in tables, only
  fantasai: Yeah, just the min-content size.
  dbaron: Presumably the min-content sizes don't matter.

  cbiesinger: For the min size of flex and grid would make it zero in
              this cases.
  dbaron: In many cases you want them to get smaller but not to 0
  fantasai: A lot of the cases that are here the minimum would be
            controlled by other content that happens to be there
  fantasai: If they don't want it to get to 0 they can set a min size
            on the flex or grid item, or on the scroller itself
  <fantasai> This is more understandable than having a scrollable
             descendant of a grid or flex item several layers deep in
             a subsection of a subsection cause the flex/grid item's
             width to explode out

  dbaron: The other thing I worry about here is compat.
  cbiesinger: That is concerning.
  dholbert: Chrome already does this correct?
  cbiesinger: I don't think we do that, but we do is for nested column
              flexboxes we don't give it a min-height.
  dholbert: I thought there was something there for overflow: scroll.
  cbiesinger: I'd need to look at it.

  <fantasai> Proposal in two parts:
  <fantasai> 1 flex/grid items with overflow != visible | hidden have
               min-content contribution of zero
  <fantasai> 2 inline dimension of block with overflow != visible |
               hidden has min-content contribution of zero

  Rossen: I read through the post about this issue, but I'd want more
          use cases for this. I am not going to object, but there will
          be compat issues for this.
  Rossen: dbaron any objections?
  dbaron: I wouldn't object, but I'd like to discuss the compat
  Rossen: We can discuss this on the side - let's not rush the
  dbaron: I would be hesitant to come up with something too magical.
  Rossen: Unless there is something else to be discussed.

Define which replaced elements are affected by width: % rule zeroing
  github: https://github.com/w3c/csswg-drafts/issues/1889

  fantasai: We would like to resolve on this issue.
  fantasai: We would want dbaron's approval though.
  <astearns> text is:
  <fantasai> https://drafts.csswg.org/css-sizing-3/#min-content-zero
  <Rossen> elements include: select, textarea, progress, meter.
  *explains commit up above*

  fremy: The only one I can think of is input type="color" as I think
         most browsers implement it as a button.
  fantasai: These are things that the min-content contribution is
            going to be zero'd out if a percentage is used on there.
  fremy: I think for us it's just easier to add color to this.
  dholbert: Same for us.
  fantasai: For things that need to remain for UX, you might want to
            reserve some amount of that space, the exception list
            should include button.
  fantasai: The button gets its size from the content.
  Rossen: What fremy is advocating for is so that input type color
          doesn't disappear.
  TabAtkins: We can say some spec language to allow anything that's
             like a button.
  Rossen: In our case it's just a button that has the swatch.
  fantasai: That makes it so that you can't go down to zero and would
            loose the swatch?
  Rossen: Yes, which defeats the point.
  fantasai: That is the same with the text input you can go down to 0
            and can't type.
  Rossen: What is the push back on including color.
  fantasai: Maybe it's that is tied to a button.
  TabAtkins: That's why I suggested "button like".
  TabAtkins: Everything that looks like a button.
  Rossen: Are you ok with this?
  fantasai: Yeah.

  Rossen: With the amended button like to the list, any objections?
  Rossen: ok resolved, pending dbaron opinion.

  *break 15 minutes*

Moving min-width/height partial definitions to Sizing
  Scribe: TabAtkins
  github: https://github.com/w3c/csswg-drafts/issues/1920

  fantasai: Oriol pointed out the Flexbox isn't the best place to
            define a new initial value for min-width/height.
  fantasai: Suggested it move to the Sizing spec. Makes sense to me.
  fantasai: Definition of what automatic size means in Flexbox will
            stay, but move the propdef table that defines the keyword
            to Sizing.
  Rossen: Sounds reasonable.

  RESOLVED: Move definition of the min-width:auto keyword to Sizing.

Move box-sizing to Sizing
  github: https://github.com/w3c/csswg-drafts/issues/1906

  florian: Width and height are defined in 2.1. Box-sizing is defined
           in UI as a monkey-patch on that.
  florian: Works, but is ugly.
  florian: Now that UI is getting to Rec, it's about time we get that
           into a spec of its own.
  florian: So we should take what's in 2.1, apply the box-sizing
           patch, and put it into a spec, probably Sizing.
  florian: Also need to make sure it work for logical/etc.
  florian: So Sizing 4 looks like a good place to have it.

  Rossen: This is in UI3, already tested, right?
  <tantek> Yes
  florian: Right, it's in UI3, and staying there as it goes to Rec.
           It's only in there, tho, because 15 years ago we thought UI
           would be the first to hit Rec. Turns out to have been true,
           but there are better places for it.
  fantasai: Happy to pull in the monkey patch, hesitant to pull in all
            of 2.1...
  Rossen: No need to dive into details, just about moving box-sizing
          from UI4 to Sizing.

  RESOLVED: Move the box-sizing property from UI 4 to Sizing.
Received on Tuesday, 5 December 2017 00:29:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:04 UTC