- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 29 Aug 2012 16:36:01 -0700
- To: "www-style@w3.org" <www-style@w3.org>
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
connection.
<pcupp> can you hear us?
pcupp: If everyone looking at wiki link
pcupp: First topic is [dropped connection]
http://wiki.csswg.org/spec/css3-grid-layout?rev=1344977627#issues-for-san-diego-2012-f2f-meeting
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
once
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
module?
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
model
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
manually
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
idents
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
poster.
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
system
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
discussion
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
proposal.
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
system.
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
geometrically.
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
stable
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
grid
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
thing.
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
reasons.
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
later?
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
positioning.
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
separately.
fantasai: Another position was grid-template-rows/columns/slots for the
template.
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
way.
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