[CSSWG] Minutes Telecon 2016-08-03 [css-values] [css-variables] [css-grid]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[CSSWG] Minutes Telecon 2016-08-03 [css-values] [css-variables] [css-grid]

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


Start adding things to TPAC agenda
----------------------------------

  - Please add items to the wiki, including those that would require
      joint meetings.
  - gregwhitworth was actioned to find out exactly what the plan is
      for Houdini at TPAC.

Ideographic character unit
--------------------------

  - RESOLVED: Accept text as proposed: https://drafts.csswg.org/css-values/#ic

lh and rlh line-height units
----------------------------

  -  RESOLVED: Add lh and rlh with a note on use cases it doesn't
               solve and a link to max-lines.

CSS Variables transition to PR?
-------------------------------

  - gsnedders is going to confirm that the test suite provides
      adequate coverage. If he finds that it does, the group will
      vote on PR next week.

Transition to CR for Grid?
--------------------------

  - RESOLVED: Take Grid to CR

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

Agenda: http://lists.w3.org/Archives/Public/www-style/2016Aug/0006.html

Present:
  David Baron (IRC Only)
  Bert Bos
  Tantek Çelik
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Florian Rivoal
  Geoffrey Sneddon
  Lea Verou
  Greg Whitworth
  Steve Zilles

Regrets:
  Rachel Andrew
  Rossen Atanassov
  Dave Cramer
  Daniel Glazman
  Michael Miller
  Alan Stearns

Scribe: Dael

Start adding things to TPAC agenda
----------------------------------

  Bert: Not that many here yet, but let's get started.
  Bert: Don't forget to present+ so we know who is here.
  Bert: Anything we need to talk about not on the agenda?
  <bkardell> I sent a post to www-style - I'd like comments but I
             don't know if it needs to be on agenda.
  <bkardell> https://lists.w3.org/Archives/Public/www-style/2016Aug/0004.html

  Bert: This is a reminder. TPAC is coming and we need an agenda. If
        you have anything please put it on the wiki. Topics, issues.
        Also think about topics for joint meetings and such. Please
        look at the wiki and put your ideas here.
  Bert: Address is: https://wiki.csswg.org/planning/tpac-2016

  <myles> where is everybody?
  Bert: That is a good question, it's vacation season.
  <fantasai> Tab is on a bus. :/ He should be here in 10.

  ??: Is there houdini stuff planned?
  Bert: That's a good question.
  bkardell: Would we main stream it into CSS?
  Florian: I believe there's some Houdini planned, but I think
           something more official would be good. Having it off
           schedule makes it hard to coordinate.
  fantasai: Would it make sense on Thursday/Friday?
  Florian: I think Thursday/Friday was the plan. It's unfortunate
           it's not on the official schedule. The earlier we know
           the better we can avoid conflicts.
  <dbaron> There was certainly an email thread about planning
           Houdini stuff, which I think concluded on Thursday
           despite conflict with the AC.
  <dbaron> http://www.w3.org/mid/BY2PR03MB192220DEF29185D440EF4D29B630@...
  Bert: It might be hard to dedicate a room. The rooms are on a day
        by day basis so fewer groups doesn't mean empty rooms. But
        was can always ask.

  Bert: Anyone feel like taking an action?
  gregwhitworth: I suggest we wait until next week because I've sent
                 asks to a lot of places, but Rossen will be back
                 next week and we can make him find out.
  ACTION gregwhitworth to follow up with Rossen and Shane about
         Houdini and TPAC
  <trackbot> Created ACTION-784

  Bert: Anything else on TPAC?
  Florian: Reminder that if you're interested in Air BnB let me
           know. And if you're usually Air BnB and not interested
           let me know so I know it's not slow replies.
  Bert: Yes. So contact Florian if you want to share AirBnB. I have
        a hotel room, so don't come to me :)

