[CSSWG] Minutes Santa Clara F2F 2014-10-27 Part IV: Grid, Test Suites


  - There was a long conversation about the request from SASS to not
      use bare parentheses since they use it for grouping.
      - Brackets were suggested as an alternative. The editors
          stated that when they were originally writing this part of
          the spec, the selection of parenthesis over brackets was a
          coin-toss choice, not a specific preference.
      - There was conversation on which provided more readability,
          brackets or parenthesis which no clear winner, but no one
          strongly disliking either option
      - However, there were a considerably number of people that had
          concerns about the precedent that the group would be
          setting by agreeing to make this change for one
          preprocessor, even though it's a large one.
      - Ultimately, there was no consensus on the change.

  - Rossen brought his proposed algorithm for grid fragmentation to
      the group for feedback.  His algorithm sought to maintain grid
      areas as non-fragmented as possible.
      - There was concern about forcing items onto the next page to
          avoid fragmentation and about defining a non-ideal
          algorithm when implementers may be able to do better
      - Break properties were also discussed with some concern
          expressed that the proposal states that they don't apply
          to grid items, just the content inside.

  - The work gregwithworth has done on collapsing was tabled for the
      time being.

  - Grid's inability to handle problems like this
      should be solved since it's a reasonable case. Fantasai
      outlined a potential approach and she and TabAtkins will work
      on making it possible.

  - Sizing of grid items inside the containing block will be
      clarified slightly in the spec language by explicitly stating
      that sizing is defined by the object's type.

Test Suites

  - ArronEi will go through the errata on CSS 2.1 and see exactly
      what needs tests so that an update can be published with a
      test suite.
  - He is also working on creating a document that standardizes the
      process for getting tests and will use the backgrounds and
      borders test suite to make sure his process is complete and
      accurate before presenting the document to the group.


  Scribe: dael

Grid Layout

