- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 24 May 2016 19:35:05 -0400
- 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.
=========================================
Flexbox
-------
- RESOLVED: Issue 1 the text for a11y is accepted.
Box Alignment
-------------
- RESOLVED: Apply justify-content to columns in multicol elements
- RESOLVED: Make “smart safe” alignment the default for handling
overflow; but put at risk with a note saying to
contact CSSWG if there is a problem regarding compat.
Grid
----
- RESOLVED: Keep the spec the way it is in regards to issue #3
(Abspos item placement in degenerate grids)
- RESOLVED: Keep spec as is in regards to issue #24 (Drop empty
tracks at ends or also in the middle?)
- Rossen was tasked with reviewing issue #39, missing 'auto'
changes for span>1
- RESOLVED: subgrid proposal accepted in the at-risk section
===== FULL MINUTES BELOW =======
Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics
Present:
Rossen Atanassov, Microsoft
Tab Atkins, Google
L. David Baron, Mozilla
Tantek Çelik, Mozilla
Dave Cramer, Hachette Livre
Elika Etemad, Invited Expert
Daniel Glazman, Disruptive Innovations (only IRC)
Daniel Holbert, Mozilla
Jihye Hong, LG Electronics (only IRC)
Koji Ishii, Google
Brad Kemper, Invited Expert
Ian Kilpatrick, Google
Chris Lilley, W3C
Peter Linss, HPI
Myles Maxfield, Apple
Edward O'Connor, Apple
Simon Pieters, Opera
Florian Rivoal, Vivliostyle Inc.
Andrey Rybka, Bloomberg
Hiroshi Sakakibara, Beyond Perspective Solutions
Simon Sapin, Mozilla (only phone)
Jen Simmons, Mozilla
Geoffrey Sneddon, Invited Expert
Alan Stearns, Adobe
Shane Stephens, Google
Lea Verou, Invited Expert (only IRC)
Greg Whitworth, Microsoft
Regrets:
Dael Jackson, Invited Expert
Hyojin Song, LG Electronics
Scribe: gregwhitworth
Flexbox
=======
<fantasai> https://drafts.csswg.org/css-flexbox-1/issues-cr-20160301
fantasai: As we mentioned, pretty much everything is fixed.
fantasai: We asked for people to review issue 1 and 3.
fantasai: We're asking for official resolution of those two, the
rest are editorial.
fantasai: You're happy to review them. After resolving we would
like a CR.
fantasai: Anyone need more time for issue 3?
dbaron: The resolution for issue 3, is it independent of percent
sizing with intrinsic widths?
fantasai: Good question.
astearns: That is one thing that does not have a time slot, that
can be breakout session.
dbaron: I just want to make sure that we're not tying this to
something that isn't compatible with the web.
fantasai: This one I believe is about the intrinsic minimum sizes.
florian: Is it flex specific?
dbaron: No.
florian: If there is a side convo please try to include me.
hober: If the dependency graph includes the percentage issue, then
we should resolve that first.
dbaron: I'm not saying it does, I'm just asking.
fantasai: I'm not sure... yeah I think there is somewhat a
dependency so we should resolve on those together.
fantasai: So issue 1: a11y wording.
Rossen: Do we have text for issue 1?
fantasai: Yes.
<fantasai> Note at the bottom of
https://drafts.csswg.org/css-flexbox-1/#order-accessibility
dauwhe: Are the a11y wg happy with it?
fantasai: Cynthia is, she reported it.
Rossen: I think the wording is exactly how we decided it, we
should be fine. I'll follow up with Cynthia and close the
loop with Richard and the rest of the WG.
RESOLVED: Issue 1 the text for a11y is accepted.
Box Alignment
=============
Application of justify-content to multicol columns
--------------------------------------------------
fantasai: Tab and I went through the spec and updated the baseline
alignment stuff to the best of our ability.
fantasai: Anyone that's interested please take a look at it.
fantasai: One open issue is whether the justify-content property
applies to column boxes.
fantasai: The other is the default value of overflow.
fantasai: The justify-content property: in grid it justifies the
tracks and in flex it justifies the flex lines.
fantasai: [gives example of how justify-content works]
fantasai: The goal of this spec is to allow alignment to work for
all layout models.
fantasai: Should justify-content apply to the columns or not?
TabAtkins: No - justify-content can't because it applies to one
line of things.
florian: It sounds interesting, but do we have any wiggle room?
fantasai: We can say that the normal value is doing what multicol
already does,
fantasai: for blocks it does nothing for them.
<fantasai> https://drafts.csswg.org/css-align-3/#distribution-block
florian: It sounds interesting to me.
dbaron: It still doesn't make sense to me why it doesn't apply to
block.
TabAtkins: There is only one flow of stuff, so you can't justify
its items - you can justify self.
fantasai: If you think in terms of flex, block is like having one
flex line.
fantasai: There is no line in a block.
dbaron: I was confusing justify-content and justify-items.
jensimmons: If you specify the width of the col at 200, if we
change this would you be able to do this and add the
power to keep it at 200 and distribute from that fixed
size?
fantasai: Yes, this adds power to multi-col.
florian: We cover step sizing a little bit later.
dauwhe: This makes sense.
TabAtkins: The mechanics are all there, this just allows you to
control those gaps.
RESOLVED: Add justify-content to multicol
florian: Now we have column rules in the middle of column gaps
TabAtkins: just like grid the things on the side are not gaps
default overflow-alignment value
--------------------------------
<fantasai> https://drafts.csswg.org/css-align-3/#overflow-values
fantasai: The next issue is the initial handling of
overflow-alignment.
fantasai: We have safe and unsafe keywords, e.g. with 'unsafe'
if you say center it will absolutely center it even
if that causes it to overflow both sides, so the 'safe'
keyword restricts overflow to the end side.
fantasai: But a lot of times what you really want is true
centering, except you want to keep it inside of the
scrollable region.
fantasai: The user wants to be able to see the content and they
should be able to get to the content.
fantasai: The initial behavior we're proposing is to do the unsafe
behavior up until you would overflow the unscrollable
container and then switch to the safe behavior.
dbaron: That is very expensive on the layout engine.
dbaron: I would prefer for people to have to ask for the slow path.
fantasai: The people that need this won't know they'll need to
change this. So it won't be useful as a default.
fantasai: Only if you have overflow do you need to re-layout this.
dbaron: I don't buy that there isn't overflow the majority of cases.
dbaron: We can't change the default for block.
fantasai: Block already does safe alignment.
fantasai: This is all new stuff.
fantasai: The only legacy is flex box.
fantasai: Once this spec is implemented it will apply to
everything and will only work if you set the alignment
keywords.
esprehn: I want to talk about the feature.
esprehn: Someone showed a layout where the content is
inaccessible, we need to solve it.
dbaron: I prefer safe rather than true for that reason.
esprehn: The example we had was a video in an iframe and the top
was cut off and you could only scroll down.
dbaron: A lot of layout issues deal with how a parent deals with
its children.
Rossen: Once you start nesting you're going to have very bad
performance.
Rossen: This sounds like a weird position: sticky-ish.
TabAtkins: This is still scrollable and only goes back if you
overflow out of your scrollable bounds.
dbaron: I agree with Rossen.
Rossen: The benefit of sticky, you can keep it on the compositor
and not re-layout.
shans: This is about the negative bounds, not the scrollable region.
Rossen: This is how I understood it, if you begin layout and you
center align some items you start overflowing you have to
redo layout to fix it.
shans: On resize you re-layout anyways.
fantasai: [draws a diagram]
fantasai: [explains drawing]
fantasai: This is all about the scrollable region, when the
shifting occurs and it's outside the scrollable bounds
this will change the box's alignment position to allow the
content to be visible.
fantasai: If you have a box that is a flexbox and it has a flex
item that will have an item that goes into the
unscrollable area then you flag it.
fantasai: This only triggers when you have overflow in the
scrollable direction.
florian: Is this a third value?
florian: Yes it's a third value.
TabAtkins: It's kinda safe.
zcorpan: You want this to happen in any direction right?
fantasai: Yes.
dholbert: This will affect any container with any alignment props
set.
fantasai: I think you could probably optimize this mostly away.
dbaron: I think in theory that's fine, but it will take 10 years
to find all the bugs.
fantasai: We would like to put it in the spec and put it at risk,
we don't expect it to be implemented soon.
fantasai: Our content dependency is with flexbox.
fantasai: The change in behavior may look a little bit worse on
some pages, but for pages (like esprehn's example)
where users can't scroll to see the content, this will
fix those pages.
bradk: Why not just make it so that you can scroll to the content?
TabAtkins: That's the idea.
hober: I don't want an infinite scrollbar because someone
positioned something way out on the left for cargo cult
a11y reasons.
dbaron: What UI do you do when the scrollbar position is somewhere
random in the middle?
bradk: In a non-perfect world it seems like a good solution.
dbaron: I looked into implementing it about 10 years ago and
realized that it was too much of a compat risk.
zcorpan: It would need to be opt in.
TabAtkins: People use negative margins to hide stuff off the start
edge of the document.
fantasai: Any other comments?
dholbert: Maybe an idea to work out later, but relpos/abspos would
need to be taken into account.
Rossen: The point is you should not start in a positive, safe will
take you to the origin of that box, we don't want to move
content.
fantasai: We'll make you less unsafe until you're safe.
florian: If you make this the default and at risk, please be clear
in the spec what to do if you're not willing to implement
this.
TabAtkins: We still need a name.
Rossen: un-safe-ish
Rossen: scrollport
fantasai: Does that sound like a reasonable plan?
TabAtkins: Default to unsafe and put it at risk.
dbaron: What happens to flex?
fantasai: It will cause a behavior change where items are aligned
such that they are not fully within the scrollable area.
fantasai: This will probably fix more pages than it breaks.
dbaron: I'm not sure I buy that.
fantasai: But it only affects things that are aligning items into
unscrollable regions.
esprehn: Every time we change flex, we get yelled at - let's
change and see how loud the yell is.
hober: Also put a note that if you change and get yelled at let us
know.
RESOLVED: Put it into the spec, put at risk with a note saying to
contact specs if you hear from authors regarding compat.
<dholbert> fantasai/tab: we'd need to also be sure this
"scrollsafe" alignment thing would interact nicely with
layout containment
<dholbert> In particular, layout containment probably needs to
block aligned things from finding their nearest
scrollable ancestor
<dholbert> (for the purposes of this keyword)
* fantasai likes the name scrollsafe :)
fantasai: We'll publish next week.
fantasai: Probably.
dbaron: How much do we need to add to custom layout to make that
work in Houdini?
Rossen: Not much I think, you would need to add the origin and
it's nearest ancestor.
Rossen: You're always avoiding the origin for scrolling purposes.
iank: I'm trying to catch up
dbaron: I think if the nearest scroller is in another writing mode.
Rossen: It still has an origin.
dbaron: OK, you're right.
Rossen: It's implementable.
Rossen: Now that I understand it, it's not that scary.
<iank> This seems fine for Houdini at a first glance, in your
constraintspace at the moment you know at which point
you'll trigger a scroll, and can adjust off that; but I'd
have to have a little more of a think.
Grid
====
<fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20150917
abspos items in degenerative grids (Issue 3)
--------------------------------------------
TabAtkins: We have a couple things that we need approval first.
TabAtkins: Abspos items in degenerative grids.
TabAtkins: The question here was what to do when you have a grid
with no tracks whatsoever and how to place abspos items
as a result; they care where the grid is.
TabAtkins: There is no grid items, just some abspos and the grid
has one grid line but no tracks, where should this line
be?
TabAtkins: The spec says it's against the start edge in both axis.
astearns: Does anyone have any issues?
astearns: Any objections?
hober: What do the implementations do?
TabAtkins: Don't know.
RESOLVED: Keep the spec the way it is in regards to issue #3
Repeat function with auto-fit and auto-fill keywords (Issue 24)
---------------------------------------------------------------
<fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20150917#issue-24
TabAtkins: The repeat function with auto-fit and auto-fill keywords.
TabAtkins: If you have 1000px to work with and auto-fit with 10
tracks it will adjust accordingly, with auto-fill and
you don't have enough columns it will drop them.
TabAtkins: Which columns should you drop?
TabAtkins: These columns in the middle are not being used, do you
drop them?
TabAtkins: We don't have a strong opinion on this, currently it's
defined at the end.
fantasai: We spec it currently based on what's implemented.
jensimmons: Correct me if I'm wrong, I want empty columns in the
middle and they don't want them to go away.
fantasai: No this is for the auto-fill not auto-fit within the
repeat() syntax.
jensimmons: I just want to get what I've defined.
fantasai: We'll do that,
fantasai: But sometimes when you want to center columns and that
contradicts with the amount of columns available, do you
drop the tracks at the end and middle, or just the end.
So we have an 'auto-fit' keyword to allow for that option.
fantasai: Can anyone come up with a use case and behavior that
people prefer?
TabAtkins: Unless anyone has any strong opinion, we'll keep it the
way the spec is.
TabAtkins: Which is to drop all empty tracks.
dholbert: The counterintuitive part is you can have something in
col1 and col10 and then remove all the empty ones when
you wanted them apart.
RESOLVED: Keep spec as is in regards to issue #24
Missing 'auto' changes for span>1 (Issue 39)
--------------------------------------------
<fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20150917#issue-39
TabAtkins: The counterintuitive part is why you would ask for auto
generated rows and then explicitly set them into cols.
fantasai: We need very competent people to take a look at this one.
astearns: Anyone?
TabAtkins: We think the spec is correct, but we would like for
someone to take a look.
Rossen was voluntold.
ACTION Rossen to review issue 39 of the grid spec
<trackbot> Created ACTION-768
Subgrid
-------
TabAtkins: The previous position on subgrid was complex so we
removed it. That said, there are use cases that can't
be done in current grid.
TabAtkins: So we've put together a much simpler proposal that
covers the majority of use cases.
<fantasai> http://meyerweb.com/eric/thoughts/2016/01/15/subgrids-considered-essential/
fantasai: Here's the feedback we got on subgrid:
<fantasai> http://blogs.igalia.com/mrego/2016/02/12/subgrids-thinking-out-loud/
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jan/0141.html
<jensimmons> Rachel Andrew on subgrid, her response:
https://rachelandrew.co.uk/archives/2016/04/25/a-revised-subgrid-specification/
fantasai: What are the things we need to address and how simple
can we get it?
fantasai: There were things we could get rid of, e.g. the subgrid
auto sizing itself based on its contents.
fantasai: So now you can't have any overflow tracks in the subgrid.
fantasai: You can have overflowing content however (due to sizing),
so they are still scrollable.
fantasai: It won't affect the sizing of the parent grid however.
<fantasai> Current proposal -
https://lists.w3.org/Archives/Public/www-style/2016Apr/0254.html
TabAtkins: [shows example of the subgrid]
TabAtkins: You declare an item to be a subgrid by giving it
display: subgrid
TabAtkins: This makes it a grid container but grid-template-
columns/rows do nothing on it.
TabAtkins: The children on the subgrid position themselves on the
parent's grid.
TabAtkins: The subgrid still lays out.
TabAtkins: The margin/padding/border they get applied accordingly
magically to apply the declared amount.
florian: I assume this does the right thing no matter the writing
mode?
TabAtkins: Yes.
TabAtkins: It works the same way in nested subgrids.
TabAtkins: You cannot get implicit tracks from the subgrid.
florian: Can you use display: contents?
TabAtkins: Sure, if you don't need a wrapper at all, then use
display: contents.
TabAtkins: You can't set grid gaps on a subgrid.
florian: Anyone implementing grid not implementing
display: contents?
TabAtkins: We plan to, but will take awhile because we need to
refactor a lot of code. FF has an implementation of it,
webkit has a prototype I think.
florian: I'll write a blog post,
florian: to convince everyone to implement display: contents.
TabAtkins: That's the proposal.
TabAtkins: Does the WG feel this is a good direction to with?
TabAtkins: Overflow still applies.
astearns: You were going to go over the single dimension case that
this doesn't support.
TabAtkins: Right.
TabAtkins: Let's say you have a subgrid and your parent is 2x2
square but you don't care about the rows of the
parent's grid,
TabAtkins: and you don't know how many rows itself will have.
TabAtkins: This particular case is easy to hit with HEADER,
CONTENT, FOOTER and then you want to fill in the
content with your catalog items.
TabAtkins: However, this makes it very complicated to handle.
TabAtkins: The case is relatively small, and you can use a nested
grid to allow for this so long as track sizes are not
intrinsic.
TabAtkins: If people demand a lot of this we may try to address it
in the future.
Rossen: By current subgrid proposal, this is not possible?
TabAtkins: Yes, it can't work.
Rossen: Good, I think this keeps it quite simple and keeps the
mental model of the grid intact and symmetric.
florian: Have you heard from the authors?
fantasai: Yeah, I think this addresses the majority of the issues.
Wanting to interweave the subgrid lines with the
parents lines is very hard, and is not covered here.
fantasai: There is an issue we marked, subgrid only takes affect
if it is a grid item and the grid-template properties
are set.
fantasai: This gives us an extension point that allows us to use
subgrid to ensure that the grid properties are set to
none which they don't affect and later may affect it in
the future it could break it.
fantasai: The goal of adding the condition is so that the grid
WILL break so that we can improve subgrid later.
astearns: What do you do in this case then?
fantasai: Maybe just treat it as block.
dbaron: You're intentionally making it not work unless things are
set for extension later then you should say so it in the
spec and then also suggest implementations give console
warnings.
dholbert: We risk authors being ok with the "broken" behavior.
florian: There's always a risk of that, but grid is so central to
your layout that I think if it breaks then we won't have
as much compat risk.
astearns: If people do depend on it, we would need to come up with
another way to solve it.
astearns: We basically heard from all implementors saying 'subgrid.
This is crazy.', have thoughts changed?
TabAtkins: Igalia said their opinion on the list,
dholbert: I spoke to Mats, and he feels this is still complex as
you need to keep track of overflow for the items.
fantasai: We would be ok with computing overflow to visible always
if that is a concern.
TabAtkins: Another issue is paint order.
fantasai: I expect authors to be able to control z-index from
within.
dholbert: With that change, it may make it simpler.
fantasai: You won't have to keep track of scrollers, etc
dbaron: z-index also applies to all graphical stuff as well,
masks, transforms, etc.
fantasai: I think everything should just work as normal unless
stated otherwise.
dbaron: This is odd that it's basically an element that doesn't
have a box.
dbaron: This is similar to an element that doesn't have a box.
TabAtkins: We're getting more explicit about the box.
dbaron: But does the spec on filters or mask define whether this
applies to elements or boxes, thus would impact a subgrid.
esprehn: I don't think we should have another table row problem
again.
fantasai: I agree, it should get a box and we will on purpose
exclude stuff from it to ease implementer complexity.
dbaron: So it gets a box?
fantasai: Yes.
dbaron: This is well defined how the positioning/margin/border/
padding.
TabAtkins: Yes.
<Rossen> plinss, so you're saying that for layout purposes the
subgrid is considered empty but has a size independent of
its children sizes?
jensimmons: I am an author and feel very strongly that subgrid
should be included with grid, and I'm hoping that this
is simple enough to ship it.
jensimmons: From my experience they're going to be very confused
that they can't align everything to the parent grid.
jensimmons: I'm not sure this will cover all use cases, mainly
because haven't had the time to play with it.
jensimmons: In most cases they're going to be thinking about the
explicit grid, not the implicit grid and I hope that
this is simple enough that vendors will implement this.
fantasai: I think we can resolve that overflow is at risk and say
it computes to visible.
astearns: So an at-risk within the at-risk section.
astearns: Is there anything more people want to add?
RESOLVED: subgrid proposal accepted in the at-risk section
[break=15 minutes]
Received on Tuesday, 24 May 2016 23:36:05 UTC