Ideographic character unit
--------------------------

  <fantasai> https://drafts.csswg.org/css-values/#ic
  fantasai: There's a draft definition for ic character. We can call
            it ich or whatever. There is a definition in the spec if
            anyone wants to review. Florian had comments that are
            handled.
  fantasai: ich would be maybe more clear, it's more clear though
            longer
  Bert: I don't have a preference. If people have they can speak up.
  myles: Name aside the idea seems fine to me.
  Florian: As mentioned, I like it. I had a minor comment and it's
           fixed.

  Bert: The text mentions used font?
  fantasai: It's the font used to render that character. Whatever
            font you find that character is the font you use to
            measure that character. It's a frequent case that you
            don't have a water ideograph and you have to go through
            the fallbacks to find it and measure. Same process as
            the ch unit. If you have a font without a 0 glyph you go
            through fallback. Most fonts have 0 but it'll be more
            common to have that with CJK.
  Bert: As long as it's clear in the text it's good.
  fantasai: Yep. [reads spec]
  Florian: And the phrasing is identical to the ch unit.

  Bert: Sounds good. Anyone think it's not?
  Bert: shall we conclude?
  <bradk> Maybe the unit name should be a Chinese/konji character.
  Florian: I think so. For the name ic or ich no one will guess what
           it means. ic is less typing. Same for most units. you can
           guess mm but the rest you have to know.
  Bert: I don't see strong opinions on name.
  <dbaron> 'ich' is more clearly related to 'ch', but looks rather
           too much like 'inch'

  RESOLVED: Accept text as proposed.

  fantasai: We can look at the name if someone has a strong opinion.