Line Name Lists: Parentheses vs. Brackets

  TabAtkins: Before we start full grid, I've been talking to the
             lead maintainer of SASS because they use parentheses as
             a grouping and that's common with preprocessors. The
             only way to work around this is to inject some very
             specific language. She's requesting we revisit the
             syntax and either make it named or use a different
             grouping character.
  ??: What would the named function be?
  fantasai: not-a-SASS-function()?

  TabAtkins: I don't think we...I'm not sure if we've implemented
             the syntax or if we just did it, but we could change
  fantasai: I don't think we're shipping.
  TabAtkins: If we're okay coming up with a name, we can just say
             that and address what it would be on the ML?
  Rossen: I wouldn't be opposed.

  TabAtkins: Their request is please don't ever use bare parentheses.
  plinss: What about inside calc?

  <leaverou> shouldn't preprocessors follow CSS instead of the
             opposite? It's much easier for preprocessors to change
             their syntax than it is for CSS.

  TabAtkins: It's already intrinsically-magic. She's talking on the
             property level.
  Bert: We use them in MQ.
  TabAtkins: Different syntax pieces, it's any property where it
             means something different.
  TabAtkins: Right now they use parentheses as a grouping and
             they're heavily used everywhere. They can't change
             their current use and they want to, as much as
             possible, have that for SASS it is a super-set. Any CSS
             is correct in SASS and that would force that to change.
  TabAtkins: And she says that calc is a crazy special case already.

  TabAtkins: We'd be resolving to not ever use bare parentheses.
  plinss: I'm not sure I'm okay with that.
  TabAtkins: This preprocessor is already 5 years old.
  leaverou: CSS has more users then preprocessors. If both options
            are the same we can make it easier for preprocessors,
            but if this is easier for authors we should do it.
  TabAtkins: This is small, though.

  astearns: The parentheses in question are grouping line names?
  astearns: Is there any other place in CSS where we've wanted to
            give alternate names?
  TabAtkins: What do you mean?
  fantasai: One issue is you'll make the syntax more awkward. Even
            if you pick a great name, every time you define a grid
            template, you'll have to type it again. It's not buying
            the author anything great.
  <TabAtkins> http://dev.w3.org/csswg/css-grid/#track-sizing

  rossen: Can they special case?
  TabAtkins: Not without special case-ing this one property and any
             others where we create blanks.
  rossen: They can create a lookup table.
  TabAtkins: They've avoided it until now.

  fantasai: We have three options. 1) switch to brackets
  fantasai: 2) switch to curly brackets.
  TabAtkins: I don't think we want that.
  fantasai: 2) is switch to a short name.
  fantasai: 3) is we tell SASS that the effort to put this into
            special case...we tell them they have to special case
  fantasai: The downside of switching to name is it makes the syntax
            have a lot of noise and it becomes harder to read. It's
            not helping the authors any.
  fantasai: Downside of telling SASS to special case is they have to
            put in some time to implement a special case.
  TabAtkins: Also, handing stuff in script becomes harder. In this
             particular case the parentheses in a list get
             translated to actual parentheses. It makes the model
             less consistent.

  fantasai: The only option without a downside is switch to brackets.
  fantasai: I'm not impressed with the list.
  bkardell: Brackets is pretty good.
  TabAtkins: The only point of a function is to group.
  bkardell: Also SASS is open source so anyone can submit a patch.
            If the WG felt strongly SASS should change they can send
            a request.
  <bkardell> I don't support us changing SASS
  florian: It's also bad for SASS users.
  TabAtkins: Their population is smaller, but it's not insignificant.
             They have lots of users.
  TabAtkins: I'm fine with square brackets.

  fantasai: Any other issues with them?
  fantasai: The only option I'm not okay with is script.
  TabAtkins: I'm down with square brackets. And in the future when
             we need to group things, we'll just use square brackets.

  <leaverou> I would argue that parentheses are more natural and
             intuitive for any kind of grouping.
  plinss: The forward compat parsing is that you match parentheses
          and brackets. That means we can use them where ever we
          want. That someone else jumped over that isn't our fault.
  TabAtkins: And within functions it's different.
  plinss: But we might have something in selectors or something we
          don't see now in the future.
  fantasai: I think plinss is objecting on principle.
  TabAtkins: I think the practical overrides principle as long as
             there's a reasonable answer to it.
  <fantasai> http://dev.w3.org/csswg/css-grid/#named-lines

  dauwhe: Will brackets feel as natural?
  TabAtkins: You don't need shift.
  dbaron: Is that true for non US keyboards?
  [it's not]
  TabAtkins: Anyone that writes code on their keyboard can find a
             square bracket.
  SteveZ: I'm not opposed but to me traditionally that means
  SteveZ: I think it's going to be a point of mild confusion where
          parentheses would be less.

  TabAtkins: This isn't common in programming languages.
  many: lists
  dauwhe: What % of CSS users are programmers?
  TabAtkins: Pretty low.
  bkardell: It's loaded. A lot of CSS users do basic PHP. They're
            not totally withdrawn.
  rossen: dbaron, didn't you use brackets in your overflow or
  dbaron: I don't know.
  TabAtkins: It would be this (link above) with square brackets.

  gregwhitworth: What was the argument again?
  TabAtkins: SASS uses parentheses for grouping.
  TabAtkins: LESS has similar problems.

  plinss: I'm not married to the parentheses and I don't mind
          alternate syntax, but I object to us giving up parentheses
  <leaverou> plinss++
  florian: We're weighing the pros and cons.
  TabAtkins: Any argument we make here is for anywhere we use
  SteveZ: If you establish that square brackets are ways of
          identifying chunks, we should use that anywhere that we're
          doing chunks.
  florian: And if we find another reason to use naked parentheses we
           can still do it.
  <leaverou> As many pointed out, it's not this particular property.
             If we use brackets here, we have to use them in every
             future property that needs grouping/chunks of any sort,
             for consistency

  rossen: So if you go back to them and say no, would they declare
          war or...?
  TabAtkins: They'll figure something out, but it would be
             frustrating for them and their users.
  bkardell: The problem is there's a bunch of SASS out there now.
  rossen: Existing SASS targeting grid.
  bkardell: That's true.
  TabAtkins: They can't tell context immediately. It's probably
             possible to make it work, but it would be weird.
  plinss: Well, they could change it.
  TabAtkins: That would break that "all valid CSS is valid SASS."
  plinss: If that's their rule, they violated it.
  TabAtkins: Technically any syntax they choose violates that
             because we can use it.
  plinss: I don't want to constrain ourselves because someone else
          picked a syntax. If they had restricted themselves to the
          extension points in our syntax they'd be fine.
  TabAtkins: Like @rule
  plinss: And prefixes
  TabAtkins: But they didn't and we can't go back in time. My first
             answer was "sucks to be you", but then she explained
             more and it makes sense.

  florian: Given that I don't find square brackets odder it's fine.
           In this case it's fine.
  leaverou: It's creating a precedent
  florian: If we find later a place where naked parentheses is
           better, screw SASS but right now we have an alternative
           that's not any worse.
  florian: If you think list you're in trouble, but this it doesn't
           matter square or round.
  TabAtkins: Sizes may be keywords so you need to disambiguate.
  fantasai: Or we might add the keyword.
  ???: Use strings?
  TabAtkins: It's uglier.
  fantasai: We had strings before. We switched to idents because
            that's what CSS uses for custom names. Also it's not
            just here, we use them in the grid position properties.

  rossen: I think the argument is beyond this. I think this is on
          the grounds of do we give up parentheses.
  florian: I don't think we have to always, but in this case they're
           not the only good choice.
  Rossen: You're saying that later in time there will be a larger
          chance of us going to SASS and ask them to change when
          they have more content because we'll have to use them.
  TabAtkins: We're making future us deal with it.
  leaverou: And they don't need to change until this ships.
  TabAtkins: We hope to ship in Q4
  florian: Forcing SASS users to use inconsistent, we want to avoid
  leaverou: But they'll special case.
  florian: But they'll have to remember the special case.

  <zcorpan> how about grid-template-columns: first nav 150px,
            main 1fr, last; ? i.e. use comma, all but the last
            component value are custom names
  <SimonSapin> Rossen, Is IE shipping the keywords-in-strings syntax
               of grid-template-areas?

  bkardell: Is there a compelling case why parentheses are better
            here? leaverou, I feel like you don't like this and I
            want to figure out why
  leaverou: I'm worried about the precedent.
  TabAtkins: When SASS has asked before, I've said no. It was a
             little inconvenient. They've just dealt with it like
             when we use /. This is a different bucket and way more
  bradk: Can they change their syntax?
  TabAtkins: Not at this point.
  TabAtkins: It would just make all SASS scripts broken.

  bkardell: Let me re-frame. I like brackets better.
  bradk: They make me think of attr.
  TabAtkins: That is where we use it right now.
  fantasai: Selectors is a completely different syntactic space.

  TabAtkins: If we pretend I had always used square brackets, is
             there an argument to switch to parentheses?
  <fantasai> Note, it wasn't Tab's suggestion to use parentheses
             originally, it was mine. :)
  dauwhe: The corner is hard on my eyes.
  dbaron: Would it inconvenience other preprocessors?
  TabAtkins: Not that I'm aware of.
  <dbaron> (Tab said he thinks [] are fine for SASS and LESS.)

  adenilson: For this specific case in grid we change to square, but
             it's important to let them know that this is an
             exception and we may use parentheses in the future.
             Since you'll have close contact, we can say we care
             about SASS but we are leading.
  TabAtkins: In this case which character doesn't effect our users.
  plinss: I think we need to be definitive that it's a future them
          that has to deal with this. If we do this the installed
          base of parentheses users will keep growing. Even if we
          say yes but we reserve the right, but we're creating a
          world where that's harder.
  TabAtkins: We can always say screw it SASS.
  fantasai: If the choices were between SASS fixes or we use names,
            I would says SASS has to fix its stuff.

  TabAtkins: So, square brackets. Objections?
  plinss: I object.
  TabAtkins: You object to future problems.
  fantasai: I think we switch to square brackets and tell SASS that
            if we have this problem again they have to fix it
  <hiroshi2> I think, to think about SASS users and scripts are
             important. but the time to take effects this
             parentheses would take some time. so, now we can ignore
             about sass. (SASS can moderate this change)
  TabAtkins: Remember future us has never treated past us's
             resolutions as unchangeable

  fantasai: Propose we switch grid line naming to square brackets
            and tell SASS that in the future they'll have to deal
            with it.
  rossen: Can we do a straw poll to see if others are objecting?
  glazou: I'd like to hear precisely.

  plinss: Is anyone else objecting to switching to square brackets?
  Rossen: I'm with you on the basis to giving up parentheses, yes.
          For a spec def that no one ships I don't care.
  florian: You can buy into a slippery slope where it applies.
  plinss: No matter what we say, we are.
  TabAtkins: No, we're not.
  plinss: If we're saying it's a bad idea now it'll be worse later.
          And the amount of pain and size will get worse.
  plinss: We're either forcing them to take pain now or force them
          to take a lot of pain later.
  Rossen: And you're saying if we use brackets here and need them
          again later we'll be inconsistent with ourselves.
  * glazou is with plinss and objecting too
  * ArronEi is also with plinss and objecting as well

  fantasai: We just did a coin toss to choose before and now SASS
            says we have a reason for you to go the other way. In
            the future we may need another type of grouping that's
            not square brackets, then we can tell SASS they have to
  fantasai: We're saying next time we have this problem they have to
  <leaverou> if in the future we have a similar discussion, there
             will also be the argument of consistency, i.e. "but
             we're already using brackets here and there"
  <leaverou> so it essentially makes it more difficult to resolve to
             parentheses in the future.

  plinss: Do you believe SASS will make changes based on this?
  fantasai: No.

  florian: As for it being worse in the future, this isn't obvious
           that SASS user base is growing faster than CSS.
  plinss: SASS may go away, but another one may step in.

  glazou: We have two arguments and no one is changing their mind.
          We have at least three objections. Raise your hand if
          you're objecting to using square brackets.
  TabAtkins: You're objecting to if we had picked brackets in the
  plinss: But if we had done the opposite we would be in the same
  glazou: So let me see hands.
  glazou: It's significant. It's too much.
  florian: We could use angle brackets, but it would inconvenience
           HTML users.
  dauwhe: This doesn't look like consensus.

  TabAtkins: I really don't like it.
  fantasai: People are objecting to changing but not to brackets.
  TabAtkins: We can say in the future we can tell SASS to change.
  plinss: We're telling SASS they made a mistake and they have to
          fix it now.
  TabAtkins: Your preferences are path-dependent
  glazou: We didn't choose to use the $ because it was used by
          preprocessors and we asked if they could change and they
          could not.
  glazou: We cannot be blocked by a 3rd party
  florian: It's about SASS users. Its inconvenient there.
  bkardell: If your argument is true, we already blocked ourselves.
  bkardell: If the argument is we set a precedent that we'll change,
            we already did it.
  <fantasai> could've just said script users need to use $$, just
             like in bash
  <fantasai> everyone else can use $
  glazou: But we found another option
  bkardell: Which we can do this again. If SASS had a WG rep they
            would have said they don't like parentheses.

  plinss: We're into our break. Lets go on break, meet back at
          3:30ish. If we come back with changed minds we can revisit.
          Otherwise this is done.

  <astearns> One possible argument that brackets could be better -
             the names can be nested in a repeat function
  <astearns> I find this: repeat(4, 10px [col-start] 250px [col-end])
  <astearns> easier to read than this: repeat(4, 10px (col-start)
             250px (col-end))
  <shans> astearns: me too

  [Snack Break]

