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

[CSSWG] Minutes Seattle F2F 2017-01-13 Part II: Scrolling, Sizing [css-overflow] [css-sizing]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 13 Feb 2017 21:32:09 -0500
Message-ID: <CADhPm3v0ORLjc0-MiKNFH91K35hmpF_bJkpuoU94H4T2ZfZ48w@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.


  - The group revisited scrollers and overflow now that they could
      draw out visual aids.
  - To help understand the problem, they created a grid of the
      current values of 'overflow' (scroll, auto, hidden) and
      behavior groups desired (auto=current, always, stable).
  - RESOLVED: scrollbar-gutter is a new property independent of
  - RESOLVED: Values are auto | stable | always, potentially
              with a rename for always if it becomes an issue in
              later discussion on hidden/visible.
  - RESOLVED: Add the 'force' keyword to apply gutter even when
              overflow is not scroll/auto. (But bikeshed the name.)
  - RESOLVED: Add 'both' as an optional keyword: gutter is applied to
              both sides of element (for cases that desire symmetry).
  - RESOLVED: 'both' will only affect the block direction.


  - RESOLVED: Add width/height:contain to Sizing 4 for review.
  - RESOLVED: Change "width: fill" to "width: stretch".
  - RESOLVED: Treat min/max-content keywords as "auto" in the block
  - RESOLVED: Treat fit-content that way, too.
  - The authors will rename "fill-available sizing" to "stretch


Agenda: https://wiki.csswg.org/planning/seattle-2017

Scribe: gregwhitworth


  Rossen: Looking at next issues.
  Rossen: Who added scrolling?
  Rossen: [Lists off issues]
  Florian: I added the overflow thing.
  astearns: The other was discussed on a telecon and it was deferred
            to the f2f.

