- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 27 Apr 2018 14:28:52 -0700
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Grid L2
-------
- Author expectations and use cases were toward having the per-axis subgrid
(Issue #2280) however several people needed more time to review the spec
text so the group will revisit this issue later in the F2F.
- RESOLVED: Add an ar unit to the grid 2 spec for align-content and
justify-content. (Issue #1116)
Grid L1
-------
- The group believed that the Grid algorithm could still be adjusted to
accomplish the use case in issue #2356; however the correct adjustments
weren't immediately clear. TabAtkins and fantasai will look into a
post-processing step that was suggested and Florian will reach out to
Bert to see if he has any insights.
https://github.com/w3c/csswg-drafts/issues/2356#issuecomment-379878492
- RESOLVED: Edit in Rossen proposal in issue #2177 "Spanners that cross tracks
that have content-based mins AND flexible maxes only contribute
content sizes to those tracks; otherwise they participate normally."
https://github.com/w3c/csswg-drafts/issues/2177
- RESOLVED: Alignment and gaps in multicol behave exactly like grid and we
will add a note explaining the concerns in the issue and how to
solve them. (Issue #1420)
- RESOLVED: Remove these terms (row-axis and column-axis) from the grid spec
(Issue #1299)
Alignment
---------
- RESOLVED: Zero out percentages on non-sizing use of calc. (Issue #2297)
- RESOLVED: Fallback alignment for last-baseline is 'safe end' (Issue #1611)
- RESOLVED: Publish a new WD of Alignment with the one edit from the baseline
resolution.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule
Scribe: dael
Grid Layout Level 2
===================
Spec: https://www.w3.org/TR/css-grid-2/
Dual-axis vs. Per-axis Subgrids
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2280
fantasai: Issue with grid L2: it has some proposals and no feedback.
I can't do anything to go forward.
fantasai: Open issue says, here's 2 proposals for subgrid, which do we want?
fantasai: I wanted to bring this up because there's strong requests from the
community to do this, but the spec for subgrid is, well, there's
2 specs for subgrid. I don't know what to do next.
florian: Is there author feedback?
rachelandrew: I have feedback. Authors really want subgrid. The use cases
I've seen are tied to single-dimension subgrid...
the proposal that was pulled from L1 wouldn't solve them.
rachelandrew: People want the columns to be subgridded. They don't want to
define the rows. Having it locked to both dimensions would be
more frustrating then useful. Things I've seen assumed one
dimension.
fantasai: Proposal is then to resolve on per axis subgrids.
Rossen: Didn't we decide in Tokyo?
tantek: We added it as a possibility in Tokyo.
Rossen: Sounds good to me. I thought we did that.
Rossen: This is the 1.5 dimension model?
fantasai: No, the way we set things up there's not many changes from one
version to the other. Differences are in green.
https://www.w3.org/TR/2018/WD-css-grid-2-20180206/#subgrids
fantasai: Main change is for per axis you need to ensure that if you're
interweaving the algorithm of the parent and child grids.
fantasai: Algorithm is all defined. That's where spec is at. I think
it's complete, mostly.
astearns: Do we have impl?
fantasai: I don't think anyone is working on subgrids.
TabAtkins: Mats was interested and opposed the non-per axis. That's what
Igalia partly implemented.
rego: We didn't impl anything yet.
<tantek> Mats is working on it, see the Firefox subgrid meta bug
(with dependent implementation bugs)
https://bugzilla.mozilla.org/show_bug.cgi?id=1240834
fantasai: Syntactic difference is the per-axis version has a subgrid keyword
on grid-template-rows and grid-template-columns.
Dual-axis was a keyword on display.
astearns: Would anyone object to single axis subgrid?
TabAtkins: No one has described how to do it yet.
fantasai: It's in the spec. Here's the algorithm (section 2.4:
https://www.w3.org/TR/2018/WD-css-grid-2-20180206/#subgrid-sizing )
astearns: It's specified as a diff to a doc with both.
fantasai: It inlines everything in. It just has two colors of ink.
astearns: Anyone besides TabAtkins have concerns on single axis subgrid?
rego: Seems more complex to impl but it would be good to know use cases.
If there are clear use cases where we need this it's fine.
rachelandrew: I brought use cases to the last F2F but I rarely see something
from an author that works for double axis. An e-commerce site
that has a template where they want it to work no matter if
there's 2 rows or 6 rows of stuff.
rachelandrew: Let me see if I can find the examples.
<rachelandrew> https://codepen.io/rachelandrew/project/editor/68cc7a5da9cfbb56c6e8366d7d92e6ba
<rachelandrew> this is a better view, some examples
https://codepen.io/rachelandrew/project/full/68cc7a5da9cfbb56c6e8366d7d92e6ba/XWYGMD/
astearns: Would people object to dual-axis subgrid?
florian: I think rachelandrew would.
astearns: I'm hearing some people for and against single axis subgrid but
I haven't heard opinions on per-axis besides everyone thought
it was too hard to get to for the first level of grid.
<tantek> IIRC, all variants of subgrid were too much for grid level 1
Rossen: I still agree it was a good move to hold it back. To your second
point as to if dual- or per-axis is what we want, now that we can
reason about it and think holistically the dual-axis is an easy
shortcut to cover some use cases but during Tokyo I heard enough
compelling reasons to have the per-axis variant. I will admit I
haven't reviewed the spec. But I prefer the per-axis one. I don't
think there will be all that much work per-axis, at least in our impl.
astearns: Perhaps we could leave it at people should review the spec and
look at the use cases and then come back soon?
rachelandrew: I could probably get more use cases now that people are
using grid.
astearns: Is there an issue for choose which approach?
fantasai: Yep. https://github.com/w3c/csswg-drafts/issues/2280
astearns: I suggest we continue discussing in that issue.
astearns: Anything else?
fantasai: When do we want to return?
Rossen: End of F2F.
astearns: We can try and bring this up end of Thursday. Then perhaps we
can make a decision then.
astearns: Please take breaks or lunch time if as you read you have questions.
dbaron: Would it help to get Mats on a call?
fantasai: It would be good to have Mats look and reply on github.
fantasai: I haven't heard from him.
dbaron: If you want me to poke him can you send me what you want me to do?
fantasai: Review the spec and comment.
fantasai: And if there's nothing wrong with it say it's good.
florian: Also express a preference? Or he always has.
"equal gutters" with justify-content on grid items
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1116
astearns: Other part of grid L2 as aspect ratio controls.
fantasai: We resolved to add this to the first level of the WD.
Just a request for people to let me know what they think.
TabAtkins: Other than that I want a unit on these I think it looks great.
fantasai: Unit proposed is ar unit for aspect ratio.
astearns: Two options are a bare number or an ar unit.
fantasai: I'm open to name suggestions.
TabAtkins: I regret not putting a unit on flex.
astearns: Could ar be used in other places?
TabAtkins: A generic aspect ratio.
florian: It's mathematically unitless.
fantasai: It's a multiplier.
TabAtkins: Whatever the other thing results in, multiply it.
florian: Does the unit thing play into if we want to ever use calc on it.
TabAtkins: Numbers tend to cause parsing issues. It causes issues on the
flex things. I'd prefer not to continue that pattern. This
has a specific meaning so it should be tagged in a specific way.
Angles are just numbers.
fantasai: They're not.
TabAtkins: They're radians which are just an ID.
<ChrisL> how are radians an ID?
<TabAtkins> ChrisL, Radian is (length of arc) / (length of radius),
which is unitless
<ChrisL> an aspect ratio is (by definition) a ratio. It is a length
divided by a length, and thus also unitless.
<TabAtkins> Yes, that's my point. We already associate units with "unitless"
things, to give it an easily-interpreted meaning and help with
parsing. This is the same deal.
<ChrisL> remember though that whenever we add units, it stops those things
being used in custom properties, because we can't divide by unit-ed
values
fantasai: Somewhat related issue has been aspect ratio units for grid, #1173
fantasai: There was a request for having an aspect ratio in the grid spec.
A lot of the cases we want to have are covered by an aspect-ratio
property that can apply to grid items (driving auto-sizing in the
other dimension).
fantasai: Question was if there isn't an element can you assign the aspect
ratio property; then we need another approach.
fantasai: You might decide you have a bunch of fr columns and you want the
rows to be 1:1. Once we add aspect-ratio, if there's at least one
element you can key off of you can auto-size the rest. If you
don't put anything the auto row collapses to 0.
astearns: The only things in having that row were spanning it would be weird.
fantasai: One proposal was to have an ar unit in grid template columns that
would represent the aspect ratio multiplied by track size in the
opposite axis. Problem was, what if there are multiple tracks of
different sizes?
fantasai: Proposal I had is 1ar is always resolved value of 1fr in the
opposite axis.
florian: You can't map to a column 'cause you don't know which to match.
fantasai: It's not clear what we need to do for this issue.
astearns: And a side discussion.
fantasai: A unit may be useful in this case.
astearns: So do you want to resolve to add a ar unit?
TabAtkins: If we accept the proposed syntax I feel we should have a unit.
ChrisL: Remember when we add units you can't use them in custom properties.
You can't divide by an ar.
TabAtkins: You can, it works now.
<TabAtkins> (I've been slow to add the functionality to calc(), but we
resolved to do so a while back, and Typed OM allows it.)
<ChrisL> fair enough; would be good to see that agreement in the spec,
and implemented
astearns: Objections to adding an ar unit to the grid 2 spec for align content
and justify content?
RESOLVED: Add an ar unit to the grid 2 spec for align-content and justify-content.
astearns: Anything else on grid 2?
fantasai: It's just those 2 things. Once we have agreement on subgrid and
someone has read it [and there's no issues] I'd be happy to request
CR.
astearns: I'd like to get an impl started.
astearns: I'd also like to see progress on grid area styling proposal.
fantasai: That's grid 3. Grid 2 is just subgrid and this one other small
thing. Styling of grid areas is more complex spec-wise for sure
(uncertain about impl-wise). In terms of figuring out the spec
that'll be harder.
Grid Layout Level 1
===================
Can the sizing algo be made to deal with this
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2356
<florian> https://florian.rivoal.net/csswg/grid/grid-span-auto-001-ref.html
florian: I was laying out a page of manga using grid so each cell is a grid.
It should layout like ^
florian: Defining a bunch of columns and rows and everything can fit,
but it's manual.
<florian> https://florian.rivoal.net/csswg/grid/grid-span-auto-001.html
florian: Here's what you get ^
florian: It has unneeded empty spaces.
florian: I think this boils down to current sizing algorithm not considering
enough things. It's described as a possibly improvable heuristic.
If we agree this is a good thing to solve... it sounds desirable...
florian: I think this is linear programming solvable by constraints. I'm not
good enough at math to put the steps but I think this is solvable.
<TabAtkins> Very simple example:
https://github.com/w3c/csswg-drafts/issues/2356#issuecomment-379878492
TabAtkins: Simple example ^
TabAtkins: [explains example]
TabAtkins: We take the largest of the planned increases so we're not loosely
wrapping each item. Ideal would be the latter image. It's one
possible version.
florian: I believe an algorithm exists that could solve it... or are we too
locked into compat?
fantasai: I think we should be able to make the adjustments here. I don't
think anyone depends on this slight amount of slack. As time goes
on we might get more constrained but I think we're not at that
state. If we could solve it it would be great, but I don't know
how to do it.
florian: I might be able to research the theoretical algorithm but I'm not
right person to say if it's implementable.
fremy: I've been working on some layouts and you can do a post-process to
reduce the sizing.
TabAtkins: This example (bottom of link) it shows one possible switch.
But there's several ways to solve it like making the columns
50,250,0, which is a big change from the current way they lay out.
florian: Some examples have a range of solutions, mine has one solution.
florian: I think it's worth looking into if there's a general option that
we're not blocked in. I'd appreciate a mathematically-inclined
person to help. Maybe do the current algorithm and squish would work.
fremy: Browsers have already implemented grid and we don't want to change
the whole algorithm, so a post-processing step is easier.
TabAtkins: And your site may be doing it for you. In the manga example your
images have known widths, it's just easier if CSS does it for you.
fantasai: TabAtkins and I can take an action to look at adding a
post-processing step to see if that works.
fantasai: Maybe send a email to bert with a link to this issue to see if
he has some insight?
ChrisL: We were talking to people from Monash University with expertise.
fantasai: We also had César who was working on an impl of Bert's grid spec.
florian: I think the trickier part is that this is more complicated.
If we have auto sizing it's simpler. If you have one min and one
max you span. It's much harder to explain to people that don't
know CSS but I'll try.
astearns: Anything more?
florian: Nope.
Grid track sizing items spanning a flexible track
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2177
rego: Quite related, you have an item that spans 2 columns.
One of them is outside its flexible track, and we weren't sure
what would be the best result. We're not sure what's the core
approach. Rossen was trying to clarify in the last comment.
astearns: There's a specific tweak to the algorithm you propose?
rego: Original algorithm was aligned that you don't expand a track
with a flexible track sizing. Maybe we can open the use cases.
fantasai: We should try Rossen suggestion in the issue and see if it
works. I haven't fully thought it through but that's what
I'd want to try.
Rossen: When we looked we played with magazine layouts. One recurring
thing was when you have a splash page when an item that spans
N columns and want to influence rest of layout. Those columns
need to be flexible when you're on a browser. That was the
original motivation.
Rossen: Since then in the issue... we can go either way. I don't think
there's enough concept to support one or the other. What I
proposed should work.
fantasai: Makes sense to me.
astearns: Do we need a resolution to edit in Rossen proposal?
fantasai: Resolution to add Rossen proposal and we'll revisit if
there's a problem.
RESOLVED: Edit in Rossen proposal in https://github.com/w3c/csswg-drafts/issues/2177
'justify-content' on multicol
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/1420
astearns: We've discussed in the past.
TabAtkins: As florian says from third to last comment, right place to start
reading is the one above.
<fantasai> https://github.com/w3c/csswg-drafts/issues/1420#issuecomment-303958104
TabAtkins: florian objections to current spec are 3.
TabAtkins: 1) in current spec you can't robustly fix the ratio of the
default column gaps.
florian: Fixed that.
TabAtkins: 2) default behavior of space between ends up with not the correct
ratio because space-between space is added. Trivial fix, if
you set column-gap to 0 it works. Solving it precisely would
involve special cases multicol if the column gap and so we'd
be against that.
florian: You should not set the column gap to 0, though, because depending
on the space you end up with it might be 0 and it's unreadable.
TabAtkins: Then you set padding.
florian: I'm not completely opposed to your proposal. Setting gap to 0 it
can be mushed so you get padding on the edges. Typically multicol
has text, though, and if you don't have room you fallback to block
which is good. But if you're forcing padding for space you keep the
padding when you collapse.
TabAtkins: I disagree. So you want space around. You leave column gap at
1em and padding to 1/2em on either side. I don't see why when
you go to 1 column that you don't want the 1/2em padding.
You put it there for a reason and I don't see why it goes away.
It goes away in multicol because it has no gaps, but you're
explicitly putting the gaps.
TabAtkins: If a single column you want the text flush you'd want that in
many columns.
fantasai: Like if you have 1 column and you split to 2 you don't want
padding on common container but you want a gap between the 2.
fantasai: Regardless, I'm opposed to different behavior between multicol
and grid.
rachelandrew: Authors wouldn't use space-around if they're not okay with
gaps on the outside. If you didn't want that you'd use
space-between.
rachelandrew: I agree we want to be able to maintain the 1em so people
don't set column-gap to 0.
florian: This issue traces back to before we merged the models. Now we have.
I'm okay with what you proposed, we just never discussed it. It was
just added to the spec. If everyone agrees.
fantasai: Proposed that alignment & gaps in multicol behave exactly like grid.
astearns: Close no remaining changes.
TabAtkins: I could go with a note for how it works.
fantasai: I think people know how to do padding. They figured it would for
grid so you'd have to have a note in both.
florian: There's many ways to space in grid that don't require figuring
this out. I think a note wouldn't hurt. Doesn't have to be multicol
specific, but I think it would help more there.
astearns: I'd prefer the note because it shows we considered this, discussed,
and have a solution. As people read they can agree or disagree.
Without a note it's fairly opaque.
astearns: Proposal: alignment and gaps in multi col behave exactly like grid
and we will add a not explaining the issues in the issue and how
to solve them
astearns: Obj?
RESOLVED: Alignment and gaps in multicol behave exactly like grid and we will
add a note explaining the issues in the issue and how to solve them.
Axis Names
----------
github: https://github.com/w3c/csswg-drafts/issues/1299
fantasai: SelenIT commented that rachelandrew's articles had the opposite
meaning of row-axis and column-axis as what's in the grid spec.
We only use them in a handful of places, and since most people
learn grid from rachelandrew it's probably better to match her
terminology.
rachelandrew: I've commented before that people struggle to learn this.
People are used to a main and a cross which you don't have
in grid. People are explaining it all sorts of ways. It's
gone around and around.
fantasai: 3 options:
1 is don't change the spec.
2 flip to match rachelandrew.
3 remove terminology.
<fantasai> Reasoning for the spec's usage is in
https://github.com/w3c/csswg-drafts/issues/1299#issuecomment-298106439
<fantasai> terminology is in https://drafts.csswg.org/css-grid-1/#grid-concepts
TabAtkins: I'm in favor or removing the terminology. Both schemes make sense.
Flipping to the other doesn't have a compelling reason because
other people will not understand. We should use block and inline.
rachelandrew: I prefer block and inline.
Rossen: rachelandrew can you fix and teach people the way we have intended
this to be spec?
rachelandrew: I'd prefer us to use block and inline.
Rossen: I think it's fine but also spec what the row and columns are correctly.
fantasai: Note that the axis names appear 3-5 times total.
Rossen: I'm slightly opposed because the column-axis and row-axis are
something which applies to internal layout of grid. Easy to
rationalize which is which. Even thought inline and block axis
apply externally the two aren't necessarily the same.
fantasai: Actually they are exactly the same.
fantasai: Question for you--don't look at the spec
fantasai: Which is the row axis? Horizontal or vertical?
Rossen: Vertical.
fantasai: It's horizontal in the spec.
fantasai: If we want to match your head we need to flip.
Rossen: Row is if you add more rows so it's how it advance.
plinss: Thing you put in a row progress horizontally.
astearns: I hear these terms aren't used much in the spec. What damage does
removal cause?
TabAtkins: Every time we use the terms we also call it block or inline
in parentheses.
fantasai: There's no occurrence of these terms where both aren't used.
astearns: Useless terms. Causes confusion. We should remove.
RESOLVED: Remove these terms from the grid spec.
<rego> the last comment in previous issue:
https://github.com/w3c/csswg-drafts/issues/1299#issuecomment-377490475
<rego> was suggesting about if it'd make sense to change the properties
"grid-column-start" to "grid-inline-start" and "grid-row-start" to
"grid-block-start" and so on
<fantasai> rego: no
<rego> fantasai: :)
Alignment: Closing out last few open issues and republishing
============================================================
Issues list: https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-align-3
calc() with percentages in margins/padding
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2297#issuecomment-376263348
<fantasai> Comment summarizing issue:
https://github.com/w3c/csswg-drafts/issues/2297#issuecomment-376263348
fantasai: It was to discuss zeroing out a percentage vs the entire expression.
Example calc (10% + 10px).
fantasai: Zeroing the entire expression is what's impl. Zeroing the percent
is more meaningful. This is for purpose of calculating the intrinsic
size of the element.
dbaron: It's also continuous in terms of what happens when you have a calc
that approaches 0 and you remove the calc.
TabAtkins: Are we okay with some properties having a different indefinite
percent with calcs?
fantasai: I prefer 0 out the percent.
florian: Justification to zero everything is just that it's what we have impl.
fantasai: I didn't hear anything.
Rossen: I agree with fantasai. Zeroing the percent makes more sense.
Having a box model with some percent and non-percent values results
in the same logic, where we would zero out the % values and add the
rest of the defined sizes
fantasai: For sizes like width/height, we ignore entire calc. We closed that
in #1132. Sorry, we throw out the calc and treat as auto.
Fallback to initial value.
fantasai: That makes sense for sizing in a way it doesn't here is if you
fallback to the original that has some kind of meaning. In this
ase there's no meaningful value for margins and padding.
astearns: In only zeroing out percents when not sizing is a discrepency.
fantasai: Correct.
asteanrs: Why do we throw out the expression for sizing properties?
florian: We can do calc of 10%+10px is the same as 10px but we can't do
auto+10px because that's not defined.
astearns: Arguments against only zeroing out percent on non-sizing props?
astearns: Objections?
RESOLVED: Zero out percentages on non-sizing use of calc.
Should last-baseline's fallback alignment be safe or unsafe?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1611
fantasai: Say you have a row flexbox and inside you have items with
last-baseline alignment, but the flexbox is larger than the items
we have to decide how to align them. Just like for first-baseline
you align and then start align the set at the top, we align the
last-baseline set at the bottom.
fantasai: But what if it's too small to contain all the items? In that case,
what happens? Do we continue to align at the bottom and the large
items overflow the top or do we take the things that are too big
and start-align them so they no longer participate in baseline
alignment?
astearns: From I can access and read safe is better, but from design unsafe
is better.
myles: Implementation difference.
fantasai: We were generally unsure before.
myles: Have we asked authors?
florian: Can we default to safe? Defaulting to safe sounds...safer? And let
authors opt-in if needed.
TabAtkins: We don't let you set it. It seemed like more switches then you
needed access to.
fantasai: We could make it possible to combine the keywords.
florian: I'd prefer default safe and have the keyword.
astearns: We last left this that someone would write a blog post.
fantasai: That was not done.
astearns: I don't think we should assume we will add a switch. We should
decide based on probability that this is a weird edge case so
it's not worth our time to have a switch.
TabAtkins: That's why we haven't done it.
Rossen: Can we resolve on choosing safe? If someone squeaks really hard
we'll solve it.
astearns: Objections to using the safe behavior in this case of last-baseline
alignment?
fantasai: All using the alignment properties.
astearns: In this case with content that will not fit in it's container and
we fail to be able to last-baseline align things, things will
overflow in a safe direction.
RESOLVED: In this case with content that will not fit in its container and
we fail to be able to last-baseline align things things will
overflow in a safe direction.
Publication
-----------
fantasai: New WD once dbaron says they're okay?
astearns: Objections to new WD once we get through some of the remaining
open issues?
ChrisL: I'd rather be told when it's approved, not we approve some time
in the future.
Rossen: Let's publish now and again later.
astearns: We just resolved 2 things.
fantasai: One was no changes.
Rossen: The one for calc was in sizing?
astearns: Objections to publishing a new WD of Alignment with the one edit
from the baseline-alignment resolution.
RESOLVED: Publish a new WD of Alignment with the one edit from the
baseline-alignment resolution.
<br type="short">
Received on Friday, 27 April 2018 21:29:23 UTC