Fragmenting Grid Layout

  plinss: Other grid issues?
  Rossen: Did we close on the previous one?
  gregwhitworth: It was no consensus.
  plinss: What's next on grid?

  <Rossen> http://dev.w3.org/csswg/css-grid/#pagination
  Rossen: The one issue I wanted to cover is grid fragmentation
          which is something I added earlier today so I don't expect
          anyone to have reviewed it yet.
  Rossen: I can go over the proposed behavior and explain some of
          the decisions.
  Rossen: So, for context, CSS grid is a layout mechanism that
          allows you to divide your area into rows and columns and
          define grid areas in between those and the content can
          influence those by their size.
  Rossen: When we talk in terms of fragmentation, it's not a use
          case where grid should be expected to work great.
  Rossen: In other words, grid as a layout primitive in an ideal
          should be used in non-fragmented cases. It should be in
          the page, not across many pages.
  Rossen: With that in mind, our intent with the proposed algorithm
          is we wanted to keep the areas as intact as possible.
  Rossen: That's why that algorithm is fairly simple. Any time you
          come across a row on a fragment break, we would want to
          push that row to the next fragment.
  Rossen: The question is how you would resolve fr and auto row
          sizes because they depend on content and you might end up
          with reverse dependency.
  Rossen: The current algorithm resolves grid in the first fragment
          space, assuming it has a definite width. Then we resolve
          all the fr and auto rows, then we would fragment that
  Rossen: Again, the question is what happens when a row gets to be
          fragmented. For example it's the first row and it's long
          enough it needs to fragment.
  Rossen: Obviously the content will become longer and larger than
          what we measured inside continuous space.
  Rossen: We would fragment the current rows and will overflow grid
          rows in the case of fixed height or extend if they are
          auto or fragment without having to re-layout the grid
  Rossen: Does that make sense?

  SteveZ: The last statement of if the second column overflows, does
          that extend the row across?
  Rossen: If it's not fixed height.
  SteveZ: So you're taking the max?

  plinss: I think what you're saying makes sense but falls down in
          more complex cases. Maybe this is a non-issue. You said if
          a row is fragmented you take all the areas...
  Rossen: All the areas that start in that row. So what happens with
          the lines, the line on the row, you can align bottom in
          that fragment and bottom on the other.
  plinss: Probably available on both fragmentainers.
  plinss: So say you have a grid that's a single cell and you have
          something that spans two lines. So the spanning cell gets
          split in the middle. It may get taller than it would have
          been and needs to behave properly to push the line down.
  Rossen: Yes, in step 4 we say you would not take that into account
          when spanning items.
  Rossen: I'm sure that we'll keep refining this as we come across
          more cases, but as a general intent, we want to keep grid
          areas as non-fragmented as possible. In the error case
          where a row has to fragment, we follow normal rules and
          that row may or may not extend depending on if it's set to
          auto or fixed.

  fantasai: I don't think we should push to next page if they don't
            fit. People want to use grid for page layout. If you
            have a bunch of headers/navigation and an article, you
            don't want a lot of blank space between the header and
            the start of the article. Tables don't avoid breaks
            within rows that for that reason. If you want that
            behavior you can set it with 'break-inside: avoid',
            but it shouldn't be an unchangeable default.
  fantasai: The other comment, fragmenting of grid layout will have
            similar problems to flex layout. It might make sense to
            use the same spec text which is 'here are the general
            rules' and not spec the algorithm except in an example.
  fantasai: I think that trying to get, we don't want to push
            implementors to implement a fragmentation algorithm that
            isn't ideal and any we put in right now won't handle
            flex ideally. Like if you have something with a lot of
            flexing and pagination, you sometimes want to pull
            things *up* to optimize space rather than pushing it
  fantasai: If you're using flex to size you have extra space on the
            first but not the second, if you're fixed height you
            want to take that space to avoid a break by pulling into
            the first page. I don't want to normatively require
            something simple when we know people can do better.
  fantasai: We should encourage them to do better.
  <fantasai> Flexbox: http://dev.w3.org/csswg/css-flexbox/#pagination
  Rossen: I'm not opposed to it.

  astearns: I have a question, it says the break properties don't
            apply to grid items. There's no way to assign a break to
            a grid item. If an element is assigned to a grid area
            and it has a break before...?
  Rossen: It was clarifying to say you can't apply break properties
          to grid areas.
  fantasai: Flexbox propagates it out. For consistency we should do
            that. Break-inside should apply to all these things.
  plinss: I'm not so sure about that. If you have multiple columns
          and have a break, do you want to break every column at the
          same place?
  astearns: You could have items in the same row on different pages
            which would be weird.
  dbaron: I can imagine cases where pages would work badly if you
          don't line it up. So you have something on the side and it
          breaks in the main content, there's an expectation that
          they'd line up.

  fantasai: If you have a forced break inside a flex item, it's
            basically an expanded margin within the flex item,
            and stretches its content height.
  fantasai: If you have something that's 'I'm a flex item break
            before me', that pushes the item to the next page.
  fantasai: They just operate on the actual item.
  Rossen: That's the easy case.
  plinss: Problem is you have a multi-column grid. One thing in
          there wants to break. Does it break the entire grid?
  fantasai: Yeah. We can't put a forced break property on grid rows.
  plinss: I know cases where that's really bad.
  fantasai: You can't put it on the grid row, just the items in it.
  plinss: So I have multiple columns it's a magazine flow, and one
          article has a break.
  fantasai: It won't break the grid, it increases the height of the
            item. If you say this *item* should start on a new page,
            it pushes down the whole row.
  astearns: And you could end up in a situation where you have a row
            on the first page and a duplicate on the second page.
  plinss: Authors are going to want it both ways.
  fantasai: If they want it just in that, they can create a wrapper
            item. You can work around that. You're looking at
            conceptually there's an item that has stuff inside it
            and you're pushing stuff up or down.
  fantasai: I'm having a hard time coming up with examples where
            this makes sense.
  fantasai: If you're trying to get things to line up, you do that.
            If you don't want them to line up you shouldn't be using
            grid anyway. If the goal is you're using grid you want
            things to line up.
  fantasai: If you think this is a bad idea, maybe we should revisit
  plinss: I think it makes sense for flex, but that's one dimension
          and this is two.

  Rossen: I'm mostly modeling after table layout.
  fantasai: You never have a case where a table cell starts on the
            next page just because all its content didn't fit.
  plinss: Page break before an entire cell.
  dbaron: I think the spec says it's not supposed to wrap.
  dbaron: I believe Gecko has bugs saying it doesn't work in Gecko
          and it does in other implementations and we've pointed to
          the spec saying it's not supposed to work.

  Rossen: We can try a different heuristic. Going to your example
          where you used grid to create a header and content. I'm
          not sure pushing grid down and starting on the second page
          is worse than breaking on the first page.
  fantasai: I think that it's much worse. If you want that you can
            opt in, but if you dictate you can't do that, no one
            will ever have a normal looking article. If we want it
            to replace tables and floats, we want it to look like
            that when we're printing. The printing should be
  Rossen: Which is what tables will do.
  fantasai: They do not push. Want me to write a test case?
  dbaron: Bigger point isn't just about equivalence. They'll design
          a page and just expect printing to work. Massive gaps
          count as not working. So do a bunch of other things.

  SteveZ: What I don't understand, I would like to start the next
          row on a new page if it's a small gap. Since that's a
          conditional, we could define a property that says when to
          start a new page, but there's something we want to happen
          automatically that isn't force to a new page or break into
          a new cell.
  fantasai: I think if you want that you want that for all layout
  fantasai: File a bug against fragmentation.

  plinss: You might need a precedent where you have multiple grid
          items and conflicting layout. You have to come up with
          something rational for the whole row.
  fantasai: For the content of a grid item, you don't have two items
            consecutively in the same row, you just have one item
            and content inside the item. If you have to do different
            fragmentation requirements, then that just effectively
            increases the content height of the row.

  plinss: Is that it?
  Rossen: That's pretty much all I had.
  Rossen: That was the issue we addressed. We'll keep working given
          the feedback, but at least we don't have a big gap anymore.