lh and rlh line-height units
----------------------------

  fantasai: Back in 2014 there was a proposal for lh and rlh. These
            would be useful. You want one unit of line height
            spacing. lh is the computed line height and rlh is the
            root line height. Proposal is add to V&U 4.
  Florian: In CJK typography you size the height of the content as
           an integer of lines. You can use it for that.
  Florian: Independently they're useful and the line grid proposals
           combine well with these.

  myles: I'm a little confused about some of the comments. The first
         line can be taller than the second are we using the used
         height of the line or?
  fantasai: It's what the prop value computes to.
  myles: So if someone says make this 3 lines tall and it's 2 lines
         tall the user will be confused.
  fantasai: The only time you want the line height to be the height
            of the line is if you're measuring the height of the
            element. If you want the margin height to be 3 lines
            tall you don't know which line to pick. If you want to
            limit and element there's a proposal for max-line to
            have that effect.
  fantasai: This is a unit to be used for measurements in any
            dimension so it's meaningless to match any specific line.
  Florian: If you want just 3 lines it's the max-lines property. If
           you're using this one to size a number of lines in the
           content area, that's common in printing. You set the page
           size and say content is 30 lines and the margin is auto.
           And you use line grids to get the heights you want, but
           the area is sized to a number of lines.
  myles: The problem I'm worried about is if you set the content
         area to be 30 lines, that doesn't mean it'll have 30 lines.
         I'm trying to avoid that having 29 lines.
  Florian: I think that's fine. That's something you get when you do
           this. You have to be careful the content you put in or
           use the line grid things. Or you have a long form
           document you'll have it line up. It's a size, not a count
           of lines. If you want a count you have to use other
           things. But they combine well.
  myles: I understand it can work correctly if you plan every glyph
         of every string, but fonts fallback often. I'm worried
         about adding a property where it's a common case to get it
         wrong.

  Bert: That's an interesting problem, but that's not what this unit
        is trying to solve. It's a short hand to doing ems and
        calculation.
  Bert: The problem with fixing lines is a bigger problem.
  Florian: I want to solve that as well.
  Florian: But let's say you want to draw a border and line up the
           content and size it...if you're trying to use this for a
           line grid you'll fail. It doesn't do that.
  myles: The difference between the user saying make this 3 lines
         tall and the user doing some math is that the user has said
         they want it to be 3 lines, but if the user does that
         calculation the browser obeys. If the math turns out not
         correct that's an error on the page author, not the browser.

  <SteveZ> There is also a possibility of introducing a circularity
           if LH uses actual line heights versus computed LH

  TabAtkins: Note there's no concern on font fallback. If you put in
             an image it may make the line something unexpected.
  Florian: Or you do an H1.
  Florian: Things can happen, but not font fallback.
  myles: Lots of things cause this to do the wrong thing.
  Florian: It's the same as if you say width is 30ch and you put an
           image and so you don't have 30 characters.
  myles: It's the same problem, but it is a problem.
  fantasai: Main use case isn't the height of a specific elements.
            It's the fragmentainer. It's not I want only 30 lines in
            this element. For that you want max-lines.
  fantasai: lh lets you use line height for other purposes. For
            fragmentainers you don't want max-line. You want all
            your pages 30 lines tall and if your content is taller
            it paginates. You don't want the height of the page to
            vary depending on content. This is a different use case.
            We want both, but right now we're discussing this unit
            that does things that max-lines doesn't allow for.
  fantasai: You can technically already do this, but you do a bunch
            of calc against an em but you have to go back if you
            change things and it's a maintenance problem. This unit
            is to make it easier.

  Bert: To summarize, it's convenient on one hand. On the other the
        name suggests it does something else. Is it a name thing or
        deeper problems?
  <gregwhitworth> I would like to know how much author confusion
                  would occur with this
  myles: I guess I'm agreeing. The issue is not that I think this
         concept shouldn't exist. I'm worried the user will see
         height 20lh and the user will think there should be 20
         lines.
  Florian: That would be worse if called 20 lines.

  gregwhitworth: I think part of the problem is the first example in
                 the e-mail says n lines on a page. So the example
                 makes it seem like it's root lines.
  <gsnedders> gregwhitworth: a fair bit, because line-heights
              surprise people often enough in general
  <tantek> agrees with gsnedders re: line-heights surprise people
           often enough in general
  <gsnedders> I mean they confuse *me* as an author. And I like to
              think I have a good idea about how they work.
  fantasai: That is a use case where this is meant to be used. The
            height of the page being 30 lines is what you use. You
            want every page to be the same height and if it's filled
            with text it's 30 lines. If there's images or the like
            it'll paginate, but the ideal height is 30 lines tall.
            So if it's just text there's no justification. For CJK
            they want to be able to specify the width. It's
            monospace. So on a line 100% CJK it doesn't need
            justification.
  fantasai: Most lines aren't 100% CJK but you want to design the
            page so when it is there's no justification space.
  fantasai: You assume all text content and if it isn't, which will
            happen, pagination takes care of it. This isn't a case
            for non-paginated content. It won't work well for I want
            this to be 4 lines tall.
  gregwhitworth: I'm more asking author confusion. Looking at this
                 I'd read it that way. I see a lot of people
                 expecting what myles says. You guys know the space
                 and if there's a large reason for it, great. I just
                 foresee a lot of authors thinking this solves the
                 max-line problem.
  Florian: I tend to think people will misunderstand things in
           general. People understand how heights work, though.
           They're not magical.
  Bert: I think we know what the problem is. Do we have proposals
        for bringing the viewports together?

  myles: I think if we change the name to something that describes
         what it does...no one likes that. Maybe add a note in the
         spec saying this is for x, if you want y use max-lines.
  fantasai: I'm happy to add a note.
  SteveZ: I disagree with Florian. Line height only defines the
          height if it's particularly [missed]. Calling it the line
          height is how it's used in CSS.

  <tantek> wait how is that useful?
  <fantasai> tantek, we were just discussing this for like 30min

  Bert: So the question: Do we add this unit? Or do people want to
        object?
  Florian: I'm in favor
  Bert: It's two units. lh and rlh. Do they need to be discussed
        separately?
  <ChrisL> +1 to both
  <SteveZ> +1 for both

  tantek: I'm a little bothered by what SteveZ said. I find the
          justification that it is the computed line height
          non-empathetic to what authors deal with. From authoring
          view if you're trying to base on the line height
          physically and you don't get the result you're creating
          another set of those CSS is Awesome mugs.
  fantasai: tantek, there are two incompatible line based heights.
            One is I want this number of lines based on the lines in
            that box. The second is I want it based on the ideal
            size of the line and I don't care about the content.
            Both have use cases. We're not handling the first one
            here because you can't do it with a unit. That's the
            max-lines. The second case the unit is the right way to
            do it so we're adding it.
  fantasai: We need both these things.
  tantek: Do you have a link to where these use cases are documented?
  Florian: You can start with JLreq. It documents how it's normally
           done in Japanese typography using ideal empty lines and
           the margins fall out of that.
  <fantasai> https://www.w3.org/TR/jlreq/#page_formats_for_japanese_documents

  <dbaron> maybe it's more valuable to work on line grid than to
           trick developers with a unit that won't do what they want?
  <dbaron> aren't many of the use cases people would want
           line-height sized things actually substantially more
           complicated, and probably use cases for line grid rather
           than units?
  <gsnedders> dbaron: that only solves the first of what fantasai
              just said after that, I think.
  <gsnedders> dbaron: and I think line grid is the right solution
              for that.

  myles: From fantasai's argument, maybe it would be valuable if we
         only added both these properties at the same time.
         Max-lines and this new unit so they exist together since we
         need both.
  <gregwhitworth> max-lines is going to be a mess to actually solve
                  generically
  Florian: They're for different use cases. They're similar on the
           surface, but they're doing different things.
  Florian: I don't see why they should be coupled. We have max-lines
           in various drafts already so we're late adding this one.
  tantek: I think myles' reason is because there are multiple use
          cases. When we introduce one authors will try to use it
          for either use case and half those authors will be
          disappointed and think it's buggy.
  tantek: If you want features to succeed presenting both educates
          the authors.
  <Florian> Max-lines is already defined there:
            https://drafts.csswg.org/css-overflow/#max-lines
  <fantasai> https://drafts.csswg.org/css-overflow/#max-lines
  Florian: max-lines is in the spec, we can point to it.
  fantasai: If you want to introduce both simultaneously, we're late.
  tantek: I don't understand the we're late comment. If you
          introduce one expect confusion
  Florian: We've introduced one. If you want both introduce the
           second one.
  <tantek> to be clear, I'm not objecting to introducing just one,
           I'm merely adding to myles's point, and trying to set
           expectations accordingly (that one-only = more likelihood
           of confusion). Defer to WG to decide on that.
  <Florian> This section of JLREQ talks about how pages are
            traditionally sized in Japanese layout as a function of
            the number of lines:
https://www.w3.org/TR/jlreq/#procedure_for_defining_the_kihonhanmen

  <leaverou> so this is the standard version of -webkit-line-clamp?
  <gsnedders> leaverou: no
  <fantasai> leaverou, no that's max-lines
  <leaverou> fantasai: I'm asking about max-lines
  <fantasai> yes

  gregwhitworth: I don't disagree, but max-line only says truncate,
                 but we haven't solved the insane problem of the
                 algorithm.
  Florian: I agree.
  gregwhitworth: I don't think we have to tie them together, but
                 this will need a lot of education. I'm okay if we
                 discuss this at TPAC, but I do think authors will
                 think it's solving both even if we're not.

  Bert: It seems like yes we want them, but how do we introduce
        them. Maybe we can leave it there and talk at TPAC.
  fantasai: I'd prefer to add this and a use case showing why it
            doesn't work for max-lines.
  gsnedders: Will we resolve on what we're going to call it?
  <ChrisL> lh and rlh
  fantasai: lh and rlh
  Bert: Is there a reasonable chance of better names?
  gsnedders: I feel names will lead to author confusion.
  <ChrisL> those names for units seem pretty clear to me.
  fantasai: We don't have other options on the table. This is the
            computed value.
  gsnedders: I'm not objecting to the name now, but we may want to
             see if someone has a better name before TPAC.
  fantasai: If someone has a better name they can add an issue
  <ChrisL> yes
  <bradk> +1
  <tantek> aside: I dislike "lh" aesthetically, as the "l" looks too
           much like a "1" in many fonts
  <tantek> especially in the context where you have a number
           immediately preceding it
  <tantek> e.g. 11lh

  Bert: So do we introduce these? Any objections?
  myles: I want to make sure the example links to max-lines.
  Bert: fantasai can you promise that?
  fantasai: Of course
  myles: Then I'm fine.
  Bert: Any concerns or support?
  <bradk> Support
  Florian: I support

  RESOLVED: Add lh and rlh with a note on use cases it doesn't solve
            and a link to max-lines.

  Bert: We can discuss names and use cases later.
  Bert: There was a second question in that thread. Do we know what
        lh means when used on line height.
  fantasai: Should follow the font size property example and use the
            value on the parent.
  Florian: Yeah.
  Bert: Logical to me.
  Bert: Any reason to not do that?
  Bert: Okay. That's the direction we're going.

  <tantek> note that the "em" unit is "em" and not "fs"
  <fantasai> because "em" is a word that already exists

CSS Variables transition to PR?
-------------------------------

  <ChrisL> test suite report
