[CSSWG] Minutes and Resolutions San Diego F2F Tue 2012-08-14 PM I: Grid Layout

Grid Layout

   - Discussed named lines. General agreement that what's in the spec is not good,
     but no proposal for what's good.

   - Fundamental conflict in Grid Layout module is between application designers' "grid"
     (what's in the spec) and typographic designers' "grid" (what some other people want).
     Peter to propose a Unified Model for grid.

   - Discussed various markup models, and how the current spec requires flattening all
     markup in order to put things into the grid; how to change Grid Layout to work with
     common HTML markup patterns.

   - Discussed default handling of grid element's children, whether to turn them into
     grid items (like in Flexbox) or have them form a single flow, and pull positioned
     items out into the grid.

   - Discussed subgrid proposal, which has grid items inside a grid item participate in
     the sizing of the outer grid, but be positioned within the grid item.

   - Discussed naming of grid properties that define tracks, to make them less confusable
     with grid properties that position things into tracks.

   - Phil summarized the status of Grid Layout module

====== Full minutes below ======

Grid Layout

   [most technical difficulties edited out, the following preserved for atmosphere]
   fantasai: Let's all thank Phil for being very patient with us for starting
             late, for discussing other things, and for not having a phone
   <pcupp> can you hear us?
   pcupp: If everyone looking at wiki link
   pcupp: First topic is [dropped connection]

   pcupp: In hamburg we didn't really talk about why dropping named lines
   pcupp: just said general consensus among editors
   pcupp: We wrote out rationale here
   plinss: Named lines are powerful and useful
   plinss: would object to dropping them
   plinss: Think named lines are very important to grids
   plinss: look at historical usage, have classes of lines, types of lines,
           naming them is quite important
   plinss: if you want layouts that can adapt quickly without redefining
           everything from scratch
   plinss: with named lines can just move the lines around and everything
           just works
   fantasai: We have that with templates.
   pcupp: Wrt plinss, agree with fantasai that points made about named
         lines aliasing capabilities are handled by template
   pcupp: Template syntax is preferred by editors, including Bert and fantasai

   Molly: Has everyone read Mark Boulton's blog post on grid issues?
   several: yes
   <Molly> URL for article: http://www.markboulton.co.uk/journal/comments/open-letter-to-w3c-css-working-group-re-css-grids
   Molly: Would like to keep language similar to what language designers use
   Molly: discuss takeaways
   pcupp: Wrt Mark Boulton's post, Bert has a good response to that
   pcupp: In his model, grid sizes are fixed, and content adapts on top of that
   pcupp: But in our grid, the rows and columns can adapt to their contents
   pcupp: Similar to tables, but with more predictable sizing and better
          placement capabilities
   pcupp: Having read through Mark Boulton's blog post, it doesn't solve
          the same set of scenarios because using fixed grid
   pcupp: Nomenclature of past grids, originate in print media where don't
          have fluid layouts: no resizing of the page or dynamic content
   pcupp: Grid that we have addresses more scenarios and I think the template
          syntax is sufficient aliasing mechanism for that grid
   Molly: I was just concerned with the nomenclature
   Molly: more we have of that, better it is for authors
   pcupp: Wrt nomenclature, we have a bugzilla issue on that
   pcupp: e.g. we have column-gap and column-rule for gutters
   pcupp: There would be a discrepency there
   pcupp: Is it more important to call them gutters, or snap to what's
          already used in multi-column?
   fantasai: From reading the blog post, the only thing I noticed where we
             could change things, where the concepts matched and we weren't
             constrained by existing (e.g. column-gap vs. column-gutter),
   fantasai: was to change "grid area" to "grid field"

   szilles: There are a number of variable-size designs in print design as
            well, printing onto different pages/cards/etc.
   plinss: There's a long history of grids in print publishing, don't think
            we should lose that.
   pcupp: I'm not proposing that there isn't such a thing as a grid line
   pcupp: I'm saying that we don't need to give those things names
   pcupp: Because as an aliasing syntax, I think it's poorer than the
          template syntax

   plinss: You currently specify that you can only have one name existing
   plinss: Think we should be able to reuse same name over and over across
           the grid
   plinss: e.g. class lines into "left line" and "right line", and have
           multiple of these
   plinss: If something gets bumped out of the way, snaps to next line of
           same class
   plinss: Especially vertically, that's done quite commonly
   plinss: Can avoid collisions and have things snap to lines
   plinss: e.g. snap headlines to a headline line
   plinss: you can't do that without giving an identifier
   jdaggett: Are you saying that you want that feature specced out in this
   plinss: I want that capability in this spec

   fantasai: I think what plinss is asking for is very useful, but it's not
             what this module is currently about
   fantasai: named lines as they are right now aren't about a snap-to-grid
   fantasai: The current model is about positioning into specific slots into
             the grid
   fantasai: and named lines are a really awkward way to do that.
   pcupp: ...
   pcupp: Not clear why current grid would preclude a snapping feature
   fantasai: I agree we should have snap-to-grid, but that's not what this
             module is about
   fantasai: Could add it as a different module, one that interacts with
             this one or reuses some of its syntax, but it would be a
             different thing
   plinss: I don't what to have two different kinds of grids
   plinss: My proposal is that this grid system do what grids historically
           have done
   plinss: and think named lines is an important feature
   plinss: think snapping-to-grid feature should be an easy extension of
           this grid
   Bert: There are different traditions
   Bert: I've seen grids, but not named lines
   plinss: It's not named explicitly, but if the designer draws out the
           grid the lines are drawn out differently and different things
           align to different types of lines
   plinss: They're not named because the designer is laying things out

   Tab: How is this different from template positioning?
   plinss: Can't have repetition
   plinss: say I have text flow through multiple boxes
   plinss: want image to snap to nearest available image line, which is
           different than text-snapping lines
   plinss: This is how grids have historically been used
   szilles: Peter's model doesn't have cells, it has lines.
   plinss: I want a model that doesn't have cells.

   pcupp: Can you have lines that are positioned by content in your model?
   plinss: Historically they have not been used that way.
   plinss: But could.
   plinss: Algorithm is complex, but not that complex.
   pcupp: In algorithm right now, size influences other elements
   pcupp: When you introduce snapping-to-grid feature, then depending on
          where the item is position it may span more lines
   pcupp: but the lines depend on the sizes of contents inside
   pcupp: so get a cycle
   pcupp: If you have a fixed grid, can have content stretch over it
   pcupp: But doesn't create relationships among contents
   pcupp: e.g. item in here is as wide as all other items in the column
   pcupp: Right now grid track sizes can be driven by content
   pcupp: So grid flexes to fit the content, rather than items flexing
          to fit the grid
   pcupp: I don't think you can combine these two models.
   plinss: I don't have a mathematical proof of the opposite either

   Florian: Can't you get the model you want by chaining cells using regions,
             and then pouring content into the regions rather than the cells?
   szilles: no, they're not cells
   szilles: ... offset it to the next line
   szilles: Straight line in sequence of cells
   plinss: Have cells that are overlapping
   plinss: Because going to arbitrary lines for different things
   fantasai: So... afaict nobody wants the named lines as they are in the
             spec now.
   fantasai: We have a desire for a snap-to-grid model.
   plinss: disagree with that
   plinss: I like the named lines as they are in the spec.
   fantasai and Tab think they're horrible

   pcupp: Let's walk through current named lines
   pcupp: First thing that's a little unnatural is template syntax using
   pcupp: whereas named lines use strings
   pcupp: This is due to syntactic collisions
   szilles: asks about collisions
   fantasai explains there are two points of collision for named lines:
      * with template slots in the positioning properties
      * with size keywords in the grid track syntax
   pcupp: named lines is 4x as long as the alternative syntax we proposed,
   pcupp: because you need 4 lines, but only one area
   pcupp: is that problem clear?

   szilles: I just want to move the lines
   plinss: I'm going to move all the lines, and keep things stuck to the lines
   pcupp: did you see in the sample, that by naming lines, we just created
          a box. Might as well have used a named slot
   szilles: You're focused on creating cells, that's not what plinss is
            asking for
   pcupp: I just want to put an item into the grid
   discussion of whether overlap is desired
   szilles: You want your figures to bleed into the gutters, but not the text
   pcupp: The grid definitely allows overlapping
   pcupp: The template syntax doesn't allowed named areas to overlap one another
   plinss: You lose that by losing named lines
   pcupp: Seems pretty specialized use case
   Bert: I've never seen that
   plinss: I'm talking about boxes wrapping around each other
   Bert: yes, exclusions
   Bert: They don't overlap, they wrap around
   Molly: Wouldn't that be deconstructing the grid?
   Molly: Maybe this is part of the problem. They're thinking about cells too.
   Molly: It's part also of the table legacy
   szilles shows a picture of a grid layout:
   one tall box along the left side, intersecting a long horizontal box
     in the bottom third of the page
   Bert: That's not named lines. That's a specific layout for a particular
   Bert: You're not aligning images to one line and text to another
   Bert: You can do that with the grid, too, but not necessarily the default.
   szilles: We're not saying that you can't use what's in the module right
            now, but that there are other uses

   plinss: You get the other cases by naming the lines, and thinking of it
           in terms of lines rather than cells.
   plinss: It's an entirely different mental model.
   plinss: We have a whole bunch of different layout systems that use boxes
   plinss: flexbox, tables, floats
   fantasai: But none of those do 2D alignment. Grid does
   plinss: 2D flexbox
   fantasai: That's what Grid Layout is.
   plinss: Haven't we all used vector drawing program?
   plinss: First thing you do is drag out guide lines, and start laying
           things out to those lines.
   Tab: Alternative is that main thing grid layout tries to do
   Tab: is take the table-based layout concepts and make them not shitty
   Tab: These are two different use cases
   Tab: You can't just say "put named lines into grid"
   Tab: question is whether named lines should be in this grid module
   Tab: The way they are defined now, no.
   Tab: As they are written right now, as the spec is designed right now --
        and I think the model in the spec is a good one --
   Tab: named lines doesn't fit in
   Tab: we should go and see if we can add a snap-to-grid model
   Tab: Make grid layout work nicely with snap-to-grid

   Florian: Do we need to rename what is currently called grid to something else?
   sylvaing: No, we do that at Last Call.
   jdaggett: The spec right now is called Grid Layout, we had another one
             called Grid.
   jdaggett: That was more of a graphic designers view of grid layout
   fantasai: That model was abspos with grid coordinates, had all the
             collision problems of abspos, didn't have snap-to-grid
   plinss: You need exclusions and you need collision model.

   pcupp: So, where are we now?
   szilles: I'd summarize, we've established clearly that the set of things
            that szilles and plinss want to do is different from the set of
            things you want to do
   szilles: Certainly common overlap between the two
   szilles: Haven't established whether it's impossible to do them all in
            the same model
   plinss: I think we can do this in one model
   jdaggett: We need a concrete action item on someone to write up the
             functionality that you think is required.
   jdaggett: Having this discussion over again is counter-productive.
   pcupp: Agree
   jdaggett: I'm not objecting to what you're proposing, but we need a
             proposal that's in more concrete form
   * fantasai jdaggett++

   sylvaing: Can we pull what's in the spec out?
   sylvaing: and put an issue to design something new?
   plinss: Been asking for grid people to understand the model I want
   plinss: If we pull the named lines then it'll go the wrong way
   Tab: I don't think you want to patch what you want onto the current
        named lines
   plinss: I think what we want is going to be different than what we have
   plinss: Otherwise we'll fork the spec
   Tab: What currently exists is not what anybody wants. So we shouldn't
        have it in the spec. Kill it and go ahead, develop something better
        that we can put back into the spec
   Tab: Nobody's helped by the thing that's in the spec right now.

   szilles: as long as I can only define cells between adjacent lines
   szilles: If I can define cells that can span lines, then I can get what
            I want
   several: You can already do that.
   pcupp: wrt maintainability, it's easier to renumber than to come up
          with four names per box
   plinss: Problem with current system is that if I make a new grid with
           different number of lines, because different sized page, I
           have to go and redefine where everything lands in that grid
   Tab: But you don't. You use a template together. Don't even have to use
        the template slots, but can use the names created by there to
        position grid items
   Tab explains how grid template slot names can be used as coordinates
   plinss: If we want to add what plinss wants, it's something completely
           different from this

   Molly: The problem here is a lot bigger than maybe we even imagine
   Molly: CSS Layout is a bear. Now the concerns I want you to come back
          to is to ask ourselves who is the customer, who is to user
   Molly: The author is the user. Based on that, the integrity of grids
          and the long history that designers have, should be maintaine
          by calling it grid. Simultaneously a template is a grid, but
          more like table model. Grid system is a line system. We have
          to do this correctly or we end up harming authors more than
          helping them.
   <Bert> q+ to say that most lines in a grid have multiple functions:
          the same vertical line delimits text in the first row and
          images in the second. Finding a name for that line is going
          to be difficult.
   Tab: So you're saying we should rename the spec
   sylvaing: The grid model here is familiar to anyone who understand
             tables. Don't understand why that's bad
   jdaggett: model is not as familiar as you think
   jdaggett: This is an *application developer's* model of a grid.
             It's not a graphic designer's concept of a grid.
   jdaggett: What I do think needs to happen is that Peter and Steve need
             to iron out a concrete proposal of how to change what's there
             into what you want.
   sylvaing: Different designers are comfortable with different models
   sylvaing: We need both
   plinss: I believe we can have a unified grid model.
   plinss: That has the functionality page designers want, but allows you
           to address things the way the spec defines it.
   plinss: I want this unified grid model. I don't want Yet Another layout

   Florian: How to get there?
   Florian: Should we yank the bit that's currently in the spec, or leave
            what's there until we either find a replacement or an addition
            that makes it better?
   plinss: If we yank it now, we've gone down the path of the application grid
   Florian: Maybe the solution you want will replace what's there, maybe
            add to it
   jdaggett: Let's mark the spec with a big red issue, mark it as under
   Florian: Add an issue next to the bits proposed to be yanked, saying
            these bits are trying to accomplish [insert description of what
            plinss] wants. We are still looking for a way to address that
            problem well.
   Tab: I would not tell our implementers to implement grid lines as they
        are in the spec
   Tab: Leaving it in leave the spec in a weird state that we have something
        we *know* we don't want
   Florian: Should leave work in progress in the spec so people can build on it
   jdaggett: I think Tab's arguing that we shouldn't put things in our specs
             that we know are complete rubbish.
   Tab: I doubt the correct solution is an evolution of the current spec
   fantasai: What Tab is saying is that anyone working on this problem would
             be better served by a blank slate than starting with what's there.
   plinss: Tab made a point that named lines complicates the model. It doesn't,
           it only complicates the syntax of addressing the model.
   jdaggett: Can we wrap this up with an action item?
   jdaggett: I'd like an action on Peter and Steve to come up with a concrete
   ACTION szilles and plinss to describe a line-based layout grid unified
                             model of everything
   ACTION pcupp Add note Florian proposes to the spec
   <trackbot> Created ACTION-500
   pcupp: we tried to bring this into the model and failed. we need you to
          show us the way
   ACTION plinss draft note Florian proposes and send it to pcupp
   <trackbot> Created ACTION-501

   pcupp: Next item...
   pcupp: I have another thing describing anonymous grid items and how we
          create them
   pcupp: There are some images there that help show this
   pcupp: Current behavior in spec mirrors Flexbox behavior
   pcupp: All children of grid are grid items, loose text is wrapped in
          anon grid item
   pcupp: A complaint is that these items all stack on top of each other
          in the first cell
   pcupp: If you turn on auto-flow, you'll get separate grid items that
          flow into boxes
   pcupp: What we recently discussed on a last telecon, talked about what
          if we did something different
   pcupp: What if we wrapped all the contents of grid element into one
          anonymous grid item
   pcupp: and pulled actual grid items out of the flow of the anon one
          and positioned them
   pcupp: Default grid item could be auto-positioned, or put in 1-1
   pcupp: and so you get third image
   pcupp: Introduced one more idea, what if you use this concept of
          everything in anon item
   pcupp: and allow descendants with grid-pos properties to be pulled out
          of the flow, not just direct children
   pcupp: fantasai pointed out a point recently, wrt markup
   pcupp: e.g. form elements inside list items
   pcupp: say you wanted labels in 1st column, inputs in 2nd column
   pcupp: what do we do with this remaining markup? does it collapse down
          to nothing?
   pcupp: With descendants pulled into grid, have this issue
   pcupp: Then the conversation on www-style, fantasai proposed we could
          deal with this by a new 'display: subgrid'
   pcupp: Then some discussion of pursuing subgrid, or deferring it
   pcupp: Question to WG is, do we address this now, or defer to later
          level and just try to handle compat now
   Tab: I support wrap everything in anonymous grid cell and pull things out
   Tab: I think that also happens to solve the problem of what to do with
        leftover markup when you pull descendants out
   Tab: goes into anon grid cell
   pcupp: How do we keep it from displaying
   Tab: make anon cell display: none by default
   fantasai: So what you're proposing is that if something's display:grid,
             then suddenly the things inside it wouldn't show up.
   fantasai: We try not to have things disappear by default
   fantasai: try to have things show up by default
   Tab: Template had default slot concept
   Tab: Could even have that be the default template
Scribe: dbaron
     fantasai: Pulling things out into the ancestor and having grid stuff
               all float together seems like a good idea.
     fantasai: we have a grid-auto-flow property that would let us switch
               into auto placement

     fantasai: My concern with pulling sub-grids into a later level is
               that it seems like a lot of markup that we want to lay out
               with grid has structure to it.
   fantasai: You want several layers of descendants to participating in
             the same grid and align together.
   fantasai: To use the current level of grid you'd have to strip out that
             markup, and couldn't have graceful fallback to non-grid layout.
   fantasai: So my concern with deferring it
   fantasai: ... is that if it was possible to add later and still be
             possible to have sane markup at the current level
   fantasai: ... but I'm concerned that we can't.
   fantasai: Bert brought up -- mail on www-style
   fantasai: <fieldset> <ul> <li> <label> <input> </li> <li> <label> <input> </li> </ul>
   fantasai: you might want to have label and input and put borders around
             each pair
   fantasai: [draws]
   fantasai: want to align the labels and the inputs
   fantasai: if you don't have subgrids you can't do that -- you either
             have to strip out the markup or keep it styled so that it
             will effectively disappear
   fantasai: this seems like a sensible common use case for ui grids --
             to style intermediary list-item
   Peter: When you use the term sub-grid, you mean children or descendant
          elements, not grids within grids?
   fantasai: the idea was that display:subgrid behaves like display:grid
             except that the children are laid out into the same grid as
             the parent instead of creating new grid lines
   fantasai: but coordinates are scoped and margins and padding are
             subtracted out
   Steve: Is it a way of changing what the items are?
   fantasai: I should pull up my email...
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Aug/0310.html
   Phil: In fantasai's proposal, she's saying the grid lines are permeating
         the descendants with display:subgrid
   Phil: It's their children or however far you drill down... it's those
         items that influence the content-size tracks of the grid.
   Phil: ??? to account for margin / border / padding on ancestor elements
         by pretending they have larger margin
   Phil: Has great potential, I like the ... .
   Phil: In level 1, is it not a reasonable requirement that people tailor
         their markup so they have the items at the right level to operate
         on the right grid level?
   Phil: I don't know why we couldn't add this in a later level of grid.
   Phil: And people need to be able to author markup with subgrid in mind today.
   Phil: The issue isn't about authoring with subgrid in mind; it's about
         authoring the markup as it should be and then choosing to display
         it wit grid.
   Tab: Example markup in wiki: this kind of thing is very reasonable.
   Tab: The correct way to mark up html that puts the significant parts as
        not children of the grid
   Phil: But in this example I created it to illustrate a problem that
         exists due to markup structure.
   Phil: But I could have collected labels and inputs as children of grid.
   Peter: What you would have lost is how these things behave on a client
         that doesn't support grids
   Tab: or a client without CSS at all?
   Florian: You write the markup because it's the correct way to mark it up,
            then style it.
   Tab: You sometimes need to adjust your markup some... the question is
        what's too much in terms of requiring adjustment in markup.
   Tab: Having to flatten all children seems like too much.
   Tab: Case of figure -- pulling out img and figcaption -- can't do that
        without losing markup connection from <figure>.
   Bert: With example on whiteboard -- issue is how you get a border around
         2 things that are individually positioned.  That's not just a matter
         of markup, also the issue of how to make a border around something
         that's not a single cell.
   fantasai: This isn't an issue about creating pseudo-elements, since it's
             something that the markup has or should have already.
   Phil: One issue about border -- not that I'm saying it's how it should
         be done -- could be done with layering another element.
   fantasai: But you need to put margins on 3 sides of both things... could
             get hairy with arbitrary children.
   Tab: Subgrids good for this kind of case
   fantasai: Subgrids work like this:  if I want to position item into a grid...
             look at children and see how many cells spanning ...
   fantasai: [draws]
   fantasai: take up this many slots in the parent grid
   fantasai: From children's perspective, this is the numbering system,
             but for parent and numbering system *this* is the positioning
   fantasai: children affect sizing of parent grid, except extra margin
             added to items to account for subgrid's margin/border/padding
   fantasai: That's the idea, and it would solve this problem.
   Bert: I don't understand how it solves this problem.
   fantasai: you'd give the li { display: subgrid }, li would be a grid
             item inside this grid; the label and the input would be grid
             items inside the subgrid
   fantasai: the items in the subgrid participate in the parent grid,
             so [points at drawing]
   Peter: I'm not sure why you need to create the level of subgrids --
          couldn't the li be placed in cells and its children be placed
          in other cells?
   fantasai: The children would then need to know the grid position of
             its parent
   Peter: So its grid coordinate system is relative to its parent
   Steve: constraining the range of auto fill
   Steve: In some sense you're making grid items out of the children,
          but there's more to it than that.
   fantasai: You're scoping their positioning, and you're taking the
             distance between margin and content edge of the parent
             and using it to change the size of the grid cells the
             items are going into so they stay inside each other
   fantasai: As Phil said, you can do the same thing manually by manually
             computing the right positions and the right extra margins
             on the items.  But you have to track row/column and amount
             of margin.
   Steve: I'm unclear how the border gets done
   fantasai: you just put a border on the li -- it's there
   Steve: ah, ok
   Phil: So if everybody understands that -- back to the original question
   Phil: So Tab wants to see it in level 1.
   Phil: The more we try to solve in level 1 the further it is from being
   Phil: We'd like to have a version of the spec to point to that reflects
         what we have in the marketplace
   Tab: I'm fine with subgrid being in level 2.  I don't think it's required
        for basic grid functionality.  But I think being able to pull
        descendants out for your grid is necessary functionality.
   Tab: ... there are required or recommended markup patterns in HTML that
        prevent you from flattening children
   Phil: I was coupling the subgrid solution fantasai proposed with the
         solution for what we do with the solution for leftover semantic
         markup, and I'm hearing Tab say we could defer subgrid and find
         other solutions for the semantic markup
   Phil: ... could solve it in another way... what do we do with the semantic
         markup, maybe a mechanism for hiding it or something?
   fantasai: I'm not sure I'm comfortable with deferring this problem
   Phil: I'm not sure what that solution is; could take an action item
   Phil: I'd prefer not to tie that to level 1 at all.
   fantasai: Not sure if I full-on object to that, but afraid people will
             do bad things to their markup.
   Tab: subgrid or descendants being pulled in?
   fantasai: pulling is good; concern is about subgrid
   fantasai: Concern about people doing weird things to their markup to
             make alignment happen, impact a11y etc, bad markup practices.

   Phil: To be clear, I was talking about removing descendant positioning
         as a whole.
   fantasai: I think that's something you can't turn on in the future
             because it would break existing content because of random
             grid positioning properties on descendants.
   fantasai: Could create a positioned-grid value required to pull
             descendants and turn it on that way
   tab: I'm concerned about contortion of markup patterns
   tab: I think the solutions to do pulling descendants without subgrid
        are hacky on CSS side but won't encourage contortion of markup
   fantasai: I think they both will
   Phil: What about flexbox?
   fantasai: We didn't have use cases for pulling descendants into the
             main flexbox
   Tab: can also address all of those use cases by making the wrapper a
        flexbox as well... and that's not true of grid
   fantasai: because of the alignment across both dimensions
   Phil: ok, so we're resolved to continue pursuing descendant solution,
         but not requiring subgrids as part of that solution?
   Tab: That's what I want.
   fantasai: I want to hear from other people

   Steve: Weak approx to subgrid called honor-descendants
   Steve: Have to explicitly say I want to say descendants positions should
          be interpreted, but I don't get extra mechanisms of subgrid
   Tab: That solves problem of stray grid positioning
   Tab: But it doesn't solve problem of people having to distort their
        markup right now to flatten everything into being children of the
   Steve: I thought I'm turning it on so I didn't have to flatten.
   Steve: Treat my children as being me.
   Tab: So you're saying do that right now?
   Steve: I'm saying to do that right now is a way of doing the descendants
   Tab: I don't think we have a problem with needing to be explicit right
        now.  The reason to need to be explicit is if we're delaying it
        for the future.
   Bert: why need a property at all?
   Florian: We only need it if we introduce it later, and thus it needs
            to be opt-in
   Bert: but the default should be on
   Tab, Florian: yes
   Steve: But it doesn't interact with subgrids?

   Tab: We can patch this by saying that if a particular descendant wants
        to escape out -- still future-friendly for subgrid.
   fantasai: I don't dispute that -- my concern is markup on whiteboard
             (input/label) -- people want to put border around input/label
             pairs  -- and have that markup structure, e.g., for non-CSS
   fantasai: Fact that we can't handle that right now without really being hacky
   Bert: As long as you don't want image borders...normal borders you can do.
   Bert: 3 borders on left cell and 3 borders on right cell
   fantasai: label inside there... input has its own borders
   Tab: People could hack it into working just with CSS
   Tab: What are you concerned people will do to their markup to help that?
   fantasai: Not sure, but I think it would be pretty ugly.

   Bert: Another worry with subgrid:  if you suddenly take margins into
         account, things don't line up anymore.  The label is no longer
         left-aligned to the frist grid line because there's a margin
         in-between.  So if it's 100% it's 100% of something else --
         the left over space -- not the grid.
   Tab: The leftover space, given the grid and the extra margin.  It will
        still work as long as we define it correctly.
   Bert: I think it will be difficult to design because of subtracting margins.
   fantasai: If you didn't want the space then you wouldn't put any padding there
   Bert: But you're already putting the label within a grid cell, so you'd
         expect it to line up with the grid cell and not be influenced by
         something else.
   Tab: As long as we craft the spec correctly, we can all make it work
        correctly -- even if you're pushed in on the left your right edge
        will still line up with the grid.
   dbaron: I think what Tab is saying that is if you didn't want the subgrid
           to cause things to not be lined up with the parent grid, then
           don't put margins/borders/padding on it
   dbaron: And then it will line up
   dbaron: But if you do put margin/padding/border, we honor them
   Bert: it works out -- but you're assigning things to the same grid
         column and they don't line up.  That's confusing.
   Tab: That's the actual functionality of subgrids.
   Steve: If you don't put margins on the li, then it lines up.
   Tab: yes.
   Steve: You have the option of getting more indent.
   fantasai: I think we should resolve on doing descendants going up into
             grid, mark subgrid as something to think about.
   RESOLVED: descendants of grids can be positioned into the grid as part
             of Level 1, mark subgrids as an issue to think about

   fantasai: Do we want to have that happen with position:grid, or just
             happen if your row or column is non-auto?
   Tab: Oh, key it to something else like position:grid?
   Phil: I think I like the row-or-column-is-non-auto.
   Phil: Sorry, I think we'd need to introduce new value like none for
         grid-row or grid-column
   Tab: You want most of your descendants to not do anything special
   fantasai: Initial value would be none.
   Phil: For children of grid, in anonymous default grid item, would need
         to give them grid-row/column: auto
   fantasai: Disadvantage: If you want to turn on auto positioning you'd
             need to turn those all to auto *and* turn on auto positioning
   Tab: alternative is to make none compute to auto for children of grid
   varous: no
   fantasai: so looks like either we can have descendants be positioned
             into the grid if they're non-auto row/col, or we can have
             auto-positioning be a single switch, but not both
   fantasai: so we need to think about that

   Steve: Had a question about default cell:  why do you want to throw away
          the content if it's group into this default ...?
   fantasai: I don't think we want to do that.
   Tab: I just think we may want to allow you to throw away the content.
   Tab: I'd prefer if it didn't make anything disappear until you actually
        position some children.
   Tab: need to make sure that works properly
   Bert: More generic problem there:  in many cases there are things you
         want to throw away even though the children of the thing should
         still be displayed
   Bert: We might want to have something that throws away everything except
         things that really want to be displayed.
   Bert: useful for collapsing lists
   fantasai: visibility:collapse but done right?

   Phil: Next issue is the shorthand naming.
   Phil: We added a bunch of new shorthands into latest ED.
   Phil: I think we're pretty happy with names -- discussion about what
         used to be grid-rows and grid-columns -- now grid-definition-rows
         and grid-defintion-columns -- to make them more distinct from
         grid-row and grid-column.
   Phil: Some suggestion of grid-row-tracks and grid-column-tracks instead
   Phil: suggestions?
   Tab: I agree with renaming -- grid-row vs. grid-rows was bad.
   Tab: Not super-happy with grid-definition-rows
   Phil: Recommended process for resolving on names?
   fantasai: Brainstorm for a bit, straw poll.  If nothing good, try again
   Bert: grid-columns and grid rows for definitions, grid-area for positioning
   Tab: I think grid-area is shorthand for all 4 at once
   Bert: Could say there are no individual property and just use shorthand.
   fantasai: I think there are use cases for longhand, esp. with auto
   Tab: [rapidly-described use case combinatorics]
   Bert: They always have an x and a y position anyway.
   Tab: I think it's useful to do x and y separately.
   Tab: e.g. say all of these are in this column, this one's in this row,
        that's in that row, the other's in the other row
   Steve: Instead of putting extra word in the definition, put it in the use?
   fantasai: Problem with that is that it's the one you're going to type
             the most.
   Bert: I think that's not the case.
   Bert: I think you're going to use the positioning less than the definition.
   Bert: Most grids will not be used with positioned elements not elements
         that are flowing.
   Bert: So you don't need explicit x and y wery often.
   Tab: Don't know about this.
   Tab: I think that reasonably commonly -- grid-area works -- but still
        quite reasonable and reasonably common to do x and y positions
   fantasai: Another position was grid-template-rows/columns/slots for the
   Bert: I like shorthand shorter:  grid not grid-template.
   Tab: Nice ideas, make sure they get pulled into brainstorming thread.

   Phil: There was a side discussion during break, with tab fantasai peter
         steve bert.
   Phil: Did you settle on something?  Did you decide to remove named lines?
   Steve: There were 2 discussions I could recall.  Nobody was in favor of
          current syntax, but were in favor of model.  Discussion about
          whether that meant to remove syntax or not.
   Steve: Consensus that syntax improvement was needed.
   Tab: One of us should put together better syntax for named lines
   Steve: peter gave an example of usage of lines that acts as illustration
          of issue Peter actioned to work on:  being able to delete a named
          line and having the positioning default in a useful and predictable
   Steve: ... so that you can do media queries to set up grid and where the
          lines fall fall out in a natural way, and you don't have to rewrite
          a lot of your code for each media queries.
   Phil: ok, I think I heard those
   Tab: Useful part:  can we remove the current syntax because we're going
        to do better and soon?
   Steve: If we can come up with something in a week we'd certainly put the
          new syntax in.
   [Tab still wants the old syntax out, but gives in]
   * TabAtkins sad face.
   <TabAtkins> I'm not going to tell my implementors to do the current named
               line syntax.
   <TabAtkins> And I hope no one else does either, so there's no sense
               keeping it in there.

   Phil: I'm just going to wrap up with status:
   Phil: ... updates recently to grid.  Template property now taking identifiers.

   Phil: ... automatic placement algorithm updated based on discussion with
             fantasai -- forward only, no backfilling
   Phil: ... new shorthands just mentioned
   Phil: ... next steps: editors work on descendant piece, work on gutters
   Phil: ... not sure if this was implied -- we also plan to pull in
             column/row-rule with column/row-gap
   Phil: ... and issues in bugzilla we'll start working on.

Received on Wednesday, 29 August 2012 23:36:32 UTC