- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Dec 2014 20:46:00 -0500
- To: www-style@w3.org
Grid
----
- 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
behavior.
- 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
https://twitter.com/AlanHogan/status/519256635911307265/photo/1
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.
===== FULL MINUTES BELOW ======
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
ours.
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
this.
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
subscript.
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
something?
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
forever.
<leaverou> plinss++
florian: We're weighing the pros and cons.
TabAtkins: Any argument we make here is for anywhere we use
parentheses.
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
that.
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
inconvenient.
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
deal.
fantasai: We're saying next time we have this problem they have to
deal.
<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
past.
plinss: But if we had done the opposite we would be in the same
place.
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
layout.
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
down.
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
flex.
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
equivalent.
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
models.
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
unfortunate.
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
problems.
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
reasonable.
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
block?
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?
Shrink-wrap?
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
for.
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
layout.
TabAtkins: Alright.
TabAtkins: Can you send a reminder to what wording you want in
flexbox?
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
tomorrow.
[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
that.
ArronEi: I don't want to create new tests until I have everything
documented.
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