http://test.csswg.org/harness/results/css-variables-1_dev/grouped/
  <ChrisL> https://github.com/w3c/csswg-drafts/labels/css-variables-1
  <ChrisL> http://caniuse.com/#search=css%20var
  ChrisL: This was me, TabAtkins is the author. It has 135 of 175
          passes.
  ChrisL: There aren't any inline issues in the spec
  <bkardell> it seems to already exceed the PR criteria, right?
  <bkardell> shipit
  ChrisL: We've got all the passes we should require. In the report
          it has one thing for webkit, but it should be split into
          blink and webkit. Caniuse.com has green for everything
          except Edge. Anyone care to implement it from MS?
  ChrisL: Edge 14; CSS variables and custom properties?
  leaverou: They don't support it yet.
  gregwhitworth: No. Not yet.
  <ChrisL> tab, what am I missing here?

  Bert: If we have tests we can ask for PR
  <tantek> do we have tests for every feature?
  Florian: Is the test quite complete? Do we have sufficient tests?
  ChrisL: It seems there's tests on each section. It seems to me
          there's moderately good test coverage. It's 175 tests and
          a reasonably small spec.
  <ChrisL> and each section has some tests
  Florian: I don't think we're lacking, but I want to make sure
           someone has evaluated.
  gsnedders: One way of knowing is if browsers have lots of bugs
             that would be a good sign.
  gsnedders: I don't know how many bugs are around variables.

  ChrisL: Given everyone uses this already are we better served
          moving this forward and starting variables 2 or is there a
          reason to hold off?
  Florian: I think we should do this, but it would be more reliable
           if the author looked through the test suite and said it's
           reasonable.
  TabAtkins: My phone hung up on me. I haven't reviewed the test
             suite [missed]
  fantasai: I think if the tests from each vendor is in the test
            suite there's enough coverage. If we've got all the test
            from blink and webkit and if Microsoft has any tests
            they haven't submitted that should be enough.
  fantasai: If only Mozilla did tests and there's no other tests I'd
            be concerned. But if we have all the tests from all the
            vendors we're in good shape.
  Florian: Either someone knows the answer or we action someone to
           check and we do go to PR

  ACTION gsnedders to check if Variables test coverage is from many
         browsers
  <trackbot> Created ACTION-785

  <ChrisL> I would like to see the test coverage split for blink and
           for webkit. Peter tells me this is possible
  <gsnedders> ChrisL: likewise.
  <ChrisL> the individual test results have the full user agent
           string, so they can be split after the fact
  <dbaron> (also, worth searching browser bug systems to see if
           there are any interesting bugs outstanding that should be
           in the test suite)

  <fantasai> Actually, if only *Mozilla* submitted all their tests,
             I wouldn't be as concerned... They're pretty good at
             tests. :)

  Bert: How much time do you need?
  gsnedders: End of the week, probably.
  Bert: Very nice. Then we can ask for PR soon.
  Bert: Anything else ChrisL?
  ChrisL: No. Thanks.