Overflow: Consider reserving space for scrollbars with some property

  <Rossen> https://github.com/w3c/csswg-drafts/issues/92
  Florian: This is the overflow gutter and overflow overlay issue.
  Florian: Does everyone remember what this is about?
  Rossen: I think we should draw them out.
  Rossen: I can draw them.

  Florian: So, this is about overflow: auto
  Florian: it doesn't always do what you want.
  Florian: There are two sets to consider:
  Florian: some browsers have overlay scrollbars
  Florian: some browsers have scrollbars that consume space.
  Florian: If you put something into overflow: auto and the
           scrollbar consumes space will appear.
  Florian: In browsers that have overlay, it doesn't change the
           amount of space that is available for the content.
  Florian: In browsers that have scrollers that consume space, even
           though I'm not overflowing please consume the space
  Florian: Basically, I know what size I want for my content, just
           give me a gutter.
  Florian: The one we have today is we have always consuming space.
  fantasai: I thought that was the first one.

  Rossen: [shows whiteboard picture]
  [picture of whiteboard at end of discussion:
  Rossen: You have the border, then some padding, and then the
          content box
  Rossen: if this box has overflow: auto.
  Rossen: When the content reaches this boundary, the scrollbar is
          currently defined to go between the outer padding edge and
          the inner border edge.
  Rossen: In order to do this we take space out of the content width
          or height
  Rossen: this caused a new reflow.
  Rossen: In the case of overflow: overlay it may still be 17px wide
          but it takes no layout space in the box model.
  Rossen: Of course the drawback of this is that if you don't have
          padding the scroller is overlapping your content.
  Rossen: One of the proposals is to control the space that is where
          the scroller is.

  Florian: We had agreed on 3 behaviors:
  Florian: 1 being what we have today-
  Florian: always reserving that space in browsers that don't have
  dbaron: How much do you consume if you have overlay?
  Florian: The size of the scrollbar widget that is displayed.
  Rossen: Is this defined by UA?
  Florian: Yes.
  Florian: Yes, this is UA defined.
  Rossen: So this isn't exposed to the user?
  smfr: On mac it's a bit more magical, it's in a skinny state and
        then when you mouse over it's a fat state.
  smfr: Probably need to leave it up to the UA.
  Florian: You could potentially use the unit for other things.
  zcorpan: The use case for the scrollbar unit and this sets to get
           two boxes the same size.
  fantasai: If you preserve the space and overflow: auto you'll
            never get the scrollbar.
  fantasai: This solves that use case.
  Florian: Depending on the property that we solve that with, there
           is an overflow: auto but it doesn't show a scroll bar.
  Florian: If you want an overflow: auto and it will scroll but it
           won't show a scroll bar.
  Florian: I'm just mentioning it

  fantasai: And if you don't have a touch interface and need a
            scrollbar to scroll?
  smfr: I drew this just to clarify this.
  smfr: For overflow: scroll we already preserve space even if it's
        not scrollable.
  smfr: This is asking the question when does the UA preserve space.
  smfr: If you're overflow: auto it only shows when overflow, if
        you're not overflowing do you preserve space.
  Rossen: For your proposal I think it's the opposite.
  Rossen: You need one more column which is for the proposal.
  Florian: We haven't resolved if this is a new prop or unit.
  Rossen: Sure, but let's add a column for it to show the usecase.
  smfr: Does this new property ever preserve space if the scrollbar
        isn't being shown.
  fantasai: I thought that was the whole point.
  Rossen: Yes, you should preserve the space whether you're showing
          it or not.
  Florian: There is the three behaviors we've stated.

  dbaron: Also there's scroll that always preserves space even if
          you have overlay scrollbars.
  esprehn: Overlay is 0 size.
  esprehn: What's missing from this is the unit that is the size of
           the scrollbar.
  fantasai: We already discussed this.
  fantasai: This is too abstract
  Florian: That's what this table is for but it isn't complete.
  esprehn: You're wanting to take space that takes the space of the
  Florian: Yes, if you use a unit it also can be used everywhere.
  Florian: If you're in a browser that has a scrollbar, consume the
  esprehn: Authors normally just preserve the space.

  Rossen: Florian, I think this is correct, smfr please correct me
          if you can:
  Rossen: The UA will reserve space when the scrollbar is needed.
  Rossen: If you don't have an overflow you don't reserve space.
  Rossen: In the case of overlay scrollers nothing is reserved.
  Rossen: The feature that is being reserved, it will reserve it no
          matter when the overlay scrollers come out.
  Rossen: For hidden, we don't reserve for anything.
  smfr: One question is whether we need different behaviors for
        overflowing, not overflowing, for overflow:auto.
  fantasai: You need a third column for on an overlay scrollbar you
            don't reserve the space.
  Florian: [drawing an additional column]

  [Table Description (from fantasai):
      There are three rows for the three values of 'overflow'
           (scroll, auto, hidden)
      There are 3 column groups:
           B1 (current behavior aka auto), B2 (always), B3 (stable)
      Each column group is split into columns for
          "scrollbars that take up space" and "overlay scrollbars"
      For B1 (auto), space-consuming: scroll=reserve,
      For B1 (auto), overlay: scroll=0, auto=0, hidden=0
      For B2 (always), scroll=reserve, auto=reserve, hidden=?
      For B3 (stable), space-consuming: scroll=reserve, auto=reserve, hidden=?
      For B3 (stable), overlay: scroll=0, auto=0, hidden=?
                    auto        ||      always      ||     stable
               spaced | overlay || spaced = overlay ||  spaced | overlay
  'scroll' |  reserve |   zero  ||     reserve      || reserve |   zero
  'auto'   |r if need |   zero  ||     reserve      || reserve |   zero
  'hidden' |    zero  |   zero  ||        ?         ||    ?    |    ?
  [picture of whiteboard at end of discussion:

  Florian: The last time we discussed this we agreed on having these
           three - but we didn't agree on what triggers it:
  <Florian> https://github.com/w3c/csswg-drafts/issues/92#issuecomment-251727301
    Syntax proposals were:
      #1 scrollbar-gutter: auto | stable | always
      #2 overflow-gutter: auto | stable | always (longhand of
      #3 overflow: visible | hidden | scroll | auto [stable |
  Florian: This references the three syntax we have proposed.
  Florian: 1 was a completely independent property scrollbar-gutter:
           auto | stable | always
  Florian: I think the last time we discussed this we didn't discuss
           overflow: scroll we only discussed auto.
  fantasai: There are a lot of questions here.

  Rossen: Can we discuss this for overflow-style?
  fantasai: We renamed -style to -gutter.
  Florian: That's how far we went.

  smfr: I have a strong preference for the scrollbar-gutter property
        because the others will cause author confusion.
  fantasai: A more important problem is that the prop cascades and
            inherits independently.
  fantasai: For that reason number 1 is the best option.

  Rossen: For number 1 what does that mean for visible as well?
  Florian: For visible they do nothing.
  Rossen: Then for hidden they do nothing.
  Rossen: They should be the same.
  Rossen: The reason I'm saying this, for people that do their own
          scrollbar they will use the property to set hidden to
          preserve space and then scroll the content.

  fantasai: First let's resolve on that first question.
  fantasai: Do we accept option number 1?
  Rossen: Before we do this, the third option went a little bit
  Florian: It is not a new property, but it becomes an optional
           keyword on the auto keyword.
  Rossen: Which means you can't use it for hidden, visible or scroll
  Rossen: so this breaks the usecase I just suggested.
  Florian: Also what fantasai was saying, they don't cascade
  Bert: Using the word scrollbar in the property helps explain what
        it does, the others aren't as intuitive: what happens when
        the scrolling mechanism doesn't look like a scrollbar.
  Rossen: That's another good feedback in favor of 1.

  fremy: I want to come back to what esprehn and gregwhitworth said
         is the unit so that the author can control it.
  fremy: There is the space that you as the UA should preserve and a
         new unit to get either option.
  Rossen: It would need to be a calc(padding + Nsw).
  fremy: It allows people to use the unit where we don't want people
         to use it.
  smfr: We also need to think about horizontal scrollbar.
  smfr: We have various scrollers so I don't want to have multiple
        units for each.
  myles: We have an API function that will change if we put it on
         the left for RTL or not so to have the authors to define
         this would be very hard.
  Rossen: We have the same behavior as well.
  dbaron: For us it depends on the situation, it changes for the
          viewport and the iframes, etc
  Rossen: Is this really a problem with #1? - only with the unit.

  smfr: I wanted a clarification, but we can come back to that.
  zcorpan: Florian says that a unit allows authors allow for things
           that we don't know of, but the gutter doesn't take into
           account designers.
  zcorpan: ... they sometimes want to reserve the space on both
  esprehn: And designers want to get the size and match them to a
           grid to make them symmetrical and they use hacks to make
           it happen.
  smfr: I think it's somewhat orthogonal.
  esprehn: I think having the gutter and making it symmetric is
           possible, that would be good

  dbaron: The thing I wanted to bring up - do we want
          scrollbar-gutter to be an inherited property?
  dbaron: I was leaning against but I don't feel strongly.
  fantasai: I think it should be.
  Rossen: We don't inherit overflow.
  Rossen: If I have a bunch of divs, one inside the other, what do I
  Florian: That depends.
  Rossen: Even if it's on scroll, I'm squeezing the content because
          I want to preserve space on the first one.
  Rossen: I lean against inheritance.
  fantasai: The benefit is to allow you to not have to reset it on
            every scroller. At that point you might as well have it
            be an overflow keyword.
  fantasai: You need to be able to set scrollbar-gutter on the
            entire page at once.
  fantasai: Once it's set it should not have an effect on something
            that is not a scroller.
  fantasai: As far as inheritance vs universal selector, universal
            selector will jump through scopes.
  fantasai: Inheritance allows you to have different behaviors. But
            I could go either way.
  <zcorpan> fantasai+
  <zcorpan> using universal selector in the common case indicates a
            design failure

  Rossen: To move forward, let's resolve on... I hope everyone
          understands the feature and the need for it...
  Rossen: can we resolve on getting the scrollbar-gutter property?
  Rossen: Any objections?

  RESOLVED: scrollbar-gutter is a new property

  Rossen: Now let's move on to the set of values.
  Rossen: We have to decide if we want symmetric or not.
  smfr: There is a case that doesn't change between overflow and not
        overflowing please show a space.
  Rossen: What is it that you want to do.
  smfr: They want to preserve space no matter if the overlay
        scrollbar is there.
  smfr: If there is an overlay scrollbar please preserve space.
  Rossen: That's stable.
  Florian: What he wants is unstable.
  dbaron: I think he said two different things.
  smfr: With overlay scrollbars, they may want a value if the UA
        will preserve space if the UA will show an overlay scroller.
  Rossen: You want to counteract the overlayness
  Rossen: that will cause layouts.
  dbaron: It feels like what Simon wants is to treat overlay
          scrollbars as a completely different access.
  dbaron: Maybe that calls for a separate control for whether
          overlay scrollbars should be treated as taking up space.
  Rossen: Let's try with adding auto.

  fantasai: Let's resolve on the initial three.
  dbaron: That may raise the question of "always" vs "really-always".
  Rossen: It sounds like the only one we can resolve on is auto.
  smfr: What does auto do?
  TabAtkins: I'm not resolving on one value.
  Florian: How about stable, most people agree with stable.
  gsnedders: Can we resolve on stable and always and just put a note
             to bikeshed the name?
  fantasai: I'm ok with that.
  Rossen: It doesn't sound like we're ready.
  Rossen: What does always do?
  Rossen: No objections, let's add always

  RESOLVED: Values are auto | stable | always, potentially with a
            rename for always if it becomes an issue in later
            discussion on hidden/visible

  <break type=lunch>

  Florian: So we had to resolve with the three values but a better
           name for always.
  Florian: We haven't resolved on what b2/always do.
  Florian: The natural answer is that they do nothing
  Florian: but
  Florian: there is a gmail problem.
  Florian: This is the gmail UI:
  Florian: there is scrollbar on the right and it's always.
  Florian: Right above it you have a toolbar, and you want to align
           the UI with the other content which is pushed in by the
  Florian: One way to solve this is to have always apply to
           overflow: visible
  Florian: but this is bad on a lot of other areas
  Florian: but we probably shouldn't change the current setup.
  smfr: You shouldn't use units though because of the RTL arguments.
  Florian: In gmail's case they have scrollers on both sides, so
           that isn't an issue - but that isn't always the case.
  Florian: One way to solve this is by adding a keyword in
           combination and how it works for this usecase.
  Florian: For this keyword I suggest force.
  Florian: Always can be reserve.
  <fantasai> the proposal is that we fill in hidden/visible/clip
             with 0 for the general case and with a copy of the
             'overflow: auto' value if the optional keyword 'force'
             is present.

  smfr: You still have the inheritance problem right?
  Florian: Yes, but don't put "always force" on the entire page

  Florian: So do people like force?
  Florian: Thoughts?
  Rossen: I'm not crazy about the name.
  smfr: Do we have more use cases, we have one but does this need to
        be l1?
  fantasai: I think so.
  Rossen: This will eliminate the need for force.
  Florian: No, this is just showing when force will reserve and it

  Florian: Is this resolved?
  Florian: The behavior and the name, or separately.
  esprehn: The name isn't great, but the behavior is fine.
  Rossen: Any objections to adding the force optional keyword for
          hidden and visible?
  tantek: This is just for the gutter?
  Florian: Yes.
  tantek: Then why not just gutter?
  Rossen: So you'll have something like scrollbar-gutter: gutter.
  tantek: I just tend to dislike generic keywords like force.
  tantek: We should re-bikeshed on the force name.
  Rossen: That's in agreement.

  RESOLVED: Add the force keyword but bikeshed on the name

  smfr: scrollbar-gutter: force would add gutters to all elements
  Florian: No that is when using always force.
  Rossen: If I have in my case, rather than taking space from the
          content it will keep adding space-
  Rossen: it takes width away from the box.
  fantasai: Yes.
  Florian: It just takes space away from the scrollbar not how you
           go it.
  Rossen: Any objections to both?

  RESOLVED: Add both as an optional keyword: gutter is applied to
            both sides of element (for symmetry).

  Florian: Now that we have overflow-x and overflow-y do we want a
           different behavior there?
  Rossen: Can't that work automatically.
  Florian: If you do overflow: auto or hidden at the bottom, but
           this on the side - you don't need this.
  Florian: I put scrollers on both sides, and try not to overflow.
  Rossen: That's what you do because you're trying to follow good
  fantasai: We don't want to forbid this just to get this effect to
            work properly.
  Florian: Proposal, turn this into a shorthand and add x and y.
  fremy: Do we need logical props?
  fantasai: Yes.
  fantasai: It's either that or we only do this in the block axis.
  Rossen: That's not going to work.
  Florian: No one's thrilled with this, but what else do we do?

  Rossen: Would you use it for anything other than block, seriously?
  Florian: Yes.
  Rossen: When would you want the symmetrical in the vertical axis?
  Florian: jensimmons please help!!!
  Florian: You have a multicol that may overflow
  Florian: and you want to preserve the space.
  Rossen: But why would you want the symmetrical.
  Florian: Not sure about both.
  Rossen: So it's already not working out for horizontal.
  esprehn: The use case I can think of is like a dialog is you want
           the same space all the way around the box and you don't
           want the content to shrink.
  Rossen: You have padding.
  Rossen: [not impressed]

  Florian: I think there may be needs for inline.
  Florian: I agree most use cases are block.
  Rossen: We can make it a long hand later if enough demand calls
          for it.
  Florian: So if it's a shorthand you'd omit the keywords.
  philipwalton: Isn't that inconsistent with how overflow works?
  Florian: Yes.
  philipwalton: That seems confusing.
  Florian: The day that we solve this is by making the syntax for
           both, and the omitted one will mean auto.
  <philipwalton> the majority use case for both is
                 scrollbar-gutter-y: both and scrollbar-gutter-x:

  fantasai: Having it default to the block makes sense.
  fantasai: When you have multiple keywords we allow you to re-order
            them arbitrarily.
  Florian: We can put a comma or slash in between them.
  TabAtkins: Slash is the appropriate one here.
  Florian: We'll put some kind of separator when we get to that
  Florian: I've never been a big fan of x/y doesn't make much sense.

  Rossen: Do we need a resolution?
  Florian: We need a resolution that it applies to the block
           direction only.
  philipwalton: I think we should do both.
  TabAtkins: Yeah.
  Rossen: It's easier to add than remove.
  TabAtkins: esprehn gave an example.
  philipwalton: I'd hate to have a confusing long hand later.
  Rossen: I have a feeling that we may add it sooner than later.
  Florian: I think it's good that if you only specify it once it
           only applies in the block direction.
  Florian: I don't care either way.
  Rossen: I could go either way.
  philipwalton: My objection was only contingent was the single
                applying to both.
  philipwalton: If everyone is ok with inconsistency with overflow
                then I'm ok with that.

  RESOLVED: both will only affect the block direction

  Florian: Behavior number 4
  astearns: Can we do this later?
  Florian: Yes.

  myles: We've been talking this whole time about layout, you have
         to paint something in this - do you just paint what you
         would paint in the padding box?
  TabAtkins: Imagine your scrollbar is not there, that's what you
  myles: Imagine I adjust it in script, you'll get more padding
         visually to the end user.

Scroll bounding behavior
  Scribe: fantasai

  <smfr> https://github.com/w3c/csswg-drafts/issues/769
  smfr: I think we need some discussion here.
  smfr: There are differences between being in the beginning/middle/
        end of a gesture.
  smfr: UAs have different latching behavior.
  gregwhitworth: I'd like Matt Rakow to be involved here.
  TabAtkins: Should have a proposal for this.

  Scribe: TabAtkins

  fantasai: Continuing from morning, do we want to add width:
            contain to the spec?
  dbaron: Want to see a more solid proposal for it first.
  <dbaron> (given that you were talking about putting it in a draft
           that's about ready for CR)
  fantasai: So maybe add it to 4, we can pull it down if it's
            miraculously stable.
  jensimmons: Just don't punt it too far?
  gregwhitworth: Would be helpful to then gather more interest.
  fantasai: We have an ED of level 4 for the purpose of defining
            intrinsic sizes already.
  fantasai: We can add to that.
  fantasai: Intrinsic sizing was taking a long time; we just punted
            it out and deferred to CSS 2.1 (left it mostly
            undefined, but no worse than status quo).
  astearns: So proposal is to add width:contain to Sizing 4 for

  RESOLVED: Add width/height:contain to Sizing 4 for review.

  fantasai: Request from jensimmons to rename "fill" keyword to
            "stretch", to tie it into the stretch keyword in
  jensimmons: Like it. "stretch" seems more obvious than fit/fill.
  astearns: Is "fill" implemented?
  fantasai: Think so, but looks like no wild usage yet.
  dbaron: We have it implemented prefixed.
  astearns: Any concern with changing "fill" to "stretch"?

  RESOLVED: Change "width: fill" to "width: stretch".

  <gregwhitworth> dbaron fantasai -moz-fill-available was not seen
                  on any of the 800K sites we crawled
  <gregwhitworth> dbaron fantasai for perspective:
                  -moz-control-character-visibility was used 166
  <gregwhitworth> it's important to note that this ensures that the
                  element is on the page, not just parsed
  <dbaron> gregwhitworth, sorry, it's just -moz-available, not
  <gregwhitworth> dbaron: my only -moz prop that has an a is
                  -moz-appearance - so that -moz-available isn't
                  there as well

Intrinsic size of replaced elements incorrect

  <fantasai> https://github.com/w3c/csswg-drafts/issues/794
  fantasai: About max-content and min-content keywords.
  fantasai: And whether they should be sensitive to the aspect ratio.
  fantasai: fit-content is "shrink-to-fit sizing". It operates as a
            min/max formula that takes in min/max size, and a
            constraint (usually containing block).
  <TabAtkins> min-content and max-content represent the extremes of
              fit-content sizing.
  <TabAtkins> min-content is size with maximum soft wraps (longest
              unbreakble content), while max-content is size with no
              soft wraps.
  fantasai: Images have just one size, no text.
  fantasai: But they have an aspect ratio.
  fantasai: So if I have a floated image, and I set the height, it
            transfers thru the aspect ratio and affects the width.
  fantasai: We wanted to make sure that min/max-content are affected
            by the sizing constraints of the other dimension.
  fantasai: Do this by saying "size as a shrink-to-fit float".
  fantasai: So if you say min-content, it acts exactly like a float
            in a zero-width container, max-content with an
            infinite-width container.

  fantasai: dbaron had a different concept.
  fantasai: That they should be the intrinsic size of the image,
            without regard for specified sizes.
  fantasai: The advantage is that this corresponds to an internal
            layout concept.
  fantasai: Downside is it's not a concept that appears in CSS in an
            author-exposed manner.
  fantasai: We *always* respect the aspect-ratio if possible.
  fantasai: So you never see the raw intrinsic size.

  dbaron: I don't think it's true.
  dbaron: We've exposed it thru these new width keywords.
  dbaron: I've been particular to insist that all the intrinsic
          sizes definitions for an element *not* consider its min/
          max-width/height properties, so we can have keywords for
          those properties that represent those values.
  dbaron: But instead you have values that pay attention to those
          properties as part of determining the size of its parent.
  dbaron: Also, I thought you were proposing there would be an
          affect from the outside of the element.
  dbaron: There's no cases where this happens yet, we really don't
          want to do that. This is computationally a bottom-up thing.

  fantasai: There are cases where we do this.
  fantasai: Set a floated image sized in width percentage.
  dbaron: These concepts only exist in the inline dimension.
  fantasai: What do we do for height:max-content?
  dbaron: We treat it as auto. It's only useful for writing-mode

  fantasai: Is that okay for other people?
  gregwhitworth: Seems okay to me.

  RESOLVED: Treat min/max-content keywords as "auto" in the block

  <dbaron> (and the other two)
  <dbaron> and fit-content

  RESOLVED: Treat fit-content that way, too.

  fantasai: Back to the inline axis.
  fantasai: [example] 300x300 container. Image has "height: 200px".
  fantasai: Goal of min-max/content is to represent shrink-to-fit
  fantasai: To match shrink wrapping, width:min-content should be
  dbaron: That's fine for fit-content on the parent. I don't want to
          change the behavior on the image itself.
  fantasai: That's the point tho. A floating image with width:auto
            is same as width:fit-content, right?
  dbaron: I'd like to keep "auto" separate from that.
  fantasai: My understanding was that the goal of "fit-content" was
            to give the float behavior. But you're saying that's not
            the case...
  fantasai: for replaced elements.

  gregwhitworth: I'm trying to understand what the engine is
                 supposed to do with that.
  astearns: You've got a 300x300 image, set to 200px height.
  astearns: What's the difference you want to see between
            fit-content and auto?
  fantasai: I don't, dbaron does.
  dbaron: I'd like to see fit-content be the simple formula, but
          maybe replaced elements is where you do something

  dbaron: I'm not comfortable with changing min-content, it
          precludes us doing expression languages with them later.
  dbaron: I was thinking fit-content would still be 300px (not
          consider height property), but auto would be 200px.
  dbaron: I might be okay with fit-content, but really not min or
  dbaron: In the future, if we want to write "calc(min-content *
  fantasai: If you want a keyword to access to size of a replaced
            element no matter what, we can add that -
            "intrinsic-size" or something.
  dbaron: I'm willing to think about that more, but not accept it

  fantasai: The Grid spec defines auto sizing as max-content sizing.
  fantasai: Pretty sure we want Grid to take this stuff into
            account, so it's not just fit-content.
  fantasai: I think generally the intrinsic size of an image isn't
  [missed a little bit]
  fantasai: I feel like if you wanted to multiply min-content by 2,
            you want the result of shrink-to-fit, then multiply that
            by 2.
  fantasai: Or you want specifically for replaced elements to blow
            up the image by 2.
  fantasai: Which I think we already have a property for.
  fantasai: But if you say "I want my grid track to be min-content
            size", and some of the images have explicit height, you
            want to use the altered height.
  dbaron: I'm feeling less confident about fit-content now.
  fantasai: We really just need to think about Grid here. We did min/
            max-content with the understanding that it would do
            something useful for sizing the track.
  fantasai: If you're using it for the intrinsic size of the image,
            that's kinda weird.
  <fantasai> https://drafts.csswg.org/css-sizing-3/#extrinsic

  astearns: Any further issues?
  fantasai: Nothing we can resolve in the next 7 minutes.

  ACTION fantasai and tab to rename "fill-available sizing" to
         "stretch sizing".
  <trackbot> Created ACTION-825

  <break type=short><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
        <td style="width: 55px; padding-top: 13px;"><a
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
		<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
target="_blank" style="color: #4453ea;">www.avast.com</a>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
Received on Tuesday, 14 February 2017 02:33:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:06 UTC