Collapsing Rows and Columns

  plinss: The wiki said collapsing.
  gregwhitworth: We started by trying to come up with ways to
                 collapse a grid. At first it seemed simple like you
                 should be able to call an column, but then we
                 realized that the user would want to do that based
                 on an item, not a column.
  gregwhitworth: We came up with a couple ways to do it. I can paste
                 in the one that would be a pain to implement.
  <gregwhitworth> .grid::grid-row(“row-name”) {
  gregwhitworth: Inside that would be visibility: collapse and you
                 could declare a row name.
  gregwhitworth: There's no way to attach to a thing, so it would
                 end up being quite verbose. And I would like to
                 interact with an item and talk to its parent.
  plinss: The grid row solution; you're using two indexes to find it.
          You name/ID the two lines.
  plinss: Or use the span notation.
  gregwhitworth: I think it's one we can revisit.

  Rossen: Let's table this.
  plinss: But basically you're defining a new pseudo.
  gregwhitworth: It's the only thing we came up with.
  Rossen: Okay.
  plinss: No other issues?
  Rossen: We have issues, but nothing that we've worked on.

Auto-column-count Grids

  fantasai: There was one. Let me find it.
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Oct/0108.html

  SimonSapin: I sent something months ago. Grid doesn't define
              determining the size of the grid item which is
  TabAtkins: It does.
  SimonSapin: That was fixed?
  fantasai: I'm linking to something different.
  TabAtkins: SimonSapin can you find the original complaint?

  <fantasai> https://twitter.com/AlanHogan/status/519256635911307265/photo/1
  fantasai: The issue if you look at the second link (right above),
            it's the problem.
  fantasai: Well, this was kinda a grid layout. To try and get that
            layout you can't do it right now. There's a couple of
  TabAtkins: The reason you can't do it in grid, it's not a 5
             column, it's fixed width columns, but as many as
             you need to fill the available space.
  fantasai: We need two things to fix this, which seems pretty
  fantasai: To get this to work properly you need to put as many
            columns as fit items of size x. What we need is a repeat
            function that says as many columns that will fit in the
            space and they're 15em wide.
  fantasai: I think it would be useful and encourage flexible grids
            that look good on multiple screen sizes. I think this
            should be simple, but I don't have syntax yet.
  fantasai: Second thing that's necessary is, you'll notice the
            space is just enough that the columns fill the space. We
            have a property in flex that gives you this alignment.
            The simple solution is to reuse the property and have
            that mean there's a gap between the columns. Once you've
            figured out the size, space out the grid with that
            amount of space.
  fantasai: It might be tricky to define in terms of spanning, but
            it's a property we have.

  TabAtkins: We were planning to add row-gap and column-gap.
  fantasai: This is in addition. You might want those as minimums.
            We have basic syntax here.

  SteveZ: If I have a span, do I assume the span covers the gap?
  TabAtkins: So if your edge, it'll go over to the closest.
  SteveZ: So the ends of the span line up with the ends of rows.
  TabAtkins: It's difficult to spec, but we'll handle it.

  TabAtkins: This stuff should be the first things in level 2. As
             soon as things start to ship, next year we can start on
             level 2.
  fantasai: I think the repeat is almost syntactic sugar. The
            justify is tricky.
  TabAtkins: You can center the whole grid or, if you center each
             item within, you can get space.
  fantasai: Which is I think is good enough. I think it would make
            people happy if we did repeat to fill.
  TabAtkins: I'm trying to be as conservative as possible to get
             grid level 1 done. I want grid and flexbox to finish at
             the same time.
  Rossen: You're not alone.

  * leaverou notes that the tweet fantasai linked to also
             demonstrates a great case for static value
             interpolation (that we discussed a while ago in the ML)

  plinss: Is that it?
  fantasai: I think TabAtkins and I need to do a lot of editing and
            we'll come back.

Sizing the Grid Container

  SimonSapin: I have an issue. There was grid containers, that's
              fixed. The only thing I can find on sizing with ident
              is by default they're stretched in the grid area.
  TabAtkins: Grid defines the containing block as the containing
             area, what else do we need?
  TabAtkins: The size is that of the containing block.
  SimonSapin: You said size is the containing block. Where is the
              sizing defined? Same as blocks?
  TabAtkins: If they're a block they display as block?
  Rossen: This is the same as asking how the table cell size are
          defined by the view of table?
  SimonSapin: That's defined. What we do in the spec, the outside is
              defined specifically. Blocks have their own sizing,
              what is the sizing of grid items inside the containing

  fantasai: He has a point. They are participating in a grid layout
            context. What that does is not defined.
  fantasai: You're confusing display inside and outside.
  TabAtkins: I'm not. It doesn't have a display outside.
  TabAtkins: Once we've established how big based on the layout
             algorithm, it should just have a containing block.
  dbaron: So if a grid item is just display block, and it has a
          background, the background fills the width of the grid
          cell but not the height?
  TabAtkins: If its got align self stretch, it's height will be the
             height of the grid area.

  fantasai: Normally is under-defined because there's no normal.
            let's look at width.
  fantasai: If align-self is start, how does it display?
  TabAtkins: Flex says that. What needs to be defined besides the
             containing block.
  fantasai: We need to say that if it's start it's shrink-wrapped.
            If it's not we should say that.
  SimonSapin: Maybe by normally you mean like blocks. That's fine.
  TabAtkins: But we can't because if you're a table you don't.

  Rossen: If your item is another grid, what do you expect?
  TabAtkins: Certain types of things, flex puts requirements on how
             you size. But sometimes the layout says format as
             normal and give me your size.
  TabAtkins: How does a block layout, it does things and you get a
             size back.
  Rossen: You get a grid item that is a grid. In this case normal
          means do your grid layout and give me back your size. If
          that item happens to be table, it sizes like a table, if
          it's block it will behave like a block.
  TabAtkins: So you're looking for context on how blocks behave and
             I'm not getting what exactly you want.
  TabAtkins: Some display models put extra constraints on how
             children layout, but otherwise the rules should be
             defined by the layout mode.

  dbaron: It sounds like if the editors don't agree what the spec
          says, they should make sure there is language.
  TabAtkins: I'd love to but I don't understand what's being asked
  SimonSapin: When in alignment it says that grid items stretch to
              fill the area, what does it mean.
  TabAtkins: The align: self defines how you stretch.
  SimonSapin: So the default is auto.
  TabAtkins: Which is stretch for grid items.
  TabAtkins: Chrome isn't conformant with this right now. We're in
             the process.
  SimonSapin: Maybe add a note that says the sizing of grid items
              depends on the items' layout mode.

  Rossen: Do we have this text on flex?
  TabAtkins: Flex puts some constraints, but it just says do layout
             based on these things. I'll find it and if it's
             inconsistent, we need to fix it, but I'd like to know
             why it's inconsistent or incomplete.
  <TabAtkins> Flex algo line 3E
  TabAtkins: Is this insufficiently specified? It's the same level
             as grid right now.
  SimonSapin: Okay.
  TabAtkins: If you can figure out what needs to be stated in those
             cases we can fix that.

  Rossen: An editorial note?
  TabAtkins: I can't think of what it should say. If you can come up
             with something we'll put it in, but I think that 'do
             layout as you would normally for your display type' is
             a thing that doesn't need more qualification.
  SimonSapin: The thing I'm missing is for it's type.
  TabAtkins: Okay. That's also missing from flex layout right now.
             Okay, we can add detail as to what it means to do
  TabAtkins: Alright.

  TabAtkins: Can you send a reminder to what wording you want in
  Rossen: Or just put it in the minutes. We'll parse it out.
  plinss: So is that it on grid?
  Rossen: We're done.

Topic Search

  Rossen: Who put flexbox?
  fantasai: I think we were expecting to have the issues in.
  Rossen: Can we push that to tomorrow?

  plinss: That's the agenda for today. We should pull something from
  [general mentions of brackets]
  ArronEi: The test suite?
  TabAtkins: We're talking about 3.1 Who put the 2.2 test suite?

Test Suites

  <astearns> https://wiki.csswg.org/test/css2.1
  Bert: I put 2.2 up. We talked about publishing an updated 2.1 with
        the errata and we decided we couldn't because we don't have
        a test suite.
  Bert: Each errata needed one or more tests and there were people
        supposed to write them.

  [crickets... literally thanks to rossen]

  astearns: There's assignments, but nothing indicates if it's done.
  TabAtkins: There's reviews of changes, but not of tests.
  TabAtkins: ArronEi is on most of the lines.
  ArronEi: I was surprised.
  ArronEi: I can look at my stuff, but it won't be for a couple of
           weeks. Maybe next conference call.
  ArronEi: If I'm starting, I can look at them all and give an
           update on all of them.

  ArronEi: The other thing is about the current test suites for
           everything in CR. I'm starting to put together a detailed
           document on how to approach testing since its been ad hoc.
  * astearns dismally ad-hoc
  ArronEi: I want to direct the testing a bit more so we know how to
           approach various tasks. I'm putting that together to get
           done in the next few weeks so we can attack specs in the
           same way. I'm going to test my documentation by testing
           it against whatever spec needs the most done.

  ArronEi: Which one is the highest priority?
  fantasai: Backgrounds and borders is almost done. It needs someone
            to pull it together.
  ArronEi: That's my question. I'll create my process document based
           on that and test my theories. After that's tested and can
           move forward I'll hand it over.

  florian: When it comes to writing tests from scratch, we also have
           the case of the existing mountains of un-reviewed tests.
  ArronEi: I'm going to have the review and updating of those. I
           know there's a lot from backgrounds and borders that are
           coming from a lot of places.
  florian: Opera has large amounts of probably good tests, but they
           need updates.
  ArronEi: I'll make sure I cover something on who to contact to ask
           for tests.

  fantasai: Backgrounds and borders needs triage. There's a bug on
  ArronEi: I don't want to create new tests until I have everything
  ArronEi: This isn't the case for all specs.
  fantasai: Pretty much anything implemented has a bunch of tests.
  ArronEi: I'm trying to catch all the pieces. I'll focus on
           backgrounds and borders and put links on the wiki.
           Hopefully in the next month or so we'll have a process we
           can hand to other people.

  plinss: That's it on testing?
  ArronEi: That's all I have.
  plinss: Anything else from tomorrow?
  plinss: the ::role() proposal?
  smfr: I think that was James Craig.
  TabAtkins: I think it should have been and it was testing of aria
             roles? Let's get him in here for that one.
  plinss: So are we done for the day?
  plinss: I think we're done.

  [End of Day]

Received on Thursday, 18 December 2014 01:46:29 UTC