Transition to CR for Grid?
--------------------------

  <fantasai> https://github.com/w3c/csswg-drafts/issues/345
  Bert: TabAtkins said there was one issue left.
  Bert: Anyone know what it is?
  tantek: Anything at risk in grid?
  fantasai: A bunch. Subgrid. I think they're listed. Main thing to
            discuss before is the concern about percentage grid
            sizes and if that should be dropped/at risk. There
            weren't strong use cases, it was added for completeness.
  fantasai: That's the only open issue except fremy filled something
            about baseline alignment, but we have that covered.

  Bert: Sounds a bit hesitant. Are we sure we want to go to CR?
  fantasai: It's been sitting around and not collecting many bugs.
            It's stable enough for CR. Given the rate of issues is
            CR level. 1 or 2 a month.
  tantek: That's a good sign.

  tantek: The question about percentage grid sizes, has anyone
          indicated intent to implement?
  fantasai: I think the ?? folks were looking into it and asked if
            it's intrinsically sized and do we really need this.
  fantasai: We had added without a strong use case.
  Florian: And do the other implementors support it?
  fantasai: We don't know.
  fantasai: It's currently as at risk.
  tantek: Okay.
  fantasai: We can leave it in the spec.
  Bert: The only issues are marked as at risk?

  gregwhitworth: We'd like to review baseline align and the dev
                 looking into that wanted to know how we'd go about
                 that. Has there been any feedback on align content
                 or the items in track sizing.
  fantasai: We've gotten feedback from Mats of Mozilla. There was a
            handful of issues in May. It's been in the spec for
            years. As far as we can tell it's covered in alignment.
            If you want more time to review that's fine. I'm also
            fine if we want to go to CR and file it as an issue in
            CR.

  Florian: If the type of feedback we're expecting is the type you
           get as you try to implement that seems reasonable for CR.
  Florian: One of the implications of going CR is it's a green light
           to ship it.
  Florian: Maybe that's a way to phrase it. Are we confident now is
           the time to release this in the wild?
  ChrisL: If that's the worry we'd never go to CR until we know it
          could be implemented. CR to see if it can be implemented.
  fantasai: CR is implemented and testing. I think we've finished
            the design phrase. The feedback we're getting is this
            detail in the algorithm is wrong. That kind of feedback
            is what we'd expect. That is appropriate to get in CR.
  fantasai: I don't think we'll get more progress until people
            implement and that's when you put it in CR. We've done
            as much thinking and reviewing as we can without people
            implementing and testing.
  tantek: I tend to agree with fantasai's summary. I'd add do we
          being there are no current outstanding substantiative
          issues. Is that correct?
  fantasai: Yeah. There's a DoC.
  <fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20160519
  tantek: I take your word for it. I just wanted to ask the question.
  tantek: If we have it's better to go to CR then wait.
  fantasai: Issue 14 is waiting on commenter review. Everything else
            is in good shape. There's no other open issues.
  tantek: Great. Ship it.

  Bert: Do we go to CR now?
  <Florian> ship it
  <gsnedders> I'm +1 on CR
  Bert: Seems no objections
  Bert: Some people in favor.
  Bert: Anything we need to do? fantasai is doing the DoC.
  ChrisL: Does the DoC have a reasonable number of responses from
          commenters?
  ChrisL: If not can you do a sweep up round of "please respond" We
          need to show we tried.

  <tantek> sorry, one more question, do we think it has received
           "wide" review?
  <tantek> (beyond this WG right, thanks, I figured)
  fantasai: Yes tantek we've had a lot of review. We've had a lot of
            comments and they're all tracked.
  <fantasai> tantek, and Rachel Andrew and Jen Simmons have brought
             it up with authors at various conferences as well :) I
             would hope they've forwarded any feedback

  RESOLVED: Take Grid to CR

  <dbaron> My biggest concern is about getting stuck with algorithms
           that are slow where we'd rather have higher-performance
           algorithms.
  <dbaron> But it's not clear to me that we aren't already stuck
           with them.

  Florian: Quick follow-up because I wasn't clear earlier. As per
           our new rules, CR is not alone a green light to ship
           unprefixed, but CR + your implementation follows the spec.
  Bert: Do we need to decide anything on prefixes?
  Florian: No. Just earlier I said only CR was greenlight to ship.

  gsnedders: What's the test suite status?
  <TabAtkins> Test Suite = lol
  Florian: It exists but it's small.
  Bert: Anything else we need to decide?
  Bert: I guess ChrisL and I need to do something
  ChrisL: One of us needs to write transition request. I've been
          CCing the member only list on that.
  Bert: You want the task?
  <ChrisL> I can do the transition request

  ACTION ChrisL to do the transition request for Grid
  <trackbot> Created ACTION-786

  Bert: We're at the top of the hour. Anything before we close?
  Bert: See you next week!

Conversation After the Call
---------------------------

  <dbaron> BTW, does grid define intrinsic sizing rules for grid, or
           is that in sizing?
  <dbaron> (since that's the area I'm most concerned about
           performance of)
  <dbaron> fantasai, see my questions above^
  <fantasai> dbaron: It's in grid
  <fantasai> dbaron: https://drafts.csswg.org/css-grid/#intrinsic-sizes
  <dbaron> fantasai, where is "sized under a max-content
           constraint", etc., defined?
  <TabAtkins> The Sizing spec
  <fantasai> dbaron: It's referenced as an if clause a few places in
             the sizing algorithm
  <fantasai> e.g. https://www.w3.org/TR/css-grid-1/#algo-content
  <dbaron> fantasai: I don't see anything there that's not about
           track sizes
  <fantasai> dbaron: the grid container's intrinsic size is the sum
             of its track sizes
  <fantasai> as defined in the earlier section
  <dbaron> fantasai: is there a difference between the grid being
           sized under a max-content constraint and the grid tracks
           being sized under a max-content constraint?
  <fantasai> dbaron: no
  <dbaron> (I have been assuming there is, but maybe you're saying
           there isn't)
  <dbaron> fantasai: maybe the end of each of the last 2 paragraphs
           of https://drafts.csswg.org/css-grid/#intrinsic-sizes
           should be reworded?